Local Interfaces, Local Invocation

SODA is largely about refactoring your component based applications into service based applications. This forces the developer to think loose coupling and reusability.

When I talk with developers about the 'service-ification' of their application the first thing they usually point out is that the performance will stink. They say that all of this serialization and deserialization between services is often unnecessary, wasting computing resources and making the application perform poorly. But I live in tomorrow-land where this problem is resolved by the 'service engine'. And here is how it works:

If one service needs to call another service AND...
1.The two services exist in the same process then...
... perform a regular method call - no serialization/deserialization - no network - all local. Use the heap.
2. The two services exist in different processes but are of the same platform/language then...
... perform the call using the native RPC (RMI, .Net Remoting, etc.)
3. The two services are on different platforms/languages then...
... perform the call using the SOAP over the network.

** You should be able to use ONE invocation model for all three of the aforementioned scenarios

The key is that the actual invocation should look the same regardless of the three situations - syntactically, the three should appear the same. Java attempted to do this with RMI, but this obviously didn't hold true for the Java to .Net call. This dynamic resolution of invocation style has been evolving and to me, it appears as though this is where IBM is starting to go with its WSIF (Web Services Invocation Framework). Here, the invocation is abstracted so that, "developers can work with the same programming model regardless of how the Web service is implemented and accessed." Initially, I thought that WSIF was designed to get around the SOAP vs. REST dispute or to just abstract the developer from the JAX-RPC/JAX-M stuff. But now I believe that the true value of WSIF is in its potential to be used in a SODA model to allow the service engine to automatically adjust to the underlying invocation implementation that performs the best for the situation. Think HotSpot for services.

As we unglue our applications and refactor them into services, we rewrite many of the method invocations as service invocations. If it turns out that you deploy the services on the same box, then the service engine will resolve the service invocation into a method call (performance problem absolved). Did we add extra code? Yes, and it may run a bit slower but in return we gained transparency.

Location transparency - platform transparency - language transparency - invocation model transparency. Bliss.