HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

Networked Applications Bring Distributed Computing to Life
Never has distributed computing been as commonplace as it is in these days of Web applications or Networked Applications. The requirements on such applications for distributed processing across multiple servers has brought distributed objects into the mainstream.

In the beginning of Java there was the home-grown approach. Certainly, there are plenty who have ventured down the road of establishing a TCP-IP socket from a Java client in order to remote control a related Java process on a server to get remote processing. We were all relieved at how simple the socket management was with this language and how networking was an obvious part of Java's lingua franca.

In the second year of Java we saw a surge on two fronts: Remote Method Invocation (RMI) and Java for CORBA (IONA's OrbixWeb and the Visigenic ORB). Early adopters moved quickly to utilize these infrastructures for n-tier computing and distributed objects, while authors such as Bob Orfali had a veritable field day creating an aura for distributed Java objects. In 1997, if you weren't engaged in IDL, RMI, CORBA, IIOP and Java, you might as well have been living in a cave.

During the spring of 1997, in the midst of the second Java One conference, JavaSoft announced the Enterprise JavaBeans specification plans. The promise was impressive: server side components that could interoperate and be part of a comprehensive enterprise class processing environment (messaging, transactions, persistence, etc.). Of course, a specification is just that - a spec.

By the following Java One conference, several companies formally announced plans to ship EJB implementations. Two of these companies were Weblogic (Tengah) and Progress Software (Apptivity 3.0).

One of the major significances of EJBs is that its design can bring the powerful concept of server, business logic componentry to the masses. Sure, with RMI or CORBA, business logic components could always be achieved by the gurus. But a really great EJB implementation, coupled with tool support, can allow an "average Java Joe" to make use of the organization, design and infrastructure. That is very significant.

Remember what SQL's "SELECT * FROM CUSTOMER" did for the average programmer faced with database query challenges? An EJB implementation, in and of itself, is not enough. The average developer and the developer with serious productivity requirements demand an integrated environment with EJB components, JavaBeans, an event infrastructure and state of the art IDE to put it all together.

As we stand today, EJBs are already receiving criticism for not being "run anywhere, anytime" - the familiar psalm of the Java-critical choir. The complaint is that an EJB from one EJB container cannot instantly be ported to a different EJB container without significant effort. The fact is that every EJB implementation vendor is adding "special sauce" to its product - this is good business practice and it benefits the developer in the long run.

What if All Database Vendors Provided Only Strict SQL Implementation? Even client-side JavaBeans didn't easily move from one design time container (IDE) to another. For example, Sun's own Java Studio produced Beans that were wrapped to provide additional value within Studio, but did not port to other IDEs.

This is not such a big problem, however, the actual Bean part of the wrapped component can always be had by the developer or put forward by the product of the Bean. Also, this lower denominator is very adept at transport. The producer of EJBs or JavaBeans is responsible for putting forward a full-blown "special sauce" component and a plain vanilla specification component, whenever possible.

RMI, CORBA, EJB - the movement toward distributed computing and components is on and it's headed for the masses. In 1999 the average Java Joe developer will definitely be able to create and use Enterprise JavaBeans in the construction of Networked Applications. This is a big step forward for Java as well as the vendors providing solutions to developers.

About The Author
Java George is George Kassabgi, director of developer relations for Progress Software's Apptivity Product Unit. You can e-mail him at [email protected]

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.