J2EE Web Services Integration
Before looking at each specific vendor, let's look at how to perform integration using an application server. Recall from our earlier discussion that an application server provides common server-side servicessuch as load balancing, fault tolerance, and database poolingthat are needed by all applications but not provided by the J2EE specifications. The various application servers from J2EE vendors (BEA, IBM, Sun, etc.) implement these services in different ways and with varying levels of performance; however, at a conceptual level, they're all doing the same thing.
An application server usually includes a servlet engine and an EJB (enterprise Java beans) container. To add to the confusion, however, not all application servers have built-in servlet engines, and not all application servers can host EJBs. As of this writing, all the major application server vendors have announced support for SOAP and varying levels of support for WSDL and UDDI.
To support web services effectively, a servlet must be able to process an incoming SOAP request (usually via HTTP) and then route the request to the appropriate destination (JMS message, EJB, another servlet, and so on). Once the SOAP request has been processed, the application then uses other facilities in the application to continue processing. This may include connecting to a legacy system using JCA and/or connecting to a relational database using JDBC. This result is then packaged into an XML document and returned via SOAP to the client. Figure 1 illustrates this sequence.
Figure 1 Web services integration with JCA and JDBC.
In summary, the technologies required to handle web services are already present in J2EE. Now that you know how web services are architected in J2EE, we'll consider J2EE vendors and supplemental technologies, such as web services networks, to handle other issues such as non-repudiation, guaranteed messaging, and so on.
Let's focus first on the J2EE vendors and their products.