|
|
| Service Oriented Enterprise |
|
|
Saturday, December 21, 2002 Web Service Presentations I just ran across a good powerpoint: http://www.almaden.ibm.com/u/mohan/WebServices_TES2002_Slides.pdf posted by jeff | 3:55 PM WS-Duopoly WS-Duopoly is an alias for the stronghold that IBM and Microsoft have on Web Service specifications. Many view this "arrangement" as a good thing; Microsoft and IBM have been fast tracking web service standards in order to reinvigorate I.T. spending. Others view it as a duopoly trying to crush second tier players. posted by jeff | 3:08 PM SOAP Router Homogeneity After reading the ws-routing specification, it appears to me that people will interpret the composition of a SOAP Router in very different ways. The specification requires the implementations to conform to a minimal amount but also encourages alternative uses. Additional functionality that may be included in a SOAP Router that are beyond the ws-routing scope include: message filtering, message transformations, content based routing, load balancing, response-message caching and others. Actually, the inverse is more likely to happen: participants in an SOA will incorporate routing functionality (e.g. SOAP Load Balancers will incorporate routing functionality, etc.) The 'good side' of this is that people will create new servers (like content based routers) that are single-purpose utilities and leverage the basic infrastructure of the ws-routing specification. The ability to drop routing functionality into the server facilitates the pipeline service pattern. This, in my humble opinion, is where the magic of a service oriented architecture is created. There are a few potential downsides to not having an actual specification for a SOAP Router. One is that many of the functions that a router can perform are very dissimilar (domain routing vs. content routing). By keeping a server homogenous, you are able to more accurately predict the response to changes in the router settings (e.g. routing logic based on complicated algorithms, etc.) Also, from a marketplace perspective, it is hard to comparison shop for a 'SOAP Router' when the functionality can swing so drastically - although, one could argue that this is what slow down product commoditization. Either way, when vendors begin releasing SOAP Routers, it may be worth asking, "So, what exactly does your router do?" And perhaps one day, the WS-I or another organization (the ws-duopoly) will create a SOAP Router Profile. posted by jeff | 2:44 PM UDDI and the SOAP Router WS-Routing describes a way where you can send a message from point A to point B with *minimal* concern for the path that was taken. It has occurred to me that the entries in a public or private UDDI server *should* point to the SOAP router. Thus, UDDI is responsible for all the usual stuff (aggregating service descriptions, providing 'publish' and 'find' syntax, etc.) but it is not responsible for identify the actual address of the service provider, rather it is responsible for providing the address for a SOAP Router that is aware of one or more applicable service providers. *minimal* - You still specify a 'from', 'to' and potentially a 'via' in the route description - thus, address based routing. posted by jeff | 2:25 PM Friday, December 20, 2002 Message Correlation So, I have been trying to figure out how asynchronous, reliable messaging in web services will occur at the wire level (not api). This seems like an easy enough task, however my small brain has been in overdrive trying to crack the nut. Part of the problem seems to be the ambiguous use of the term 'message correlation' throughout the various specs. I'm now of the opinion that at least three levels of message correlation exist: Correlation at the Business Process / Web Service Orchestration Level Imagine a WSO engine is running a single orchestration script, however there are 50 instances of this 'process' in play. A WSO engine must be able to take an in-bound message and correlate it to the proper instance of the process. An example of this is described in the BPEL4WS script titled, "Message Correlation". Correlation at the SOAP Router Level In a service network, documents are passed across enterprises. Company A shouldn't care about the physical location of where Service X is running inside of Company B. This abstraction takes place in the SOAP router. It magically gets a SOAP document to the right place by using internal routing tables and acts as a proxy between domains. So, a service network will send a document from A to B and potentially use multiple go-betweens (aka, intermediaries, SOAP routers, etc.) as the transportation vehicle. Along the way (or at the end) a fault may occur. If this happens, the service network must be able to backtrack and send the fault code back to the originator. This means that it must tell each Router that, "I am message #968, please pass on that I failed." In this context, message correlation is used by an intermediary to *dynamically or statically* create a reverse path for the purpose of fault notification. Correlation at the SOAP Server Level If SOAP Server (A) sends SOAP Server (B) a message (M1) in an asynchronous fashion, it may want a response (M2) back (e.g. an answer to a request). When (B) sends (M2) (the response) to (A), (A) must be able to determine that (M2) correlates (is the response) to (M1). It appears as thought this type of message correlation also is taken care of by ws-routing (although I'm not sure). Unlike many network protocols, a service network must be able to send asynchronous, bi-directional & correlated, reliable messages without utilizing a virtual circuit. The downside of this is that it means that any initiator or receiver must be able to sniff the routing path to determine where to send the message back. This seems to violate the distincition between SOAP routing and SOAP serving, but it appears as though it is a necessary evil. Thus, the reverse message path in ws-routing not only sends fault information but also provides the necessary information for a SOAP server to send an 'application-level reply' back to the initiator. * Note that SOAP 1.2 clearly states that 'message correlation' is out of scope for SOAP. ** One other item of interest is that "retransmission" information is NOT sent in the ws-routing information. In theory, you would need this to increase reliability. One could guess that this was intentionally left out and in the ws-* fashion, reliability will become its own spec (think ws-reliability or ws-sla). posted by jeff | 7:45 AM WS-* Roadmaps Overall, I have been impressed with the detail of the ws-* specifications. In general, they are detailed, consistent in terminology and provide some level of examples. However, the overarching document seems to be missing. This would be the specification that puts all of the specs into a single context. Now W3C has an architecture document that is coming together nicely, however it addresses the architecture at more of a conceptual level. The IBM/MS duo are in need of a ws-* roadmap. It would show how the pieces connect to each other, define the common glossary, spell out what is done today, identify what is out of scope, etc. Now, I know that 25 different people have all made best-effort stabs at these maps - but we need an official one from the source. The ws-security team actually did a nice job of putting together their local roadmap. posted by jeff | 7:32 AM Tuesday, December 17, 2002 What's in a SOAP Router? SOAP Router = Message correlation service + Message forwarding (proxy, alternate path routing) + Transport protocol swapping (tunneling) + Router configuration (think telnet kind of stuff) + Durable queues for store & forward + Invoke service (when there is no "to" element) + Activity logging + Regular SOAP server stuff including security posted by jeff | 11:23 PM An Asynchronous Landing... It's late... I've read too much on asynchronous reliable messaging with SOAP. So, here is where I've landed: 1. People are going to use HTTP for everything on the outside of the firewall 2. You can break 1 synchronous call into 2 asynchronous call as long as you have a message correlator. 3. It looks like WS-Routing will provide wire syntax for correlation - thank you MS for an early impl, too. posted by jeff | 10:56 PM Terminology: "Orchestration" and "Choreography" I found an interesting email thread on some terminology that I thought I'd share. From: "Sanjiva Weerawarana" To: Date: Wed, 14 Aug 2002 14:18:35 +0600 Subject: Re: "Orchestration" and "Choreography" I'm not sure whether there's such a clear distinction between the terms. During the lifetime of the BPEL4WS document, it was at one point called WS-Orchestration, then WS-Choreography, then WS-Business Process and and eventually BPEL4WS. I can tell you that the name changes had nothing whatsoever to do with technical distinctions between the words .. it was all marketing and, um sometimes, politics ;-). To me orchestration, choreography, business process, workflow are all ways of indicating how to take a bunch of things and put them together to do something meaningful. We also use the term composition for the same thing .. BPEL4WS is a language for composing a set of Web services into another service. The thing that makes it a workflow language is that the composition primitives chosen are those that are well-known in the workflow domain. Edwin's distinction seems to be the difference between what WSFL called global models vs. flow models. I think that distinction is definitely valid (BPEL4WS doesn't yet handle global models, for example), but I don't think the terms choreography and orchestration distinguish between those two. Coordination is different IMO; that's really distributed synchronization (rendezvous). Hope this helps, Sanjiva ---- Later, I found this email which goes into some working definitions that the w3-arch group considered. posted by jeff | 6:12 PM Monday, December 16, 2002 JMS as an Asynchronous, Reliable, Message Passing Vehicle I was reading where some people were wanting to use JMS as a vehicle for asynchronous web service communication. This made me go back and re-read the spec. It was as I thought, JMS is a predefined API, but leaves the wire protocol up to the vendor. Thus, the app dev person should be able to swap out JMS providers (vendors), but in all likelyhood, no two vendors calls will work with each other - thus, it isn't an option for B2B reliable messaging (nor was it intended). APP 1 --> JMS API --> [[Proprietary wire protocol]] --> [[Server]] --> [[Proprietary wire protocol]] --> JMS API --> App 2 Nigel Thomas reminds us, "JMS implementations from different vendors are not required to interoperate - details of wire format and transport protocol are left to the provider's discretion. So JMS usage is limited to 'single provider' situations - where the developer controls both producers and consumers. JAXM is designed to support inter-business messaging. Based on Simple Object Access Protocol (SOAP) 1.1 with Attachments, message formats, payloads and transport are standardized so that the other business will be able to receive and understand them. Unlike JMS, JAXM only supports the point-to-point messaging domain - not least because B2B messaging is usually one to one. The high performance, low latency and programmatic flexibility of JMS are traded for simplicity, reliability and interoperability. " Hmm... better go back and read the JAXM spec. From what I remember it was a rather wordy API that didn't actually spell out a SOAP binding. posted by jeff | 7:33 PM Asynchronous, Guaranteed Web Service Protocols Most people seem to agree that web service orchestration will primarily occur through an asynchronous, document based architecture. One should also assume that some level of guarantee is required (the package arrived in whole, the package arrived intact, the content of the package makes sense, etc.) I'm hoping that someone has done a comparsion of potential wire protocols for delivering asynchronous, SOAP messages in an open format. If so, please drop me a note. Compare / contrast the following wire protocols as potential vehichles for delivering asynch. SOAP messages: - BEEP - HTTPR - AWSP - SMTP (or others that I may be missing, for now I'm not interested in vendor specific or platform specific stuff) SOAP 1.1 binding to BEEP: http://www.ietf.org/rfc/rfc3288.txt SOAP 1.2 binding to SMTP: http://www.w3.org/TR/soap12-email Note that the SMTP binding has a field for message correlation. SOAP 1.2 binding to SMTP Illustration: http://www.w3.org/2000/xp/Group/2/02/emailbinding.html AWSP to SOAP (not really a binding...) : http://www.trans-enterprise.com/technology/aws/awsp.html Other: Generic SOAP binding framework (proposal): http://www.w3.org/2000/xp/Group/1/10/12/Binding_Framework_Proposal SOAP binding to HTTP: http://www.w3.org/2000/xp/Group/1/10/11/2001-10-11_Framework_HTTP_Binding posted by jeff | 3:14 PM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
