September 27, 2007
Don’t let the Jini out of the bottle on SOA
I’ve been following the development of Jini for quite some time. The idea of mobile code fascinates and frightens me, especially in aspects of security, and I’m not dropping the ‘A’ word for nothing. It is an intriguing technology that I have yet to use on a real project, and now that the guys behind Jini have jumped on the SOA bandwagon I thought I’d take another look. Here’s what the www.jini.org site has to say about services in SOA: A service may be a computation, storage, a communication channel to another user, a software filter, a hardware device, or another user. Two examples of services are printing a document and translating from one word-processor format to some other.
It appears that they are very specific in their definition of a service. A service is, most definitely, some… thing, probably having to do with computers in some way. They have another go at it here as well: In more pedestrian terms, a Jini service is usually code running under some JVM that is capable of being called remotely, by Jini clients or even by other services.
So according to this, one example of SOA is distributed objects. And the purpose of Jini is then:
Jini systems provide mechanisms for service construction, lookup, communication, and use in a distributed system. Examples of services include: devices such as printers, displays, or disks; software such as applications or utilities; information such as databases and files; and users of the system.
In other words, hooking computer related things together without any real restrictions or guidance as to how that should be done. Is that much different from CORBA? Or any of the other generic distribution technologies we’ve seen. Granted, the mobile code thing is different, but nothing about that gets into the SOA discussion.
It also seems to fail on two out of the three dimensions of coupling. They seem to have the spatial coupling down by use of mobile code, but that’s it. In terms of technology coupling, Jini is Java-only – there are some ways to get interoperability with .net and other platforms, but it doesn’t look like Jini set out to handle it. Finally, the issue of temporal coupling isn’t considered an issue – do synchronous calls, asynchronous calls, whatever. Nothing is mentioned in terms of reliable messaging. So, my bottom line on Jini hasn’t changed – mobile code, cool, but I still don’t know what to do with it. As for SOA, Jini seems to have as much to do with SOA as does CORBA. Maybe somebody can do something on top of Jini to make it more relevant to SOA, but as it stands now, I’ll be sticking to my buses – ESBs and such. Posted by Udi Dahan at 07:52 PM Permalink
|
