Hi Stefan, Somehow, I missed this in the inbox.
On Mon, 2006-04-03 at 19:37, Stefan Tilkov wrote: > You might want to take a look at Systinet's API, which I personally > find pretty neat: > http://www.systinet.com/doc/ssj-65/ssj/sequence_api.html Thanks for the pointer. I agree, from an API-design point of view, it seems pretty well thought out. However (and probably because of my current set of project blinders), I really think the choice of providing transport integration using something like JCA is still a lot better. Yes, there's always the trade-off between what you need to do with the API for a specific specialization vs. what you can do with a fixed API specification, and, depending on how you do it, you're tied to a vendor, you can still generally apply all of this code somewhere that isn't part of the core application sending messages. Of course (and this is where the blinders come in), I'm assuming that you are going to be sending messages in more-or-less the same way to various endpoints. I know this isn't really aligned with the WS-* school of thought, but I think from a practical point of view, these differences probably aren't such that you couldn't describe with a vocabulary like WS-Policy (as is done in SCA-land). It goes back to the overall architectural constraints of the system you're creating. If you're talking about individual Web services talking to each other, then, yes, there's infinite possibilities and reflecting those differences needs to be possible in your services. However, I would strongly argue that these shouldn't be the concern of the service implementation. This stuff should take place between the service that performs function X, and how that function is invoked. To me, this is where the Service Activator pattern [Hohpe et.al.] comes into play. This is especially true in an instance of an SOA, because (as has been described elsewhere) you're really establishing a community that is based around business relationships, contracts, and business processes. In this sort of environment, you're going to have different architectural constraints which allow you to ignore the question "do I need the flexibility to call any Web service implementation on the planet". Therefore, in this environment, I believe that having a standardized (at the architectural level, not necessarily at a standards body level) invocation mechanism for sending and receiving messages is not only possible, but is essential. Once you have this, then you can vary your technology and platform choices independently of changing your service implementation code and therefore reduce your operational risk as well as insulate yourself against inevitable future change. I think this is essentially what Gregg is trying to do by establishing RMI as an interface paradigm. But, as I mentioned, I think that carries with it too much object-oriented baggage, but it is, I think, pursuing a similar goal to what I describe above. I think two important points are relevant to Web services and SOA: 1) It's not about distributed objects, therefore you're at risk of not taking full advantage of the Web services paradigm's capabilities if this is your starting point, and 2) Web services "in the large" should not be confused with SOA. As has been pointed out to me recently, SOA isn't just a set of Web services that interact, it's about a community. I think this is a summary of all of what I had been thinking about SOA previously (trying to ensure a focus and balance of people, process and technology), and I think the "community" handle best describes the environment in which an SOA must exist. This means that you can effectively profile all of the capabilities of WS-* or whatever implementation technology you're using in order to align with the legitimacy [Aldo de Moor] goals of your SOA community. Once you can do this, the complexity of your service implementations can be reduced. Cheers, ast -- Join me in Dubrovnik, Croatia on May 8-10th when I will be speaking at InfoSeCon 2006. For more information, see www.infosecon.org. *************************************************************************************************** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *************************************************************************************************** Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
