This chapter discusses message transformation patterns and how they can be implemented in Java CAPS.
Java CAPS toolbox provides support for message transformation within Java Collaborations, within Business Process Execution Language (BPEL)–based Business Processes and within XSLT Collaborations. Whichever method is used, the source message must be represented as an Object Type Definition (OTD) and the destination message must be represented as an OTD.
[eDesigner] discusses the use of Java Collaborations and XSLT Collaborations for message transformation in detail. [eInsight] discusses the use of business rules in a process model for transformation.
Envelope Wrapper and related concepts are discussed at length in Chapter 7, “Message Construction,” section 7.4.
Content Enricher [EIP] is a component that receives a message, enriches it by adding information not already carried in the message, and passes on the enriched message. Additional information, such as order-total calculation using item quantities and item prices carried in the message, could be computed by an algorithm implemented in the Content Enricher. Additional information, such as a timestamp, could be obtained from the environment in which the solution operates. Additional information could also be obtained from an external system—for example, item price could be looked up in an inventory system given the item number carried in the message. All three methods of obtaining additional information can be combined; for example, transforming a purchase order into an invoice could involve looking up item prices in the inventory system, calculating item totals and order total, obtaining the invoice date from the environment, and assembling an invoice message containing both the original the order information and the additional information produced by the Content Enricher. Content Enricher is a specialized Message Translator [EIP].
In Java CAPS–based solutions, Content Enricher is one of the most commonly implemented components. It can be implemented both as a Java Collaboration and as an eInsight Business Process. Facilities to obtain environment values, such as timestamps, are built right into the infrastructure through Java language facilities and BPEL functions. A plethora of eWay Adapters can be used to obtain information from external systems. Arbitrary business algorithms can be implemented using both.
Chapter 6, section 6.2, “Content Enricher,” in Part II (located on the accompanying CD-ROM), illustrates this discussion with a detailed example.
Content Filter is another specialized Message Transformer. Unlike a Content Enricher, which adds information to messages, a Content Filter [EIP] removes information from messages before passing them on. Reasons for removing content from messages are many. They vary from the need to reduce message size for transportation, to externalizing static information to improve message system performance, to removing sensitive information before passing messages to external systems with no “need to know.” Other reasons for the use of Message Filters might be the desire to “flatten” a highly structured message for ease of processing or the desire to implement a Splitter as a series of Message Filters operating on copies of an original message through a subscription mechanism. Java CAPS OTD framework can be readily used to transform messages both in Java Collaborations and eInsight Business Processes, including implementing arbitrarily complex Message Filters.
The Claim Check pattern [EIP] is a solution in which some information is removed from a message in a processing step, then retrieved by some subsequent processing step. Intermediate processing steps deal with a smaller message, one that does not contain “uninteresting,” “irrelevant,” or “sensitive” information. Claim Check, unless implemented as a Business Process, requires the use of at least three individual components and a backing store. This is why it is classified here as a solution rather then as a component. The initial step is, in essence, a Message Filter. The final step is, in essence, a Message Enricher.
In a Claim Check solution, the Message Filter transforms an incoming message into two messages: a reduced message that contains information to be passed on and a “to-be-stored” message that contains either the entire original message or those parts of the original message that are not to be passed along. In order to allow a downstream Message Enricher to gain access to information removed in this step, the removed information must be stored in a backing store. Before storing the message, the Message Filter must create a unique identifier to be associated with this information. This unique identifier is added to the reduced message for passing along. It is also associated with the stored message to facilitate later retrieval. This identifier becomes the Claim Check. Intermediate components operate on the reduced message in whatever manner is appropriate, taking care to preserve the Claim Check. Once the reduced message reaches the Message Enricher, the Claim Check is used to retrieve information from the backing store and enrich the message or reconstitute the original message.
[EIP] discusses various ways in which the unique identifier can be generated. If the message volume is low, fewer then one message per millisecond, java.utilDate().getTime() can be used to generate a timestamp-based unique identifier. If the volume may vary and may exceed one message per millisecond, this method is not appropriate. To reduce the possibility of duplicates, you could use java.rmi.server.UID, java.rmi.dgc.VMID, or some other implementation of a Globally Unique Identifier (GUID).
The backing store, necessary to this implementation, could be a Java Database Connectivity (JDBC)–compliant database, accessed via an appropriate Java CAPS database eWay Adapter, or a file in a file system, accessed through one of the Batch eWay variants. The key requirement is that both the Content Filter and the Content Enricher have access to that store.
The preceding discussion assumes that separate Java Collaborations are used as the Message Filter and the Message Enricher; consequently, an external Message Store is required.
Using Java CAPS eInsight Business Process, the Claim Check can be implemented as a single component with no external message store and no need for a unique identifier. A message, received by a Business Process Instance, can be transformed into a message expected by some intermediate component. The Process Instance can invoke this component, passing it the reduced message, and receive a response. It would then use the response and the original message, to which it still has access, to create a final message to pass on to a component downstream from it. The Message Filter is implicit in the initial message transformation. The Message Enricher is implicit in the final message transformation. The message store is internalized to the Business Process Instance, as the message continues to be accessible to the Process Instance while not being accessible to the intermediate component the instance invoked. This implementation is typical of what an eInsight Business Process would do, so attaching the name of Claim Check seems contrived. To follow [EIP] discussion of using Process Manager with Claim Check, this is what such a Business Process implements.
Message Normalizer [EIP] is a component that transforms messages with the same informational content, but of different formats, into a Canonical Message Format. Normalizer may be required where there are multiple systems, perhaps acquired through mergers and acquisitions, that send the same kinds of messages, perhaps purchase orders. The purchase orders receiving system can only deal with purchase orders of a specific format. Normalizers, introduced between sending systems and the receiving system, transform purchase orders from sending systems’ native formats to a format that the receiving system expects or the canonical format if one is in use in the enterprise.
The Java CAPS OTD framework would be used to create OTDs corresponding to the various message formats, and Normalizers would be constructed using Java Collaborations or eInsight Business Processes to transform between formats.
When message senders and receivers use different message formats, it is necessary to deploy message transformation components. A naïve approach would see a message transformation component built for each sender and receiver pair. Such an approach would rapidly lead to exponential growth in the number of message transformations and, ultimately, to a messaging solution that is brittle and difficult to manage. If there are a significant number of message senders and receivers that use different message formats or whose number is expected to grow over time, it can become a significant issue. Canonical Data Model [EIP] is a solution that introduces an intermediate message format. Messages arriving into the system are transformed to the canonical format and passed around in that format. Outgoing messages are transformed from the canonical format to the format expected by the external system. This introduces a degree of indirection, decouples senders from receivers, and reduces the number of transformations to the point where it will be at most as large as the number of external systems involved. As a side benefit, each external system and its corresponding message transformation can be replaced without affecting other parts of the system. A drawback of this approach, which needs to be weighed against the benefits, is that messages would need to be transformed twice on the way between the sender and the receiver, increasing resource consumption and increasing latency.
Java CAPS OTD Framework can be used to implement the message formats, and Java Collaborations and eInsight Business Processes can be used to implement transformation rules.
The Canonical Data Model need not be XML based. In traditional healthcare enterprises, for example, a specific version of the HL7 messaging standard might be chosen as the basis of the Canonical Data Model. All other HL7 version messages would be transformed to the chosen version, and other normalization, such as code table synchronization, would be applied, thus producing canonical HL7 messages. Other message structure standards, like X12 or UN/EDIFACT, used in various industries, could similarly be chosen as the basis for Canonical Data Models in appropriate environments.