|
|
| Service Oriented Enterprise |
|
|
Saturday, February 01, 2003 Optimistic, Pessimistic and Realistic Invocations It has been stated that one of the primary advantages of web services is loose coupling. I believe that web services have the ability to provide loose coupling, but it is something that must be achieved; it isn't granted. An example of this is in the web service invocation model. Most people are aware that web services fall into the SOA model, thus they have a consumer, producer and directory. The idea is that a consumer will look in a directory to find a producer then use this information to call the producer. This can provide different values such as: - the ability to find competing service providers (trading partner style) - the ability to find multiple, redundant services (same service, different boxes) - the ability to abstract the caller from backward compatible revisions in the service (such as a change in physical location of the service provider) It is this last example where most people start shouting that web services enable loose coupling. Yet, what I have found after reviewing sample web service code is that most people don't actually design their software to take advantage of this feature. I've created a few terms that should help articulate the point: Optimistic Invocation Most of the sample source that I have seen does "optimistic invocation". That is, the client makes the assumption that it already knows where the service provider is (surely nothing will ever change in the production environment...) Thus, you see code like this (excuse my pseudo): Proxy MyProxy = new Proxy ("http://www.HardCodedLocation.com/myservice/"); MyProxy.invoke(someOperation, blah blah blah); Here, the programmer is an optimist. They assume to know where the service is located and call it. This is quick (no directory lookup) and simple (no directory lookup). Pessimistic Invocation Another method of calling some service is to assume that we know nothing.. Directory MyDirectory = new Directory(); Proxy MyProxy = new Proxy(); MyProxy = MyDirectory.lookup("some service description..." MyProxy.invoke(someOperation, blah blah blah); Here, the programmer checks the directory before each call... making sure that the client has the latest information on service providers. This adds a few lines of code and increases the processing time by adding a directory lookup to each call. Realistic Invocation The Realistic Invocation model is designed to find a happy medium between 'optimistic' and 'pessimistic". The idea is to start out optimistic and if it doesn't work to fail over to pessimistic: Proxy MyProxy = new Proxy ("http://www.HardCodedLocation.com/myservice/"); try { // give the optimistic way a try... MyProxy.invoke(someOperation, blah blah blah); } catch (Exception e) { // if optimistic failed, switch to pessimistic Directory MyDirectory = new Directory(); Proxy MyProxy = new Proxy(); MyProxy = MyDirectory.lookup("some service description..." MyProxy.invoke(someOperation, blah blah blah); } Wow... 'Realistic Invocation' just turned into a whole bunch of code. Well, that should be easy enough to fix. You can either turn this model into a helper function or apply an aspect across the service calls. The real point is that optimistic invocation doesn't help much with loose coupling... pessimistic invocation usually isn't realistic from a performance standpoint, thus using a realistic model (with helper functions) gives you a simple, effective method of doing distributed calls while preserving the loosely coupled model. posted by jeff | 6:04 AM Monday, January 27, 2003 XML Pipeline Definition Language In February of 2002, Sun Microsystems submitted their XML Pipeline Definition Language to the W3C. See http://www.w3.org/TR/xml-pipeline/ I took the time to read the specification because I am interested in alternative ways to create composite web services. I found this spec hard to read - in a Sun kind-of-way, but here are some thoughts: - XML PDL goes beyond web services, it is about processing xml documents in a pipeline manner, thus it may have significant relevance outside of the web service world. - XML PDL uses a declarative approach to defining inputs and output. It makes the assumption that if I produce X and you consume X, then the producer will automatically feed the consumer. There is no need to write the actual web service call - it is implied. If multiple participants could produce X or consume X, it cries foul - and declares it an error. This is rather odd, but will work when you define a well scoped process that the pipeline works within. - XML PDL is expressed in XML and can be implemented in your favorite language (C, C++, Java, etc.) All in all, I gotta pass on this one as a real player in the web services world. Although, I do see the need to steal some of the concepts. I liked the concept of creating a 'pipeline scope' and performing implicit invocations. Now, this won't work in many environments, but I do see it being valuable in ad-hoc scripting environments, but with this said, you don't want to do ad-hoc scripts in an xml dialect IMHO. If XML PDL finds a home, it will likely be found behind the scenes in environments like web service platforms and web service scripting language implementations. posted by jeff | 6:00 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
