Home arrow Web Services arrow Page 2 - Web Services and J2EE

Web Services and J2EE

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).

Author Info:
By: Sams Publishing
Rating: 4 stars4 stars4 stars4 stars4 stars / 6
May 18, 2006
  1. · Web Services and J2EE
  2. · Enterprise JavaBeans
  3. · Roles: Development, Assembly, and Deployment
  4. · Benefits of Using Web Services with J2EE

print this article

Web Services and J2EE - Enterprise JavaBeans
(Page 2 of 4 )

The core of J2EE is the EJB component. This is the programming model for writing and deploying business logic into an application server. EJBs provide a component model for creating business applications. EJB components are mainly focused on aspects such business logic, as well as database and legacy server access, transactions, security, and threading—in other words, how you build core business services in a Java environment.

EJBs initially look complex because they were designed to layer over ordinary Java. For each component, there are multiple .java files. Ideally, the user has an Integrated Development Environment (IDE) that shows each component as a whole as well as the individual class files for that component. However, in the examples later in this book, we simply use a text editor and basic tools for portability.

The EJB component model allows you to structure the business logic into discrete connected components. EJB applications are loosely coupled, with well-defined interfaces.

EJBs come in a variety of styles:

  • Session beans are business logic components that are instantiated on behalf of a user and last no longer than the time the client program remains active and running (a session).

  • Entity beans are components that are mapped into an underlying database or persistent store (for example, a bank account, purchase order, telephone number, or email address). Each instance must have a unique key under which it is stored and retrieved.

  • Message-driven beans (MDBs) are executed in response to a message at the server, usually a one-way, asynchronous JMS message, but also including messages from other systems such as SAP R/3 or PeopleSoft coming through a connector.

There is another distinction: between local and remote EJBs. Local EJBs can only be called from within the same container, whereas remote EJBs are callable across a network over distributed networking protocols (such as RMI-IIOP).

An application can be thought of as having distinct parts—for example:

  • The part that deals with the long-term storage of data in a database or other persistent backend (local entity beans)

  • The part that provides business logic (stateless local session beans)

  • The part that provides the interface with thick clients or a graphical interface layer (stateless or stateful remote session beans)

  • The graphical Web interface (servlets and JSPs)

  • The part that deals with messaging—sending and receiving messages from other systems (message-driven beans)

As you can see, the J2EE application model is a component model that provides the right component types to support solid business applications.

EJB Lifecycle

Another aspect of J2EE that's very important to Web services is the lifecycle of an EJB. Components have well-defined lifecycles—they're instantiated, persisted, and destroyed. EJBs define a "home" factory for creating and managing the lifecycle of components. EJBs can be divided into those with no real lifecycle and those with a lifecycle.

Note - The Open Grid Services Infrastructure (OGSI) offers a model of services that have lifecycles. This is a point of debate around Service-Oriented Architecture—whether services have lifecycles like objects or whether they're stateless.

Stateless session beans are session beans with no real lifecycle—the container instantiates a pool of these as needed. Although there are multiple instances of the component, each instance is interchangeable with any other, because they have no state that differs from method call to method call.

Message-driven beans (MDBs) have no lifecycle either. They are instantiated and pooled by the container—so they are always available.

Stateful session beans (SFSBs) are explicitly created by an application, with parameters in the create() method (part of the home interface). The instance of an SFSB contains state information specific to that client, and therefore it must either be explicitly destroyed or timed out by the container (otherwise the number would grow until the system's capacity was used up).

Entity beans are stateful and have attributes that are stored in a database, file system, or other persistent storage. They must be either created or found using a key. Because they're kept in a persistent datastore, the objects have a very extended lifetime—unlike SFSBs, which last as long as the client code is running, these object instances remain available until they're explicitly deleted, surviving reboots, crashes, system migrations, and so on. Another difference with SFSBs is that many clients can talk to one entity bean instance.

The lifecycle-free model of services matches the model of stateless session beans and MDBs. In fact, a common design pattern in EJB programming involves all distributed interaction with the EJB application taking place through a façade of stateless session beans and MDBs. This model most closely fits today's services infrastructure.

Initiatives such as WS-Addressing (http://www-106.ibm.com/developerworks/library/ specification/ws-add/) and the WS-Resource Framework (WSRF; http://www.globus.org/wsrf/default.asp) allow stateful components to be addressed as services. There are ways of doing it without these technologies (such as adding a key to the end of the address URL), but they aren't standardized. Apache Axis has recently added support for WS-Addressing, but it isn't supported in Apache Axis or in the J2EE specification at the time of this writing.

Note - Apache SOAP supports this approach. See  http://ws.apache.org/soap/.

As you'll see when we dive deeper into J2EE support for Web services, the only supported components that can be accessed as Web services are servlets, stateless session beans, and MDBs. For more information about stateful services, see Chapter 8, "Web Services and Stateful Resources."

blog comments powered by Disqus

- Dealing with Loose Coupling in a Service-Ori...
- Loose Coupling in a Service-Oriented Archite...
- Safety, Idempotence, and the Resource-Orient...
- The Resource-Oriented Architecture in Action
- Features of the Resource-Oriented Architectu...
- The Resource-Oriented Architecture
- Getting Started with Flex
- Automated Billing and Faxing for the Web
- An Introduction to Web Services
- The Foundations of Web Services: From Novice...
- Web Services Reengineering: Finishing Touches
- Fault Handling with Web Services
- Flow and Web Services
- Process Lifecycles and Web Services
- Business Processes and Web Services

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials