The diagram at right is designed to provide an agent remote access to agency software using a Web browser or wireless device. The agency system will be characterized as the middleware and can be thought of as a Web services container. The middle tier can also be accessed using platform-specific, rich-client software. The agency system will provide connectivity to both local and remote databases and the carrier mainframe.

Presentation

Any universally distributed application must operate with all standard Web browsers. As a practical matter that means most shops code to Microsofts Internet Explorer (IE) and then test on Netscape Navigator. At National Underwriter, we generally try to limit what we serve up to HTML and a little JavaScript. Every time we step outside of those bounds, we end up with problems. It is interesting we have had more trouble with Java on Netscape than IE. One of our products uses a little Java client-side application to draw a table of contents. It works fine with medium security settings on IE but refused to load properly on Netscape Navigator 5.X. My point is that no one is going to try to get too fancy with anything on the thin-client presentation layer. .NET will use ASP.NET (the .NET version of ASP) to serve up dynamic HTML. The ASP.NET framework requires Windows 2000 server and Microsofts Internet Information Server (IIS). J2EE operations will use JSP (Java Server Pages) and servlets to generate HTML. These will run on a number of server platforms, including IBMs WebSphere and BEAs WebLogic servers.

^{Rich-client applications do not need to adhere to restrictions of interoperability. Both J2EE and .NET provide a full boat of tools to build rich-platform-specific applications. Traditional Windows APIs using COM and ActiveX controls are available as well as new .NET managed components. Virtually everything that can be done using C++ and the Windows API can be accomplished using the .NET development environment with C#, VB.NET, or other managed libraries. Java applications can make full use of the Java suite of tools, including servlets and beans using Java Remote Method Invocation (JRMI) technology run over Internet Inter-Orb Protocol (IIOP). Its interesting that one of the criticisms of J2EE is it is not a mature technology . . . rightthese things have been around for a long time.}

Middleware

The middle tier is where all the Web services components live and work. Lets just call this tier the Web services container. Its a vessel in which the appropriate virtual machine runs. For .NET, this is the Common Language Runtime (CLR) and the associated class libraries. In the J2EE world, the Java Runtime Environment (also known as the Java Runtime or JRE) consists of the Java virtual machine, the Java platform core classes, and supporting files. Components for J2EE are EJBs (Enterprise JavaBeans), which are server-side components for the development and deployment of distributed object systems for the Java platform. Simply put, they are objects that expose an interface that allows them to be used by software within the JRE. Data access is accomplished using JDBC, which provides a standard API that can be used regardless of what database is being accessed. JDBC is supported by a large set of JDBC drivers and database-dependent modules that provide connectivity to a large number of databases.

The .NET equivalent of EJBs are managed .NET components and assemblies. At this point, all .NET components will be built using the Microsoft Visual Studio .NET. I know there are some free compiler tools, and Notepad is an excellent programming tool. Fine, but I have become rather fond of the development tool figuring out what I really mean. From the programmers point of view, there is little difference between a .NET component and traditional COM+ component. The real difference is in the architecturespecifically, the Common Language Runtime. Database connectivity is accomplished via ADO.NET, which is an extension or improvement to Microsoft ActiveX Data Objects (ADO) that provides platform interoperability and scalable data access. Using eXtensible Markup Language (XML), ADO.NET is likewise designed to interoperate with a number of databases.

Connectivity

If we look at our hypothetical system, there is really only one place where the new Web services paradigm really comes into playthe XML over HTTP connection between the middleware and the company system. In the real world, we would have another Web services container at the company level. That container would give access to the mainframe as well as exposing a Web services interface that provides a hook for the middleware.

Both Microsoft and Sun had proprietary connectivity tools (IIOP, JNDI, DCOM, etc.) before the world became interested in Web services. I suspect most enterprise systems will continue to use these proven systems. What is interesting here, however, is true Web services connectivity. That means XML Web service technologies, such as SOAP, UUDI, WSDL, and ebXML. The Java APIs for XML (JAX) provide access to these technologies. Microsoft Web services also provide direct support for XML for HTTP. Most of these XML technologies were discussed last month. ebXML (Electronic Business using eXtensible Markup Language), sponsored by UN/CEFACT and OASIS, is a modular suite of specifications designed to enable business over the Internet.

Runtime

Java has gotten a lot of mileage out of the write once, run anywhere paradigm. Now we all know it is a little more complicated than that. When the concept of having to load a runtime environment on top of an operating system just to get an application to run was introduced, I was appalled. It seemed like a horribly inefficient thunk just to achieve cross-platform independence. I was just as disenchanted with the old Microsoft VB runtime as I was with the Java virtual machine. After all, real programmers (read C/C++ programmers) wrote directly to the operating system, the API, or the machine. Nevertheless, VMs are here to stay. Machines are faster and more efficient as are operating systems, and virtual machines seem less a burden than they used to.

In the Java world developers write source code in Java, which is compiled into bytecode. Bytecode is the cross-platform intermediary, halfway between source code and machine language. At runtime, the JRE interprets this bytecode, drops it down to machine level, and executes it.

Microsoft has added an additional layer of complexity because it wants the ability to code to its runtime using a variety of programming language. .NET developers write source code that is translated into Microsoft Intermediate Language (MSIL). The intermediate language code is language neutral and is analogous to Java bytecode. At runtime the IL is interpreted and translated into native machine executable code via the Microsoft CLR. So CLR = JRE, Java bytecode = MSIL. I know thats a gross oversimplification, but I only have two pages here.

So, What Next?

Are we going to redesign all of our systems to enable Web services? Probably not. This really is an evolutionary thing. Microsoft has gone to the Java model with a runtime environment. Sun has extended its specifications to include more XML interoperability. No big deal. As we go forward, we will undoubtedly make use of a lot of the cool new features available. Microsoft shops get a lot of functionality through the normal upgrade process. Java shops have a wealth of different vendors providing J2EE application servers and pre-built components. Let us all use this new technology wiselyand let us resist the urge to go with a particular solution for the wrong reasons.