Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those des-ignations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capi-tal letters or in all capitals.
Sun Microsystems, Inc. has intellectual property rights relating to implementations of the technology described in this publication. Inparticular, and without limitation, these intellectual property rights may include one or more U.S. patents, foreign patents, or pendingapplications.
Sun, Sun Microsystems, the Sun logo, J2ME, J2EE, Java Card, and all Sun- and Java-based trademarks and logos are trademarks or reg-istered trademarks of Sun Microsystems, Inc., in the United States and other countries. UNIX is a registered trademark in the UnitedStates and other countries, exclusively licensed through X/Open Company, Ltd. THIS PUBLICATION IS PROVIDED โAS ISโ WITH-OUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WAR-RANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. THIS PUBLICATIONCOULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TOTHE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THE PUBLICATION.SUN MICROSYSTEMS, INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PRO-GRAM(S) DESCRIBED IN THIS PUBLICATION AT ANY TIME.
The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind andassume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection withor arising out of the use of the information or programs contained herein.
The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may includeelectronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding inter-ests. For more information, please contact: U.S. Corporate and Government Sales, (800) 382-3419, [email protected].
For sales outside the United States, please contact: International Sales, [email protected].
This Book Is Safari Enabled
The Safariยฎ Enabled icon on the cover of your favorite technology book means the book is available through Safari Bookshelf. When you buy this book, you get free access to the online edition for 45 days.
Safari Bookshelf is an electronic reference library that lets you easily search thousands of technical books, find code samples, download chapters, and access technical information whenever and wherever you need it.
To gain 45-day Safari Enabled access to this book:
โข Go to informit.com/onlineeditionโข Complete the brief registration formโข Enter the coupon code RSGP-E1MF-1USJ-UKFG-MUS6
If you have difficulty registering on Safari Bookshelf or accessing the online edition, please e-mail [email protected].
Visit us on the Web: informit.com/ph
Library of Congress Cataloging-in-Publication Data
Java CAPS basics : implementing common EAI patterns / Michael Czapski ... [et al.].
p. cm.Includes bibliographical references and index.ISBN-13: 978-0-13-713071-9 (hardcover : alk. paper)ISBN-10: 0-13-713071-6 (hardcover : alk. paper)
1. Java (Computer program language) 2. Enterprise application integration (Computer systems) I. Czapski, Michael.QA76.73.J38J3633 2008005.13'3โdc22 2008007526
Copyright ยฉ 2008 Sun Microsystems, Inc.4150 Network Circle, Santa Clara, California 95054 U.S.A.All rights reserved.
Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the pub-lisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic,mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc., Rightsand Contracts Department, 501 Boylston Street, Suite 900, Boston, MA 02116, Fax: (617) 671-3447.
ISBN-13: 978-0-13-713071-9ISBN-10: 0-13-713071-6 Text printed in the United States on recycled paper at Courier in Westford, Massachusetts.First printing, April 2008
xiii
Preface
In their book Enterprise Integration Patterns: Designing, Building, and DeployingMessaging Solutions [EIP], Gregor Hohpe and Bobby Woolf elaborate on the subjectof Enterprise Application Integration using messaging. They present, discuss, andillustrate over sixty EAI design patterns. These patterns, they believe, are key pat-terns most designers of EAI solutions will use when building enterprise integrationsolutions. Most examples in [EIP] use raw C# and raw Java to illustrate details ofEAI patterns under discussion. Most of these patterns can be implemented suc-cinctly, elegantly, and comprehensively using tools and technologies provided inthe Sun Java Composite Application Platform Suite [Java CAPS].
This book is about implementing selected enterprise integration patterns,discussed in [EIP], using Java CAPS as the means to building practical enterpriseintegration solutions. It bridges the gap between the somewhat abstract patternlanguage and the practical implementation details. It is designed for integrationarchitects, solution architects, and developers who wish to quickly implemententerprise solutions with Java CAPS. It discusses how enterprise integration pat-terns can be implemented quickly and efficiently by leveraging the Java CAPS toolsand the authorsโ field experience.
While this book discusses Java CAPS implementation of [EIP] patterns, itdoes not discuss the patterns in depth. It is assumed that you are already familiarwith the subject and need to apply the theoretical knowledge using Java CAPS.
This book is also about basics of the essential Java CAPS Suite components,based on the premise that you cannot apply patterns if you cannot effectively use thetools with which to do it. Since the complete Java CAPS offering has so many com-ponents, including ones that are not essential to integration, this book elaboratesonly on the basic integration tools: eGate, eInsight, eWays, and Java Message Ser-vice (JMS).
This book also provides information you may need to effectively use JavaCAPS. A considerable amount of Java CAPS-related material, provided in the text,is not published anywhere else.
xiv Preface
The accompanying CD-ROM provides over 60 detailed examples that illustrateconcepts and patterns under discussion. Some examples are high level, illustrat-ing specific points. Other examples follow a step-by-step approach.
Java CAPS projects discussed and developed as examples are available forimport and perusal.
HOW THIS BOOK IS ORGANIZED
This book is divided into three sections. Section I, โPreliminaries,โ contains chap-ters that discuss integration and background Java CAPS topics, including enterpriseintegration styles, Java CAPS architecture, and project structure and deployment.
Section II, โPatterns Review and Application,โ covers most [EIP] patterns withdiscussion of Java CAPS approaches to implementing them. This section includeschapters dealing with message exchange patterns, message correlation, messaginginfrastructure, message routing, message construction, message transformation,messaging endpoints, and system management patterns and concepts. While dis-cussing Java CAPS implementation of specific patterns, relevant Java CAPS con-cepts and methods are also discussed. When discussing implementations of theMessage Sequence pattern, for example, Java CAPS concepts of JMS serial modeconcurrency, Sun SeeBeyond JMS Message Server FIFO modes, and serializingeInsight Business Processes via JMS and XA are also discussed.
Section III, โSpecialized Java CAPS Topics,โ discusses non-pattern matters ofimportance like solution partitioning, subprocess and Web Services implementa-tion, management, reusability, scalability and resilience options, and others thatare not covered elsewhere. This section also covers security features of Java CAPS.
The accompanying CD-ROM contains over 60 detailed examples implement-ing most of the patterns and concepts under discussion as well as two completeexample solutions using many of the patterns discussed and illustrated in thisbook. The CD-ROM also contains a detailed practical walkthrough of generationand use of cryptographic objects such as X.509 Certificates, PKCS#12 and JKSKeystores, and related matters.
ABOUT THE EXAMPLES
Conventions
Java CAPS Enterprise Designer (eDesigner) is a NetBeans-based Integrated Devel-opment Environment (IDE), which developers use to design and build Java CAPS
Preface xv
integration solutions. The vast majority of tasks can be accomplished in eDesignerby means of manipulating components represented by graphical objects, connect-ing graphical objects with lines, filling information in dialog boxes and propertysheets, and choosing components in drop-down menus. The intention was tomake development of integration solutions easy for business analysts and similarpersons whose coding skills might not be up to the task in nongraphical environ-ments. Since development of Java CAPS solutions results in production of J2EEEnterprise Applications, this graphical orientation might come as a bit of a sur-prise to hardcore J2EE developers used to writing raw Java and the fine-grainedcontrol they exercise through deployment descriptors and other J2EE artifacts. Bethat as it may, you will find most Java Collaboration examples shown using Javasource code rather than its graphical equivalent. This is principally to make thesamples concise, clearly showing essential parts of each solution, and to minimizewasting space on graphics that add no particular value to the discussion. Every oneof the Java Collaborations could have been shown in โStandard mode,โ but thatwould have required numerous pictures, pretty much one for each Java statement,to illustrate what just a few lines of Java code can show in just a few lines. Figure P-1shows an example of a Java Collaboration in Standard mode.
Evident are several lines of pseudocode in the Business Rules pane and justone mapping in the Business Rules Designer pane.
FIGURE P-1: Java Collaboration in Standard mode
xvi Preface
In contrast, the same Java Collaboration in Source Code mode is much moreilluminating, as seen in Figure P-2, as it shows all there is to know about 30 or solines of code all at once.
Since switching between Standard mode and Source Code mode is a button-click away, we chose to use Source Code mode for Java Collaboration examples.
eInsight Business Processes are much easier to understand when presented inthe graphical view, appearing similar to what is shown in Figure P-3. Object icons,taken from the Business Process Modeling Notation, are quite pleasant to look at,in this authorโs opinion.
In contrast, working directly with BPEL4WS XML source, an example ofwhich is shown in Figure P-4, which is possible, is in this authorโs opinion bor-dering on cruel and unusual punishment, just as working directly with any otherXML-based procedural language would be.
So, Java Collaborations are mostly shown in the Source Code mode, and eIn-sight Business Processes are mostly shown with the Business Rules Designer.
How you work with the tool is still up to you.
FIGURE P-2: Java Collaboration in Source Code mode
Preface xvii
FIGURE P-3: eInsight Business Processes in the graphical view
FIGURE P-4: BPEL4WS XML source
xviii Preface
LIST OF ILLUSTRATIONS AND EXAMPLES
To include both discussion and all relevant examples in one book would havemade it over 1,000 pages in lengthโtoo large for printing. As a consequence,this book discusses Java CAPS facilities, focusing on their application to implemen-tation of enterprise integration patterns with high-level illustrations. References todetailed examples are provided in PDF format on the accompanying CD-ROM.The PDF on the CD-ROM provides both detailed illustrations for most of the pat-terns as well as two completely worked-through Java CAPSโbased case study solu-tions that implement a number of the patterns discussed in this book.
The CD-ROM also contains a chapter dealing with cryptographic objects usedto configure security-related aspects of the suite.
Illustrations and examples included on the CD-ROM are listed in Table P-1,with section headers in the order of appearance. Of the over 60 examples, mostare developed in a step-by-step manner, deployed, and exercised. In most cases,results of execution are shown and discussed.
TABLE P-1: Illustrations and Examples in Part II
Chapter/Section Example Topic
Hello Java CAPS World
Introductory step-by-step example. Basic file transfer projects with separate implementations using eGate and eInsight.
Event Message Using Scheduler
Event Message pattern implementation.
Basic scheduled solution using Event Message triggered by a Scheduler eWay.
External Scheduler Example
Event Message pattern implementation.
Scheduled solution using external scheduler and an external TCP Sender client injecting an Event Message through a TCP Server eWay.
JMS Request/Reply Invoker for eInsight
Request/Reply pattern implementation.
New Web Service Java Collaboration for invoking JMS Request/Reply functionality from an eInsight Business Process.
Preface xix
Chapter/Section Example Topic
JMS Request/Response Auction Pattern
Request/Reply pattern implementation.
Java Collaboration and JMS Request/Replyโbased implementation of an Auction pattern where the fastest responder wins.
HTTP Request/Response
Request/Reply pattern implementation.
A series of HTTP requestor and HTTP responder implementations using both HTML and XML payloads, prefaced by a recap of HTTP principles and mechanics.
SOAP Request/Response
Request/Reply pattern implementation.
Specialization of a HTTP request/response implementation using explicitly constructed and parsed SOAP XML messages as requests and responses.
Web Service Request/Reply
Request/Reply pattern implementation.
Web Service request/response implementation as an example of a Request/Response pattern using both eInsight Business Processes and Java Collaborations.
JMS Serial Mode Concurrency
Message Sequence pattern.
Using Sun SeeBeyond JMS Message Server facilities for implementation of message sequence preserving solutions.
Sun SeeBeyond JMS FIFO Modes
Using Sun SeeBeyond JMS Message Server facilities for implementation of message sequence preserving solutions. Series of examples demonstrates the impact of different Sun SeeBeyond JMS Message Server FIFO modes on message sequence.
Serializing Business Processes with XA
Message Sequence pattern.
Examples illustrating the impact of imposing XA transactionality on eInsight Business Processes and how it affects message sequence preservation (new in v. 5.1)
Message Expiration Java Collaboration and JMS-based example illustrating Message Expiration.
(continues)
TABLE P-1: Illustrations and Examples in Part II (continued)
xx Preface
Chapter/Section Example Topic
Batch Local File Streaming
Data streaming examples using Batch Local File eWay with discussion of buffering and its impact on message throughput.
eTL Streaming Very basic eTL example streaming data from a flat file to a database table and a functionally equivalent Java Collaboration example.
Temporary JMS Destinations
Anti-example illustrating the use of an explicitly created JMS temporary destination.
Static Selector Example illustrating the use of static JMS selectors.
Dynamic Selector Example illustrating the use of dynamic JMS selectors, constructed at runtime and used in a Java Collaboration to explicitly choose messages to receive.
Resilient JMS with JMS Grid
Example of a simple JMS Grid-based automatic JMS Client failover.
JMS Message Body Formats
Example collaboration that inspects JMS header properties to determine JMS message body format and branch.
Dead Letter Channel in 5.1.2
Example exercising JMS Redelivery Handling functionality with undeliverable message being delivered to a Dead Letter Queue.
eInsight XA Transactionality
Example inducing success and failure outcomes that demonstrate XA transactionality of an eInsight Business Process with side effects in non-XA-capable resources.
eInsight Persistence Illustration of eInsight persistence, eInsight monitoring, and eInsight restart-recovery of in-flight process instances.
Resequencer:Basic Version
Simple resequencer with memory-based message buffer.
Resequencer:Persisted Version
More sophisticated resequencer with RDBMS-based message buffer and message sequence persistence.
Routing Slip Routing slip-based message routing solution using JSM and Java Collaborations.
JMS User Properties Envelope Wrappers
Series of examples demonstrating Envelope Wrapper pattern implemented using JMS message header properties in Java Collaborations and eInsight Business Processes.
TABLE P-1: Illustrations and Examples in Part II (continued)
Preface xxi
Chapter/Section Example Topic
Content Enricher Content Enricher implementation using eInsight and Oracle eWay to receive a Purchase Order, enrich it with pricing information for an Oracle database, and produce an Invoice.
Polling File System Series of examples polling local file system using Scheduler eWayโdriven and Batch Inboundโdriven Batch Local File eWay to implement polling solutions.
Polling JMS Destination
Try-wait-retry FTP delivery solution implementing JMS Destination polling for retry scheduling.
Durable Subscriber Example illustrating the concept of a JMS topic durable subscriber and behavioral differences between nondurable and durable subscribers.
Idempotent Receiver Example illustrating message duplication detectionโbased Idempotent receiver solution.
Multi-Input Service Activator
Example using the OpenTravel Alliances XML Schema documents to implement a Service Activator solution that allows the business service to be activated through a file submission, JMS message submission, and Web Services invocation.
Monitoring eInsight-based Solutions
Example illustrating eInsight persistence, persistence for reporting, and runtime monitoring of eInsight Business Process instances.
Simple Alert Processor for a JMS Channel
Example implementing a simple solution that receives and processes Alert Agent alerts delivered through the JMS Alert Channel.
CatchingโUncatchableโ Exceptions
Example using Alert Agent infrastructure to catch and process exceptions that occur outside the Java Collaborations and Business Processes and therefore cannot be caught and processed in JCDs or BPs. Catching and processing a database connectivity exception is the subject of this example.
Programmatic Management
Example Java Collaboration that uses the JMX instrumentation to programmatically start and stop a specified Java CAPS component, such as another Java Collaboration or a Business Process service.
(continues)
TABLE P-1: Illustrations and Examples in Part II (continued)
xxii Preface
Chapter/Section Example Topic
JMS Latency Java Collaboration and eInsight Business Process examples illustrating calculation of JMS message delivery latency.
eInsight Correlation Processor: First Cut
Example of an incorrect, naรฏve implementation of eInsight correlation.
eInsight Correlation Processor: Second Cut
Example of correct implementation of a simple eInsight correlation with a simple correlation key.
Derived Correlation Identifiers
Example of a more complex eInsight correlation with a structured, message-derived correlation key based on a subprocess-based correlation key derivation solution.
Derived Correlation Identifiers: Alternative
Alternative example of a more complex eInsight correlation with a structured, message-derived correlation key based on Java Collaboration correlation key derivation preprocessor.
Message Relationship Patterns
Series of examples of using eInsight correlation facilities to implement Message Relationship patterns: Header-Items-Trailer Correlation, Any Order Two Items Correlation, Any Order Two Items Correlation with Timeout, Items-Trailer Correlation, Header Counted Items Correlation, Counted and Timed Items Correlation, Timed Items Correlation, Scatter-Gather Correlation.
Items-Trailer Correlation
Reimplementation of the Items-Trailer Correlation using a Java Collaboration, JMS, and dynamic JMS selectorsโno eInsight.
Using New Web Service Collaborations
Example of using New Web Service Java Collaborations to implement reusable modules for use as activities in eInsight Business Processes.
Using eInsight Subprocesses for Reusability
Series of examples of using eInsight subprocesses as reusable components for use as activities in eInsight Business Processes: Request/Response, OneWay Operation, and Notification Subprocess implementations.
Using eInsight Web Services for Reusability
Series of examples of using Web Services as reusable components for use as activities in eInsight Business Processes: Request/Response, OneWay Operation, and Notification Web Service implementations.
JMS-Triggered Java Collaborations
Example of exception and JMS redelivery handling in a JMS messageโtriggered Java Collaboration.
TABLE P-1: Illustrations and Examples in Part II (continued)
Preface xxiii
Chapter/Section Example Topic
Other Java Collaborations
Example of exception processing in a non-JMS messageโtriggered Java Collaboration.
JMS-TriggeredBusiness Processes
Example of exception handling in a JMS messageโtriggered eInsight Business Process demonstrating behavior differences between XA and non-XA processes.
Fault Handlers Example of using Fault Handlers in eInsight Business Processes.
Secure Sockets Layer (SSL, TLS)
Series of examples illustrating the use of SSL in Java CAPS solutions, both HTTP eWay- and Web Services-based. Covers server-side and mutual authentication for both server and client endpoints.
Web Service, Stored Procedures, and XA
Complete case study implementing an Employee Database Maintenance process with a multi-database update, Web Services, Oracle Stored Procedures, and an XA Business Process. This example implements and exercises a large number of patterns and suite features.
Example Travel Reservation
Complete Travel Reservation case study using Web Services orchestration and eInsight exception handling and compensation. This example implements and exercises a large number of patterns and suite features.
Handling Repeating Nodes in BPEL
Example of handling repeating nodes from XSD-based OTD in eInsight.
XML Deep Parse vs. Shallow Parse
Example implementing lazy XMLparse.
Using Multi-Operation WSDL
Example of implementing a multi-operation Web Service using WSDL and eInsight.
Cryptographic Objects Step-by-step discussion of cryptographic objects required to configure PKI-related aspects of Java CAPS, with tools, commands, and scripts necessary to create certificate signing requests, convert between various certificate formats, and create various keystore types.
TABLE P-1: Illustrations and Examples in Part II (continued)
161
C H A P T E R S I X
Message Routing
6
6.1 INTRODUCTION
This chapter discusses message routing patterns. It includes discussion and applica-tion of patterns from [EIP] Messaging Systems and Message Routing. The chapterbriefly discusses where a Java CAPS solution developer can make routing decisionsand discusses each of the routing patterns in turn, specifically Splitter, Aggregator,Resequencer, Scatter-Gather, Routing Slip, Process Manager, and Message Broker.
6.2 OVERVIEW
A messaging-based integration solution, whether or not and however it trans-forms messages as they pass through, inevitably routes messages from one ormore sources to one or more destinations. A Java CAPS solution can make mes-sage routing decisions in four areas: the JMS Message Server, the connectivitymap, the Java Collaboration definition, and the eInsight Business Process. Typicalsolutions that use just the eGate infrastructure would perform routing throughthe JMS Message Server, the connectivity map, and possibly the Java Collabora-tions. Typical solutions that use eInsight Business Process Management (BPM)would perform routing predominantly within eInsight Business Processes butmay also route in the connectivity map. In all but the simplest solutions, routingwill likely be performed by multiple components.
Routing in the JMS Message Server is performed as a consequence of config-uring nondefault redelivery handling, which can divert messages to Dead LetterQueues. This issue was discussed in Chapter 5, โMessaging Infrastructure,โ sec-tion 5.13.
162 Message Routing
The connectivity map, the graphical representation of how Java CAPS com-ponents are connected, is the means to both collect all integration solution com-ponents that will be deployed as part of a single enterprise application and toconfigure certain aspects of the message endpoints that are logical in nature, suchas JMS Destination names and properties, or names and name patterns for filesystem objects. The simplest functional Java CAPS solution must have a mini-mum of two components: a message source and a service that operates on mes-sages from that source. Unlikely as it may seem, in special circumstance, such anapparently useless solution might be valid and reasonable. What [EIP] calls theChannel Purger would be an example of a solution that receives messages froman endpoint and routes them to nowhere. Figure 6-1 shows a connectivity mapfor a basic Channel Purger.
This is the simplest example of message routing: Fixed Routing [EIP].
Message Router [EIP], a specialized Filter [EIP], represents a component inan integration solution that causes messages to be passed from a source to a des-tination depending on a possibly empty set of criteria. Unlike connectivity mapโ
๏ฟฝ NoteA Java CAPS implementer would typically look at the connectivity map forrouting informationโwhich components publish and subscribe to which JMSDestinations and how many, and which JMS Destinations are subscribed to/published to by an eInsight Business Process. For that reason, a solution thatmakes explicit routing decisions in Java Collaboration Definitions (JCDs) orBusiness Processes will be more difficult to analyze by an implementer new toit. It will also make it harder for the original developers to recall where andhow routing decisions are made. If no other considerations dictate specificchoices, given a choice of explicit routing in a JCD and explicit routing in aneInsight Business Process, choose the latter, as its graphical depiction of pro-cessing logic makes it more obvious that explicit routing takes place. Multiplesubscriptions and/or publications by a service on a connectivity map are astrong hint that explicit routing is taking place inside a service component.
FIGURE 6-1: Channel Purger
6.3 Fixed Router 163
based fixed routing, Message Router variants that make explicit routing decisionsprogrammatically can all be implemented in a Java CAPS solution using eitherJCDs or eInsight Business Processes or both.
The following sections discuss implementation of most of the router patternsusing Java CAPS as the infrastructure.
6.3 FIXED ROUTER
A fixed router, one where a single channel is a source of messages and a singlechannel is a destination, is the most trivial form of a Message Router. You wouldtypically configure the connectivity map source and destination to configure afixed router. If necessary, however, a Java Collaboration or a Business Processcan be constructed to explicitly choose a destination if that destination is a JMSDestination.
Given the connectivity map shown in Figure 6-2, we would expect that theJava Collaboration publishes messages to the JMS Destination (queue) qDummy-Destination.
Inspection of the collaboration source, shown in Figure 6-3, reveals that it isthe JMS Destination (queue) qNewQueue that is the actual destination of mes-sages. This destination is hardcoded in the fixed router.
The same effect could be achieved by explicit assignment of the destinationqueue name prior to sending the message, as shown in Figure 6-4.
Given the connectivity map shown in Figure 6-5, we would again expect thequeue qDummyDestination to be the destination of messages.
Inspecting the business rules embedded in the eInsight Business Process, shownin Figure 6-6, reveals this to not be the case.
In this example, an explicit assignment of a JMS Destination name to the des-tination node of the JMS OTD results in messages being explicitly routed to aJMS Destination (queue) qNewJMSDestination.
FIGURE 6-2: Connectivity map of an implicit fixed router
164 Message Routing
FIGURE 6-3: Hardcoded JMS queue name in a fixed router, which uses a sendTo() OTD method
FIGURE 6-4: Hardcoded JMS queue name in a fixed router using a โdestinationโ OTD node
FIGURE 6-5: Implicit fixed router connectivity map
6.4 Content-Based Router 165
6.4 CONTENT-BASED ROUTER
Content of the message may dictate the destination to which the message must bedelivered. Content-based Router [EIP] inspects the message it receives and sendsit to a destination depending on the content.
In a simple case, a Java Collaboration or a Business Process would have a setof destinations hardcoded within a switch or an if-then-else construct that oper-ates on all or part of the message. An example in Figure 6-7 is a simple Java Col-laboration that illustrates dynamic JMS Destination selection.
๏ฟฝ NoteIn all of the previous examples, the JMS Destination name contained the lit-eral Dummy. This is a hint to the developer who inspects the connectivitymap that the actual destination is likely different and is configured within thecomponent that publishes to the โdummyโ destination. This is a good practicesuggestion, since no part of Java CAPS enforces naming conventions.
FIGURE 6-6: Explicit JMS queue assignment in a Business Process
166 Message Routing
A Business Process that implements a dynamic router can be constructedsimilarly, as the example in Figure 6-8 shows.
Here a decision gate inspects a message to determine which branch to follow.A Business Rules activity assigns a string literal to the JMS Destinationโs destina-tion attribute, and the JMS.send activity gets the message delivered to the desti-nation so set.
FIGURE 6-7: Hardcode dynamic router
FIGURE 6-8: eInsight Business Processโbased dynamic router
6.4 Content-Based Router 167
Whether a JCD or a Business Process is used, the connectivity map for theexample will be identical to that used for the fixed router in the example in theprevious section (i.e., the name of the JMS Destination will be unrelated to theactual JMS Destination to which messages will be delivered).
In the two examples shown in Figures 6-7 and 6-8, a conditional was evalu-ated to determine the destination of the message, which was hardcoded. If addi-tional destinations were required, the collaboration or the process would have tobe modified, and the application containing it would have to be redeployed topropagate changes to the runtime environment. This implementation of a Con-tent-based Router is potentially a high-maintenance implementation if destina-tions change frequently.
In a special case, you could use the message, or the message component, asthe complete name or a part of the name of the destination. You would not needto use a conditional or hardcode destination names.
The JCD in Figure 6-9 appends the first 10 characters of the input message toa literal qDest to form the name of the destination. The message is then written tothe destination with the resulting name.
If the first 10 characters of messages were PRIMARY??? and SECONDARY?,where ? represents a space character, the resulting destination names would beqDestPRIMARY and qDestSECONDARY respectively. If using the Sun See-Beyond JMS implementation, which does not require you to preconfigure JMS
FIGURE 6-9: Dynamically generating JMS Destination names
168 Message Routing
Destinations ahead of time but rather creates JMS Destinations on first referenceif they donโt already exist, this could result in a completely dynamic Content-based Router. You could introduce a message whose initial characters weresomething other than PRIMARY??? and SECONDARY?, and the Sun SeeBeyondJMS implementation would create a new JMS Destination with that appropriatename and deliver the message there. There may not be a receiver for the messagedelivered to the new destination, but the Content-based Router itself would bedynamic and would not require modification. Addition of a destination wouldnot require redeployment of the application containing such a router if no otherchanges were needed to take advantage of the new route. This solution does notrequire maintenance of the router if the number of destinations changes butmakes it difficult to determine to how many destinations messages are routed, asit removes the setting of the content, upon which routing decisions are made,from the router to some other component upstream from the router or evenoutside the integration solution altogether.
In the previous examples, a very simple text message was used and some lead-ing or trailing characters were extracted from the text for use in the conditionalor as a part of a destination name. Messaging systems will rarely deal with suchunstructured text messages. Much more likely, messages will be structured. Thecontents of one or more fields in the message will then be used for routing deci-sions or destination name derivation. For simplicity, we will continue using sim-ple text messages wherever message structure has no bearing on the discussion.
These trivial examples demonstrate how explicit routing can be performedprogrammatically within a JCD or a Business Process. This method will be usedto set destinations for more complex Message Routers.
6.5 MESSAGE FILTER
Message Filter [EIP] is a component in an integration solution that selectivelyprocesses messages. A Java CAPS solution offers two ways in which a Message Fil-ter can determine whether or not to process a message.
If the message source is a JMS Destination, such as a queue or a topic, theMessage Filter can be configured, through the connectivity map, to only acceptmessages whose attributes match an SQL-like selection expression. This methodleverages the JMS selector mechanism. Rather than receiving a message and, ifnot of interest, discarding it, the JMS selectorโbased Message Filter prevents
6.6 Recipient List 169
delivery of messages that do not match the selector expression to the filteringreceiver. This mechanism is static in that the selection expression is configuredthrough the connectivity map and cannot be changed without redeploying theenterprise application.
Java CAPS provides the means to implement a dynamic selection solutionusing a Java Collaboration. This technique, discussed at length in Chapter 5, sec-tion 5.6.7, and Chapter 11, โMessage Correlation,โ section 11.11, allows selectionexpression to change at runtime, thus providing the means to implement dynamicrouting solutions.
6.6 RECIPIENT LIST
By Saurabh Sahai
Often, it is required that a message be selectively sent to more than one recipient.The recipients that are to receive each message are determined either dynami-cally, based on the message content, or statically, based on external business rules.For example, an expense approval request message, pertaining to expenses belowa certain amount, may get sent to the immediate manager for approval, whereas amessage above the defined limit must also be sent to the business unit head forspecial approval.
A recipient list processor is similar to a Content-based Router; however, unlikea Content-based Router that routes the message to a specific destination based onmessage content, a recipient list processor sends the message to one or more des-ignated recipients. The list of recipients can be static, hardcoded within theimplementation, or dynamic, provided to the implementation from an externallymaintained source. The latter approach provides greater flexibility as it allows therecipient list to be dynamically configured.
In Java CAPS, a recipient list can be implemented using either a JCD or aBusiness Process. In either case, once the message is received, the list of intendedrecipients is computed from the available recipients, and the message is forwardedas required.
The Java Collaboration shown in Figure 6-10 receives an expense report mes-sage for an amount greater than $300. Based on business rules, the collaborationlooks up additional approvers that are required to approve this expense reportand sends a copy of the message to these approvers in addition to the default
170 Message Routing
approver. This is an example of a dynamic recipient list, where the collaborationuses information stored in an external store such as the organizationโs Light-weight Directory Access Protocol (LDAP) server to create the required recipientlist. Exception processing has been omitted in Figure 6-10 to focus on the essen-tials of the example.
In the example in Figure 6-10, the additional approval threshold has beenhardcoded within the Java Collaboration. In a more realistic example, externallyconfigurable delegation of authority rules would be loaded into the collaborationusing one of the techniques for dealing with dynamic runtime reconfiguration ofcomponents, discussed elsewhere in the book.
The example uses a hypothetical sendMail() method to send the expense reportto a recipient for approval. The collaboration could have equally validly used multi-ple JMS Destinations, a single JMS Destination with target recipient indicatedusing JMS user properties, a Batch eWay, WebSphere MQ eWay, or any number ofother endpoints, as dictated by the environment or business requirements.
FIGURE 6-10: Recipient list example
6.7 Splitter 171
6.7 SPLITTER
By Saurabh Sahai
An incoming message may encapsulate one or more submessages. It is oftendesired to process submessages independently as separate messages. For example,an order message may consist of multiple order line items, each of which corre-sponds to a unique item type and may be fulfilled by a separate inventory store.
A splitter solves the problem of processing a composite message comprisingmultiple submessages, each of which may be processed differently by breaking upthe message into individual messages and sending each separate message for fur-ther processing by a downstream component.
A splitter can be implemented in Java CAPS in multiple ways. Java Collabora-tions can be used to receive the composite message, iterate over the individualsubmessages, and, on the basis of the message content, send each of them to aunique destination that is responsible for processing a specific type of message.
The collaboration shown in Figure 6-11 is an example of processing anincoming message consisting of multiple order items. The collaboration iteratesover each order item and creates a new message, enriched with the original orderitem information, and sends it for processing by a specific system. The item num-ber contained in each order item is used to determine the destination addresswhere the enriched order item message is to be sent. Exception processing hasbeen omitted in the example to focus on the essentials of the example.
Splitter is a component that, as the name suggests, breaks messages into com-ponent parts. How easy or difficult it is to split original messages and create com-ponent messages largely depends on the size and complexity of the messagestructures involved. As a general rule, it is easier to handle a composite messagewith more than one level of components using a Java Collaboration than to do sousing an eInsight Business Process. Implementing nested loops in a Java Collabo-ration is easier and more compact than doing the same in Business Process Exe-cution Language (BPEL) using the graphical environment. While loops, whethersingle-level or nested, are clearly visible in an eInsight Business Process graphic,making it obvious that splitting is taking place, it is necessary to reset the targetOTD structure prior to its being populated in each iteration, which is neitherobvious nor easily discovered by the casual observer.
172 Message Routing
6.8 AGGREGATOR
Aggregator [EIP] is a special Filter that collects related messages until some com-pleteness condition has been reached, at which point it processes the related mes-sages to obtain a single aggregated message that is then passed on to the nextcomponent.
An Aggregator must be able to correlate related messages, store related mes-sages until ready to process, determine when the completeness condition is met,and implement the aggregation logic.
Java CAPS eInsight engine is a convenient tool to use for building Aggregators,as it inherently supports correlations and transparently stores related messages.The specific eInsight Business Process must only implement the completenesscondition and the aggregation logic in order to become a specific Aggregator.
FIGURE 6-11: Dynamic content-based routing
6.9 Resequencer 173
At the heart of every Aggregator is correlation logic, logic that determineswhich messages are related and therefore are subject to aggregation. Chapter 11discusses at length the topic of message correlation with references to a numberof specific examples presented in Part II (located on the accompanying CD-ROM). Chapter 11, section 11.10, discusses in detail a number of correlationimplementations that incorporate an Aggregator.
Implementing an Aggregator without the benefit of eInsight is much harder.In addition to having to implement a completeness condition and aggregationlogic, the solution designer must also do all the work related to storing and corre-lating messages. Chapter 11, section 11.11, discusses this topic and presents anexample of how to accomplish the task of storing and correlating messages usingjust eGate and the Sun SeeBeyond JMS Message Server.
[EIP] discusses a number of completeness conditions an Aggregator mightimplement: Wait for All, Timeout, First Best, Timeout with Override, and ExternalEvent. Variants of these completeness conditions are discussed in Chapter 11, sec-tion 11.10. Implementing these conditions using eInsight with correlations israther trivial. Implementing most of them using just eGate is much more difficult.
[EIP] also discusses a number of aggregation algorithms, including SelectBest, Condense, and Collect for Later. Variants of these are also discussed in Chap-ter 11, section 11.10. Since aggregation will not start until all related messages arecollectedโthat is, until the completeness condition has been satisfiedโimple-menting aggregation logic is equally simple whether eInsight or eGate is used.
6.9 RESEQUENCER
By Sebastian Krueger
Messages can arrive out of order for many reasons. If these messages are requiredto be delivered in sequence to a downstream component, the easiest solutionwould be to make sure that they never get out of order in the first place. Suchapproaches were discussed in Chapter 4, โMessage Exchange Patterns,โ section4.8. However, there may be times when we donโt have a choice of how theupstream components are implemented; for example, we may control only thereceiving side. Thus, the need to implement a component that will reorder mes-sages may arise.
A number of implementations of a resequencer are possible. Chapter 4, sec-tion 4.2, โResequencer,โ in Part II, discusses and illustrates two implementations
174 Message Routing
using examples: a simple buffered resequencer and a persisted resequencer, bothof which are discussed in the remainder of this section.
The simple buffered resequencer operates as follows. When the resequencerreceives a message, it adds that message to an internal buffer. It then sends allconsecutive messages from the buffer.
In order to send all consecutive messages, the resequencer component needsto know the current sequence number index and whether a message with thisindex is in the buffer. If the index is not found in the buffer, then the message hasnot arrived yet. The resequencer will not send out buffered messages until at leastthe next message arrives.
A resequencer implementation requires all messages to have a uniquesequence number. Not only do these sequence numbers have to be unique, theyalso have to be consecutive. That is, no gaps are allowed to exist in the sequence.
If a message gets lost and never arrives, messages would be queued up andwould never be sent out because the resequencer component would be waiting fora message that will never arrive. To get around this issue, the designer could imple-ment a solution whereby the resequencer only waits a set time for a message toarrive and then moves on to the next messages, effectively ignoring the messagethat never arrived. However, what if the message arrives late? What if a duplicatemessage arrives? Strategies for dealing with these conditions would have to be con-sidered in designing a robust resequencer. The designer could, for example, discardthe message, or send it to a Dead Letter Channel for alerting and auditing purposes.
When a simple resequencer starts, it expects the first message to have asequence number of 0. However, what if this is not the case? For example, the rese-quencer might restart. Unless the sequence is persisted, the resequencer wouldexpect the message sequence to start at 0 again. There are two ways to get aroundthis problem. An initialization message could be sent that informs the resequencerwhich number is the start of the sequence. Alternatively, the sequence could bepersisted so that it can be recovered in appropriate circumstances.
Another point that a simple resequencer does not handle is buffer overrun. Iftoo many messages get queued up, the HashMap, used to store messages whileassembling message sequences, may get too large to fit into the JVM allocatedmemory.
Implementation of a robust and scalable resequencer would require a signifi-cant amount of code and would likely be domain specific. An improved rese-quencer is discussed next. Implementation of a perfect resequencer is beyond thescope of this book.
6.11 Scatter-Gather 175
An improvement to the previous resequencer would be to implement thebuffer as a database table. By moving the message buffer to a persistent store, wesolve two problems exhibited by the previous implementation. First, we effec-tively have an unlimited buffer, so no buffer overflow will occur. Second, in caseof a server failure, buffered messages are not lost.
There are still unresolved issues with this persisted resequencer. The initial-ization of sequence numbers expects the first message to always start at 0. Also,we have not accounted for messages that never arrive. We briefly touched on thesome of these issues in the previous section. They are out of the scope of thischapter.
While the two resequencers discussed in this chapter are by no means perfect,they do give examples of simple resequencers and give an indication of what isrequired to implement a robust resequencer.
6.10 COMPOSED MESSAGE PROCESSOR
Composed Message Processor [EIP] is a higher-order component of a messagingsystem that accepts a message, breaks it up into submessages that are dispatchedand processed by multiple lower-order components, then reassembles submes-sages into a final message.
In Java CAPS, as in any messaging system, implementation of a ComposedMessage Processor requires the use of correlations. Superficially, Composed Mes-sage Processor pattern is no different from the Scatter-Gather pattern [EIP]. Bothinvolve breaking a message and reassembling the pieces once they are processedby independent intermediate components.
Chapter 11 discusses correlation implementation options provided by JavaCAPS and presents a number of correlation examples. Section 11.10.5 provides aJava CAPS example of a Scatter-Gather pattern and Composed Message Proces-sor pattern implementation.
6.11 SCATTER-GATHER
The Scatter-Gather [EIP] pattern involves breaking up a message, or replicating amessage, delivering multiple messages to multiple components, then collectingrelated messages back together. Implementation of a Scatter-Gather patternrequires the use of correlations. It is discussed in various sections of Chapter 11.
176 Message Routing
6.12 ROUTING SLIP
Routing Slip [EIP] is a mechanism that can be used to dynamically route a mes-sage through a series of components such that individual components do notembed routing logic. The route the message is to take can be computed by a routerthat embeds the necessary logic. This route is then attached to the message as aRouting Slip, and each component through which the message passes, once it per-forms its processing, forwards the message onto the next component specified inthe Routing Slip. [EIP] discusses at length the rationale behind a desire to imple-ment the Routing Slip pattern. Java CAPS, and its underlying JMS Message Serverimplementation, lends itself to building Routing Slipโbased solutions; however,eInsight Business Processes may be better, in many circumstances, as an approachto conditional component invocation and dynamic route determination.
In a fixed Routing Slip solution, the message, once it leaves the router, ispassed from component to component. There is no opportunity to change themessage route once it is computed. An alternative to this approach is to have therouter compute the next component to which to send the message, send the mes-sage to it, and have the component return the message back to the router once itis done. Routing decisions are still centralized, making routing logic simple tomaintain, and the route the message takes can be changed by the router at anytime based on the outcome of message processing.
In Java CAPS, a Routing Slip, or return destination, can be attached to themessage in one of two ways. It can be passed via JMS user-defined properties ifthe message is passed from component to component over JMS, or the messagecan be packaged into an Envelope Wrapper and the Routing Slip can be incorpo-rated into the Envelope metadata.
Envelope Wrapper is discussed at length in Chapter 8, โMessage Transforma-tion,โ section 8.2. The route, computed by the router, could be represented in theEnvelope node as a series of labels delimited by some delimiter, or an ordered,repeating collection of labels.
Chapter 4, section 4.3, โRouting Slip,โ in Part II, illustrates this discussionwith an example implementation of a Routing Slip pattern using Java Collabora-tions and JMS.
We could have used an eInsight Business Process to implement the kind offunctionality that the Routing Slip facilitates. Each processing component couldhave been implemented as a New Web Service Java Collaboration or an eInsightsubprocess. The Business Process would orchestrate execution of these compo-nents according to routing logic rules it implements.
6.14 Message Broker 177
6.13 PROCESS MANAGER
One of the Routing Slip solutions involves a single routing component that deter-mines the next component to which a message must be sent and receives the mes-sage back once the component is finished with it. This central routingcomponent directs flow of messages using routing logic it embeds. Since it alwaysreceives messages that are processed by the processing components, it can modifythe route a message is to take based on the outcome of processing by a particularcomponent. Thus, the route the message finally takes may be different from theroute a fixed router, which does not use intermediate processing results for rout-ing decisions, would have determined.
Process Manager is a component that implements conditional routing logicand orchestrates execution of other processing components. Java CAPS supportsimplementation of the Process Manager, with functionality as described in theopening paragraph, as a Java Collaboration using JMS, possibly in Request/Replymode, to dispatch and receive messages to and from processing components. Thedisadvantage of this approach is that the routing logic is hidden away in the Javacode and, depending on the size and complexity of logic involved, may be diffi-cult to understand.
Java CAPS eInsight Business Process Manager provides a graphical BusinessProcess modeling environment. It overcomes the understandability limitations ofa Java-only implementation and offers a number of features for Business Processmodeling, component orchestration, and runtime monitoring that are not avail-able with Java-only implementations.
Using eInsight Business Process Manager, you can implement any desiredrouting and component orchestration solutions. eInsight examples appear inmost sections of this book and illustrate all manner of solutions of varying com-plexity. When a dynamic routing or component orchestration is required, eIn-sight Business Process can be developed to satisfy the requirement.
6.14 MESSAGE BROKER
Message Broker [EIP] is an EAI architectural style wherein a component of amessaging system implements centralized routing for all messages flowingthrough the system. [EIP] also uses the term hub-and-spoke when referring tothis architectural style. SeeBeyondโs DataGate 3.6 product, predecessor to eGate4.x, ICAN 5.0, and Java CAPS 5.1, is a Message Brokerโbased EAI package.
178 Message Routing
Message Broker architecture allows decoupling of senders from receivers. Thesenders need not know where the messages are going, and receivers need notknow from where the messages are coming. The Message Broker embeds all rout-ing logic necessary to get messages from senders to receivers. This centralizesrouting logic maintenance.
In Java CAPS, and ICAN before it, each connectivity map could be consid-ered to represent a Message Brokerโbased solution. In effect, all collaborationsand Business Processes present in a connectivity map route messages fromsources to destinations. Each eInsight Business Process could also be considered aMessage Broker implementation, as it, too, makes routing decisions when orches-trating a series of activities. Collections of connectivity maps sharing commonchannels could be considered hierarchies of Message Brokers [EIP].
While Java CAPS can certainly be used to implement centralized routingsolutions in the spirit of Message Broker, doing so does not appear particularlynecessary or particularly advantageous.
6.15 CHAPTER SUMMARY
This chapter discussed [EIP] message routing and message routingโrelated pat-terns. It included discussion and application of patterns from [EIP] MessagingSystems and Message Routing.
The chapter briefly discussed where a Java CAPS solution developer can makerouting decisions and discussed each of the routing patterns, specifically Splitter,Aggregator, Resequencer, Scatter-Gather, Routing Slip, Process Manager, and Mes-sage Broker.
445
Index
AAggregator pattern, 78โ79, 172โ173
See also Envelope WrapperSee also Message SequenceSee also Splitter
Alert Agent. See also Alert Services; Alerts.Alert Codes, 251โ257alerts
delivering, 248โ249eInsight Business Processes, starting/
stopping, 251endpoint support for, 251event notification schema, 257filtering, 250, 257, 259โ260recipients, defining, 249โ250, 257Web Services providers, starting/stopping,
251channel types, 246channels
electronic mail, 246โ249JMS, 246โ249minimum number, 246network management. See SNMP.SMTP, 246โ249SNMP, 246โ249
configuring, 246reasons for using, 259
Alert Codes, 251โ257Alert Services. See also Alert Agent; Alerts.
closeSession request, 274โ275, 296filtering alerts, 287โ296filters, examples, 295โ296getAlertQueryFields request, 287โ292getAlerts, with filter, 292โ295getAllAlerts request, 281โ284invalid session ID, 296listing alerts, 281โ284Message Codes, 290โ291observeAllAlerts request, 285
observing alerts, 284โ286Query Fields, listing, 287โ292resetAllAlerts request, 286resetting alerts, 286session not found, 296SOAP Fault, 296table types, 291โ292URl for, 271
Alerts. See also Alert Agent; Alert Services.delivering, 248โ249eInsight Business Processes, starting/stopping,
251endpoint support for, 251event notification schema, 257filtering
codes for, 250โ257examples, 295โ296prior to SNMP, 259โ260by severity, 257xxxAllAlerts operations, 287โ288
listing, 281โ284managing, 271observing, 284โ286recipients, defining, 249โ250, 257resetting, 286Web Services providers, starting/stopping, 251
Any Order Two Items Correlation pattern, 358โ360
Any Order Two Items Correlation with Timeout pattern, 360
Application connectivity, 401โ403Application Server Domain. See Logical host.Architecture, Java CAPS
configuration information, storing, 18โ19connectivity maps
associating with physical resources, 21. Seealso Deployment, profiles.
creating, 20โ21context, 14โ16
446 Index
Architecture, Java CAPS, continueddefinition, 13deployment, 50โ53deployment profiles, 21โ22design time environment, 16โ19developer authentication information,
storing, 18eDesigner IDE, 16โ17high availability
application connectivity, 401โ403Enterprise Manager, 397failover, intersite, 403โ406failover, intrasite, 402โ403Integration Server, 397โ398introduction, 396IQ Manager, 398JMS Grid, 398โ401JMS Grid cluster, 399JMS Grid network, 399queue failover, 404โ405replication, Grid-based, 405โ406replication, queue manager disk-based, 406Repository, 396UDDI Registry, 397
history of, 13โ14LDAP (Lightweight Directory Access Proto-
col), 18โ19logical host, 18, 21management facilities, 19messaging infrastructure, 18โ19monitoring facilities, 19Repository Server, 16โ19run time environment, 16โ19solution development stages, 20โ23
Asynchronous notification, 94Auction pattern, 72Automation. See Enterprise Manager, Command-
Line Client.
BBacking up data, 36โ39Batch eWay Streaming, 88โ89Batch FTP eWay, 4Batch Inbound eWay, 4, 212โ213Batch Local File eWay, 4, 212Batch Record eWay, 4BOB (Business Object Broker), 14
BPEL (Business Process Execution Language)Competing Consumers, 129message correlation, 337โ338
BPEL4WS (Business Process Execution Language for Web Services). See BPEL (Business Pro-cess Execution Language).
BPM (Business Process Management), 344โ349Branching, 42Breaking up messages
See Data StreamingSee Message SequenceSee Scatter-GatherSee Splitter
Build process, 54โ55BytesMessage format, 132
CCanonical Data Model, 206Centralized routing, 177โ178Channel Adapter pattern, 150โ151. See also EWay
Adapters; Messaging Endpoints.Channel Purger pattern, 329โ331Channel types, 246Channels
distributing messages to. See MessageDispatcher.
electronic mail, 246โ249handling messages of different types. See Mes-
sage Dispatcher.JMS, 246โ249minimum number, 246one message in, multiple out. See Publish-
Subscribe Channel.one message in, one out. See Point-to-Point
Channel.single message type. See Datatype Channel.SMTP, 246โ249SNMP, 246โ249undeliverable messages. See Dead Letter
Channel; Invalid Message Channel.Checked-in state, 40, 46Checked-out state, 40, 46Ciphers, 428โ429Claim Check pattern, 205โ206. See also Content
Enricher; Envelope Wrapper.Clear-text channel, 420Client authentication, 99
Index 447
closeSession request, 274โ275, 296Collaboration, 100โ104. See also Java
Collaborations.Combining messages
See Aggregator.See Envelope Wrapper.See Scatter-Gather.
COM/DCOM eWay, deployment limitation, 21Command Message pattern, 60Command-line tools, 54โ55. See also Enterprise
Manager, Command-Line Client.Commit, 100Compensation, 394โ395Competing Consumers pattern
BPEL (Business Process Execution Language), 129
configuring, 114Connection Consumer mode, 128โ129description, 217โ218FIFO mode, 80โ81, 114, 129implementing, 127โ129Java Collaborations, 127โ129message order, preserving, 114receivers
eGate, 127โ129eInsight Business Processes, 129โ131Java Collaborations, 127โ129preserving message ordering, 131
Component paths, listing, 277Components
disabled, 279โ280invalid, 279โ280listing, 268โ269, 275โ277state, monitoring, 318status, obtaining, 278โ279stopping/starting, 280tagging, 43testing, 327โ328
Composed Message Processor pattern, 175Composite Applications, 8, 158Concurrency. See also Competing Consumers.
IQ ManagerConnection Consumer Mode, 105default mode, 105enabling, 105Server Session Pool property, 105
overview, 105
Conditional routing, 177Configuration information, storing, 18โ19Connection Consumer Mode, 105, 128โ129Connection Factories, 96Connectivity maps
associating with physical resources, 21Connection Consumer mode, displaying,
128creating, 20โ21, 28โ30definition, 26directory structure, 32dragging and dropping into, 29hierarchical organization, 28โ32listing variables, 35mapping variables, 35misspelling destination names, 29โ30packaging into EAR files, 21queue consumer concurrency, 80
Connector OTDs, 181Constants, 33โ36Consumers
competing. See Competing Consumers.event-driven, 216selective, 219
Content Enricher pattern, 203โ204. See alsoClaim Check; Envelope Wrapper.
Content Filter pattern, 204Content-based router, 165โ168Contention for resources, 131Context, 14โ16Control Bus pattern, 318Correlation, definition, 336. See also Message
correlation.Correlation Identifiers
derived, 349โ354derived, alternatives to, 354โ357description, 343โ344
Correlation Keys, 337โ338, 345โ349Correlation patterns. See Message Relationship.Correlation processors, 336Correlation Sets, 345โ349Counted and Timed Items Correlation pattern,
363Counted-and-timed-items correlation,
363Cron, 62Cryptographic Handshake, 91
448 Index
DData
extraction and load, 88, 90structures. See OTDs (Object Type Definitions).transfer, 88, 90. See also FTP (File Transfer
Protocol).Data Streaming pattern, 88โ90Database sharing, 4โ5Datatype Channel pattern
definition, 132endpoint-dependent datatypes, 133Java Collaborations, 134JMS message body formats, 132โ133multiple datatypes, 134โ135
Dead Letter Channel pattern. See also Invalid Message Channel.
IQ Manager, 137โ138Java CAPS, 5.1.2 and greater, 139โ140Java CAPS, prior to 5.1.2, 137โ138JMS Redelivery feature, 137โ138overview, 136redelivery, 137โ140
Dead Letter Queues. See Dead Letter Channel.Deadlocks, 131De-duping messages, 222Deleting messages. See Discarding messages.Delimited Envelope Wrapper, 190โ192Delivery mode, configuring, 106โ107Delivery time, calculating, 84Dependent projects, 37, 39Deployment
architecture, 50โ53EAR files, 51โ52logical break points, 9management
branching, 42checked-in state, 40, 46checked-out state, 40, 46circumventing, 42command-line tools, 54โ55deployment profile snapshots, 43โ46project tagging, 43retrieved state, 40third-party systems, 46โ49unique user ID requirement, 42version history, 41version isolation, 42
to multiple physical environments, 22
profilesconfiguration settings, 33โ36constants, 33โ36creating a directory for, 30โ31creating from a single connectivity map, 36definition, 9, 21โ22directory structure, 32exporting, 39mapping components, 9โ11naming, 30โ31snapshots, 43โ46variables, 33โ36
scripting, 54โ56. See also Enterprise Manager, Command-Line Client.
Deployment Profile Editor, 35, 43โ46Derived Correlation Identifiers, 349โ357. See also
Correlation Identifiers.Design time environment, 16โ19Destinations. See JMS Destinations.Detour pattern, 318โ319Developer authentication information, storing, 18Digital signatures, 91Discarding messages, 83โ85, 243โ244, 327โ328Distributing components
eGate, 384โ386eInsight, 387overview, 383โ384
Document Message pattern, 60Duplicate messages, 174, 220โ223Durable Subscriber pattern, 219โ220Durable subscriptions, 98, 219โ220Dynamic router, 165โ168. See also Message
Dispatcher.Dynamic routing, 176Dynamic selectors, 109โ114, 366โ369
EEAR files
deploying to the runtime environment, 51โ52description, 8โ9generating, 9multiple deployments, 22names
default, 30โ32maximum length, 32renaming, 27setting with deployment profile properties, 32
packaging connectivity maps, 21
Index 449
eDesigner, 16โ17, 25eGate
Competing Consumers, 127โ129component distribution, 384โ386correlation, with dynamic selectors,
366โ369resilience, 384โ386scalabilty, 384โ386
eInsight, Business ProcessesCompeting Consumers, 129โ131components, distributing, 387Datatype Channel pattern, 135default processing model, 217Guaranteed Delivery pattern
guaranteed nondelivery on failure, 146overview, 145โ146persistence, 147โ148rolling back transactions, 135, 146โ148XA transactionality, 146โ147
persistence, enabling, 233โ235Request/Reply pattern, 65, 70โ72, 74resilience, 387scalabilty, 387serializing processing, 131starting/stopping, alerts for, 251XA transactionality, 131
eInsight, Correlation Processorautomatic correlation, 344โ349BPM (Business Process Management),
344โ349Correlation Keys, 337โ338, 345โ349Correlation Sets, 345โ349
eInsight, reusabilitysubprocesses
Notification relationships, 375, 376โ378, 382
OneWayOperation relationships, 375, 376, 382
overview, 373โ375Request/Reply subprocess, 375โ376, 382WSDL definitions, 373โ375
Web ServicesNotification Web Service, 381โ382OneWayOperation Web Service,
381โ382Request/Reply Web Service, 378โ382servlet context, 379โ380
eInsight engine, 172
Electronic mail channels, 246โ249Encryption
ciphers, 428โ429messages in transit, 91public keys, 417โ419SSL (Secure Sockets Layer), 417
Endpoint-dependent datatypes, 133Endpoints
See Channel Adapter.See eWay Adapters.See Messaging Endpoints.
Enriching messages, 78โ79See also Claim Check.See also Content Enricher.See also Envelope Wrapper.
Enterprise Applications, 23. See also Projects; Solutions.
Enterprise Designer, 16โ17, 25Enterprise Manager
Command-Line Clientalert management, 271credentials, 267currently deployed components, listing,
268โ269host name, 267Java Collaboration, 269โ271port number, 267runtime methods, listing, 267โ268service state, obtaining, 269โ271usage notes, 267
high-availability architecture, 397Enterprise Manager, Web Service API
Alert ServicescloseSession request, 274โ275, 296filtering alerts, 287โ296filters, examples, 295โ296getAlertQueryFields request, 287โ292getAlerts, with filter, 292โ295getAllAlerts request, 281โ284invalid session ID, 296listing alerts, 281โ284Message Codes, 290โ291observeAllAlerts request, 285observing alerts, 284โ286Query Fields, listing, 287โ292resetAllAlerts request, 286resetting alerts, 286SOAP Fault, 296
450 Index
Enterprise Manager, Web Service API, continuedAlert Services, continued
table types, 291โ292URl for, 271
Login Servicesdescription, 273โ275openSession request, 273โ275Session IDs, obtaining, 273โ275, 275URL for, 271
Runtime ServicescloseSession request, 274โ275disabled components, 279โ280getComponentList request, 275โ277invalid components, 279โ280listing component paths, 277listing components, 275โ277obtaining component status, 278โ279SOAP Fault, 279โ280stopping/starting components, 280URl for, 271
Service Manager Servicesavailable services, listing, 272โ273description, 272โ273URL for, 271
Session IDsafter restart, 274โ275invalid, 274โ275obtaining, 273โ275, 275
WSDL interface definitions, 271โ272, 280Envelope Wrapper pattern
See also Aggregator.See also Claim Check.See also Content Enricher.See also Message Sequence.See also Splitter.message sequencing, 78โ79OTD
delimited Envelope Wrapper, 190โ192JMS properties, 201โ202overview, 188โ189XML within XML, 192โ201
sequence metadata, 79ETL (Extract, Transfer, and Load), 88. See also
Data Streaming.eTL Streaming, 90Event Message pattern, 60Event notification schema, 257
Event-Driven Consumer pattern, 216Event-driven consumers, 216Events
notification. See Alert Agent; Alert Services; Alerts.
SNMP. See Traps.triggering, 62
eWay Adapters. See also Channel Adapter; HTTP eWay; Messaging Endpoints.
Batch FTP eWay, 4Batch Inbound eWay, 4Batch Local File eWay, 4Batch Record eWay, 4COM/DCOM, 6description, 5
Exception handlingfaults handlers, 392โ393faults in Business Processes, 390โ393higher-level, 393Java collaborations, 388โ390
Expiration, messages, 82โ86, 144Exporting
deployment profiles, 39projects, 36โ39
Extensible Markup Language (XML)appropriate use of, 180โ181enveloping within XML, 192โ201
Extract, Transfer, and Load (ETL), 88. See alsoData Streaming.
FFactoring solutions. See Distributing components.Failover, 402โ406Fault handlers, 392โ393Faults, in Business Processes, 390โ393Fault-tolerance, 94. See also Resilience.FIFO modes
Competing Consumers, 114, 129effect on Connection Consumer mode, 129IQ Manager, 114JMS Message Server, 80โ81
File systems, polling, 211โ214File Transfer Protocol (FTP), 433โ435File transfer security, 433โ435Files
reading, 211โ214renaming, 212โ213
Index 451
Filteringalerts
codes for, 250โ257examples, 295โ296prior to SNMP, 259โ260by severity, 257xxxAllAlerts operations, 287โ288
Content Filter pattern, 204getAlerts requests, 292โ295JMS selectors. See also Message Filter.
dynamic, 109โ114overview, 107static, 107โ109
Message Filter pattern, 168โ169. See also JMS selectors.
messages, 204Fixed router, 163โ165Format indicator, 86โ88Format Indicator pattern, 86โ88. See also Messag-
ing Bridge.Fragmenting messages
See Data Streaming.See Message Sequence.See Scatter-Gather.See Splitter.
FTP (File Transfer Protocol), 433โ435Fully Concurrent Processing, 80Fully Serialized Processing, 80
GGET method, 73โ74getAlertQueryFields request, 287โ292getAlerts, with filter, 292โ295getAllAlerts request, 281โ284getComponentList request, 275โ277GMT (Greenwich mean time), 83โ84Grid. See JMS Grid.Grid clusters. See JMS Grid, clusters.Guaranteed Delivery pattern
delivery mode, configuring, 106โ107eInsight Business Processes
guaranteed nondelivery on failure, 146overview, 145โ146persistence, 147โ148rolling back transactions, 135,
146โ148XA transactionality, 146โ147
Java CAPS facilities for, 141โ142JMS-based
message expiration, 144Persistent Delivery mode, 145required services, 143โ144transacted sessions, 144โ145
Nonpersistent Delivery mode, 106โ107overview, 140persistence, 142โ143Persistent Delivery mode, 106โ107requirement for, 140โ141solution-specific, 148โ149transparent replication, 143
Guaranteed nondelivery on failure, 146
HHeader-Counted-Items Correlation pattern,
362โ363Header-Items-Trailer Correlation pattern,
357โ358Heap graph, 304Heartbeat-based schedulers, 63High-availability architecture
introduction, 396Java CAPS components
application connectivity, 401โ403Enterprise Manager, 397failover, intersite, 403โ406failover, intrasite, 402โ403Integration Server, 397โ398IQ Manager, 398JMS Grid, 398โ401JMS Grid cluster, 399JMS Grid network, 399queue failover, 404โ405replication, Grid-based, 405โ406replication, queue manager disk-based, 406Repository, 396UDDI Registry, 397
Hostname verification, 432HTTP (Hypertext Transfer Protocol)
Basic Authentication, 410โ415connectors, 29GET method, 73โ74listener port assignments, 419POST method, 73โ74Proxy Server configuration, 409โ410
452 Index
HTTP (Hypertext Transfer Protocol), continued
Request/Reply, 73โ74Server, 73โ74Server/Responder, 419
HTTP eWayclear-text channel, 420client/server projects, 419mutual authentication
client configuration, 425โ426exercising the channel, 427โ428server configuration, 424โ425
purpose of, 73โ74server-side authentication, 420โ424SSL (Secure Sockets Layer), 427โ428
IIdempotence, 220Idempotent Receiver pattern, 220โ223Importing projects, 36โ39Inspecting messages, 100โ104Integration Server
description, 8high-availability architecture, 397โ398keystores, referencing, 99truststores, referencing, 99
Integration stylescentralized vs. distributed, 8โ11database sharing, 4โ5file transfer, 3โ4messaging, 6โ7remote procedure invocation, 5โ6resiliency, 8โ11scalabilty, 8โ11service orchestration, 7โ8
Invalid Message Channel pattern, 136. See alsoDead Letter Channel.
Invalid Message Queues. See Dead Letter Channel.
Invalid session ID, 296IQ Manager. See also JMS Message Server.
automatic destination creation, 29โ30concurrency
Connection Consumer Mode, 105default mode, 105enabling, 105Server Session Pool property, 105
Connection Consumer mode, displaying, 128Dead Letter Channel pattern, 137โ138FIFO modes, 114high-availability architecture, 398JMS Destinations
checking existence, 98creating, 97โ98destroying, 97โ98temporary, 98โ99
JMS selectorsdynamic, 109โ114overview, 107static, 107โ109
JMS transactionscommit, 100definition, 99inspecting messages, 100โ104purpose of, 100scope, 100Transacted mode behavior, 104Transacted setting, 103โ104Transactionality property, 103uncommitted messages, 100
message journaling, 117โ119misspelling destination names, 29โ30persistence
delivery mode, configuring, 106โ107description, 105โ107guaranteed delivery, 106JMS delivery mode vs. subscription
durability, 106redelivery handling, 116โ117security, 99throttling, 115โ116transactionality
commit, 100definition, 99inspecting messages, 100โ104purpose of, 100scope, 100Transacted mode behavior, 104Transacted setting, 103โ104Transactionality property, 103uncommitted messages, 100
Items-trailer correlation, 360โ362, 367โ369Items-Trailer Correlation pattern, 360โ362,
367โ369
Index 453
JJava CAPS
communication with third-party applications. See Channel Adapter.
JMS properties, setting, 107โ109JMX Console, 297โ303Repository. See Repository, Java CAPS.
Java CollaborationsCompeting Consumers, 127โ129Datatype Channel pattern, 134default processing model, 217exception handling, 388โ390receive method, examples, 65โ66, 67โ68Request/Reply pattern, 65โ72service state, obtaining, 269โ270starting/stopping, 270โ271state, obtaining, 269โ271
Java Management Extensions (JMX). See JMX (Java Management Extensions).
Java Message Service (JMS). See JMS (Java Mes-sage Service).
Java Naming and Directory Interface (JNDI), 109โ112
JCA-compliant adapters. See eWay Adapters.JCD (Java Collaboration Definition), 101โ103JCE (Java Cryptography Extension), 428โ429JConsole, enabling, 303โ307JMS (Java Message Service)
administration, 94asynchronous notification, 94channels, 246โ249clusters. See JMS Grid, clusters.Connection Factories, 96delivery mode vs. subscription durability, 106fault-tolerance, 94. See also JMS Grid, clusters.FIFO modes, 79, 80โ81Grid. See JMS Grid.integrating non-Java environments, 95โ96. See
also Messaging Bridge.interoperability, 95. See also Messaging Bridge.latency, 313โ317load-balancing, 94message body formats, 132โ133message repository, 94message type definitions, 94OTDs, 201โ202overview, 94โ95
physical implementation issues, 95point-to-point message, 96. See also JMS topics.properties, setting with Java CAPS, 107โ109publish-subscribe messaging, 96. See also JMS
queues.Redelivery feature, 137โ138Request/Reply pattern, 64โ72, 371โ372resilience, 119โ126. See also JMS Grid.security, 94โ95Serial mode concurrency, 79โ80serializing business processes, 81โ82
JMS Destinations. See also JMS queues.wire protocols, 94โ95
creating, 29description, 96IQ Manager
checking existence, 98creating, 97โ98destroying, 97โ98temporary, 98โ99
polling, 214โ216JMS Grid
Admin Console, 124โ126administering, 124โ126clusters
configuration, 120โ122definition, 119high-availability architecture, 399illustration, 120size, 120transparent replication, 119uses for, 120, 124
features, 119high-availability architecture, 398โ401network, 399network configuration, 120โ121
JMS Message Server. See also IQ Manager.discarding messages, 96โ97FIFO modes, 79โ80, 114guaranteed delivery, 143โ145interoperability, 95โ96message expiration, 82โ84, 144Message Journaling, 85Messaging Bridge, 151โ156overview, 18โ22persistence, 105โ107Persistent Delivery mode, 145
454 Index
JMS Message Server, continuedredelivery, 116โ117resilience, 119โ126security, 99selectors, 107โ114Sync to Disk, 145throttling, 115โ116transacted sessions, 144โ145XA sessions, 144โ145
JMS queues. See also JMS Destinations; Point-to-Point Channel.
creating, 29definition, 96failover, 404โ405journaled, listing, 244โ245listing, 241message content, displaying, 244โ245messages, listing, 242โ243no receivers, 98status, displaying, 242vs. topics, 96โ97
JMS selectors. See also Message Filter.dynamic, 109โ114overview, 107static, 107โ109
JMS topics. See also Publish-Subscribe Channel.creating, 29definition, 96durable subscriptions, removing, 98no subscribers, 98vs. queues, 96โ97
JMS transactionscommit, 100definition, 99inspecting messages, 100โ104purpose of, 100scope, 100Transacted mode behavior, 104Transacted setting, 103โ104Transactionality property, 103uncommitted messages, 100
JMSCorrelationID, 337JMX (Java Management Extensions)
agent, enabling, 303Java CAPS JMX Console, 297โ303JConsole, enabling, 303โ307JMX agent, enabling, 303JMX Console, 307โ308
log dumps, 298โ303MBeans, 297โ303programmatic management, 308โ313uses for, 297
JMX Console, 307โ308JNDI (Java Naming and Directory Interface),
109โ112Job scheduling. See Scheduling.Journaling messages, 84โ86, 117โ119, 244โ245Journaling status, checking, 244
KKeystores, referencing, 99
LLatency, 313โ317LDAP (Lightweight Directory Access Protocol),
18โ19Load-balancing, 94Log dumps, 298โ303Logical host, 18, 21Login Services
description, 273โ275openSession request, 273โ275Session IDs, obtaining, 273โ275, 275URL for, 271
MManagement facilities. See Monitoring and
management.MapMessage format, 132โ133Mapping
components, deployment profiles, 9โ11connectivity. See Connectivity maps.variables, 35
Marshaling messages, 180โ181. See also Serializ-ing messages.
Maximum Lifetime, 83MBeans, 297โ303MDN (Message Disposition Notification), 77Message body formats, 132โ133Message Broker pattern, 177โ178Message Bus pattern, 157โ158Message Codes, 290โ291Message concept, 179โ180Message correlation
any order two items, 358โ360any order two items with timeout, 360
Index 455
BPEL correlations, 337โ338correlation, definition, 336Correlation Identifiers
derived, 349โ354derived, alternatives to, 354โ357description, 343โ344
Correlation Keys, 337โ338correlation processors, 336counted and timed items, 363eGate, with dynamic selectors, 366โ369eInsight Correlation Processor
automatic correlation, 344โ349BPM (Business Process Management),
344โ349Correlation Keys, 345โ349Correlation Sets, 345โ349queuing messages manually, 342โ343receive activities, 338โ341
eInsight correlations, 337โ338header-counted-items, 362โ363header-items-trailer, 357โ358items-trailer, 360โ362, 367โ369JMSCorrelationID, 337overview, 336predefined JMS Header fields, 337scatter-gather, 364โ365timed items, 363โ364
Message Dispatcher pattern, 218. See alsoDynamic router.
Message Disposition Notification (MDN), 77
Message exchange patternsAggregator, 78โ79Auction, 72Command Message, 60Data Streaming, 88โ90Document Message, 60Envelope Wrapper, 78โ79Event Message, 60Format Indicator, 86โ88Message Expiration, 82โ86Message Security, 90โ91Message Sequence
combining messages, 78โ79Competing Consumers, 80โ81enriching messages, 78โ79FIFO modes, 79, 80โ81Fully Concurrent Processing, 80
Fully Serialized Processing, 80JMS Serial mode concurrency, 79โ80Protected Concurrent Processing, 80sequence metadata, 79Serial Concurrency mode, 80serializing business processes, 81โ82splitting messages, 78โ79
Request/ReplyAuction pattern, 72eInsight Business Process, 65, 70โ72eInsight subprocesses, 74HTTP eWay, 73โ74HTTP GET method, 73โ74HTTP POST method, 73โ74HTTP Request/Reply, 73โ74HTTP Server, 73โ74Java Collaboration, 65โ72JMS Request/Reply, 64โ72overview, 63โ64requestReply( ) method, 72SOAP Request/Reply, 74โ75temporary queues, 70Web Services implementation, 75โ76
Return Address, 76โ77Splitter, 78โ79
Message Expiration pattern, 82โ86Message Filter pattern, 168โ169. See also JMS
selectors.Message History pattern, 321โ325Message ID, 222โ223Message Journaling service, 84โ85Message OTDs, 181Message Relationship patterns
Any Order Two Items Correlation, 358โ360Any Order Two Items Correlation with Time-
out, 360Counted and Timed Items Correlation, 363Header-Counted-Items Correlation,
362โ363Header-Items-Trailer Correlation,
357โ358Items-Trailer Correlation, 360โ362,
367โ369Scatter-Gather Correlation, 364โ365Timed Items Correlation, 363โ364
Message repository, 94Message Security, 90โ91Message selectors. See JMS selectors.
456 Index
Message Sequence patternSee also Aggregator.See also Envelope Wrapper.See also Splitter.combining messages, 78โ79Competing Consumers, 80โ81enriching messages, 78โ79FIFO modes, 79, 80โ81Fully Concurrent Processing, 80Fully Serialized Processing, 80JMS Serial mode concurrency, 79โ80Protected Concurrent Processing, 80sequence metadata, 79Serial Concurrency mode, 80serializing business processes, 81โ82splitting messages, 78โ79
Message serversdefault. See IQ Manager.Java CAPS JMS Message Server
journaling, 85selectors, 107โ114
JMS Message ServerAPIs, 96bridging independent solutions, 152โ156bridging JMS implementations, 156delivery mode, configuring, 106โ107FIFO modes, 114guaranteed delivery, 143โ145message expiration, 144message sequencing, 114persistence, 105โ107Persistent Delivery mode, 145redelivery, 116โ117resilience, 119โ126security, 99โ100Sync to Disk, 145throttling, 115โ116Transacted Sessions, 144โ145XA Sessions, 144โ145
Message Store pattern, 325โ327Message type definitions, 94Message-format agnostic, 86Messages
breaking upSee Data Streaming.See Message Sequence.See Scatter-Gather.See Splitter.
buffer overrun, 174combining
See Aggregator.See Envelope Wrapper.See Scatter-Gather.
concurrent processing. See CompetingConsumers.
de-duping, 222delivery time, calculating, 84different types over same channel. See Message
Dispatcher.discarding, 83โ85, 243โ244, 327โ328displaying content, 243distributing to different channels. See Message
Dispatcher.diverting to a different queue, 318โ321duplicates, 174, 220โ223enriching, 78โ79. See also Envelope
Wrapper.expiration, 82โ86, 144FIFO modes, 79, 80โ81filtering, 204format indicator, 86โ88formats, transforming. See Messages,
transformation.GMT (Greenwich mean time), 83โ84idempotence, 220inspecting, 100โ104journaled queues, listing, 244โ245journaling, 84โ86, 117โ119journaling status, checking, 244large, 78โ79, 88โ90marshaling, 180โ181. See also Serializing.Maximum Lifetime, 83one receiver per, 131order, preserving, 114, 131queuing manually, 342โ343receiving
multiple times. See Idempotent Receiver.selectively. See Selective Consumer.
redelivery, 137โ140relationship patterns. See Message Relationship
patterns.removing information from, 204,
205โ206retaining, 219โ220. See also Durable
subscriptions.routes, tracking, 321โ325
Index 457
routingAggregator pattern, 172โ173breaking up messages, 171โ172, 175centralized, 177โ178combining messages, 172โ173, 175Composed Message Processor pattern, 175conditional, 177content-based router, 165โ168dynamic router, 165โ168dynamic routing, 176fixed router, 163โ165Message Broker pattern, 177โ178Message Filter, 168โ169overview, 161โ163Process Manager pattern, 177recipient list, 169โ170Resequencer pattern, 173โ175resequencing messages, 173โ175Routing Slip pattern, 176Scatter-Gather pattern, 175selective processing, 168โ169Splitter pattern, 171โ172
routing patternsAggregator, 172โ173Composed Message Processor, 175Message Broker, 177โ178Message Filter, 168โ169Process Manager, 177Resequencer, 173โ175Routing Slip, 176Scatter-Gather, 175Splitter, 171โ172
safety, 220saving copies of. See Journaling.security. See Security.selective processing, 168โ169sequence numbers, 174serializing, 173โ175. See also Marshaling;
Message Sequence.slowing down, 115โ116splitting, 78โ79storing, 325โ327timeTolive property, 83โ85traffic, monitoring, 318transformation patterns. See also Envelope
Wrapper.Canonical Data Model, 206Claim Check, 205โ206
Content Enricher, 203โ204Content Filter, 204Normalizer, 206
uncommitted, 100UTC (Universal Time Coordinated), 84
Messages, infrastructure patternsChannel Adapter, 150โ151Datatype Channel, 132โ135Dead Letter Channel, 136โ140Guaranteed Delivery
eInsight Business Processes, 145โ148guaranteed nondelivery on failure, 146Java CAPS facilities for, 141โ142JMS-based, 144โ145overview, 140, 145โ146persistence, 142โ143, 147โ148requirement for, 140โ141rolling back transactions, 146โ148solution-specific, 148โ149transparent replication, 143XA transactionality, 146โ147
Invalid Message Channel, 136Message Bus, 157โ158Messaging Bridge, 151โ157
Messaging Bridge pattern. See also Format Indicator.
independent Java CAPS solutions, 152โ156other bridging solutions, 156โ157other JMS implementations, 156overview, 151
Messaging Endpoints patterns. See also Channel Adapter; EWay Adapters.
Competing Consumers, 217โ218Durable Subscriber, 219โ220Event-Driven Consumer, 216Idempotent Receiver, 220โ223Message Dispatcher, 218Messaging Gateway, 209โ210Polling Consumer
definition, 211file systems, 211โ214JMS Destinations, 214โ216other batch pollers, 214
Selective Consumer, 219Service Activator, 223โ225Transactional Client, 210โ211
Messaging Gateway pattern, 209โ210Migration, third-party version system, 46
458 Index
Monitoring and management. See also JMX (Java Management Extensions).
architecture, 19automating. See Enterprise Manager,
Command-Line Client.component state, 318deployment
branching, 42checked-in state, 40, 46checked-out state, 40, 46circumventing, 42command-line tools, 54โ55deployment profile snapshots, 43โ46project tagging, 43retrieved state, 40third-party systems, 46โ49unique user ID requirement, 42version history, 41version isolation, 42
deployments. See Deployment, management.discarding messages, 327โ328diverting messages to a different queue, 318โ321eGate-based solutions, 228โ233eInsight-based solutions, 233โ235event notification. See Alert Agent; Alert Ser-
vices; Alerts.IQ Manager
description, 235discarding messages, 243โ244displaying message content, 243journaled queues, listing, 244โ245journaling status, checking, 244monitoring features, 235โ240queue messages, listing, 242โ243queue status, displaying, 242queues, listing, 241receivers, listing, 241โ242status, displaying, 241stcmsctrutil utility, 240
JMS latency, 313โ317message traffic, 318network management. See SNMP Agent.networks. See SNMP Agent.overview, 227โ228patterns
Channel Purger, 329โ331Control Bus, 318Detour, 318โ319Message History, 321โ325
Message Store, 325โ327overview, 317โ318Test message, 327โ328Wire Tap, 319โ321
performance data collection, 313โ317persistence, enabling, 233โ235releases. See Deployment, management.runtime performance data, collecting, 315โ317scripting. See Enterprise Manager, Command-
Line Client.solution-specific
Channel Purger pattern, 329โ331Control Bus pattern, 318Detour pattern, 318โ319. See also Wire Tap.discarding messages, 327โ328diverting messages to a different queue,
318โ321Message History pattern, 321โ325Message Store pattern, 325โ327monitor component state, 318monitoring message traffic, 318overview, 317โ318storing messages, 325โ327Test message pattern, 327โ328testing components, 327โ328tracking message routes, 321โ325Wire Tap pattern, 319โ321. See also Detour.
storing messages, 325โ327Sun SeeBeyond JMS Message Server, 245testing components, 327โ328tracking message routes, 321โ325Web Services-based. See Enterprise Manager,
Web Service API.Mutual authentication
HTTP eWay, 424โ428SSL (Secure Sockets Layer), 418Web Services SSL, 431โ432
NNaming
deployment profiles, 30โ31EAR files
default, 30โ32maximum length, 32renaming, 27setting with deployment profile properties, 32
files, 212โ213projects, 27, 30โ31
Network management. See SNMP channels.
Index 459
New Web Service collaboration, 372โ373Normalizer pattern, 206Notification, events. See Alert Agent; Alert Ser-
vices; Alerts.Notification relationships
eInsight subprocesses, 375, 376โ378, 382eInsight Web Services, 381โ382
OObjectMessage buffer, 132โ133ObjectMessage format, 132observeAllAlerts request, 285OneWayOperation relationships
eInsight subprocesses, 375, 376, 382eInsight Web Services, 381โ382
openSession request, 273โ275OTD Wizards, 187OTDs (Object Type Definitions)
Connector OTDs, 181definition, 180Envelope Wrapper pattern
delimited Envelope Wrapper, 190โ192JMS properties, 201โ202overview, 188โ189XML within XML, 192โ201
marshaling messages, 180โ181Message OTDs, 181Oracle table, example, 181โ187types of, 181
Overwriting projects, 39
PPerformance data collection, 313โ317Persistence
enabling, 233โ235Guaranteed Delivery pattern, 142โ143, 147โ148IQ Manager
delivery mode, configuring, 106โ107description, 105โ107guaranteed delivery, 106JMS delivery mode vs. subscription durabil-
ity, 106Persistent Delivery mode, 145Point-to-Point Channel, 131. See also JMS topics.Point-to-point message, 96Polling
Batch Inbound eWay, 212โ213Batch Local File eWay, 212file systems, 211โ214
JMS Destinations, 214โ216other batch pollers, 214
Polling Consumer patterndefinition, 211file systems, 211โ214JMS Destinations, 214โ216other batch pollers, 214
Port number, 267POST method, 73โ74Predefined JMS Header fields, 337Process Manager pattern, 177Profiles, deployment
configuration settings, 33โ36constants, 33โ36creating a directory for, 30โ31creating from a single connectivity map, 36definition, 9, 21โ22directory structure, 32exporting, 39mapping components, 9โ11naming, 30โ31snapshots, 43โ46variables, 33โ36
Project structure. See also Connectivity maps; Deployment, profiles.
constants, 33โ36factors influencing, 25hierarchical organization
connectivity maps, 28โ32deployment profiles, 28โ32description, 26โ28
logical solutions, 26physical deployment, 26project folders, creating, 27shared objects, creating, 38variables, 33โ36
Projects. See also Enterprise Applications; Solutions.archives. See EAR files.backing up, 36โ39definition, 25dependent, 37, 39development-time artifacts, 25. See also
specific artifacts.exporting/importing, 36โ39naming, 27overwriting on import, 39release management. See Deployment,
management.renaming, 27
460 Index
Projects, continuedrolling back, 39, 46โ49tagging, 43version management. See Deployment,
management.Properties, setting with Java CAPS, 107โ109Protected Concurrent Processing, 80Public keys, 417โ419Publish-Subscribe Channel, 132. See also JMS
queues.Publish-subscribe messaging, 96
QQuery Fields, listing, 287โ292Queue consumer concurrency, 80Queues. See JMS queues.Queuing messages manually, 342โ343
RReading files, 211โ214Reassembling messages. See Aggregator; Scatter-
Gather.Receivers
Competing ConsumerseGate, 127โ129eInsight Business Processes, 129โ131Java Collaborations, 127โ129preserving message ordering, 131
listing, 241โ242Recipient list, 169โ170Recipients, checking for. See Request/Reply.Redelivery feature, 137โ140Redelivery handling, 116โ117. See also Messages,
routing.Relationship patterns. See Message Relationship
patterns.Release management. See Deployment,
management.Remote Method Invocation (RMI), 6Remote procedure call (RPC), 5โ6Renaming. See Naming.Replication
Grid-based, 405โ406queue manager disk-based, 406transparent, 119, 143
Repository, Java CAPSbacking up, 36โ39exporting projects, 36โ39high-availability architecture, 396
importing projects, 36โ39overwriting projects, 39rolling back transactions, 39
Repository Server, 16โ19Request/Reply pattern
Auction pattern, 72eInsight Business Process, 65, 70โ72eInsight subprocesses, 74HTTP eWay, 73โ74HTTP GET method, 73โ74HTTP POST method, 73โ74HTTP Request/Reply, 73โ74. See also SOAP
Request/Reply.HTTP Server, 73โ74Java Collaboration, 65โ72JMS Request/Reply, 64โ72overview, 63โ64requestReply( ) method, 72SOAP, 74โ75. See also HTTP (Hypertext
Transfer Protocol), Request/Reply.temporary queues, 70using, 371โ372Web Services implementation, 75โ76
Request/Reply relationshipseInsight subprocesses, 375โ376, 382eInsight Web Services, 378โ382
requestReply( ) method, 72Resequencer pattern, 173โ175Resequencing messages. See Serializing messages.resetAllAlerts request, 286Resilience. See also High-availability architecture.
distributing componentseGate components, 384โ386eInsight components, 387overview, 383โ384
exception handlingfaults handlers, 392โ393faults in Business Processes, 390โ393higher-level, 393Java collaborations, 388โ390
JMS (Java Message Service), 119โ126Retaining messages, 219โ220Retrieved state, 40Return Address pattern, 76โ77Reusability
eInsight subprocessesNotification relationships, 375, 376โ378, 382OneWayOperation relationships, 375, 376,
382
Index 461
overview, 373โ375Request/Reply subprocess, 375โ376, 382WSDL definitions, 373โ375
eInsight Web ServicesNotification Web Service, 381โ382OneWayOperation Web Service, 381โ382Request/Reply Web Service, 378โ382servlet context, 379โ380
JMS Request/Reply pattern, 371โ372New Web Service collaboration, 372โ373Service Activator, 223โ225
RMI (Remote Method Invocation), 6Rolling back
dependent projects, 39projects, 39, 46โ49transactions, 135, 146โ148
Routing. See Messages, routing.Routing Slip pattern, 176RPC (remote procedure call), 5โ6RPC/Encoded style, 6Runtime environment, 16โ19Runtime methods, listing, 267โ268Runtime performance data, collecting, 315โ317Runtime Services
closeSession request, 274โ275disabled components, 279โ280getComponentList request, 275โ277invalid components, 279โ280listing component paths, 277listing components, 275โ277obtaining component status, 278โ279SOAP Fault, 279โ280stopping/starting components, 280URl for, 271
SSAN (storage area network), 401โ407Scalabilty
centralized vs. distributed solutions, 8โ11distributing components
eGate, 384โ386eInsight, 387overview, 383โ384
Scatter-Gather Correlation, 364โ365Scatter-Gather pattern, 175Scheduler Connector, 61Scheduling
Cron, 62event triggering, 62
external schedulers, 62โ63heartbeat-based solutions, 63job identifiers, 62job parameters, 62Scheduler Connector, 61Unix Cron, 62Windows Task Scheduler, 62
Schema Runtime Environment (SRE), 151SCP (Secure Copy Protocol), 434Scripting, 54โ56. See also Enterprise Manager,
Command-Line Client.Secure File Transfer Protocol (SFTP), 434Secure Shell (SSH), 434Secure Sockets Layer (SSL). See SSL (Secure
Sockets Layer).Security. See also SSL (Secure Sockets Layer).
authenticationclient-side, 99HTTP Basic Authentication, 410โ415mutual, 418, 424โ428, 431โ432server-side, 420โ424
Cryptographic Handshake, 91developer authentication information,
storing, 18digital signatures, 91encryption
ciphers, 428โ429messages in transit, 91public keys, 417โ419SSL (Secure Sockets Layer), 417
file transfer, 433โ435FTP (File Transfer Protocol), 433โ435HTTP listener port assignments, 419HTTP Proxy Server configuration,
409โ410HTTP Server/Responder, 419JMS (Java Message Service), 94โ95messages in transit, 90โ91, 99server-side authentication, 418,
430โ431Sun SeeBeyond IQ Manager, 99TLS (Transport Layer Security), 415Web proxy, 409. See also HTTP (Hypertext
Transfer Protocol), Proxy Server.Selective Consumer pattern, 219Selective consumers, 219Selectors. See JMS selectors.Sequence metadata, 79Serial Concurrency mode, 80
462 Index
Serializing messages. See also Marshaling; Message Sequence.
business processes, 81โ82eInsight Business Processes, 131Fully Serialized Processing, 80JMS business processes, 81โ82Resequencer pattern, 173โ175
Server Session Pool property, 105Server-side authentication
HTTP eWay, 420โ424SSL (Secure Sockets Layer), 418Web Services SSL, 430โ431
Service Activator pattern, 223โ225Service Manager Services
available services, listing, 272โ273description, 272โ273URL for, 271
Servlet context, 379โ380Session IDs, 273โ275Session not found, 296SFTP (Secure File Transfer Protocol), 434SMTP channels, 246โ249Snapshots, deployment profiles, 43โ46SNMP Agent
Auto-Routing, 262, 263configuration files, 266configuring
Auto-Routing, 262debug logging, 266Listener, 264listening port, 262overview, 261passwords, 262properties, 262security, 264Traps, 261โ264usernames, 262version number, 266
filtering events, 259โ260, 263overview, 259โ260passive monitoring, 260Traps, 261โ264
SNMP channels, 246โ249SOAP Fault, 279โ280, 296SOAP Request/Reply, 74โ75Solutions. See also Enterprise Applications;
Projects.deploying. See Deployment.development stages, 20โ23
factoring. See Distributing components.logical break points, 9
Source control. See Deployment, management.Splitter pattern, 78โ79, 171โ172
See also Aggregator.See also Envelope Wrapper.See also Message Sequence.
Splitting messages, 78โ79SRE (Schema Runtime Environment), 151SSH (Secure Shell), 434SSL (Secure Sockets Layer). See also HTTP eWay.
Cryptographic Handshake, 91encryption, 417history of, 415โ416JCE (Java Cryptography Extension), 428โ429mutual authentication, 418protocol description, 416public keys, 417โ419server-side authentication, 418strong cipher suites, 428โ429Web Services
hostname verification, 432mutual authentication channel, 431โ432overview, 430server-side authentication channel, 430โ431
X.509 Certificate, 416โ419State, obtaining, 269โ271Static selectors, 107โ109stcmsctrutil utility, 240Storage area network (SAN), 401โ407StreamMessage format, 132โ133Strong cipher suites, 428โ429Sun products. See specific products.Sun SeeBeyond. See specific products.Sync to Disk property, 145System management. See Monitoring and man-
agement.
TTables Runtime Environment (TRE), 151Tagging, 43Task Scheduler, 62Temporary JMS Destinations, 98โ99Temporary queues, 70Test Message pattern, 327โ328TextMessage format, 132Third-party version control systems, 46โ49Threads graph, 304โ305Throttling, 115โ116
Index 463
Timed items correlation, 363โ364Timed Items Correlation pattern, 363โ364timeToLive property, 83โ85TLS (Transport Layer Security), 415Topics. See JMS topics.Transacted mode, 104Transacted setting, 103โ104Transactional Client, 210โ211Transactionality. See also JMS transactions; XA
transactionality.IQ Manager
commit, 100definition, 99inspecting messages, 100โ104purpose of, 100scope, 100Transacted mode behavior, 104Transacted setting, 103โ104Transactionality property, 103uncommitted messages, 100
Transactional Client, 210โ211Transactionality property, 103Transparent replication, 119, 143Traps, 261โ264TRE (Tables Runtime Environment), 151Truststores, referencing, 99
UUDDI Registry, 18, 397Undeliverable messages. See Dead Letter
Channel.UTC (Universal Time Coordinated), 84
VVariables
description, 33โ36listing, 35
mapping, 35runtime values, 35type, 33
Version control. See Deployment, management.Version history, 41Version isolation, 42
WWeb proxy, 409Web Services
creating, 29providers, alerts for starting/stopping, 251Request/Reply pattern, 75โ76service orchestration, 7โ8SSL (Secure Sockets Layer)
hostname verification, 432mutual authentication channel, 431โ432overview, 430server-side authentication channel, 430โ431
Wire protocols, 94โ95Wire Tap pattern, 319โ321WSDL definitions, 271โ272, 280, 373โ375
XX.509 Certificate, 416โ419XA transactionality
contention for resources, 131deadlocks, 131effects on eInsight business processes, 82eInsight Business Processes, 131on eInsight Business Processes, 131Guaranteed Delivery pattern, 146โ147on long-running processes, 131serializing business processes, 81โ82
XML (Extensible Markup Language)appropriate use of, 180โ181enveloping within XML, 192โ201