Home arrow Web Services arrow Web Services and J2EE
WEB SERVICES

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
TABLE OF CONTENTS:
  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
SEARCH DEVARTICLES

Web Services and J2EE
(Page 1 of 4 )

Chapter 7: Web Services and J2EE

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.

J2EE Overview

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.

Containers

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.


blog comments powered by Disqus
WEB SERVICES ARTICLES

- 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 
Support 

Developer Shed Affiliates

 




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