Given a scenario, design a Java EE web service using Web Services

Design Pattern (Asynchronous Interaction, JMS Bridge, Web Service

Cache, Web Service Broker), and Best Practices.

[PATTERNS] Patterns and Strategies for Building Document-Based Web Services
Asynchronous Interaction
Server-Side Push Implementation
The server-side push implementation decouples the input and output messages for the
interaction. In this implementation, the design is converted so that there are two separate
interactions; one from client to server that the client uses to issue its request to the server,
and another from server to client that the server uses to notify the client of its response:

1. A business document like a purchase order or invoice in XML format is sent as the
SOAP message in the request.
2. The service accepts the document and
a. Does not return any message to the client. This corresponds to a void return
type in the Service Endpoint Interface. If due to HTTP issues the client could
not receive a successful HTTP 200 message or receives a SOAP Fault, then it is
up to the client to retry the invocation or query the service. This retry logic
would need to be built into the application layer.
b. Sends a SOAP message back to the client. The contents of the message are
dictated by the schema in the WSDL. The message would typically contain an
acknowledgement, informing the client that the request is being processed.
3. Once the service receives the message it is placed on a JMS queue for processing at a
later time.
4. The Message Driven Beans deployed in the container actively receive and process the
message containing the XML business document from the queue.
5. The response to the business processing, is also placed on another JMS Queue for
dispatch to the client at a later time.
6. Other Message Driven Beans can pick up the responses use the JAX-WS API to make
client calls to the callback services on the service consumer's side. The responses to
the business could be another XML document.
JAX-WS-Based Implementation
The web services interfaces included in the Java EE specification provide support for non-
portable asynchronous interactions, but only for JAX-WS-based interactions. JAX-WS
introduces the Dispatch<T> andProvider<T> interfaces that are used to describe the client
and server sides to the interaction.
Client-side Dispatch Interface Definition:

// T is the type of the message
public interface Dispatch<T> {

//synchronous request-response
T invoke(T msg);

//async request-response
Response<T> invokeAsync(T msg);
Future<?> invokeAsync(Tmsg, AsyncHandler<T> h);

// one-way
void invokeOneWay(T msg);
}


Server-side Provider Interface Definition:

// T is the type of the message
public interface Provider<T> {

T invoke(T msg, Map<String, Object> context);

}



Client developer may use asynchronous invocations as defined by the JAX-WS specification.
JAX-WS supports asynchronous invocations through generated asynchronous methods on the
Service Endpoint Interface and javax.xml.ws.Dispatch interface. There are two forms of
asynchronous invocations in JAX-WS Polling and Callback.
o Polling
Client asynchronous polling invocations must be supported by components running in
Servlet container, EJB container and Application Client container, since any of these
components can act as JAX- WS clients. Client developers can either use the Service
Endpoint Interface or javax.xml.ws.Dispatch to make asynchronous polling
invocations.
javax.xml.ws.Dispatch - The invokeAsync method returns a Response that
may be polled using the methods inherited from Future<T> to determine when the
operation has completed and to retrieve the results.
SEI - A polling method returns a typed Response<ResponseBean> that may be
polled using methods inherited from Future<?> to determine when the operation has
completed and to retrieve the results:

Service service = ...;
StockQuote quoteService = (StockQuote)service.getPort(portName);
Response<Float> response = quoteService.getPriceAsync(ticker);
while (!response.isDone()) {
// do something while we wait
}
Float quote = response.get();


o Callback
Client asynchronous callback invocations should only be supported by components
running in EJB, Servlet container and Application Client container. Client developers
can either use the Service Endpoint Interface or javax.xml.ws.Dispatch to
implement asynchronous callback invocations. The callback handler must
implement javax.xml.ws.AsyncHandler interface.
javax.xml.ws.Dispatch - The client supplies an AsyncHandler and the runtime
calls the handleResponse method when the results of the operation are available.
The invokeAsync method returns a wildcardFuture (Future<?>) that may be
polled to determine when the operation has completed. The object returned
from Future<?>.get() has no standard type. Client code should not attempt to cast
the object to any particular type as this will result in non-portable behavior.
SEI - A callback method takes an additional final parameter that is an instance of a
typed AsyncHandler<ResponseBean> and returns a wildcard Future<?> that may
be polled to determine when the operation has completed. The object returned
from Future<?>.get() has no standard type. Client code should not attempt to cast
the object to any particular type as this will result in non-portable behavior:

StockQuotePortProxy proxy = ...

// Set up the callback handler.
MyPriceHandler callbackHandler = new MyPriceHandler();

// Make the Web Service call
Future<?> response = proxy.getPriceAsync(ticker,
callbackHandler);




class MyPriceHandler implements AsyncHandler<Float> {
...
public void handleResponse(Response<Float> response) {
Float price = response.get();
...
}
}


JMS Bridge
Provides interoperability between two different JMS implementations.
If the enterprise application is complex enough to run on more than one hardware platform, it is not
uncommon for there to be two or more JMS implementations in play, and interoperability then
becomes an issue. JMS Bridge promotes vendor independence.
The JMS Bridge pattern suggests keeping the different subsystems using their own JMS
implementations, but advocates the introduction of a client into the enterprise application that can
relay messages from one JMS implementation to the next. It decouples an abstraction from its
implementation so that the two can vary independently.

Web Service Cache
JAX-WS programming model provides an application handler facility that enables you to manipulate a
message on either an inbound or an outbound flow. You can add handlers into the JAX-WS runtime
environment to perform additional processing of request and response messages. You can use
handlers for a variety of purposes such as caching, capturing and logging information and adding
security or other information to a message. Because of the support for additional protocols beyond
SOAP, JAX-WS provides two different classifications for handlers.
One type of handler is a logical handler that is protocol independent and can obtain the message in
the flow as an extensible markup language (XML) message. The logical handlers operate on message
context properties and message payload. These handlers must implement
the javax.xml.ws.handler.LogicalHandler interface. A logical handler receives
a LogicalMessageContext object from which the handler can get the message information. Logical
handlers can exist on both SOAP and XML/HTTP-based configurations.
The second type of handler is a protocol handler. The protocol handlers operate on message context
properties and protocol-specific messages. Protocol handlers are limited to SOAP-based configurations
and must implement the javax.xml.ws.handler.soap.SOAPHandler interface. Protocol handlers
receive the message as a javax.xml.soap.SOAPMessage to read the message data.
The JAX-WS runtime makes no distinction between server-side and client-side handler classes. The
runtime does not distinguish between inbound or outbound flow when
a handleMessage(MessageContext) method orhandleFault(MessageContext) method for a
specific handler is invoked. You must configure the handlers for the server or client, and implement
sufficient logic within these methods to detect the inbound or outbound direction of the current
message.
To use handlers with Web Services client applications, you must add the @HandlerChain annotation
to the Service Endpoint Interface or the generated service class and provide the handler chain
configuration file. The@HandlerChain annotation contains a file attribute that points to a handler
chain configuration file that you create. For Web Services client applications, you can also configure
the handler chain programmatically using the Binding API. To modify the handlerchain class
programmatically, use either the default implementation or a custom implementation of
the HandlerResolver method.
To use handlers with your server application, you must set the @HandlerChain annotation on either
the Service Endpoint Interface or the endpoint implementation class, and provide the associated
handler chain configuration file. Handlers for the server are only configured by setting
the @HandlerChain annotation on the service endpoint implementation or the implementation class.
The handler classes must be included in the deployed artifact.
For both server and client implementations of handlers using the @HandlerChain annotation, you
must specify the location of the handler configuration as either a relative path from the annotated file
or as an absolute URL. For example:
@HandlerChain(file="../../common/handlers.xml")

or
@HandlerChain(file="http://java.boot.by/handlers.xml")

To create a JAX-WS handler:
1. Determine if you want to implement JAX-WS handlers on the service or the client.
a. Use the default implementation of a handler resolver. The runtime now uses
the @HandlerChain annotation and the default implementation
of HandlerResolver class to build the handler chain. You can obtain the existing
handler chain from the Binding, add or remove handlers, and then return the
modified handler chain to the Binding object.
b. To use a custom implementation of a handler resolver, set the
custom HandlerResolver class on the Service instance. The runtime uses your
custom implementation of the HandlerResolver class to build the handler chain,
and the default runtime implementation is not used. In this scenario,
the @HandlerChain annotation is not read when retrieving the handler chain from
the binding after the customHandlerResolver instance is registered on
the Service instance. You can obtain the existing handler chain from the Binding,
add or remove handlers, and then return the modified handler chain to
theBinding object.
2. Configure the client handlers by setting the @HandlerChain annotation on the service
instance or Service Endpoint Interface, or you can modify the handler chain programmatically
to control how the handler chain is built in the runtime. If you choose to modify the handler
chain programmatically, then you must determine if you will use the default handler resolver
or use a custom implementation of a handler resolver that is registered on the service
instance. A service instance uses a handler resolver when creating binding providers. When
the binding providers are created, the handler resolver that is registered with a service is used
to create a handler chain and the handler chain is subsequently used to configure the binding
provider.
3. Configure the server handlers by setting the @HandlerChain annotation on the Service
Endpoint Interface or implementation class. When the @HandlerChain annotation is
configured on both the Service Endpoint Interface and the implementation class, the
implementation class takes priority.
4. Create the handler chain configuration XML file. You must create a handler chain configuration
XML file for the @HandlerChain to reference.
5. Add the handler chain configuration XML file in the class path for the Service Endpoint
Interface when configuring the server or client handlers using
the @HandlerChain annotation. You must also include the handler classes contained in the
configuration XML file in your class path.
6. Write your handler implementation.
Web Service Cache pattern:

Opportunities for caching:
1. Client-side transparent to the application cache.
2. Server-side transparent to the application cache.
3. Server-side application-specific cache.
Web Service Broker
A Web Service is a popular way of exposing business services to other applications. The integration of
different heterogeneous systems, however, can typically involve incompatibilities and complexities.
Furthermore, it is desirable to limit the set of services that are exposed by an application as Web
Services. The Web Service Broker pattern uses XML and web protocols to selectively expose and
broker the services of an application. AWebServiceBroker coordinates the interaction among
services, collects responses and performs transactions. It is typically exposed using a WSDL.
The EndpointProcessor class is the entry point into the Web Service, and processes the client
request. The EndpointProcessor then invokes the Web Service through the WebServiceBroker,
which brokers to one or more services.
Problem:
You want to provide access to one or more services using XML and web protocols.
Forces:
You want to reuse and expose existing services to clients.
You want to monitor and potentially limit the usage of exposed services, based on your
business requirements and system resource usage.
Your services must be exposed using open standards to enable integration of heterogeneous
applications.
You want to bridge the gap between business requirements and existing service capabilities.
Solution:
Use a Web Service Broker to expose and broker one or more services in your application to
external clients as a Web Service using XML and standard web protocols:

Consequences:
Introduces a layer between client and service.
Existing remote Session Facades need be refactored to support local access.
Network performance may be impacted due to web protocols.
Coordinates interactions among one or more services, aggregates responses and may
demarcate and compensate transactions.