Build a better mousetrap and the world will build a better mouse. In the beginning we had a two-tiered architecture (I count mainframes as prehistory), and we could figure out how to do things with it. Unfortunately, one of the things we figured out was that we needed more than two tiers. Up came the concept of an application server and a Web server to accompany our ubiquitous database server.
I've had occasion recently to look at a number of currently available application servers. In general I like what I see, but as usual there isn't one single product that fulfills every need, although there should be. That's my opinion of course - but that's what this column is about.
The purpose of an application server is to provide a convenient integration point for business logic, reduce or remove business logic from client applications, minimize network traffic and provide an open interface to the business logic. No server is perfect, but here's my list of minimum features that make up my ideal starting point.
The first place I look is language support. I'm a big supporter of Java, but let's be honest: it's not the only language in use and it never will be. That's not just on the server side either. I know of many shops where Java in a browser is prohibited, and just as many who feel the same about ActiveX controls. The point is that an application server should support several languages and paradigms, from both a component standpoint inside the server and a client standpoint. To me the minimum should include Enterprise JavaBeans, regular Java classes, C/C++ code and ActiveX. I've found many application servers out there that will support Java, but only a relative handful that will support ActiveX. It's a big world, and many companies have ActiveX components or products that can become part of an application. I believe in building best-of-breed solutions, not just best-of-language.
Similarly, the methods provided for accessing the server should be as broad as possible. To my mind CORBA IDL, RMI and COM support need to be present. One vendor I know of goes so far as to support method calls as if they were stored procedures and the application server was in fact a database. In general, supporting CORBA and COM clients allows greater flexibility in client languages and deployment environments, while RMI expands the field further for us Java fanatics.
Transaction services should also be part of the package. Ideally, the server-side developer should be able to concentrate on writing code without worrying about database transactions. This is one area that shows the most variation. Almost all servers have some transaction support, but some provide their own. Some allow you to hook into existing products or specifications such as Tuxedo, DTC or XA, and some support the JTS standard. I'm on the fence about which is more appropriate. Pretty much any one of these approaches works, so the idea is to insist on some transaction service rather than coding your own. Some servers that support multiple component types don't allow transactions between types (for example, while some servers may use JTS but allow COM components, without some fancy footwork the COM component may not be able to take part in a transaction). If heterogeneous server code is a fact of life for you, make sure your server treats all components equally.
Right up there with transaction management is connection caching. A connection cache allows a small pool of database connections to service a larger number of user connections. For example, a five-user Oracle license might serve 25 clients simultaneously. The idea is that no database connection is used 100% of the time, so the connection cache can multiplex the connection for greater throughput.
Security services and network management are also features to look for. The typical approach is to apply a role to a component. This may not be granular enough if you need to apply security or data member to a particular function rather than at the component level. This is one area where no vendor really provides sufficient functionality. The ability to manage the server remotely, and for the server to participate in network management products such as HP Openview or some other SNMP-compatible product, is also a key point.
Finally, the server should support debugging. If you can't debug running code, your development time goes through the roof. Any vendor who says you can run the code first locally to see how it'll react is snowing you - you need to be able to debug inside the server.
So there's my minimum perfect beast. As soon as someone builds it, I'll let you know (and then I'll come up with a new set of features). If you'd like to help me with this, come visit me at the Java Internet Expo on December 8 in New York City. I'll be there with other members of the JDJ staff to meet with you, answer questions, hobnob with the big shots and (dare I say it) sign autographs. See you there.
About the Author
Sean Rhody is the editor-in-chief of Java Developer's Journal. He is also a senior
consultant with Computer Sciences Corporation where he specializes in application architecture, particularly distributed systems.He can be reached by e-mail at [email protected]