Dr. Ted Achacoso has a prescription for the improved health of enterprise distributed systems. Initially trained as a medical doctor, Dr. Achacoso now serves as CTO of GroupServe. GroupServe recently announced a suite of products, built on top of Sun's Jini technology, that aim to help enterprise developers create more adaptable, and therefore more robust, distributed systems.
Bill Venners recently spoke with Dr. Achacoso about the current state and future demands of enterprise software. In this interview, Dr. Achacoso explains why he feels enterprise applications need to be more network-aware, and how Jini can help. He suggests an impedance mismatch exists between the architecture of Web services and the predominately client/server architectures used to implement them. He further discusses how Jini can be leveraged in implementing Web services, and suggests ways in which he believes enterprise developers will need to evolve their thinking in the years to come.
JavaWorld: Could you tell us a bit about yourself and your company?
Dr. Ted Achacoso: I graduated college at 18 and became a medical doctor when I was 22. Post-medically, I trained, researched, and worked in three areas: interventional neuroradiology, which is poking brains; pharmacology and toxicology, which is mixing poisons; and medical informatics, which is computer applications to medical care.
GroupServe initially focused on groupware systems, because my cofounder [D. Wayne Silby] was one of the first people who started a groupware company -- around 1983. He thought that with the advent of the Internet, we could resurrect the groupware idea with faster networks and modems.
I started looking at the problem of why groupware would not scale. At that time there were lots of groupware systems, Lotus being the biggest. But the structure of these groupware systems wouldn't scale beyond the intranet. I wondered why. Looking at the problem, you see highly distributed applications running on top, with a client-server platform on the bottom. There's an impedance mismatch of infrastructures. With that realization, I started building an RMI [Remote Method Invocation]-based platform, which I call the RMI Engine.
The RMI Engine gave us a way to access resources -- like databases, mail servers, file systems, and so forth -- that match the highly distributed application running on top of them.
When Jini came along, I did a comparison. I said well, the RMI Engine is exactly the same architecture as the Jini architecture except that the Jini architecture has some wonderful spontaneous networking capabilities.
It was a quick transition. In about six weeks the modules in the RMI Engine were converted into Jini services. We call this engine JASCascades, which stands for Jini-Enabled Application Services Cascading Server. I chose the term cascading because you could cascade a suite of services in the server when you develop your application.
As the first mission-critical application for JASCascades, we hooked up our GroupPort suite of collaborative services with our billing service, a third-party service spread over three offices. We were able to glue the parent data set between our application and the billing service in less than 90 days. For us, this showcases the power of this kind of computing.
From there we monitored the path of Web services. In September 2000, many Web services announcements were being made. I looked at Web services and said, "Gee, this is a highly decoupled system. You have a service requester, a service provider, and a service broker, and these large companies are trying to provide a platform again based on a client-server and tier system." The lesson I learned from why groupware wouldn't work suddenly came back. We're going to expand to another impedance mismatch here in what supports the Web services.
In nature you repeatedly see systems or infrastructures build things in self-similar fashion. I call this fractal amplification. When I saw Web services, I realized the Jini infrastructure is exactly the self-similar infrastructure I would like to achieve the dynamism I want for a Web service. You amplify a small design -- in this case, the service broker, service requester, and service provider -- in essentially the same pattern used over and over. I could not imagine having to support a highly decoupled system like Web services with a highly coupled system like the client-server systems we have now.
JavaWorld: In general, where do you think Jini fits in the enterprise?
Dr. Achacoso: It's funny that we [as an industry] encourage enterprises to do more business on the Web without saying that as a consequence you will have to do more network programming. Looking at it from an evolutionary perspective, if you look at the enterprise, we started off with reusable code, which were subroutines. Then object-oriented programming came along and we said well OK, reusable objects. A lot of companies produced reusable class libraries. Now we're simply integrating or amplifying that pattern. We're saying now we have reusable applications, and enterprises should recognize that trend -- we are simply amplifying the same routine, the same construct over and over again.
We should be prepared because this is how we are evolving. In enterprises, it's the one step forward, two steps back phenomenon. While they increasingly recognize the benefits of networked computing, the infrastructures supporting their applications are not necessarily forward-looking enough to meet those demands.
That's where Jini comes in; it provides the network awareness you should have to co-evolve with the rest of the business ecosystem. The classic song and dance with Jini is that it provides for these wonderful things inherent in a network like, for example, failure. Networks are not reliable and Jini addresses that kind of problem.
With the advent of network-based computing, you're not only sharing objects and classes now, you're sharing entire applications. The topologies of your network can change rapidly. By the same token, you expect multiple administrators to manage this network. Now that's all nice and wonderful, but if you look at how your company will survive in the future, how do you evolve your applications? How do you offer more services? Because your current systems are now firmly coupled with your data sources and the other company resources, you're thinking of other applications that would need those other resources in your enterprise.
You start thinking, "How do I decouple this?" That's where Jini shines. I think it's a good infrastructure to embrace and extend the strategy of both Microsoft's .Net and Sun's J2EE [Java 2, Enterprise Edition]. You wrap around your current systems a highly decoupled infrastructure like Jini and start a forward-looking plan towards how you'll meet the demands of the highly distributed, highly networked commerce coming up in the next two-to-three years.
JavaWorld: By "reusable applications" I assume you mean what I think of as services. I write a business application, and project the service provided by that app across the network. Then other people writing business applications could use my service. They in turn provide a different service, which they could project across the network for still others to use. And then you just keep going.
Dr. Achacoso: Right. I call them reusable apps because it's more familiar to the public. One of Jini's biggest draws is that it's a service-oriented infrastructure. In fact, as I said in the beginning, the era of object-oriented infrastructures is over. An era of service-oriented infrastructures is now coming.
JavaWorld: What are your thoughts on Jini and Web services?
Dr. Achacoso: Again, my initial thoughts on this were that if you use Jini for Web services, you would not have an impedance mismatch of infrastructure supporting the Web services. Jini parallels the architecture of Web services. This doesn't mean that we abandon our current techniques right away. We want to reach back into the current infrastructures to produce our services. JASCascades provides you with what I call service libraries, the analogy being you are used to programming using class libraries. In a service-oriented world, why don't you program with service libraries instead?
After you have played with the extremely dynamic Jini Lookup, you become spoiled and start cursing at the UDDI registry for being so static. You get used to leasing services and getting handed service proxies, both of which are not in the UDDI design. UDDI is great if you are building a straightforward hotel registration service, and want to use another company's car rental service as part of your app. But if I were the car rental service servicing two hotels, Big Time Hotel with thousands of registrants and potential car renters, and Small Time Hotel, with a very small number of rooms, how can I dynamically allocate and deploy my computational resources appropriately when my car rental service is called by either hotel? Real-world Web service deployments prove messy indeed, requiring a constantly dynamic flow and balance of services. I don't see the current Web services infrastructure handling this anytime soon, and it's best delegated to an infrastructure that can best handle it.
The Rio project at jini.org is an elegant architecture that can handle this type of dynamic messiness that Web services will soon face. Another problem that crops up is dynamically assigning a UI for the called service, based on the nature of the service and the resources of the calling device. The ServiceUI project at jini.org handles this excellently.
JavaWorld: So you're saying that UDDI helps me deploy a traditional Web service that clients access via SOAP, but I can implement that Web service with a Jini service. When someone contacts the URL where I have advertised my Web service to exist, what implements the Web service is a Jini service?
Dr. Achacoso: Yes. It will be a Jini service that's running underneath the hood.
JavaWorld: J2EE aims to help people build business applications. Jini aims to help people deploy services. But business applications are often deployed as services across the network. In J2EE you send your session bean service across the network as an RMI stub. You look it up with JNDI [Java Naming and Directory Interface] and so on. If I were an enterprise developer, I would still want to build business applications. I would be intrigued by the dynamism that Jini allows me in composing new services out of old ones, and in changing things around to adapt to changing topologies or to deal with network failure and so on. But I still would want to know how someone will help me build a business application.
Dr. Achacoso: Again, [Groupware] faces two scenarios when we talk with customers. Number one, do I convert my existing applications to a Jini service? Second, do I build my new Web applications as Jini services? [Groupware] always offers some middle ground.
The developers can continue developing, for example, their business applications as a regular J2EE EJB service, and we tell them that they can design it such that these applications can be deployed as Jini services. It merely grabs the proxy anyway from your Jini lookup. And you're right: The developers want to continue developing their business applications there, but when it comes to service deployment management, Jini seems to be the embracing technology.
When we show them exactly, for example, how JavaSpaces work, that it bypasses the Java Transaction Service and Java Message Service by just using a JavaSpace, the simplicity gets them.
There's an addictive quality to Jini in that when people try it, just once, and it works, they rarely go back. They say I have a thousand and one uses for this. It gives you the perspective of a service dimension, in addition to your current application dimension.
JavaWorld: J2EE provides a simplified programming model people seem to like. The EJB developer doesn't have to worry about threading, security, transactions, or much of anything besides the business logic. But a paper by Jim Waldo and friends -- "A Note on Distributed Computing" -- says you shouldn't hide the fact that there's a network. If you want to build a reliable distributed system on top of the unreliable network, each piece has to deal with the nonzero latency, limited bandwidth, the possibility of failure, and other features of networks. The trouble is, dealing with the network adds complexity to code. And that conflicts with programmers' desire to be shielded from complexity, to just focus on the business logic. You said that the developers need to become more network aware, but I suspect many of them don't want to.
Dr. Achacoso: Enterprise developers have to co-evolve with the business landscape, and the landscape is taking on a highly networked, service-oriented shape. There is no enterprise software in this landscape, only enterprise services. Shielding enterprise developers from the networked service demands of this business environment will only produce maladapted products.