Thus, web services can be created out of existing enterprise
applications by adding a new "web service view" to the application
while using the same business logic and framework.
Processing
Web Service Requests
Web services respond to requests from clients. Since the web
services are enabled through technologies based on XML standards, all
requests received are XML documents. The incoming XML documents will
have to be pre-processed, and if required, transformed to a format
understood internally, and then processed for getting the information
contained therein. Also, all security checks need to be implemented
before processing the requests. There are several issues to be kept in
mind while doing the above.
Pre-Processing And Transformations: The incoming XML
documents may first have to be pre-processed and, if required,
transformed to a common internal format understood by the web
service. The need may arise to enable the web service using a common
internal format while processing the request, even while entertaining
different forms of requests from different clients for the same
service.
For example, consider a web service that provides an online billing
service. This service might get user information, account information
and payment information from a customer. On receiving this
information, the service may do proper authentication and security
checks before completing the actual payment transactions. To satisfy
the needs of different customers, the web service provider may agree
to receive requests in two different forms as shown below:
<BillingRequest>
<CustomerName>customer1</CustomerName>
<CustomerId>1234</CustomerId>
<UserDetails>
<Name>John Doe</Name>
<AcctNo>12345678</AcctNo>
<PIN>9999</PIN>
</UserDetails>
<PaymentDetails>
<BankName>Some Bank</BankName>
<RoutingNo>12345678901234</RoutingNo>
<Amount>1234.12</Amount>
</PaymentDetails>
</BillingRequest>
Listing 1: One format of Billing Request
<BillingRequest>
<CustomerName>customer2</CustomerName>
<CustomerId>6789</CustomerId>
<Details>
<BankName>Some Bank</BankName>
<AcctNo>12345678</AcctNo>
<RoutingNo>12345678901234</RoutingNo>
<PIN>9999</PIN>
<Amount>1234.12</Amount>
</Details>
</BillingRequest>
Listing 2: Another format of Billing Request
The billing web service may decide to entertain these two different
forms of requests to be more customer-friendly and flexible. Whatever
the reason for accepting two different forms of requests for the same
service, the billing service may only require the account, routing and
payment information to complete the transaction for the customer. In
such a case, instead of passing around different forms of requests, it
will be much easier for the billing service to follow a common
internal format for further processing. Such a common internal format
could be something like the XML document listed below:
<BillingRequest>
<CustomerId>6789</CustomerId>
<AcctNo>12345678</AcctNo>
<PIN>9999</PIN>
<RoutingNo>12345678901234</RoutingNo>
<Amount>1234.12</Amount>
</BillingRequest>
Listing 3 : Common Internal format of Billing Request
A common internal format will keep things simple. This will require
the web service provider to pre-process the request, ensure that it
has all the information required and convert it into the common
internal format. It is good practice to do this pre-processing and
transformation at the web tier itself. This is because any error in
the incoming request will be caught before any processing happens on
the request. This will save precious time and save unnecessary trips
to the EJB tier where the business logic resides. Keeping a single
common internal format of the request obviates the need for the
business logic to know about different request formats. This will help
keep the application loosely coupled and help addition of some other
new request format for some new customer very easy. The XSLT feature
of the JAXP APIs may be used efficiently for this pre-processing and
transformation.
Security: Along with pre-processing of incoming
requests, security also has to be managed by the web service at the
web tier itself. SSL is the best choice to implement security. In
addition, user name and password may have to be included in each
request. One more way to implement security will be to register
customers of the web service off-line and allow online access to them
through the form-based login mechanism of the J2EE platform.
Processing The Document: Once the user is
authenticated and the document is validated, the next step is to
process the contents of the XML document. The processing of XML
documents can be done in two ways: the DOM way and the SAX way. The
Java APIs for XML Processing (JAXP) support both ways of processing
XML documents. The Document Object Model (DOM) APIs convert the XML
document into a tree which can then be traversed to get the
information. The SAX APIs convert the XML document into a series of
events which have to be handled by user defined handlers. The figure
below depicts the SAX and DOM operation.
The following are some of the issues that a web service implementor
will have to keep in mind while deciding which way of processing to
use for parsing XML documents:
DOM Processing: The DOM way of processing XML is
memory and bandwidth intensive. But programming using the DOM APIs is
very simple, as the APIs provide an efficient way to build, as well as
traverse the tree. Availability of higher level APIs , like JDOM and
DOM4J, on top of DOM, makes DOM parsing much easier. DOMs are
especially useful if the XML document undergoes changes while the
request is being processed. This is because it is easy to add, delete,
or modify contents of an XML document represented as a DOM
tree. Building the DOM tree of an XML document and using it is better
within the same VM. When interacting with other systems or VMs, it is
better to pass around the document as XML document rather than DOMs
because serialization of large DOM objects is expensive. Furthermore,
if the web service request triggers a workflow, it may be better to
split the incoming XML documents into logical DOM fragments and pass
the appropriate fragment to the appropriate part of the
workflow. Doing this will reduce unnecessary processing of the
complete XML document at various part of the workflow.
For example, consider the XML document listed below. This request
could be coming to a web service that provides the functionality of an
Order Fulfillment Center. The XML document has all the information --
like user details, order details, item details, shipping details
etc. -- that is required to process an order placed by a customer. For
argument sake, assume that this document is big.
<CustomerOrder>
<UserDetails>
<Name>John Doe</Name>
<UserId>doedoe</UserId>
<CredirCard>4354543545</CreditCard>
<CardType>VISA</CardType>
<Expiry>10/2005</Expiry>
<!-- Other User information -->
</UserDetails>
<OrderDetails>
<OrderId>1234</OrderId>
<OrderType>URGENT</OrderType>
<!-- Other Order information -->
</OrderDetails>
<ItemDetails>
<ItemName>some item</ItemName>
<ItemId>KJ3423</ItemId>
<!-- Other Item information -->
</ItemDetails>
<ShippingDetails>
<Name>John Doe</Name>
<Street>1234, some street</Street>
<!-- Other Address information -->
</ShippingDetails>
</CustomerOrder>
Listing 4: XML document having order details
For processing an order, the web service will have to implement a
complete workflow. For example, this web service will have to get
credit approval for the user's credit card, ensure that the items
ordered are available, commit the order, get the items shipped, and so
on. The XML document is likely to have a life until the complete
workflow is over. It makes sense to process this document using DOM,
create a DOM tree and use this tree throughout the life of the
workflow. It may also be decided to keep the status of the workflow as
part of the XML document. In that case, again, DOM is ideal, as it is
easy to modify the DOM tree. If this workflow is going to be
implemented through the use of Enterprise JavaBeans distributed
in different VMs or by using other web services, it makes sense to
split this big document into logical fragments like a fragment
representing UserDetails, a fragment representing order details,
etc. These fragments can be sent to individual workflow implementors
for further processing. Thus unnecessary processing of complete XML
documents at different places can be avoided.
One more point to keep in mind while processing the request is to
keep the XML document as a document until the time when information in
that document is definitely required, because in a workflow not every
piece may need to understand the document fully. In the above example,
the web service may have to run some preliminary checks before
starting the actual workflow. If those preliminary checks fail, the
workflow may not even be started. In such a case, the time spent on
processing the document is a waste. Thus it is better to keep the
documents received as it is until there is an absolute need to get
information from the document.
SAX Processing: The SAX way of processing XML offers a serial access to the XML document contents. This way of processing
the XML document is really fast. But programming with SAX is more complex. SAX may be ideally suited for XML documents that are read
once, some action taken, and no changes made to the document. For example, listed below is a XML document that contains the
configuration information. For argument sake, assume that this XML document is large.
<ConfigInfo>
<ServerName>someserver</ServerName>
<ServerPort>7000</ServerPort>
<Protocol>HTTPS</Protocol>
<Login>YES</Login>
<!-- Other configuration information -->
</ConfigInfo>
Listing 5: XML document having configuration details
This could be an XML document that a web service uses to understand a service requester's configuration. This information could be
used while processing and sending back the response. It is to be noted that such configuration information is going to be used by the
web service only once and there is no need to save the information. This information is not going to be changed by the web service.
Hence in this case, SAX processing is ideal as the speed that SAX offers can be effective and none of the advantages of DOM processing
are useful in this scenario.
Response
Generation by the Web Service
After processing the request, comes the generation of the contents
for response. Just as the incoming request, the response will also
have to be a XML document. Generating the content through DOM is best
suited for this. The flexibility that a DOM tree provides with regard
to modification comes in handy while generating the response. It is a
good practice to generate the response in the web tier of the
service. Generating the response at the web tier will enable
customization of the response while using a common internal format for
processing the request. This will keep the design of the business
logic simple and there will be no duplication of code. Generating the
response at the web tier will also enable assembling all required
information before building the response. Thus passing the DOM tree
around is avoided. There is also an added advantage of applying
uniform transformations for all responses when it is done in the web
tier. Such uniform transformations can be applied either through the
use the Servlet Filters mechanism or through the use of JavaServer
Pages tags.
Web
Service Interaction Styles
So far we have seen processing of web service requests and
generation of responses. The next issue to be addressed is how to
design the interaction between web service providers and web service
requesters. Here are a few point to note while designing this
interaction.
The first point that should be addressed is the message
exchange. The Simple Object Access Protocol (SOAP) is emerging as the
standard for exchanging XML documents. SOAP is a wire protocol in the
lines of IIOP and JRMP. It is a text based protocol that uses XML
based data encoding format and uses HTTP/SMTP for transport of the
messages. SOAP is independent of the programming language used or the
platform on which the application is running. Because of these, SOAP
is emerging as the standard used for message exchanges in web
services. The Java APIs for XML Messaging (JAXM) technology supports
SOAP messaging. Of course it must be noted that while SOAP is emerging
as the standard for message exchanges, passing XML document using HTTP
POST can be also be used.
When considering frequency of message exchanges, exchanging lots of
messages with each of them containing bit and pieces of information,
is obviously least efficient. The fact that creating a SOAP message
has some overhead should be kept in mind. There is also some cost in
sending SOAP messages. So instead of sending bits and pieces of
information back and forth (in other words doing fine grained access
of information), the information exchange should be done in a more
consolidated manner (in other words the information exchange should be
in a coarse grained manner). Fine grained message exchanges will
degrade performance. Another important cost in fine grained message
exchange is the cost of the communication in terms of network delays
and bandwidth issues. Such fine grained access will also make
designing the web service more difficult because extra care needs to
be taken while handling errors (like error handling and cleanup for
errors that happen while fine grained accesses are underway, etc.)
Sending all information as part of the request and sending all
responses in one shot keeps the design simple, error handling easy,
and improves performance.
Next point to be kept in mind is the level of coupling. This can
also be viewed as a debate between RPC versus document based
messaging. It is a good practice to use document-based messaging over
SOAP. In this approach, an XML document (that has the request) is
transferred as part of the payload of the SOAP message. The receiver
will get the payload, parse the XML document and respond. Such a
message exchange will result in loose coupling as there is no need for
the interacting objects to know the remote methods. Moreover, since
all relevant data will be sent as part of the document, the
interactions will be self-contained.
Web Services
for Legacy Integration
So far we have seen how to offer web services while using existing
enterprise applications, along with some points to note while
accepting and processing web service requests. However we did not
address the place of web services among legacy systems. Most legacy
systems are not open. That leaves the question of web services
vis-a-vis legacy systems open. This question must be answered clearly
because lots of investment has already been made in legacy
systems.
The J2EE platform readily answers this question. The Connector Architecture
of the J2EE platform allows legacy systems to be connected to and used
by J2EE applications. The figure below depicts an overall architecture
of using web services for legacy integration.
The J2EE Connector architecture defines a standard architecture for
connecting the J2EE platform to heterogeneous Enterprise Information
Systems (EISs). Examples of EISs include ERP, mainframe transaction
processing, database systems, and legacy applications not written in
the Java programming language. By defining a set of scalable, secure,
and transactional mechanisms, the J2EE Connector architecture enables
the integration of EISs with application servers and enterprise
applications.
Thus, as shown in figure 3, legacy systems can be connected to
enterprise applications running on the J2EE platform which can be
exposed as a web service. This allows for faster delivery time to
market using J2EE without having to re-factor the legacy system. This
will also enable taking advantage of the tightly integrated
transaction processing and security features of legacy systems. It is
worth noting that if there is not much business logic to be done, then
the legacy systems can be accessed through the connector directly from
the web layer (JSP/Servlets) or from Java programs directly.
Conclusion
In this article, some early thoughts of the J2EE BluePrints program
on the world of web services and forthcoming features of the J2EE
platform that will enable development of web services were
discussed. Some ideas on how existing enterprise J2EE applications as
well legacy systems can expose their functions as web services were
presented. Some prelimiary thoughts on processing of incoming web
service requests and generation of response were also discussed. As
the open XML standards mature and actual implementations of web
service technologies are available, the J2EE BluePrints program will
keep updating its list of best practice guidelines along with sample
applications that will enable developers "web service-enable" their
existing applications and develop new web services.
Print-friendly Version
