Back to article

A Dynamic e-Business Application Using Web Services

May 22, 2003


The World Wide Web has brought about a revolutionary change in the way businesses are conducted on the Web. Although the initial focus was primarily on B2C interactions, it is now evident that for businesses to grow and succeed, organizations and companies not only need to participate in trading partnerships but those beyond need to work in close cooperation. B2B integration is about coordinating activities by transparently sharing information between organizations to streamline and automate business processes. Companies from across a variety of industries are embracing B2Bi, realizing the enormous competitive advantage it provides through faster time to market, reduced cycle times, increased customer service—in short, better quality of service.

What Is a Web Service?

Today, with virtually every computer and potentially every application connected to a single network, there are increased opportunities for establishing business relationships dynamically. To achieve this, business transactions must happen in real time and also use open Internet standards to integrate these disparate islands of applications. Major IT players, vendors, service providers, and consumers of IT services have now come together to agree on a common standard—Web Services. Web services based on open standards acts as a facade to provide a uniform and widely accessible dynamic interface to expose business operations. Figure 1 illustrates how a typical Web service works.

Click here for a larger image.

Figure 1: Workings of a typical Web Service

XML and HTTP form the core of Web service standards. Web service technology stacks, composed of SOAP, WSDL, and UDDI are the basic building blocks that provide a solid infrastructure, enabling systems to interoperate with relative ease and reduced cost of integration. Refer to the References section for more information on these technologies.

Web services, based on a service-oriented architecture (SOA), typically involve three entities: the service provider, the service broker, and the service requestor. Figure 2 shows the interaction of components that make up the SOA.

Figure 2: The Service-oriented architecture

In a typical Web services scenario, a service provider publishes its services in a standard format on a global business registry (the service broker) that is accessible over the Web. A service requestor can be an application on a company's intranet, a partner application on the Internet, or an application on an end-user device. It searches the business registry to discover the service and its associated endpoints. It then binds with the service provider and invokes a method on the Web service using the SOAP protocol. The method invocation is sent as an XML document embedded in an HTTP request. The service provider's Web server receives the HTTP request and passes it to the Web service engine, which in turn invokes an appropriate method on the backend system. The result of the method invocation (formatted as an XML document) is embedded within an HTTP response and returned to the service requestor. The actual object implementing business logics on the backend system may be a Java class, an EJB, a .NET component, or any legacy application.

Role of Web Services in Enterprise Architecture

Most enterprise application architectures are based on component technologies such as COM/DCOM, J2EE, and CORBA. Traditional middleware platforms based on these technologies have matured and have been well proven to implement key enterprise requirements such as distributed transaction integrity, workflow automation, security, scalability, and so forth.

However there are some downsides to it. One major drawback of these middleware architectures is their inability to interoperate with each other. This is primarily due to the binary incompatibility between the object models and proprietary protocols used for information exchange. For instance, a COM object running on a Microsoft platform cannot quite easily interact with a Java component or a CORBA object. Even if it does, the connected components are highly dependent on each other, resulting in tight coupling between them. Yet another problem associated with component technologies is firewall penetration. Object protocols such as DCOM, RMI, and IIOP operate using an arbitrary set of ports on the server, thereby opening up potential security holes. Web administrators are wary of opening ports other than 80 for security reasons.

Web services offers a perfect solution by providing a uniform interface to access business functions using protocols such as SOAP and XML-RPC. These protocols that work with XMLs as the payload over the ubiquitous HTTP, circumvent both the problems mentioned above.

Although the W3C SOAP standard specifies the bare minimum, several organizations have come up with recommendations such as WS-security, Business Transaction Protocol for WS-transactions, WSFL for workflow, and so on to meet other important enterprise requirements. So, as of now, Web services cannot be considered a replacement for component technologies, but rather complement them.

Benefits of Web Services

The key benefit of Web services is that they allow previously incompatible applications to interoperate on the Web regardless of language, platform, and operating systems, thereby creating new e-business opportunities. This makes it easy for companies to adapt to changing business relationships and develop new e-partnerships. Unlike integration using EDI, it now will be possible to unilaterally create a Web service without prior agreement from business partners.

Take the case of the travel industry—airlines, hotel chains, tour operators, insurance, and car-rental companies are gradually packaging their services to create turnkey products. For example, when a travel agent sells a ticket, he can dynamically choose among different airlines, locate a suitable travel insurance, book the client to a hotel, and arrange for a car rental service, all in a single operation. This dynamic assembly of products and services gives the client real added value and provides enterprises with marketing advantagesÿlower costs for acquiring clients, customer satisfaction, customer retention, and so forth.

Similarly, in a manufacturing company, activities such as customer/product enquiry, order processing, obtaining part/quotes information from suppliers, and the like had been traditionally done using telephone, faxes, e-mails, or Web pages. These activities can now be performed dynamically with little or no human intervention by exposing functions using Web services, thereby automating the entire work flow process. One can cite numerous such instances where Web services can be used.

Web services architecture is independent of the connected application components in an enterprise or the underlying technology used. Consequently, it allows users to focus more on the functional aspects and evolving strategies to maximize profits and minimize risks. It has earned widespread acceptance due to the fact that it does not effect existing business components and does not require users to re-write their applications, thereby protecting customer investments—a clear winner from an ROI perspective.

Web servicess represents the next generation of e-business applications. Its architecture offers a loosely coupled model for interaction between systems and removes the stumbling blocks associated with traditional e-business. The next section describes a practical example of using Web services.

The POC Application


A PC manufacturing company producing different brands of PCs plans to automate its customer enquiry and sales order processing system by exposing these functions as Web services for its customers. It also automates its supply chain process by dynamically interacting with part vendors for purchase of computer accessories. The manufacturer, customer, and vendor applications could be behind a firewall and possibly be running on different platforms and/or using a language of their choice. Clearly, an architecture merely based on component technologies cannot meet the desired objectives. To illustrate the interoperability among these diverse systems, the different vendor applications in this POC have been developed using the Java/J2EE, Java/Axis, and C#/Microsoft .NET platforms. Nevertheless, the manufacturer using Web services would be able to interact with each one of these vendors identically. Figure 3 describes this typical business scenario.

Figure 3: Overview of the POC application architecture

The application features the following:

  • A procedure-oriented, synchronous communication with endpoints using JAX-RPC (dynamic binding)
  • Loosely coupled architecture using a messaging system
  • Asynchronous, document-oriented message interchange using JAXM
  • Business process automation
  • Discovery of service, based on a classification meeting search criteria using JAXR API and to communicate with endpoints using JAX-RPC (Dynamic Invocation Interface)
  • Publishing Web services on a UDDI Business Registry (UBR) using JAXR
  • Transparently interacting with endpoints having different binding types (specifically interacting with endpoints on the J2EE, Apache/Axis, or .NET platforms)
  • MVC architecture using the Jakarta Struts framework

Customers or dealers trade directly by interacting with the manufacturing company using Web services to view product list, view order status, place orders, and so forth for the purchase of PCs. This eventually results in substantial cost reductions in terms of time and resources for the manufacturer. In addition, it also provides improved customer service and helps customers automate their systems as well.

The manufacturer application features administrative functions such as:

  • Product and customer maintenance
  • View and approve customer orders and
  • Get best quote and part details from vendors

The manufacturing company exposes functions such as customer/product enquiry, order status, place order, and so on as Web services for consumption by the customers/dealers. The manufacturer is implemented as a Web application using J2EE running on the SUN ONE application server 7.

The manufacturer sub-system consists of the following components:

  • A JAXRPC servlet to service the customer Web service requests
  • Web service implementation of the customer request functions
  • An asynchronous messaging component to process SOAP-based XML documents
  • Action components that implement page navigation and internal administration functions
  • Various business controllers and data access objects to execute business logics
  • A Web services client component consisting of call agents that transparently interacts with part vendors using appropriate binding types
  • Facility to publish Web services onto a UBR using JAXR API

The manufacturing company interacts with several part vendors to procure computer accessories such as hard disks, memory, cards, and so forth. It performs a search on the public registry (logically similar to the way a search engine searches the Web for key words) and dynamically locates potential vendors on the Internet to obtain price quotes to select the best vendor. It can be extended to show how this process can be triggered by a fall in inventory levels, thus illustrating the automation of its supply chain process.

Parts vendors make themselves known to the outside world by 'publishing' their services in a public XML Registry. The registry typically contains brief information about the company, the various services they offer, the endpoint URL for Web services interaction, type of binding supported, and possibly an external link for extra information. Organizations are listed in the registry based on standard classification schemes. The parts vendors expose functions for providing information such as parts detail and price quote as Web services.


The e-Trade application consists of three functional entities: the customers (dealers), manufacturing company, and parts vendors.

The customer is developed as a Java Swing-based application. It uses JAX-RPC, a procedure-oriented approach for invoking services such as obtaining customer profile, getting product list and details, order status, and so on. At the same time someone places a purchase order, typically an asynchronous operation is implemented using JAXM, a document-oriented processing approach with a messaging provider. This application uses the Java Messaging System (JMS) provided with the SUN ONE application server. Figure 4 depicts the interactions between the customer and the manufacturer.

Click here for a larger image.

Figure 4: The Customer-Manufacturer Interactions

A successful login process fetches the customer profiles, product details, and his previous order details using synchronous RPC to initialize the customer data models. TradingWebServicesMgr is the component that interacts with the manufacturer Web services on behalf of the customer client. The client makes use of a local proxy object and invokes a method on them. This proxy could be a stub in the case of static binding or a dynamic proxy, a class created by the client at runtime. In this application, the manufacturer Web service description document (TradingWebServices.wsdl) that is generated during deployment is available to the customer either directly or through a link in the public registry. Refer to the Resources section for more information on WSDL. The customer application uses this WSDL document to generate a dynamic proxy at run time and invokes calls on this object. The runtime makes use of serializers and de-serializers to transfer Java objects between the client and server. The code snippet from below shows steps for creating serializers for the Product class and registering with the service.

// set up serializers and de-serializers
CombinedSerializer productSerializer =
  new Product_SOAPSerializer(productQname, ENCODE_TYPE, NULLABLE,
productSerializer = new ReferenceableSerializerImpl(
                    SERIALIZE_AS_REF, productSerializer);
SerializerFactory productSerializerFactory =
              new SingletonSerializerFactory(productSerializer);
DeserializerFactory productDeSerializerFactory =
              new SingletonDeserializerFactory(productSerializer);

. . . . . . . . . .

TypeMappingRegistry registry = service.getTypeMappingRegistry();
TypeMapping typeMapping = registry.getTypeMapping(
typeMapping.register(Product.class, productQname,

The Product_SOAPSerializer class above is created when the xrpc compiler generates Web services ties on the server using information in config.xml. The extract below shows the creation of a dynamic proxy handle with the help of the Web service class and the WSDL document.

ServiceFactory serviceFactory = ServiceFactory.newInstance();
Service service = serviceFactory.createService(etradeWsdlUrl,
                  new QName(wsdlNSUri, serviceName));

. . . . . . . . . .

//get the proxy handle
tradeIF = (TradingWebServicesIF) service.getPort(new
                                 QName(wsdlNSUri, servicePort),

The JAX-RPC runtime establishes a synchronous communication channel between the client proxy and the tie object on the server. Ties are components running at the server complementing the proxy stubs on the client. JAX-RPC uses XML-based remote procedure calls to invoke services on remote systems. The calls and responses are transmitted as SOAP messages over HTTP. The JAX-RPC API hides all the complexity from the developer while writing the client code. Figure 5 shows the communication between a client and server using a dynamic proxy with JAX-RPC.

Click here for a larger image.

Figure 5: A synchronous interaction using Java API for XML-RPC

The asynchronous delivery process is implemented using JMS Queue and Topic. The customer performs a lookup for the JMS connection factories and destinations on the LDAP server using the JNDI lookup mechanism. All customer orders in the form of a Purchase Order XML document embedded within a SOAP message is funneled through the JMS Queue and delivered to the manufacturer application. The client code for this is developed using the JAXM API. Shown below is the Purchase Order XML document sent within a SOAP message.

<?xml version="1.0" encoding="UTF-8"?>
 <soap-env:Envelope xmlns:soap-env="">
  <PurchaseOrder custId="JOHNS" poRef="JOHNS1048316652804" poDate="20030322" poValue="25235">
   <billTo country="AE">
    <name>John Simon</name>
    <street>P.O Box 00001</street>
   <shipTo country="AE">
    <name>John Simon</name>
    <street>P.O Box 00001</street>
    <orderItem partNum="2512EA">
     <productName>Presario-2512EA Laptop PC</productName>
     <desc>Intel-P4, 2.5GHz, 256MB RAM, 40GB HDD, 15" XGA</desc>
    <orderItem partNum="2125EA">
     <productName>Presario-2125EA Laptop PC</productName>
     <desc>Intel-M Celeron, 2.0GHz, 256MB RAM, 30GB HDD, 15" XGA</desc>

The customer implements a MessageListener interface to receive asynchronous responses from the manufacturer via the JMS Topic destination. The JMS messages are converted to SOAP messages and the embedded data extracted from it. The code snippet from the onMessage() handler below shows how data is extracted from an incoming JMS message.

. . . . . . . . . .

TransformerFactory tf = TransformerFactory.newInstance();
Transformer transformer = tf.newTransformer();

// convert JMS to SOAP message.
SOAPMessage soapMessage =
     MessageTransformer.SOAPMessageFromJMSMessage( message,
                        MessageFactory.newInstance() );

// Get SOAP part.
SOAPPart soapPart = soapMessage.getSOAPPart();

// Get SOAP envelope.
SOAPEnvelope soapEnvelope = soapPart.getEnvelope();

// Get the empty SOAP Envelope as a generic Source and put it
// into a DOMResult
javax.xml.transform.Source spSrc = soapPart.getContent();
javax.xml.transform.dom.DOMResult domResultEnv =
          new javax.xml.transform.dom.DOMResult();
transformer.transform(spSrc, domResultEnv);

// Get the document
org.w3c.dom.Node envelopeRoot = domResultEnv.getNode();

. . . . . . . . . .

The internal customer data models are updated upon receipt of appropriate messages from the manufacturer that in turn update the onscreen data. Figure 6 is a screen snapshot of the customer application showing the Order Details tab page. This page is automatically updated when the Manufacturer receives a PO and sends an ACK back or approves the pending order.

Click here for a larger image.

Figure 6: Screen snapshot of customer application showing the Order Details tab page

The customer is assembled as a .jar standalone application.

The manufacturer application is built on the SUN ONE application server based on a Web-centric approach. It features use of servlets and other components to implement the business logics. The JAXPRC servlet provided by the container at deployment time services the JAX-RPC requests from clients and invokes the appropriate Web service method. The Web service implementation in turn invokes controller objects to perform the required functions. The BusinessController is an abstract base class for all controller objects. The controllers in turn use data access objects to access and manipulate the database.

The ManufacturerContextListener a servlet context listener, on receipt of the servlet initialized ServletContext life cycle event instantiates a ManufacturerAsyncRecv object in a separate thread. This object sets up the JMS resources lookups and listens for messages in the receive queue. Below is the code snippet of ManufacturerAsyncRecv object listening to the receive message queue.

public void listen() {

  System.out.println("ManufacturerAsync>>Starting receive loop");
  try  {
    while(!shutdown)  {
      Message m = queueReceiver.receiveNoWait();
      // received a message, process it now
      if(m!=null) processMessage(m);
      try  {
      catch (InterruptedException ie)  {}
  catch (JMSException jmse)  {
      System.out.println("ManufacturerAsync>>doGet: "+
  } finally {

On receipt of a place order message, it makes an order entry in the database and sends an acknowledgement JAXM message via the ManufacturerAsyncSend. An extract from the processMessage code that separates the PO document from the SOAP message and process the order is shown below.

. . . . . . . . . .

//locate the body node and extract the data portion
Element poNode = (Element)XPathUtil.selectSingleNode(
                  envelopeRoot, "//PurchaseOrder");

//locate the PO data
String custId      = poNode.getAttribute("custId");
String poNbr       = poNode.getAttribute("poRef");
String poDate      = poNode.getAttribute("poDate");
String poValue     = poNode.getAttribute("poValue");
NodeList itemNodes = XPathUtil.selectNodes(poNode,

// get the reqd controller and update the database with the
// status set
OrderController oc = (OrderController)(context.getAttribute(
if(oc== null) System.out.println("ManufacturerAsync:
                                  Order controller not found");

// create the Customer order object and populate it
CustomerOrder co = new CustomerOrder();

// create the line item vector and insert into the Customer
// order object
Vector itemVect = new Vector();
for(int i=0; i<itemNodes.getLength(); i++) {
  org.w3c.dom.Node itemNode = itemNodes.item(i);
  String itemid   = ((Element)itemNode).getAttribute("partNum");
  String quantity = XPathUtil.getNodeText(itemNode, "quantity");
  String price    = XPathUtil.getNodeText(itemNode, "price");
  OrderItem oi    = new OrderItem(itemid, Long.parseLong(quantity),
// update the customer order into the local database
CustomerOrder ordData = (CustomerOrder)(oc.process(co,
//store the data portion as [orderid].xml into a local file
long oid = ordData.getOrderId();
String msg = custId+":"+oid+":"+poNbr;

//send an ack message with the order id
ManufacturerAsyncSend mas = ManufacturerAsyncSend.getInstance();
mas.sendMessage("ACK", msg);

. . . . . . . . . .

The ManufacturerAsyncSend, a Singleton on receipt of an 'Order Approval' signal from the administrator, prepares the Invoice document, embeds it within a SOAP message, and dispatches it to the respective customer via the JMS Topic using JAXM API. The JMS messages are converted to SOAP messages using the MessageTransformer class. You could have a return queue for each customer instead of a single Topic object. The sendMessage() function builds the SOAP response, either an Acknowledgement message or an XML Invoice document for the customer. The SOAP message is converted to a JMS message before sending it to the JMS destination.

This application uses the Jakarta Struts framework to implement the Model-View-Controller (MVC) architecture for its page navigation and operations by the administrator. It illustrates the powerful and flexible features offered by the framework. All action elements extend the abstract BusinessBaseAction class. Refer to the Resources section for more information on the Jakarta Struts framework. Figure 7 shows the screen snapshot of the manufacturer Web application where the administrator views customer orders for approval of pending orders.

Click here for a larger image.

Figure 7: Screen snapshot of manufacturer application showing the View/Approve Order page

The administrator, upon initiating an Approve action, causes the order status to be updated by respective business controllers and an invoice message is sent to the ManufacturerAsyncSend. Figure 8 shows the interaction diagram for the order processing function.

Click here for a larger image.

Figure 8: The interaction diagram for the Order Processing function

Various functional controller objects use data access objects and JDBC for database operation. The application uses the Pointbase database bundled with the application server for data persistence.

The manufacturer discovers and interacts with parts vendors to procure computer accessories. The manufacturer application searches a UDDI business registry (UBR) for organizations matching the search classification using the JAXR API. The ServiceProviderLocator object actually performs the search for vendor organizations based on the classification and search criteria. The ProviderClent object then performs dynamic binding with the received endpoints and invokes services on the part vendors using appropriate call agents depending on the binding type. It may use Dynamic Invocation Interface, JAX-RPC (DII), or use JAXM messages. Below is the code snippet showing the ProviderClient getting quotes from all vendors.

try {
  Enumeration e= orgTable.elements();

  // iterate thrugh the cached service providers
  while(e.hasMoreElements()) {

    ServiceProviderInfo spi = (ServiceProviderInfo)e.nextElement();

    // get the endpoint for the specified service
    String[] endpoint = spi.getService(service).
    if(endpoint == null) throw new Exception(
                         "No Organisation endpoints found !");

    // Assuming 'JAXRPC' and 'SOAPNET' are the only two types of
    // service bindings.
    // Using 'JAXRPC' as default
    // create a call agent suitable for the endpoint
    ICallAgent ca = CallAgentFactory.newCallAgent(endpoint);

    // invoke the Web service method on the endpoint
    String quote = ca.getQuote(type, size);
    if(quote != null) allQuotes.put(spi.getProviderName(), quote);
  if(allQuotes.isEmpty()) throw new Exception(
               "No Vendors with matching specifications !");
} catch (Throwable t) {
  System.out.println("Exception : In Provider-getAllQuotes>> " );
  throw new Exception(t.getMessage());
// return the quote collection from all vendors
return allQuotes;

The application uses the reference UDDI implementation provided as a part of the JWSDK pack for the UBR. Figure 9 illustrates the manufacturer application and its interaction with part vendors.

Click here for a larger image.

Figure 9: The Vendor-Manufacturer Interactions

The parts vendor services are published to the UDDI test registry using the JAXR publishing APIs. They host Web services with the same service names and signatures to return product details and price quotes. One vendor is implemented as a WAR application deployed on the Tomcat servlet engine. The second vendor, also a Java application on the Apache/Axis platform, uses a Java:RPC provider to communicate with the manufacturer. Both of them use JAXP APIs to process data from an XML document that holds parts information. The third vendor is implemented using C# on the Microsoft .NET platform, which communicates with the manufacturer using synchronous JAXM. Below are the messages exchanged between the manufacturer and a vendor implemented on .NET while invoking the getQuote() method, captured using the 'tcpmon' utility from Apache/Axis.

Listen Port: 9003
Target Host: localhost
Target Port: 80
==== Request ====
POST /SymphonyQS/QuoteService/QuoteService.asmx HTTP/1.1
Content-Type: text/xml; charset="utf-8"
Content-Length: 266
User-Agent: Java1.4.0_02
Host: localhost
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

<?xml version="1.0" encoding="UTF-8"?>
 <soap-env:Envelope xmlns:soap-env="">
   <getQuote xmlns="">

==== Response ====
HTTP/1.1 100 Continue

Server: Microsoft-IIS/5.0
Date: Tue, 18 Mar 2003 20:45:01 GMT
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 18 Mar 2003 20:45:09 GMT
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 350

<?xml version="1.0" encoding="utf-8"?>
 <soap:Envelope xmlns:soap="" xmlns:xsi="" xmlns:xsd="">
   <getQuoteResponse xmlns="">

Working with the Application

  • Download the application and other required software
  • Follow the instructions in the readme.txt file of to install and deploy the application. (Important: Remember to place the struts.jar file in the /src/lib folder as mentioned in readme.txt; otherwise, the project will fail to compile.)
  • Make sure the Sun-ONE App Server is started and the Manufacturer application is up and running. You should see the message "INFO: CORE5053: Application on Ready complete." on the application server console on successful startup.
  • Test to see whether the manufacturer Web service has been installed by pointing the browser to http://localhost:81/manufacturer/jaxrpc/TradingWebServicesIF. If successfully installed, you should see a message to that effect.
  • Modify the file if required, in particular the WSDL_URL and JMS_PROVIDER_URL properties. Execute the run-client.bat file to start the Customer Client (swing based application).

    Log in using JOHNS and any password.

    On successful login, you should see the application come up with the customer information on the first of the four tab pages. The second tab page, View Products, lists product details of the one chosen from the list box. The third tab page, Create Order, is for customers to prepare and place orders. Use the buttons provided at the bottom. When an order is placed, it will be removed from this page and available as an ordered item in the last tab page Order Details. This last page shows previous orders, their status and details. The status of orders on this page is updated automatically when the administrator approves it from the manufacturer application.

  • Test to see whether the vendor Web service has been installed by pointing the browser to:

  • To run the manufacturer application point the browser to http://localhost:81/manufacturer/index.jsp . Use IE 5.0 or higher as other browsers may not render some pages properly. Select one of the options from the menu. The customer and product management options allow you to create, update, or delete items in the database. The view/approve order option allows you to selectively retrieve orders, view, and approve pending orders. On approval of an order, the invoice document is sent to the customer and order status updated both at the customer and the manufacturer application. Quote for parts is an option to retrieve all vendors registered in the global registry for a particular service. Once the parts vendors are located you can get the part information by clicking on any one of them. You can also locate the vendor that quotes the least for a particular part item. For example, enter 'IDE' for type and '40' for size and select the 'Get Best Quote' option to select the best quote vendor for an IDE HDD of size 40 GB. You can delete a vendor from the UDDI registry entry using the JAXR Registry browser and re-run the 'Get Best Quote' and expect a different result.
  • You can use the tcpmon utility that comes with Apache-Axis to view the SOAP messages that go back and forth between the Manufacturer and customer as well as those between manufacturer and the vendors.
  • The Web application response may be slow the first time you access a jsp resource as they are first converted to servlets. It should be much better on subsequent invocations of the same resource.


XML support in the Java environment:

"Web services in Java environments" by Dave Chappell and Tyler Jewell in Java Web Services (O'Reilly & Associates)

Best practices for architecting enterprise J2EE applications in Designing Enterprise Applications with the J2EE Platform, Second Edition, Inderjeet Singh et al. (Addison-Wesley Publishing Company, June 2002; ISBN: 0201787903):

Recommendations from Sun's J2EE Blueprints team: "Using Web Services Effectively:"

The Sun One Logistics Sample Application:

Using JAXR in "Web Services Take Float with JAXR" (JavaWorld, May 2002):

XML Messaging—Dirk Reinshagen discusses JAXM (JavaWorld):

B2Bi and Web Services

Developing Web Services Series: Web services and J2EE

Developer's Guide to Building XML-based Web Services with the Java 2 Platform, Enterprise Edition (J2EE)

Web Services: A Business Perspective on Platform Choice

Making your J2EE Application Web Services ready—The XML Business Delegate Pattern

List of Web services and SOAP implementations


Download demo project source - 123Kb

About the Author

Simon John is a graduate in Electrical Engineering from the University of Calicut, India. He has over fourteen years of professional experience in the areas of OOAD, real-time programming, RDBMS, Enterprise technologies (J2EE & COM), Transaction processing middleware, and Web services, and is also a Sun Certified Web components developer. He last served as a consultant with Unisys. He can be contacted at

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date