Patterns: Implementing Self-Service in an SOA Environment

158 Patterns: Implementing Self-Service in an SOA Environment

򐂰 EAD4J.Opal handles logging.

򐂰 EAD4J.Ruby handles the XML/XSLT transcoding issues.

EAD4J is more than a Web application solution framework. EAD4J provides

solutions for batch processing, interfaces with thick clients, back-office

applications, or integration into existing applications using only a single

component of the EAD4J suite. In addition to the code, EAD4J provides

documentation, UML models, extensive Javadoc™, reference applications, and

training, all required by customers who need an application infrastructure for

mission critical and enterprise scale applications.

7.2.7 WebSphere command framework with EJBs

This section discusses the motivation for using the shippable command model in

e-business applications with enterprise beans. We discuss how the command

framework can be used with session and entity beans for the application model.

For a full discussion of the WebSphere command framework, see the following

publications:

򐂰 Design and Implement Servlets, JSPs, and EJBs for IBM WebSphere

Application Server, SG24-5754

򐂰 Self-Service Patterns using WebSphere Application Server V4.0, SG24-6175

More information about the command pattern is available in Design Patterns:

Elements of Reusable Object-Oriented Software.

Command model

In their most basic form, commands simply encapsulate some request for

information or action. Commands are particularly useful for significant program

boundaries, such as the boundary between presentation code and business

logic.

To use commands you must perform the following steps:

1. Create (instantiate).

2. Initialize by setting some of the command’s properties. This can be done in

one of the command's constructors by calling some of the command’s set

methods, or by a combination of two mechanisms. All commands must have

a no-argument constructor to comply with the JavaBeans standard, but they

can also have convenience constructors that take initial values for the

command’s properties.

3. Call the command’s execute() method. This is a no-argument method that

makes the command's output properties ready for access.

Chapter 7. Application and system design guidelines 159

Optionally, you can perform the next step:

4. Inspect the command’s output properties by calling get methods. Depending

on how you implement your commands, some operations might not require

any output parameters.

The command package

WebSphere V6.0 includes support for the command model as formalized in the

command package (com.ibm.websphere.command) and extended to

accommodate command shipping (called TargetableCommands). The concept

behind command shipping is to intercept the execute method, ship the command

to a better execution point (say on a remote server), execute it there, and then

ship it back to the caller.

The command package is available to any WebSphere Java application. For

example, you can implement command shipping using an entity bean. When

execute() is called on a command, performExecute(TargetableCommand

targetableCommand) is called on the entity bean. Or, for example, you could

implement command shipping using a

catcher servlet. In this approach, the

CommandTarget class would construct and send an HttpServletRequest to a

servlet on the EJB server. The servlet would retrieve the command from the

request, execute it, then store the executed command in the

HttpServletResponse object for return to the CommandTarget.

Both of these approaches are valid. The choice of which to use can depend on

whether you want your servlet and EJB environments completely separate.

Security is also a factor. The EJB approach transports over IIOP, which can

present a problem in environments with strict firewall rules. The servlet catcher

uses HTTP for the protocol, but in some environments Internet protocols are not

allowed to pass through the firewall from the presentation layer to the application

layer.

Advantages and disadvantages of command shipping

The command shipping model has several compelling advantages:

򐂰 It is a direct extension of the base command model and therefore maintains

the same programming style and tooling advantages.

򐂰 It isolates application logic from communication protocols and routing

policies. This allows the best protocol to be selected without requiring

extensive application changes. Indeed, using techniques such as dynamic

class loading, new protocols can be supported

on-the-fly without the need to

change or recompile existing code.

򐂰 It supports an agent-oriented service definition model in which the service

provider provides a functional interface without consideration for distribution

overhead. The service client then defines commands based on the service