If you would like to learn how to use SOAP, WSDL, and the Web services stack with J2EE, this article gets you off to a good start. It is excerpted from chapter 7 of the book Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418).
This chapter introduces the concepts of using SOAP, WSDL, and the Web services stack with Java 2 Enterprise Edition (J2EE). Although a single chapter can't do justice to a wide-ranging development platform, we'll show you how to enable Enterprise JavaBean components as Web services using Axis and the JSR109 JCP proposal.
Continuing our example scenario, the SkatesTown technical team has been working in Java for a while and recently has been looking at moving some of the Java applications that run on their server into the J2EE platform. They've heard that it's secure, transactional, managed, scalable, and robust—all the things they want for their business applications. But they're also interested in Web services, and they want to be able to create services easily. So, they've decided to build a sample application called SkatesEJB, which will be a pilot project to determine the value in using J2EE to implement their Web services.
Java 2 Enterprise Edition (J2EE) is the platform for building enterprise applications in Java. J2EE standardizes the services, programming model, and deployment for applications so that developers can build solutions that can be used on a variety of application servers. J2EE has a number of application models:
Thin-client/browser-based applications use servlets and JavaServer Pages (JSPs).
Thick/managed application clients use RMI-IIOP to communicate with server-based Enterprise JavaBeans (EJB) components.
Messaging applications use the Java Message Service to act on messages in queues or from subscriptions.
To this list we can now add service-based applications, which offer services over SOAP/HTTP to clients.
J2EE provides a framework that supports high quality of service (QoS). In other words, J2EE lets you build transactional, secure, reliable applications that are available across a cluster of highly available servers. A J2EE application server provides a wide variety of capabilities including the following:
Workload and performance management—Thread management, pooling, caching, and cluster support
Security management—Password and certificate management and validation, authentication, and access control
Resource management—Access to relational databases, transactional management systems, connectors to Enterprise Resource Planning (ERP) systems, and messaging systems
Transaction management—Two-phase commit support, transactional access to databases, and distributed transactions
Management, configuration, and administration—Deployment, configuration, and administration tools
These services are provided through the concept of a container.
A container is a logical entity in a J2EE server. Containers are entities that have contracts with the components that are deployed into a server—but they also help you understand the way a J2EE system works. Components are deployed to a container, and the container manages the execution of those components as needed. The container provides isolation by intercepting calls to the EJBs, allowing the container to manage aspects such as threads, security, and transactions between components. The container also provides a useful abstraction between components and the resources they use.
For example, when one component uses a database, the programmer uses a resource reference (resource ref) to link to the database. Then the deployment engineer can configure the actual database that maps to the reference. So, the code that is written and compiled isn't hard-coded to a specific database.
This approach is also used for JMS destinations, URLs and URIs, and other EJB components in the same or different applications. Later in the chapter, you'll see an example of an ejb-ref that virtualizes access to another EJB.