The Emergence of a Global Network

Aeons (in information technology speak) ago, Sun Microsystems introduced the "strap line", "The Network is the Computer", and along came a new revolution that changed the way we work. The days of an operating system running on a single machine is over. Thanks to the genius in Tim Berners-Lee, we are moving on to an Internet operating system era. Gone are the days when we write applications (be it EAI, or e-Commerce, or mobile applications) targeting a single platform. Now most applications are written targeting the global web platform.

What has made this change possible?

I would say that TCP/IP has brought a paradigm shift in the way information technology is currently practiced. The advent of IP has changed the way we do things. The past decade has seen a tremendous application of technology in our day to day lives. Thanks to IP, it has enabled Middleware as we see it functioning invisibly on the Internet. It's important to understand the contributions made by IP as far as Middleware is concerned. Middleware abstracts most of the complexities that an underlying de-facto standard technology like TCP/IP comes with. [World Wide Web (WWW) and most Distributed Computing have one thing in common and that is the fact that they are built on IP].

We have many types of Middleware that includes:

• Object Oriented Middleware (COM/CORBA)
• Message Oriented Middleware (MQ-Series)
• Transaction Processing Middleware (Tuxedo, Encina)
• Database Middleware (SQL)
• RPC Middleware (DCE)

Take the example of a simple browser. All that you do is just a click and you get what you asked for, displayed in a rich format. Here you could think of the browser and webserver with protocols like HTML/HTTP being the Middleware that enables the ease with which we access information. A user is not concerned about the way he gets connected to the intergalactic network (As referred to by Orfali et al in their most excelled book - Distributed Object Survival Guide). A developer is not concerned with the way information is transmitted, all he does is works on HTML (I am not a fan of HTML though, I consider it very difficult to work with without an expert tool). Every piece in the WWW infrastructure has a work to do; the web server to serve requests and just that, the browser, to send requests, i.e. a true client server scenario.

Let's focus back to Middleware. What does the world require from a Middleware technology? Primary of concerns will be the reliability of the system in consideration. The technology has to be industrial strength to assure this. The more a technology is used the more reliable it going to get. This is what happens when the technology and the implementation of it evolve. So those that have been in the business for a longer time will have the better advantage. Mainframes (CICS), Message Oriented Middleware (IBM MQ Series) and Unix systems (Tuxedo) are living proof for this.

Next in concern will be the scalability of a system. The system must be able to scale up (vertical) and scale out (horizontal) on demand. When we talk of scaling up a system, we talk of increasing the power by increasing the processing power (more processors) or more memory and things in the league. Scaling out would mean clustering. When the demand increases, we add more boxes to the cluster in an intelligent fashion. Middleware should also support reusability of artifacts. There is always a tug of war between ease of use and performance. Many applications require high performance applications and that would at times mean the ability to touch the metal. However, those systems are not easy to learn, develop on and maintain. On the contrary there exist a lot of systems that demand ease of use, faster development time and easy evolution.

Another of concerns that Middleware is to answer is the need to support multiple platforms. So much for Middleware talk. Lets look at two of those important technologies that have achieved the above said requirements with great panache.


Java - the Internet Enabler

No discussion of the past decade can be complete without adding in the contributions that Java has made. The much touted "Build Once and Run Anywhere" technology has addressed many of our Internet and programming needs. Java Specification was enabled with support for the Internet from its inception. The class files that a compatible Java compiler is testimony for this. A class file offers us portability, introspection as well as network capability.

Another of the interesting specifications that came along with Java was the JDBC specification. JDBC can be though of as an abstraction over SQL interfaces. Java can interface with the various databases in the market, which till now was not possible. All that it required was the vendor implement the JDBC specification and offer a special driver that confirmed to it. ODBC did exist; however, it did not answer the needs of many important platforms. JDBC played an important role in Java's acceptance as a serious server side alternative to C++. The Java juggernaught rolled on.

The first attempt to explicitly tie Java to the Internet was the Java Applet technology. The ability to download code from the Internet answered some of the needs of a programming model that WWW lacked. However, applets were not true mobile code (mobile agents) and had minimal support to for a true web programming model. They had minimal interaction capability and were restricted by the security model that Java offered. So, it was more or less a failure, so to say.

However, Java did not stop there. They offered a better programming model, but this time, completely on the server side. Thus Servlet and JSP technology was born. No code downloading and security issues, everything will be take care of at the server side, only plain HTML code would be the outcome, but this time they were customized HTML code. Servlets/JSP still lived in a very complex world and did not answer the needs a heterogeneous world. The persistent tier problem was solved with the help of JDBC. Well, what about those legacy systems that existed? So there was this need to enable Java in a heterogeneous world. Efforts like JNI did not answer this. We shall in a short while see a very interesting picture of how Java solved this.

There was a strong need for Java to be made Enterprise ready. So Sun gave another set of specifications that is now synonymous with the Enterprise world - J2EE Specification. It includes not just Servlets and JSP, but more. Let's take a good look at it. The most famous of them all is the server side component model that Sun designed for Java, Enterprise Java Beans.

Enterprise JavaBeans servers reduce the complexity of developing applications by providing automatic support for Middleware services such as transactions, security, database connectivity, and more. Others like Java Messaging Service looks at providing Java with Messaging capabilities. JTS/JTA is the CORBA OTS specification in Java. J2EE Connector and CORBA specifications for legacy application integration. JDBC 3.0 for superior database Middleware capabilities. What world is complete with out XML? XML is now tightly integrated into the J2EE specification. And finally the JNDI specification for naming and directory services.

Distributed Computing with CORBA

As for Distributed Computing, it caters to the need of a few, though it was intended for public consumption, it never grew out of the private Intranets that it dominated. What constrained Distributed Computing? Was it because of the complexity, or was it the fact that it was more static? Or was it because only a few got to know it and use it? I would say, all of the above mentioned facts were true about Distributed Computing. Lets understand what Distributed Computing offers us, its advantages and its disadvantages.

Of late, particularly five years before, Distributed Computing has been driven by the object-oriented paradigm (CORBA was there in existence from 1991onwards, however the interfaces were implemented in C). The Object Model that many Distributed Computing models provide us is powerful enough to accommodate the needs of a heterogeneous infrastructure, like, encapsulating the various operating systems, databases and mission critical systems that need a uniform interface to interoperable. The abstraction that most Distributed Computing provide us is very much in line with the way we program in a normal programming language, the only place where emphasis is to be added is, when we expect special services like naming, asynchronous messaging, transaction, persistence or security. In recent years, this trend also has changed a lot, with the advent of attribute based programming.

CORBA (Common Object Request Broker) is a good example. CORBA is one of the elements of the OMA (Object Management Architecture) that was built from the beginning to accommodate a true distributed world. In fact it's the glue that you see in the picture. CORBA abstracted away heterogeneous languages behind IDL (Interface Definition Language). All that was offered was an interface to a CORBA object that lived in a CORBA world. As for the network, the interoperability was enabled with the help of IIOP (Internet Inter ORB Protocol), which now is the best interoperability protocol in existence, acknowledged by all the major players in the area. CORBA grew in strength and one very influential factor was it grew out of a consensus.

The services that CORBA offers are impressive. Well, why is it not popular as it was intended to be? CORBA has been used in a static environment and did not offer a usable dynamic programming interface. Also, I must say, firewalls were also responsible for the death of CORBA on the intergalactic network. The reason being that CORBA Servers listen on random ports and a network administrator would only allow a small set of ports like the HTTP/FTP ports to be accessed from the outside. Still there are ways like Iona's Wonderwall or Visibroker Gatekeeper to enable CORBA communication (they are implementation of the Concentrator Pattern). Another minor reason for CORBA not succeeding was it was a pass by reference model and offered limited pass by value semantics. More on this to follow.

Lets go back to the subject of integrating WWW and DC. They have been evolving in different directions and now it's inevitable that they both be married together for the betterment of information technology. Until DC provides a dynamic programming environment, it's not ready for public (Internet) consumption. So, the architects of the present intergalactic network decided on using Java and CORBA for this purpose. Thus started the bumpy ride that Java and CORBA always is accustomed to. The first step was from OMG, which resulted in an IDL to Java mapping. In came a plethora of Java ORBs that would support this specification.

In the mean time, Sun decided to introduce into Java, built in distribution capability that was more natural than CORBA. The outcome of this was RMI. RMI was easy to program, however, it was only possible to communicate between Java Virtual Machines, and as a result was restricted to a pure Java world. Also, it did not have the impressive services that CORBA offered. And neither was it enterprise ready. Sun did not lose time in enabling Java on the server side. They decided on a RMI/IIOP specification that would need IIOP as the transport protocol and RMI as the programmatic interface along side RMI/JRMP that was needed to support existing RMI implementations.

In the mean time, CORBA grew in strength. However, CORBA was from the beginning just a distributed object model. It never did offer the capability of component based programming model. COM is a good example of a component-based programming model. Now, people decided to tie CORBA with the Java Bean component model that Sun decided to introduce to counter the COM market. In the mean time, Sun decided to introduce its own component model for the server side. They called it Enterprise Java Beans. Now, once again, there needed to be interfaces that helped existing CORBA implementations to talk with EJBs. So Sun got into action and defined the EJB to CORBA mapping.

A component model tied to Java was not the perfect solution that OMG had in mind. So, it was time, they also introduced their own component model. OMG stated work on their version of a component model, called CORBA Component Model (CCM). By now, Sun and OMG was very much talking the same language. You can consider CCM to be the super set of EJB with a better component model in the offering. We shall see this in detail as we progress through the session.

The Better WWW

During the last decade the focus was on Distributed Computing other than WWW. There is a great chasm between these two. Distributed Computing was driven in a controlled fashion while the WWW was just the contrary. The one advantage that WWW had was the dynamism it always had. All that it took to evolve a concept offered on the WWW was minimized by the fact that the browser is just a simple interface that carried no logic in it. Presentation, Control and the Model logic were on the server side. However, there are some very major defects with WWW. As stated earlier, It did not offer a programming model and one of the firsts to address this need was CGI. Along side came Coldfusion/ASP/JSP technologies. I know of no powerful programming model that could solve this malady. Unless the browser is enabled with the power to interpret a powerful language, it would still be difficult to enable this. The growing relevance of XML has lead to a change in the way the Internet is programmed. However, its real effectiveness is questionable. A simple programming model like XSL could solve some problems though. However, XML is a structured markup language with no programming constructs. Though you can extend it with a programming construct, it would not be a practical solution. Hence you need tools to aid this phenomenon (evolution of XML into the programming model for the Internet). Since this is an article about Java and CORBA, we do not talk much of this new "silver bullet". We shall see a lot about XML as it applies to Java and CORBA in the coming discussions.

• Inside the IDL to Java Mapping.
• CORBA 2.3 - POA and OBV.
• Java to IDL Mapping.
• EJB, CORBA interoperability specification.
• CCM EJB interoperability specification.
  
  
  References:
• Distributed Object Survival Guide - Orfali et al.
• OMG - CORBA 2.4 Specification.
• Sun Microsystems - J2EE Specification.