An application has a service that it would like to make available to other applications.
How can an application design a service to be invoked both via various messaging technologies and via non-messaging techniques?
Design a Service Activator that connects the messages on the channel to the service being accessed.
A Service Activator can be one-way (request only) or two-way (Request-Reply). The service can be as simple as a method call—synchronous and non-remote—perhaps part of a Service Layer [EAA]. The activator can be hard-coded to always invoke the same service, or can use reflection to invoke the service indicated by the message. The activator handles all of the messaging details and invokes the service like any other client, such that the service doesn’t even know it’s being invoked through messaging. ...
Related patterns: Command Message, Competing Consumers, Event-Driven Consumer, Invalid Message Channel, Message Dispatcher, Message Endpoint, Messaging Gateway, Polling Consumer, Request-Reply, Transactional Client
Want to keep up-to-date? Follow My Blog.
Find the full description of this pattern in: Enterprise Integration Patterns
Gregor Hohpe and Bobby Woolf ISBN 0321200683 650 pages Addison-Wesley
| From Enterprise Integration to Enterprise Transformation: My new book describes how architects can play a critical role in IT transformation by applying their technical, communication, and organizational skills with 37 episodes from large-scale enterprise IT. DRM-free eBook on Leanpub.com Print book on Amazon.com |
Parts of this page are made available under the Creative Commons Attribution license. You can reuse the pattern icon, the pattern name, the problem and solution statements (in bold), and the sketch under this license. Other portions of the text, such as text chapters or the full pattern text, are protected by copyright.
|
|