In any complex developments, similar patterns and problem solutions occur repeatedly. Judiciously abstracting and packaging such patterns and solutions can give developers a library of reusable components and, ultimately, save development and testing time. This chapter deals with engineering Java CAPS solutions for reusability, packaging of functionality as services, and implementation of technologies that can be used for service interfaces. In particular, reusing Java CAPS components through the JMS Request/Reply, HTTP Request/Reply, eInsight subprocesses, and eInsight-based Web Services is discussed. Both Request/Reply, Notification, and OneWay WSDL-based subprocesses and Web Services are discussed.
In Chapter 4, “Message Exchange Patterns,” section 4.5.1, the use of JMS for implementation of the Request/Reply pattern was discussed. It was noted that a JMS responder could be constructed as a reusable component, able to be invoked from various parts of the overall solution using the JMS requestResponse() method. This is one way in which loose coupling could be achieved. The trick is to ensure that the functionality embedded in such a component is generic enough to be reusable.
It was pointed out that a Business Process cannot directly invoke a JMS Request/Response component, since the JMS object lacks the appropriate service. A Wrapper Java Collaboration that allows the Business Process to invoke the requestReply() method was shown. This collaboration accepts an opaque string message and, after performing a JMS Request/Response operation, returns the response as an opaque string. This is an example of a generic, reusable component. This wrapper collaboration can be used in numerous places, since the only thing that must be varied is the JMS request queue name, and that name is set in the connectivity map. The result is a universal JMS Request/Reply wrapper for use in any eInsight Business Process!
It may be observed that an HTTP Client eWay would typically submit a body of data to an HTTP Server identified by a URL dynamically set by the eWay itself or statically configured in the HTTP Client External System container. The HTTP Request/Response interaction using the HTTP eWay always involves a number of steps, which somewhat vary depending on whether HTTP GET or HTTP POST operations are implemented, whether HTTP headers are sent or received, whether cookies are used, and what the payload type is. All in all, a minimum of several lines of Java code or several BPEL mappings are required.
By defining appropriate input and output messages, we could construct a New Web Service collaboration that would wrap the HTTP request and response interaction into a reusable component. This component could then be used from any eInsight Business Process that needs to invoke HTTP Request/Reply functionality with minimum fuss and no knowledge of HTTP interaction details. The input message could consist of two fields: a possibly empty URL and a request body text. The output message could consist of two or three fields: a status (success/failure) field, an optional status text field, and a response body field.
Other kinds of reusable functionality can be similarly wrapped into New Web Service Java Collaborations and used in multiple eInsight Business Processes. One kind that springs to mind is a large and complex Object Type Definition (OTD)-based transformation, such as HL7 2.3 to HL7 2.4 mapping, where the number of OTD nodes to be mapped exceed about 20 or so and where subtree mapping is repeated a number of times.
Chapter 10, section 10.2, “Using New Web Service Collaborations,” in Part II (located on the accompanying CD-ROM), implements and exercises an example reusable HTTP Request/Response collaboration.
A reusable Java Collaboration component can be used equally readily from any number of eInsight Business Processes. The processing logic it implements can be arbitrarily complex; for example, it can be built to cope with HTTP Response codes in the 300 to 399 range, HTTP redirects, or it can accept a list of URLs and try each in turn until successful.
Other reusable components can be built in this manner to encapsulate arbitrary reusable logic to be invoked by multiple eInsight Business Processes.
A Business Process–based integration solution can be implemented as a series of eInsight Business Processes, possibly related in a hierarchical manner, to achieve desired granularity of design and monitoring. This section deals with constructing eInsight subprocesses, which can be invoked as activities in other eInsight processes, their types and their implementation details.
Note that most of this discussion applies to eInsight Business Processes exposed or consumed as Web Services, using the HTTP Binding, from activities in eInsight Business Processes. Where relevant, the differences will be noted. The principle difference is that subprocesses, using an internal transport, must be deployed to the same Integration Server as the processes that invoke them. Web Services, on the other hand, can be deployed to different Integration Servers without restrictions. For logical partitioning of an eInsight-based solution, subprocesses are appropriate; for physical partitioning, Web Services or endpoint-based partitioning are required.
eInsight, based as it is on Business Process Execution Language for Web Services (BPEL4WS), treats all activities as Web Service invocations. As a consequence, creation of an eInsight subprocess begins with the creation of a Web Services Description Language (WSDL) interface contract document—a WSDL definition. This can be achieved using Java CAPS’s built-in WSDL Editor or using a third-party tool and importing the WSDL. Bear in mind that Java CAPS expects WSDL definitions to be WS-I compliant. If the WSDL you have is not WS-I compliant, there is a distinct possibility that it will not be accepted at all, that it will not parse correctly, or that the resulting service will fail at runtime.
A typical WSDL 1.1 definition consists of a series of related sections in two groups: the service interface definition and the service implementation definition, illustrated in Listing 12-1. WSDL 1.2 changed terminology—the portType is an interface, and the two groups are called abstract and concrete respectively.
Example 12-1. WSDL 1.1 definition skeleton
<definitions xmlns:xsd="..." ... >
<types>
...
</types>
<message name="...">
...
</message>
<message name="...">
...
</message>
<portType name="...">
<operation name="...">
<input name="..." message="..."/>
<output name="..." message="..."/>
...
</operation>
</portType>
...
</definitions>The types section, using the XML Schema conventions, defines data elements and types that can be used in message sections to define the structure of messages that will be used by the Web Service. Instead of, or in addition to, defining types directly within the WSDL document, you can import existing XML Schema documents.
The message sections define messages, based on types defined or imported previously, that can be used by the Web Service as input, output, or both.
The PortType section defines the Web Services operations and associates messages with these operations. PortType is a rough equivalent of a class or a module. Operations are rough equivalents of methods or functions within that class or module.
Additional sections, not used when creating eInsight subprocesses, are the binding section and the service section, which belong to the interface implementation definition or concrete section.
WSDL 1.1 specification has a notion of four types of Web Services, classified according to how they interact with the invokers. The most common and most widely supported is the Request/Response Web Service. Much rarer are OneWayOperation Web Services, where a SOAP Message is sent without an expectation of a response, and Notification Web Services, where a SOAP Message is received without an expectation of having to provide a response. Finally, a Solicit/Response is a service where a SOAP Message sent to a service causes a service to send an asynchronous notification SOAP Message that is correlated with the original solicit message.
eInsight directly supports Request/Response and OneWayOperation services. It, with some cheating, supports notification services as well. Solicit/Response is not supported, or I have not found a way to make it work with WSDL and the built-in Web Services implementation framework.
Given the support for different types of Web Services, you can implement three kinds of main process/subprocess relationships as well as Web Service invoker/provider relationships.
An ordinary request/response relationship is one where a main process invokes a subprocess, passing it an input message, blocking until the subprocess performs its work, and receiving an output message from it. The main process can invoke any number of subprocesses—this is the basis for Business Process orchestration and construction of composite applications.
A OneWayOperation relationship is one where a main process invokes a subprocess with an input message and continues while the subprocess is started and proceeds independently of the main process. In effect, a OneWayOperation subprocess executes in parallel with the main processes from the point at which it was invoked. This relationship is a OneWayOperation as viewed from the main process’s perspective.
A notification relationship is one where a subprocess submits an output message to a main process waiting at a receive activity and both proceed in parallel from that point onward. This relationship is a notification relationship as viewed from the main process’ perspective.
If the receive activity in the main process of the notification relationship is the first receive activity, or the receive activity of a subprocess in the OneWayOperation relationship is the first receive activity, the implementation is the same. The difference is a logical classification of processes into main and subprocesses.
WSDL 1.1 Specification is readily available. This section does not elaborate on the subject any more than is necessary to create basic WSDL definitions for use in development of eInsight subprocesses; the practical manner in which the WSDL definitions are created here may depart somewhat from the dogma.
A Request/Response subprocess is one that accepts an input message, performs some work, and returns a response message. While the subprocess is busy, the invoker waits.
All messages in WSDL, both input and output messages, are defined using the XML Schema semantics within the types section of the WSDL or within the XML Schema document imported into the WSDL.
The WSDL document, defining the subprocess interface, specifies only the service interface definition, or abstract section. eInsight takes care of the implementation details. This is one of the major differences between creating WSDL definitions for subprocesses and creating WSDL definitions for Web Services.
Chapter 10, section 10.3.1, “Request/Response Subprocess,” in Part II, contains a complete example implementing a Request/Response subprocess solution.
The amount of functionality encapsulated within the subprocess is arbitrary, dictated by the requirements of the solution under construction. The subprocess can be invoked by any number of other Business Processes located in arbitrary project hierarchies, not necessarily the same as the subprocess itself. The connectivity map makes the association between the subprocess and the process that calls it; therefore, since the components on the connectivity map can come from any number of arbitrarily organized projects, a library of common reusable subprocesses can be constructed.
Unlike in a Request/Response relationship, where the invoker blocks until the subprocess returns the response, in a OneWayOperation relationship, the main process submits the input message to the subprocess and continues without waiting for the subprocess to complete. In fact, the main process and the subprocess execute in parallel from the point of invocation, and the invoking process may complete before the subprocess does.
Chapter 10, section 10.3.2, “OneWayOperation Subprocess,” in Part II, illustrates a OneWayOperation Subprocess with a complete Java CAPS implementation example.
OneWayOperation subprocess can be used in a variety of integration solutions. The main process and the subprocess must appear in the same connectivity map and will therefore be deployed to the same Integration Server. You can encapsulate an arbitrary amount of postprocessing business logic in a OneWayOperation subprocess for reuse where required.
As mentioned before, a notification relationship is one where a subprocess submits a message to a main process whose instance does not exist, causing a process instance to be created, or to an existing instance of a process waiting at a receive activity. Both proceed in parallel from that point onward. This relationship is a notification relationship as viewed from the main process’s perspective. eInsight does not directly support the use of notification WSDL, like the WSDL shown in Listing 12-2.
Example 12-2. Notification subprocess WSDL
<definitions
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:cust="http://seebeyond/Notification"
xmlns:tns="http://seebeyond/wsdlNotification"
targetNamespace="http://seebeyond/wsdlNotification"
>
<types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import
namespace="http://seebeyond/Notification"
schemaLocation="Notification.xsd"/>
</xsd:schema>
</types>
<message name="msgNotification">
<part
name="msgNotification"
element="cust:NotificationMsg"/>
</message>
<portType name="prtNotification">
<operation name="opNotification">
<output
name="msgNotification"
message="tns:msgNotification"/>
</operation>
</portType>
</definitions>Despite what some tools might say, this WSDL is perfectly valid. eInsight will happily import and validate it. However, dragging the Web Service operation from the WSDL object to the eInsight Business Process Editor canvas will produce an error dialogue box, illustrated in Figure 12-1.
To implement a notification relationship using eInsight, some cheating is called for. The technique is discussed and illustrated with an example in Chapter 10, section 10.3.3, “Notification Subprocess,” in Part II.
The business excuse for using notifications, much as Request/Response and OneWayOperation subprocesses, is that the main process deals with business objects at a fairly high level. It orchestrates services, each of which implements a considerable amount of business logic, but it does not do detailed business processing itself. A fair amount of processing must be done to input messages before they are ready to be submitted to the main process for on-passing to other components. This is one way of refactoring large processes into a hierarchy of subprocesses orchestrated by an overseer process. The subprocess must be able to kick-start the main process via a receive activity, which is the only way to cause instance creation; therefore it must be representable as a receive activity. The notification subprocess, as built following the technique presented here, is such a subprocess.
As before, an arbitrary amount of business logic can be implemented as a subprocess. This subprocess can then be reused by the solution wherever required, as a single activity in a main process.
Recall discussion of the Request/Response subprocess where it was said that until the connectivity map is constructed, there is no difference between implementing a subprocess and implementing a Web Service with the same abstract interface, or service interface definition, as WSDL 1.1 has it. Rather than connecting a main process and subprocess directly, we introduce a Web Services external application between the two, as illustrated in Figure 12-2.
This is where the relationship that was formerly a main process/subprocess relationship becomes a Web Services invocation/provision relationship. Rather than using some internal mechanism, as was done in the subprocess’s case, the deployment will explicitly use a SOAP over HTTP mechanism for communication between the invoker and the invoked. Note that when connecting the process to the Web Services external application object, we implicitly created the binding section of the concrete implementation or, as WSDL 1.1 would have it, the service implementation definition. We did not specify the service part of the concrete implementation. The service configuration is done via the properties of the Web Services external system containers in the Java CAPS environment.
Note
When on the subject of service configuration, please note that the “servlet context” that is specified in the SOAP/HTTP Web Services external system container in the environment is different in Server mode from the one specified in the Client mode even for the same service.
Consider the Server mode container properties shown in Figure 12-3.
The servlet context property is what you specify when you configure the container. The PortName is provided for you through the connectivity map–defined binding stanza and cannot be changed. The final URL for the service will be:
http://localhost:20001/wsrequestresponse/prtRequestResponseBndPort
In contrast, consider the Client mode container properties illustrated in Figure 12-4.
This is a trap for the young players who may waste large amounts of time diagnosing. The servlet context here consists of the Servlet Context string from the Server mode container suffixed with the slash (/) and the PortName from the Server mode container—not, as the uninitiated would expect, just the Server mode servlet context. This is undoubtedly documented somewhere, but all the same, beware.
This means that each Web Services implementation Business Process will have to be deployed to a different SOAP/HTTP Web Services external system container, as the PortName will be different for each!
If you get the client-side URL wrong, the server.log error messages will be totally useless insofar as indication of the source of trouble is concerned, ranging from Invalid content-type: text/html to NullPointerException and Java stack trace.
This discussion is illustrated with an example in Chapter 10, section 10.4.1, “Request/Response Web Service,” in Part II.
For continuity of argument, we reused the single connectivity map. This causes both the invoker and the invoked to be deployed to the same Integration Server. Rather that restricting ourselves to that, we could have broken the connectivity map into two: the service implementation, containing the Web Services Server external application and the sbpRequestResponder process, and the service invocation, containing the bpServiceRequestor process, the JMS Destinations, and the Web Services client external application. This way, each of the now independent components could be deployed to a different Integration Server on the same or on different hardware platforms. Even though the original connectivity map contained both the invoking and the invoked (provider) services, the provider was advertised through the UDDI Registry upon build and could be invoked independently of the invoker.
Much as the Request/Response subprocess–based implementation was made loosely coupled and distributable by changing it into a Request/Response Web Services–based implementation, so too can the OneWayOperation subprocess–based implementation be changed into a Web Services–based one, applying exactly the same technique as was applied to the Request/Response service. Here too the single connectivity map could be broken into two, the requester and the responder, and both applications could be deployed to different Integration Servers.
Much as the Request/Response and OneWayOperation subprocess–based implementations that were made loosely coupled and distributable by changing them into Request/Response and OneWayOperation Web Services-based implementations, so too the Notification subprocess–based implementation can be changed into a Web Services–based one.
Chapter 10, section 10.4.2, “Notification Web Service,” in Part II, reimplements the Notification subprocess example as a Web Service.
You will have undoubtedly noticed that whether in the case of the Request/Response, OneWayOperation, or Notification implemented using a subprocess, or in the case of the Request/Response, OneWayOperation, or Notification implemented using a Web Services invocation, the eInsight processes involved were identical. No changes whatsoever were made to the processes to deploy them as Web Services rather than as main process/subprocess. You will also have observed by now that regardless of where within the project/subproject hierarchy a component, such as a Business Process, exists, it can be included in a connectivity map defined in a totally different place in the process/subprocess hierarchy. This was demonstrated in the previous section. It should then come as no surprise that an eInsight Business Process, implemented as a service, can be deployed both as a subprocess and as a Web Services provider in different, or even in the same, connectivity maps. This in turn leads to the notion of service process libraries, implementing specific functionality, that are used to compose higher order solutions in a tightly coupled (subprocess invocation) or loosely coupled (Web Services invocation) manner as needs dictate.
This chapter dealt with facilities that help an enterprise architect engineer Java CAPS solutions for reusability and package functionality as services and implementation technologies that can be used for service interfaces. In particular, reusing Java CAPS components through the JMS Request/Reply, HTTP Request/Reply, eInsight subprocesses, and eInsight-based Web Services was discussed. Request/Reply, Notification, and OneWay WSDL–based subprocesses and Web Services were discussed.