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.
Post a Comment