Last month, this column explored the high-level differencesbetween the two competing Web service methodologies. The conclusionwas that Sun Microsystems J2EE was best defined as a model orstandard for building distributed applications, and Microsofts .NETwas essentially a product suite for accomplishing the same goals.This month, youll see how each of these products could be used tobuild a real-world set of applications.

The hype surrounding J2EE and .NET has reached new heights ofabsurdity. I have read countless white papers and articles writtenby industry experts proving that J2EE is better than .NET,or one or the other is easier to use, less expensive to implement,more secure, or whatever. It seems to me that the ultimate goal ofenterprise computing systems should be interoperability, notone-upmanship. If either J2EE or .NET becomes truly accepted, itwill be because they workand work with other systems.

Back to the Real World

Lets look at how J2EE and .NET could be used to build a realsystem. This system will focus on interoperability. Theres littlevalue in designing systems that are only usable with specialhardware and software requirements.

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

Presentation

Any universally distributed application must operate with allstandard Web browsers. As a practical matter that means most shopscode to Microsofts Internet Explorer (IE) and then test on NetscapeNavigator. At National Underwriter, we generally try to limit whatwe serve up to HTML and a little JavaScript. Every time we stepoutside of those bounds, we end up with problems. It is interestingwe have had more trouble with Java on Netscape than IE. One of ourproducts uses a little Java client-side application to draw a tableof contents. It works fine with medium security settings on IE butrefused to load properly on Netscape Navigator 5.X. My point isthat no one is going to try to get too fancy with anything on thethin-client presentation layer. .NET will use ASP.NET (the .NETversion of ASP) to serve up dynamic HTML. The ASP.NET frameworkrequires Windows 2000 server and Microsofts Internet InformationServer (IIS). J2EE operations will use JSP (Java Server Pages) andservlets to generate HTML. These will run on a number of serverplatforms, including IBMs WebSphere and BEAs WebLogic servers.

^{Rich-client applications do not need to adhere torestrictions of interoperability. Both J2EE and .NET provide a fullboat of tools to build rich-platform-specific applications.Traditional Windows APIs using COM and ActiveX controls areavailable as well as new .NET managed components. Virtuallyeverything that can be done using C++ and the Windows API can beaccomplished using the .NET development environment with C#,VB.NET, or other managed libraries. Java applications can make fulluse of the Java suite of tools, including servlets and beans usingJava Remote Method Invocation (JRMI) technology run over InternetInter-Orb Protocol (IIOP). Its interesting that one of thecriticisms 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 liveand work. Lets just call this tier the Web services container. Itsa vessel in which the appropriate virtual machine runs. For .NET,this is the Common Language Runtime (CLR) and the associated classlibraries. In the J2EE world, the Java Runtime Environment (alsoknown as the Java Runtime or JRE) consists of the Java virtualmachine, the Java platform core classes, and supporting files.Components for J2EE are EJBs (Enterprise JavaBeans), which areserver-side components for the development and deployment ofdistributed object systems for the Java platform. Simply put, theyare objects that expose an interface that allows them to be used bysoftware within the JRE. Data access is accomplished using JDBC,which provides a standard API that can be used regardless of whatdatabase is being accessed. JDBC is supported by a large set ofJDBC drivers and database-dependent modules that provideconnectivity to a large number of databases.

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

Connectivity

If we look at our hypothetical system, there is really only oneplace where the new Web services paradigm really comes into playtheXML over HTTP connection between the middleware and the companysystem. In the real world, we would have another Web servicescontainer at the company level. That container would give access tothe mainframe as well as exposing a Web services interface thatprovides a hook for the middleware.

Both Microsoft and Sun had proprietary connectivity tools (IIOP,JNDI, DCOM, etc.) before the world became interested in Webservices. I suspect most enterprise systems will continue to usethese proven systems. What is interesting here, however, is trueWeb 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 alsoprovide direct support for XML for HTTP. Most of these XMLtechnologies were discussed last month. ebXML (Electronic Businessusing eXtensible Markup Language), sponsored by UN/CEFACT andOASIS, is a modular suite of specifications designed to enablebusiness over the Internet.

Runtime

Java has gotten a lot of mileage out of the write once, runanywhere paradigm. Now we all know it is a little more complicatedthan that. When the concept of having to load a runtime environmenton top of an operating system just to get an application to run wasintroduced, I was appalled. It seemed like a horribly inefficientthunk just to achieve cross-platform independence. I was just asdisenchanted with the old Microsoft VB runtime as I was with theJava virtual machine. After all, real programmers (read C/C++programmers) wrote directly to the operating system, the API, orthe machine. Nevertheless, VMs are here to stay. Machines arefaster and more efficient as are operating systems, and virtualmachines seem less a burden than they used to.

In the Java world developers write source code in Java, which iscompiled into bytecode. Bytecode is the cross-platformintermediary, halfway between source code and machine language. Atruntime, the JRE interprets this bytecode, drops it down to machinelevel, and executes it.

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

So, What Next?

Are we going to redesign all of our systems to enable Webservices? 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 XMLinteroperability. No big deal. As we go forward, we willundoubtedly make use of a lot of the cool new features available.Microsoft shops get a lot of functionality through the normalupgrade process. Java shops have a wealth of different vendorsproviding J2EE application servers and pre-built components. Let usall use this new technology wiselyand let us resist the urge to gowith a particular solution for the wrong reasons.