|
|
| Service Oriented Enterprise |
|
|
Friday, February 07, 2003 Automatic Switching Between Coarse and Fine Grained Calls About every two or three weeks I find myself looking at WSIF. I'm usually poking around to see if something is in there or not. My recent pokings were to review the granularity of the calls. I realized that WSIF could be used to abstract the developer from knowing if the call was local or remote, but it didn't help with "granularity modulation". "Granularity Modulation" (a term I just made up 15 seconds ago) deals with the need to dynamically change the granularity of the call based on network latency and serialization requirements. The really cool thing about WSIF is that I can describe an invocation once and not care if it was a JMS call (to China), a SOAP call (to my local server farm) or a local invocation (to my running JVM). It was designed to give you invocation neutrality - one API for all your calling needs. However, it wasn't designed to give you location transparency (which are many of my calling needs). I know, I know - - there is no such thing as true location transparency... right... all the usual problems. Well, there is a path towards location transparency - and, IMHO, invocation neutrality and granularity modulation are the first two steps. Many developers, as a rule of thumb, will design local calls with fine grained access and remote calls with coarse grained access. The thinking here is that with local calls much of the data that is being operated on stays in memory. With remote calls, many times the calls are not stateful and large chunks of information need to be passed across the network (latency & serialization). The key is that they actually designed the interface differently based on the location of the operation. This is what I am trying to fix - I want to design the interface the same way for both. So, the first obvious question is how do you automatically convert between coarse and fine grained calls - clearly there is a mismatch. Yes, I know. But, in fact, in most cases, one may use several fine grained calls to accomplish what a single coarse grained call might execute. If I chose, I could describe my interfaces from both a fine and coarse grained perspective. The mode that was invoked would be based on the location (local or remote) and would be determined at runtime - not design time. Variations on this theme include using the wsdl compiler to spit out both versions for you or having a smarter JVM that is aware of the WSIF binding. This issue should also be observed under our 'coupling microscope'. By making the interface course only or fine only - did we enable loose coupling? Nope. Does the interface design hinder loose coupling? Yes. I want to be able to ask a service (or object) the same set of questions and get the right response. Design time decisions based on location will usually lead to tight coupling or at least, minimize the reusability of the asset. posted by jeff | 4:14 AM Tuesday, February 04, 2003 Web Services Benchmarks Cysive, a consulting company - turned product company has released a whitepaper documenting that, in-deed, native calls are faster than soap calls. Congratulations on this discovery! It only took 34 pages for them to unearth and articulate this finding. http://www.cysive.com/news/2003/2-03-03.htm I think my favorite line in the press release is: "Performance of Conventional Web Services Stack Too Slow for Large Scale Systems & Data" After reading the report, I figured it would be better to not comment on it and just let the readers come to their own judgement. The unfortunate news is that Cysive is only losing about $8 million a quarter and they have about $75 million in the bank. Thus, we have the wonderful opportunity of getting this kind of "insight" for at least another 7 quarters. Thank God for big IPO's. posted by jeff | 10:33 AM Sunday, February 02, 2003 Axis Asynchronous Client API I just ran across an older link that described a proposed API for an asynchronous invocation to Axis: http://marc.theaimsgroup.com/?l=axis-dev&m=103903901501446&q=p4 A few things stood out: 1. It's very JMS. 2. There is no mention in the document about JAXM. 3. Later discussions looked like they were moving along alternative paths... Mr. Snell appears to have already hacked something up: http://marc.theaimsgroup.com/?l=axis-dev&m=103115617505157&w=2 Smart guys, I'm sure they'll nail it. I figure that eventually there will be a JMS api, a JAXM api and a couple more... posted by jeff | 10:31 AM Web Service Directories http://www.xmethods.org http://www.remotemethods.com http://www.salcentral.com posted by jeff | 7:51 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
