This chapter discusses a series of patterns [EIP] grouped under the Messaging Endpoints category. A number of these patterns, such as Competing Consumers and Event-Driven Consumer, were covered in earlier chapters. In many cases, a number of Java CAPS features and facilities must be used together to implement specific patterns, such as Polling Consumer and Service Activator. Examples developed to illustrate these topics, which introduce some advanced techniques, are worth studying in themselves.

Messaging Gateway is, according to [EIP], the means of encapsulating access to the messaging system. The goal is to ensure that the application need not be aware of the intricacies of directly communicating with the messaging system via its APIs. A further goal is to expose the messaging system to the application using business-level constructs like GetCreditScore rather than “connect, send message, receive response, disconnect,” or similar actions. Following the discussion of the Messaging Gateway provided in [EIP] leads to an inescapable conclusion that a Messaging Gateway is none other than a Service Façade, very much in vogue with increased interest in service-oriented architectures.

Java CAPS offers several ways in which messaging solutions can be accessed from external applications. The low-level JMS API libraries, provided by the eGate API Kit, come in Java, C/C++, and COM+ flavors. Depending on the nature of the application that needs access to the Java CAPS solution, and the technology platform it uses, one of these libraries can be used to develop a Messaging Gateway with appropriate functionality. The JMS API Kit supports both synchronous and asynchronous messaging between applications and the Sun SeeBeyond JMS Message Server implementation and, through it, Java CAPS–based messaging solutions. The use of the JMS API Kit ties the application very closely to the Sun SeeBeyond JMS Message Server. This may be considered a major drawback if a high degree of vendor independence is sought.

Further down the scale, toward looser coupling, lie the eWays that support standard messaging protocols like TCP/IP and HTTP. A Messaging Gateway constructed to exchange messages with the messaging system over a TCP/IP-based channel, for example, requires the use of generic API libraries supported by most development environments. An example of TCP/IP-based integration between an external environment and Java CAPS is shown in the TCPSender client. This client was built to submit messages to a Java CAPS solution using an external scheduler, but the same code can be used to integrate the interaction into an arbitrary Java-based application. See Figure 2-3 in Chapter 2, section 2.2.1, “External Scheduler Example,” in Part II (located on the accompanying CD-ROM). The Gateway is vendor independent from the technology standpoint; however, both the gateway and the messaging solution, the access to which it encapsulates, must agree on the application messaging protocol to use. By application messaging protocol, we mean the types of messages that must be exchanged, the order of message exchange, and the meaning of various bits of information each message carries, and so on. This protocol is very likely to be proprietary, gateway/solution-specific. While such a gateway can be used with different messaging solutions, the solutions must support the proprietary application messaging protocol developed for the gateway.

Further still down the scale of coupling, the Web Services standards–based Messaging Gateway offers the greatest degree of vendor independence and the loosest coupling between the Messaging Gateway and the Java CAPS solution to which it is a Façade. Java CAPS allows Web Services Interoperability–compliant Web Services to be constructed and exposed graphically, including automatic registration of Web Services implementations in Java CAPS–provided UDDI Registry. Numerous development environments provide the means of automatic or semiautomatic generation of application code given the Web Service Definition Language (WSDL)-based interface definition. Sun NetBeans IDE is one such environment.

[EIP] defines Transactional Client as an application that can begin, coordinate, and complete a transaction involving a number of resources external to it, one or more of which can be the messaging system. Java CAPS does little to assist the external application in implementing and coordinating a transaction that involves it. In general, most endpoints/eWays/Adapters are not transactional in the sense that their activities cannot be externally coordinated or even undone/rolled back. In fact, endpoints such as a Batch eWay, an HTTP eWay, or a TCP/IP eWay are nontransactional. Other endpoints, such as database eWays or JMS clients, can be used transactionally. With the exception of JMS, for which there is an API and the associated object library, eWays cannot be used outside Java CAPS, so those that can be used transactionally must be used within a Java CAPS solution. eGate JMS API Kit, the API, and the associated library can be used by a third-party application. Since JMS can be used transactionally, the JMS API Kit can be used to develop a Transactional Client that orchestrates a number of resources, one of which is the Java CAPS JMS message publisher or sender.

A Java client application could send messages directly to the Java CAPS JMS Message Server using Client Acknowledgment mode and explicit JMS Session Commit. Such a client could orchestrate a transaction involving a number of resources, including a Java CAPS JMS Message Server.

While Java CAPS is principally an event-driven messaging system, some of its components can be configured to poll external systems for messages rather than setting up listeners.

Polling Consumer [EIP] is a consumer that checks the channel at intervals to determine whether there is a message to receive. It would be implemented in situations where it is impossible or impractical for an external system to notify the messaging system that a message is available or where solution design calls for polling interaction.

Polling File System

Polling Consumers are most commonly used in solutions that involve reading files deposited in a file system by an independent application. The application that creates a file is not directly integrated with the messaging solution—it typically has no way of notifying the messaging system that it has finished writing the file and the file is ready for processing, nor is it even aware that the file it produces gets processed by some other system. A typical file system is not integrated with the messaging system, so it too has no way to notify the messaging system that a file is ready for processing. This also applies to solutions involving remote file systems accessed using some variant of the File Transfer Protocol (FTP).

In Java CAPS, reading files is typically performed by a Batch Local File eWay. This eWay does not have a Receive service, so it cannot be used to trigger a Java Collaboration or a Business Process. Because Java CAPS is an event-driven system, the component that checks the file system for the presence of a file must be triggered somehow. Batch Local File eWay must be used from a Java Collaboration or an eInsight Business Process. Either can be triggered by a Scheduler eWay.

Occasionally there arises a need to poll for files whose names match a pattern constructed at runtime, perhaps involving date components or sequence numbers. The Polling Consumer necessary to support this requirement is somewhat different from that discussed in the previous section. Rather than configuring the regular expression in the Batch Local File eWay connector in the connectivity map, the Java Collaboration dynamically configures the regular expression to be used for polling. Alas, unlike a statically configured regular expression, the dynamically configured regular expression is cleared by the reset() method, so it has to be configured again each time through the multiple file loop.

Unlike the File eWay, the Batch eWay and all its variants can be dynamically configured at runtime, including dynamically specifying the regular expression to use for matching file names.

In the preceding discussion, polling functionality of the Batch eWay was triggered by a Scheduler eWay. The collaboration would use the Batch Local File eWay to read a file if it existed. Unless the getIfExists() method of the Batch Local File OTD was used, a “file not found” exception would be thrown that would have to be handled. If the getIfExists() method was used, the null payload condition, indicating that the file was not found, would still have to be handled. Every time the timer fired, the collaboration would be invoked. Since we are polling for a file in the local file system anyway, it would be better to have some component directly poll the file system to a schedule and invoke the collaboration only if file was available for processing. The Batch Inbound eWay, another variant of the Batch eWay, provides just this kind of functionality. Since it made its appearance sometime in ICAN 5.0.x, it has been used instead of the Scheduler eWay or the File eWay to implement file polling solutions.

The Batch Inbound eWay polls a directory for a file with a name that is explicitly specified as a literal or that satisfies a specified regular expression. When a matching file is found, the eWay renames the file in place by prefixing a Globally Unique ID (GUID) to the file name and invokes the collaboration or the Business Process, passing to them the original name of the file, the original directory in which file exists, and the new name of the file after it has been renamed. This approach has a number of benefits. First, if the regular expression on which to match file names is correctly specified, the Batch Inbound will not match the new name, so the component that will process the file can take its time processing the file without running the risk of the file becoming a candidate for processing again. Second, until the file becomes available, no collaboration or Business Process is triggered. Third, when invoked, the collaboration or the Business Process will have a single file to process. Any exceptions are error situations that need handling rather than being benign exceptions like “file is not found because it is not there yet.”

Note

If the regular expression is badly specified, such that it will match the name of the original file as well as the name of the file after a GUID is prepended to it, recursion will occur. The renamed file will be processed again on the next poll, getting another GUID prepended to its name. Eventually, after some number of repetitions, this process will cause the Batch Inbound eWay to exceed the length of the file name acceptable to the file system and will cause an exception. The collaboration or the Business Process will not be invoked and the file will not be processed.

Note

Batch Inbound eWay does not process the file it locates except to rename it by prefixing a GUID to the original file name. The new file name, the original file name, and the path to the file/directory where the file exists are made available to the eInsight Business Process or a Java Collaboration as values in the BatchInbound OTD. It is expected that some other eWay will be used to actually read the file and process its content as required. This ensures that the same file will not be picked up on the next poll and submitted for processing again.

Note

Batch Inbound only delivers one file name per poll. To process many files in a directory as rapidly as possible, the Batch Inbound would usually be configured with a very short schedule interval. This is resource intensive and inefficient if files are deposited for processing in bursts.

Chapter 7, section 7.2.1, “Polling File System,” in Part II, illustrates this discussion with several Java CAPS examples. Chapter 4, “Message Exchange Patterns,” section 4.11 (in Part I) discusses data streaming using the Batch eWay.

Polling JMS Destination

Much less commonly there arises a requirement to periodically poll a JMS Destination instead of configuring a message listener and processing messages as soon as they are available. One scenario in which a Polling Consumer polling a JMS Destination would be appropriate is a try-wait-retry implementation. For example, a solution might receive, from JMS, a message to deposit at an FTP server. The FTP server may be unavailable. Instead of rolling the message back and having it immediately redelivered, the solution might park the message in a “retry queue” with no connected receivers. An independent collaboration might be triggered, at intervals, to poll the retry queue and resubmit any messages it finds there to the original queue, thus causing the FTP process to be retried. One reason to avoid rolling the message back to the original queue is that the next message might be for a different FTP server. Rolling back the current message will prevent delivery of the subsequent messages, clearly an undesirable situation when messages are intended for independent destinations.

The architectural schematic in Figure 9-1 shows the try-wait-retry part of a larger solution.

Figure 9-1. JMS-based try-wait-retry pattern schematic

Note

The solution in Figure 9-1 explicitly does not preserve order of message delivery. The intent is to ensure that a message that cannot be delivered to the final destination does not block later messages and prevent their delivery to other destinations that are ready to receive them. The design does not assure preservation of order of message delivery even to the same destination because a message waiting in a retry queue may not get an opportunity to get delivered until after a subsequent message for the same destination manages to get delivered.

A set of components, upstream from qSubmitQueue, construct a Job Message containing the name of the file to be submitted by FTP, the maximum number of times to retry if delivery fails, the address and credentials of the FTP server, and the directory at the FTP server to which the file must be written. Upon receipt of this message, jcdFTPSubmitter attempts to dynamically connect to the nominated FTP server, using the address and credentials provided in the Job Message. If connection succeeds, file transfer is attempted. If connection fails, the Job Message is requeued to qRetryQueue. If the message does not have JMS Message Header user-defined properties, RetryCount, MaximumRetryCount, and SourceQueue, they are created and set to 0, the value of the maximum retry count in the Job Message, and the name of the JMS Destination from which the message originally came, respectively. If the properties already exist, because the message was already resubmitted at least once, the RetryCount property is incremented. Every n minutes, a Scheduler eWay triggers the jcdRetryResubmitter collaboration. This collaboration polls qRetryQueue, and for every message it reads from there, it inspects the retry count JMS Message Header user-defined property. If the retry count exceeds the maximum number of retries, the collaboration resubmits the message to the JMS Destination whose name is derived from the SourceQueue name with the literal “FailedJobs” appended; otherwise, it requeues the message back to the original SourceQueue.

Every transfer will be tried, at most, the “maximum number of retries” times, at nominated intervals. If initial transfer is successful, no retry functionality will be invoked. Because the retry interval is unrelated to the time at which the message was queued to the retry queue, the amount of time that elapses before the message is requeued to the original queue may vary from nothing to the scheduled interval.

Chapter 7, section 7.2.2, “Polling JMS Destination,” in Part II, illustrates this discussion with the example Java CAPS implementation.

As mentioned in the previous section, Java CAPS is essentially an event-driven messaging system. Endpoints register message listeners, which are activated as soon as a message they are to process becomes available. Occurrence of an event causes the Java Collaboration or the Business Process to begin executing. Even the Polling Consumers discussed in the previous section are Event-Driven Consumers, as each is activated by a Scheduler eWay or by a Batch Inbound eWay, triggering the component that implements polling functionality. All Java Collaborations and all eInsight Business Processes are Event-Driven Consumers.

Java CAPS offers a series of configuration properties, dependent on the endpoint in use, which allow control over whether Event-Driven Consumers can be automatically replicated to process messages concurrently and, if so, how many copies of the consumer there can be. This facility, discussed in passing in Chapter 4, section 4.8.1, allows Event-Driven Consumers to accommodate spikes in workload at the cost of increased resource use.

The Competing Consumers pattern facilitates processing multiple messages concurrently. In Java CAPS, Competing Consumers are typically JMS queue receivers. Multiple receivers from the same queue will compete for messages. As a message becomes available for processing, the JMS Message Server will randomly pick a consumer from among the consumers configured to receive from the queue and will deliver the message to it.

Java CAPS Java Collaborations are, by default, configured to receive from JMS queues in Serial mode. Only one collaboration instance will be created to receive a message. Any messages available for processing while the instance is actively processing a message will wait until the instance is finished so that the next message can be processed. Java Collaborations are not, by default, configured to operate as Competing Consumers. To implement Competing Consumers with Java Collaborations, you can explicitly drag several copies of the collaboration onto the connectivity map and make them receive from the same JMS queue; see Chapter 4, section 4.8.2, and Chapter 5, “Messaging Infrastructure,” section 5.8.1, for a discussion and an example of this approach. This approach is explicit in that a casual viewer of the connectivity map will immediately see the processing model implemented in the connectivity map. A different approach to implementing Competing Consumers using Java Collaborations is to configure the JMS Receiver Concurrency property to Connection Consumer mode, specifying the maximum number of threads that can be created to process messages. This approach is discussed in Chapter 5, section 5.8.1. This approach makes it harder for a casual viewer to discern what the real processing model is without verifying JMS Receiver connector property settings.

For eInsight Business Processes, the default processing model is to have the eInsight Engine create as many Business Process instances as there are messages to process. If an instance is processing a message when another message becomes available, the eInsight Engine will create a new instance to process it. This topic is discussed at length in Chapter 5, section 5.8.2. With Java CAPS 5.1, this default behavior can be changed by making the process an XA process, effectively serializing processing for this process.

Note

Not exactly what a desirable design ought to be, it is possible to configure multiple Batch eWays to read files with overlapping name patterns from directories with the same name or overlapping name patterns. eWays configured this way would in effect be Competing Consumers, but since there is no synchronization between them, it is possible that multiple eWays might attempt to read the same file with highly undesirable consequences.

Discussion of Message Dispatcher in [EIP] is somewhat confusing. On the one hand, Message Dispatcher is compared to a selective consumers-based solution; on the other, it is compared to a multithreaded application wherein a dispatcher invokes “performers” executing in the context of the same process. The peculiar characteristics that make this pattern a Message Dispatcher are its ability to receive messages of different types over the same channel, its ability to recognize different messages by some means, and its ability to distribute messages for processing to different channels based on these different attributes. Since Java CAPS Integration Server is, effectively, the container in which all deployments execute, and it is a single process, the “single process” distinction is irrelevant. In Java CAPS, for all intents and purposes, Message Dispatcher is no different from a dynamic router.

Implementation of a Message Dispatcher as a Java Collaboration or as an eInsight Business Process is the same as implementation of any collaboration or Business Process. Both Java Collaborations and Business Processes receive messages from a channel. Java Collaborations receive messages over only one channel, whereas Business Processes can receive messages over multiple channels. The tricky part, if any, is to decide how to implement discrimination rules so that the dispatcher, much as a dynamic router, does not become a maintenance burden.

One implementation that may be useful in specific circumstances is a message dispatcher solution consisting of Message Inspector, whether implemented as a collaboration or a Business Process, a JMS Destination, and a set of Selective Consumers, statically configured or dynamic. The Inspector will parse messages it receives, extract key information, populate the JMS Message Correlation ID property, and submit messages to a JMS Destination. Different Selective Consumers will pick up messages whose selector values match those they expect to process. The overall operation will be that of a Message Dispatcher.

Typically associated with JMS, Selective Consumers [EIP] are consumers that receive only some of the messages from their associated channel. Java CAPS supports Selective Consumers by implementing JMS Message Selectors that, when statically configured for receivers and subscribers, instruct the JMS Message Server to deliver only selected messages. A technique also exists that allows a Java Collaboration to create a selector dynamically and poll the JMS Destination for messages that satisfy the selector expression. JMS-based Selective Consumers are discussed at length in Chapter 5, section 5.6.7.

It is worth noting that, effectively, all Batch eWay variants are used to implement Selective Consumers. Much as JMS selectors instruct the Message Server to deliver messages whose properties match the selector expressions, so too the file and directory name patterns instruct the Batch eWay implementation to select only matching files.

When dealing with JMS Destinations, we expect messages that are sent or published to be retained by the JMS Message Server until they are picked up by a receiver, are delivered to all subscribers, or expire and are removed or moved off to a Message Journal. This is generally a reasonable expectation with one exception. JMS topics, as discussed in Chapter 5, section 5.5, behave differently with respect to message consumption, depending on whether subscribers are durable or nondurable.

A durable subscriber is one that the Message Server recognizes by its client name and for which the Message Server retains messages until they expire or are consumed by that subscriber. This means that even if the subscriber is not connected, at the time a message becomes available for delivery, the message will be kept for it. All retained messages will be delivered as soon as the subscriber connects if the messages have not expired in the meantime. In contrast, a nondurable subscriber will receive messages only when it is connected. This messaging model is known as a store-and-forward messaging model.

The durability property of the JMS subscriber client is configured through the JMS client connector in the connectivity map.

Chapter 7, section 7.3, “Durable Subscriber,” in Part II, provides an illustration that walks through building and exercising a simple solution that eventually leads to deployment of a durable subscriber.

By Andrew Walker

An Idempotent Receiver is a receiver that can safely handle the receipt of the same message more than once. In the context of this discussion, it is important to understand the definition of idempotent and also of safely, and to understand what is meant by duplicate message.

First, idempotent, a mathematical term that made its way into computer science, is used to describe any function that has the same effect whether executed once or multiple times; see http://en.wikipedia.org/wiki/Idempotent_(software). Applied to messaging systems, idempotent means that the effect of the receipt of a particular message is the same even if the message is received multiple times.

To define safely, let’s first consider the focus of our discussion in this section. We are considering how to implement an Idempotent Receiver as part of a larger Java CAPS application. For simplicity, let’s call this Java CAPS application the “system.” A Java CAPS application normally accepts a message from an external application or the messaging system and then processes it in some fashion, often updating other external applications or data stores or triggering processing in another Java CAPS application—it causes permanent side effects. Our requirement for safely is based on the idea that the message will be processed within a Java CAPS solution and that the processing will cause the state of the system to change in some manner (side effects), either by updating data within the system or by causing the system to carry out further processing actions—for example, publishing another message to one or many external applications or causing the execution of other processes internal or external to Java CAPS. So safely requires that even if a duplicate message is received, the system will remain in the same state it was before the duplicate message arrived; that is, no data will be updated and no processing actions with undesirable side effects will be executed.

A duplicate message is one that would cause the system to repeat exactly the same processing steps, and possibly result in unintended and undesirable side effects external or internal to the system. A good example is the processing of a message that contains transaction data for a withdrawal transaction on a bank account. The system should process the same withdrawal only once. A duplicate message would contain the same transaction data, so a duplicate message, which has the same data content, would cause the withdrawal to be invalidly processed again—an undesirable side effect.

It is important to remember that some operations are inherently idempotent. Reading a database, for example, is idempotent, whereas updating the same database is not, unless the database is updated with the data that is already there (i.e., there is no change to the database content, which makes the update also idempotent in this specific case).

It is also important to consider the requirement for idempotence in the context of a wider solution. If a solution inserts records into a database table with a unique primary key, for example, and a record with such unique primary key already exists, then the solution is likely to receive a duplicate key exception. It can then alter logic flow based on the duplicate key event without special code required to guarantee idempotence if the unique primary key constraint already ensures that no undesirable side effects occur elsewhere in the solution.

In addressing the issue of idempotence in general, it is important to consider what action needs be taken by a solution when the requirement for idempotence is not met. Should the solution simply stop processing the message and discard it, or should it do something else, like alert an operator, negatively acknowledge the message, or take some action more appropriate to and dependent on the problem being solved?

All solutions to the idempotence issue rely on one or both of two properties of a message being processed. One is the ability to determine whether the message has already been processed at least once—duplicate message recognition. The other is the ability to determine from the message whether a particular action or a set of actions taken to process the message are already idempotent and therefore require no special treatment from the idempotence standpoint.

The following discussion presents one of the possible solutions to the issue of duplicate message recognition and relies on the ability of a relational database system, used in the example, to distinguish between a new record insertion and attempted insertion of a duplicate record.

Keep in mind that the source of a duplicate message is not constrained just to external applications but may also be the messaging system itself. The cause and the source of the duplication are not relevant to the design of an Idempotent Receiver. The causes of message duplication are many but generally occur due to the effects of exceptional or unforeseen circumstances, software bugs, or unreliable networks. The key point in designing an Idempotent Receiver is to not make assumptions or restrict yourself to one set of possible conditions that may cause message duplication.

To construct an Idempotent Receiver, we must create what we will refer to as a “de-duping” service—a service that, given a message, will advise whether the message is a duplicate of a message that was already processed. At the heart of a de-duping service is a method of keeping a history of all messages received so that it is possible for a receiver to determine if the currently received message has already been processed sometime in the past by examining the history. Of course, it would be very inefficient to store the entire contents of each message received, and that approach is not recommended. A much better strategy is to store some kind of Message ID or computed message digest for every message processed.

The selection of a good Message ID is critical to the success of the duplicate detection strategy. The Message ID must be unique for every unique message received. When we talk about uniqueness, we are talking about the message content being unique. A bad choice of Message ID would be any internal ID used by the messaging system, since this ID does not guarantee that any two messages have identical message data content. A much better choice of ID is one based on the business data that the message contains, such as a Product Order ID. If multiple messages may legitimately contain the same candidate IDs, then a compound ID needs to be created that includes the business ID plus extra information from the message data itself so that the message ID is unique—for example, a transaction code or transaction type, such as New, Update, Delete, or Modify. A timestamp field is another example of a bad choice of Message ID, since a timestamp usually has no bearing on how the message data is processed but simply supplies additional information about the data (i.e., at what time the data was created or entered). Having said that, it is worth pointing out that if the external sender, which creates the timestamp and other data used for Message ID, is the source of duplicate messages, and duplicate messages have the same timestamp and other ID components, then the timestamp may be a good choice as a part of a composite ID. Once an appropriate Message ID has been selected, we can move on to consider how to actually store these Message IDs in a list for the purpose of implementing a de-duping service.

On first thought, there appears to be two possible approaches to implementing an Idempotent Receiver in Java CAPS: in-memory and persisted to a backing store. It quickly becomes clear that an in-memory system, while seemingly attractive because of its obvious speed advantage, is fatally flawed for the simple reason that it is not reliable in the face of system failures. The list of Message IDs is lost once the system is shut down or restarted. A reliable Idempotent Receiver must have a persistent store of Message IDs to use for checking.

In general, it is more efficient to design the system such that the Idempotent Receiver acts as a gatekeeper to de-dupe the messages as they enter the system, as opposed to making every receiver of a particular message type in the system capable of handling duplicate messages.

To store the list of Message IDs, we need a persistent store such as a database that serializes updates to the store so that each receiver always sees an identical and consistent view of the Message ID list. Thus, even when duplicate messages of the same type are received at the same time and processed by different receivers, one of the messages is always guaranteed to be detected as a duplicate of the other.

Since the list of Message IDs is kept in a persistent store, the list will keep growing indefinitely unless some kind of cleanup is done to keep the list at a manageable size. Two obvious strategies for a cleanup process are one that uses a time condition (i.e., remove all Message IDs from the list older than a certain period of time) and one that uses a size condition of the Message ID list (i.e., keeps only the last x number of Message IDs received). The choice of which of these two strategies to implement will depend on the business requirements of the message handling and also, to a certain extent, on the message volume and message processing performance required of the system. When choosing a cleanup strategy, a balance needs to be achieved between the competing demands of performance and risk mitigation.

In pursuit of reusability integration, architects and solution designers seek to define services that implement some core functionality but can be invoked in a variety of ways. It may be that a service must be invoked synchronously by one application and asynchronously by another. It may be that a service must process payload that can be delivered as a JMS Message or as a flat file. It may be that a message to be processed must be transformed from source format to the format the service requires. To address these kinds of issues, the architect or the designer can implement one or more Service Activators [EIP], each of which invokes the same service on behalf of some other component, providing transformation services and endpoint bridging as necessary.

In general, remotely invocable Java CAPS services can use one of three interfaces: a JMS Request/Reply, an eInsight subprocess, or a Web Service. Similarly, Java CAPS Service Activators can be constructed to invoke services via one of these interfaces. With one degree of indirection, an eGate-only solution can be constructed to implement this pattern. The functionality would be implemented in a Java Collaboration, and one or more separate Java Collaborations, exposed as Web Services or JMS Listeners, for example, would receive requests and forward them to the functionality-implementing collaboration. It is also possible, however “hacky,” to invoke a Java Collaboration directly from another Java Collaboration.

Chapter 12, “Reusability,” sections 12.4 and 12.5, discuss how the same eInsight Business Process can used as a subprocess as well as an independent Web Service by another eInsight Business Process. In the former case, the invoking process is a Service Activator, and in the latter case, the Web Service Client is a Service Activator.

Chapter 4, section 4.5.1, contains an example of an eInsight Business Process invoking a piece of business functionality exposed as a JMS Request/Reply service using a wrapper collaboration that implements the JMS Request/Response functionality on its behalf. The wrapper collaboration is an example of a Service Activator.

While not an example of a Service Activator, the example of JMS Request/Reply Responder, discussed in Chapter 4, section 4.5.1, demonstrates how a JMS Responder can be implemented to return a response to a JMS Destination provided by the invoker, thus acting as a synchronous service, or pass it on to a connectivity map–configured JMS Destination, thus acting as an asynchronous service. This particular service can be invoked synchronously, by the client specifying the response destination via the JMSReplyTo property, or asynchronously, by the client not specifying a response destination. Both client implementations could be classified as Service Activators for the same service.

An eInsight Business Process can be used to implement a Service Activator using a Business Process Execution Language (BPEL) event-based decision construct. Chapter 7, section 7.5, “Multi-input Service Activator,” in Part II, walks through the implementation of an eInsight-based multi-input Service Activator.

Note

A multi-input Service Activator can be used in a solution that is built and deployed incrementally. For example, a part of the solution may be ready to be deployed and used. Messages come from a file system because the sending system cannot deal with any other method of providing input to an integration solution. Sometime later, this system is replaced by one that can use IMS to submit messages directly, or a Messaging Bridge that uses JMS to submit messages is developed. With a multi-input Service Activator that can accept messages using a Batch eWay and a JMS client, the solution that this Service Activator is a part of does not need to change and does not need to be redeployed to accept messages from different sources.

Multi-input Service Activators can also assist with unit testing solution components by allowing test message feeds at different points from different sources.

This chapter discussed a series of patterns [EIP] grouped under the Messaging Endpoints category. In many cases, a number of Java CAPS features and facilities are used together to implement specific patterns, such as Polling Consumer and Service Activator.