msql is a small database useful for demonstration, but in a typical enterprise, Oracle, IBM's DB2, or Microsoft's SQLServer are more likely to be used. J2EE uses JDBC internally, so part of the work of configuring an application server is pointing it to the driver for your database.

A key architectural decision in an enterprise application is how to link your application's object model to the relational data model in the database. One simple way is to avoid having a relational database at all — instead use an ODBMS (Object Database Management System) such as Versant, Poet, ObjectStore, or Ozone. Some of them are implemented in pure Java and can store Java collections directly. However, ODBMS technology is still considered to lack the maturity and standardization achieved by RDBMSs, and has not been widely adopted for average enterprise applications.

Assuming then that the core data of a business is stored in a relational database system, it is necessary to map Java objects to tables. The J2EE model immediately suggests letting entity beans stand for tables or views of multiple tables. The container can manage the mapping (Container-Managed Persistence or CMP). However, entity beans, being transaction-aware, have a significant overhead associated with them. Many feel when data is accessed over a network it should only be through session beans providing coarse-grained access; others protest that entity beans themselves should be written to provide coarse-grained access rather than representing every table and view directly, Developers who believe that their application server's CMP implementation is inflexible or inefficient have the option of controlling the data mapping process using Bean-Managed Persistence or BMP: this requires writing JDBC calls within the entity beans and managing their lifetimes.

In fact many developers have preferred to avoid entity beans altogether. Object-relational mapping tools such as TopLink and CocoBase made it far easier to manage object relationships until CMR (Container Managed Relationships) was introduced in EJB 2.0. Of course even with CMR entity beans you still need to write several classes per object, so less invasive solutions have been sought. The persistence framework Hibernate became very popular after 2003. Hibernate lets you keep your business entities as POJOs while providing object-relational mapping through XML configuration files. You can create fast queries in HQL (Hibernate Query Language). The Hibernate lead developer has been integrating the technology into JBoss, the most popular open-source application server.

Another more-or-less free option is to use Java Data Objects (JDOs). JDOs are not specifically aimed at O/R mapping, but they do allow an object model to be created using plain Java classes (a more flexible, open one than is possible than with entity beans), and a JDO engine takes care of persisting them to the database and caching query results. JDO hides the underlying data store, so your application will not change if you move from, say, an RDBMS to an ODBMS. Interestingly, Sun recommends a further layer of indirection: a Data Access Object (DAO) tier which hides whether you are using JDOs, entity beans, or both (e.g. JDOs for local access and entity beans for remote access), or some other means of persistence.

RESOURCES

JavaSoft's JDBC page including a link to a list of drivers

Hibernate home page

Consider a business that puts a product catalog online. The pages are written in HTML, or generated by a servlet engine. If the presentation of the pages needs to change, then either the HTML needs to be rewritten or the servlets need to be recoded. JSP is one solution, but another good way to separate presentation from data is to list the products in an XML document obeying a custom XML Schema, define the rules for transforming XML to HTML in another document (a stylesheet written in the XSLT standard), and have an XSL processor/parser interpret these two document to create the final HTML, either on demand or in a batch processing manner.

XML is independent of any language which can be used to process it, but Java is a good choice thanks to the wealth of XML-related APIs Sun has brought out. The core API is JAXP (Java API for XML Processing), which contains interfaces for parsing XML (just the interfaces: the functionality needs to be supplied by an implementation such as Xerces or Crimson). The two main ways of parsing XML are both supported: the first way is to treat an XML as a sequence of events which invoke callback methods — SAX; the second, more memory-intensive way is to read in the whole document and construct a tree of object from it — DOM (Document Object Model). A highly popular open-source parsing package is JDOM, which gives you a DOM interface but with SAX-like performance.

A frequent need is converting XML documents to a Java object model. It would be painful to do this with JAXP alone, so there are data binding products which seek to made it as automatic as possible. The most prominent solution is the open-source Castor. Another package aimed at the same thing is JAXB (Java API for XML Binding), which was released by Sun as part of its web services development kit, though it never really caught on. Both solutions allow you to unmarshal XML content into a Java content tree and marshal the Java representation back into XML. In general a data binding solution should

• Do validation to avoid inconsistencies between the Java and XML.
• Support both XML Schemas and DTDs.
• Be as non-invasive as possible with respect to your Java object model.

One use for XML mentioned above was separating presentation from data. There are many other uses. For instance, XML has become a widely-adopted standard for properties and configuration files, especially in J2EE — ejb-jar.xml, web.xml, etc. But the biggest use is probably in providing a layer of interoperability between heterogenous systems. As it is independent of any processing language, it offers a convenient way for enterprises to create interfaces to their systems which can be used by other enterprises. Being simply text and not tied to any network protocol, it can be sent over standard HTTP and be accepted by any of the large existing numbers of web servers — without being stopped by firewalls. The quick adoption of XML over HTTP in the business world has led to a standard called SOAP, dealt with in the next section.

RESOURCES

Introduction to XML from Sun

XML concepts and JAXP

The Web's potential to help businesses communicate with each other (B2B) and the public (B2C) in service-oriented ways beyond the mere display of HTML has led to the concept of web services. To understand the concept of a web service, consider the example of a large company which wishes to "esource" all its internal document and image conversions to another company specializing in this. Rather than buying an expensive product, the large company prefers to have the facility as a service, on a pay-as-you-go basis. This requires the networks of the two companies be linked in some fashion. Traditionally when two companies have wished to cooperate this closely, it has been necessary to have CORBA or DCOM systems. These are quite complex, requiring lots of special software, possibly including a CORBA-DCOM bridge, and the maintenance of dedicated ports which open up (often prohibitive) security holes. A much smaller step is to provide the service over HTTP.

In general, a vast number of companies have been making their data available over the Web along with search functions, but only in a human-readable (HTML) format. If they also provide the data in XML along with available method calls, the data now becomes machine-readable. This greatly eases the task of Internet software agents matching buyers to sellers and doing other useful tasks.

The goal of making the Web a world of distributed objects has come closer with the adoption of a standard XML over HTTP protocol called SOAP (though strictly SOAP does not require HTTP as the transport layer).SOAP is not a Java technology, but an abstract wire protocol. Like RMI'S JRMP and CORBA's IIOP it can be used for invoking methods across a network, but unlike these protocols the encoding format used in not binary but simply XML text. This is a bit inefficient, but it means that messages have a better chance of getting though firewalls (by being wrapped in HTTP) and that it is easier to debug. SOAP does not favour any particular vendor, and it is strongly supported by Microsoft and IBM as well as Sun (offering an opportunity for .NET and J2EE to interoperate for instance). Because of the overhead of parsing XML it is best to make SOAP calls as coarse-grained as possible. In fact some have resisted the idea of SOAP as an RPC mechanism, favoring instead a document-oriented approach where whole documents like purchase orders are sent over the network rather than just method calls and arguments.

Sun has an API for document-oriented SOAP communication called JAXM, but its main API supporting SOAP is JAX-RPC. Both APIs are distributed as parts of its Java Web Services Development Pack (JWSDP). JAX-RPC makes web service communication look very much like RMI: the client invokes methods on a stub which represents the server and is generated by a special wscompile tool; the JAX-RPC runtime takes care of the work of formatting the call in a SOAP envelope and receiving messages (in JWSDP this is done via a servlet called JAXRPCServlet in a bundled Tomcat servlet container). Of key importance to J2EE developers is that the EJB specification is being rewritten (EJB 2.1) to allow EJBs to act as web services and to invoke web service operations using JAX-RPC.

This assumes that a client knows what server it wants to talk to. What if a client knows what general type of service it needs, but needs to find a specific provider? The Web Services "Yellow Pages" standard is called UDDI (Universal Description, Discovery and Integration). UDDI specifies how a registry of web services is organized.

Each web service is described in a standard XML language called WDSL (Web Services Description Language). The diagram to the right shows how a sample web is described in WDSL by the JWSDP runtime. The upper browser window is just showing the endpoint of a web service rather than a registry browser.

The Java API for accessing business registries based on UDDI or other standards such as ebXML is called JAXR (Java API for XML Registries). Besides JWSDP, a popular tool for writing web services is the open source implementation from Apache, formerly called Apache SOAP and now called Axis. An admin tool is provided for configuring web services (see below), and there is an RPCRouter servlet which takes requests from clients and forwards them to the right object in the desired service.

The basic steps in writing a web service are:

• Write an ordinary Java class or bean with methods which can take parameters and return values.
• Configure the service in the admin tool, including the full class name of the "provider" you have just written, the methods which are available, and a unique URN where the service can be found.
• Write a test client. This requires special code using the SOAP classes for creating a Call object, setting the target URI and method name on it, invoking it, and getting the response (equal to the return value of the method in the provider method).

A system of related Web services can be used to organize an SOA (Service Oriented Architecture). Whereas conventional systems have tightly-controlled straight-through processing styles, an SOA supports loosely coupled services (independent of any language or technology) which, when "orchestrated," can form end-to-end business processes. The term SOA feels a bit vague, but it has been made more concrete by the popularization of tools which allow one to write enterprise-wide workflow in BPEL (Business Process Execution Language). One dream is that BPEL offers such an abstract view of business processes -- their behavior not their implementation -- that an entire SOA could be written in it by business analysts rather than software engineers.

Separate to web services, but also based on XML messaging across a network is Project JXTA ("Juxtapose") at Sun. JXTA is specifically aimed at peer-to-peer (P2P) networking, and provides a set of interfaces and protocols to support P2P-related services like peer groups, peer discovery, and peer pipes. If there is a boom of P2P applications like Napster, JXTA may be a viable standard for coding them. Another use is for distributing computing resources on a project like SETI@home.

Sun has worked to make Java interoperable with CORBA. However, offerings from Microsoft have been less reconcilable. A few months after J2EE was launched, Microsoft announced a direct competitor: .NET, the successor to DCOM. .NET has several important parts to it: a methodology for transforming software components into web services, an updated version of the Visual Studio IDE, and a Common Language Runtime (CLR) which can run code from languages as diverse as Visual Basic, C++, and a new Java-like language called C# once they have been compiled into Intermediate Language (IL). The CLR running IL is a bit like the JVM running bytecode, and many have suggested Java provided part of the inspiration for the architecture. However, unlike J2EE and CORBA, .NET is an enterprise platform firmly attached to a single OS family: Win32.

Is .NET succeeding in taking market share away from J2EE? It has these advantages:

• Choice of languages for development, and interoperability between components written in different languages.
• Accessible to developers who are accustomed to creating only simple applications using forms and Visual Basic.
• Web services emphasis from the start.
• Familiarity of the Windows platform and its market dominance: new PCs come shipped with .NET infrastructure.

On the other hand the J2EE platform has these advantages:

• Greater maturity.
• Vendor-independence and interchangeability, making it more attractive to purchasing agents.
• Large existing base of server-side developers accustomed to programming in Java.
• Large number of free tools (JBoss, Tomcat, ant, etc.), making it more accessible to independent developers.
• Greater ability to integrate with legacy systems, making it useful to large corporations which want to leverage the large amounts of COBOL code, etc. remaining in their systems.
• Industry tradition of using non-Win32 machines for powerful server applications.

So both sides have strong advantages. The war is being fought both on a technical and a marketing front. Currently Java remains the most popular language for server-side development, and it is not clear if Microsoft will succeed in dominating the enterprise market in the same way it dominates the OS and browser market.

Whereas J2EE is a set of specifications for enterprise services, .NET is more of a product offering. Sun has its own product strategy though, which was announced hot on the heels of .NET: Sun ONE (Open Net Environment), incorporating Sun's own J2EE application server, the Forte development environment, the StarOffice suite, and other servers and tools. Early in 2003 Sun released Solaris 9 bundled with the Sun ONE application server.

Incidentally there exist Java enterprise technologies which remain outside the J2EE fold. Apart from JDO and JXTA mentioned above, there is also Jini. Like EJBs Jini is a distributed objects technology which runs on top of RMI. However, whereas the EJB framework is aimed at abstracting business logic from distributed services in back-end systems, Jini is aimed at having networks of devices interact and adapt to change. For instance, if a printer is added, this should be automatically picked up without any special configuration by users. This is like the idea of "plug and play," but there is an emphasis on the device itself having a certain intelligence, at least enough to announce itself to the network. The concept of code mobility is key to Jini.