Service Agent: Service agents (a.k.a. filters, listeners, interceptors, handlers) is an event-driven program capable of transparently intercepting and processing messages sent to or from services. Common utility functions (e.g., encryption, authentication, validation, logging, routing) can be deferred to event-driven programs that don't require explicit invocation, thereby reducing the size of service compositions. Service agents can be designed to automatically respond to predefined conditions without invocation via a published contract. Reliance on service agents, however, can further tie an inventory architecture to proprietary vendor technology. Governance can also become an issue in that service agents need to be maintained with understanding of inventory-wide impacts of their changes. Refer to: Ibid.
Asynchronous Service Messaging: Various asynchronous messaging mechanisms can be applied to exchange messages among services. Queuing allows services to exchange messages via an intermediary buffer so that the services process messages independently by remaining temporally decoupled. Message paths can be dynamically determined by service agents for various types of intermediate routing logic such as content-based routing, load balancing, etc. Message delivery can be guaranteed by having service agents track messages, manage the issuance of acknowledgements, and persist messages during failure conditions, at the cost of added processing overhead and performance degradation. When building services as SOAP web services, this pattern is commonly applied by implementing a combination of the WS-Reliable Messaging standard and guaranteed delivery extensions, such as a persistent repository.
Publish-and-Subcribe Messaging: Events that occur within the functional boundary encapsulated by a service may be of relevance to other services, but without resorting to inefficient polling-based interaction, the other services have no way of learning about these events. The related other services establish themselves as subscribers of the service. The service, in turn, automatically publishes notifications of relevant events to its subscribers. A messaging framework is implemented capable of supporting publish-and-subscribe message exchange and associated complex event processing.
Enterprise Service Bus: An enterprise service bus represents an environment designed to foster sophisticated interconnectivity between services. It establishes an intermediate layer of processing that can help overcome common problems associated with reliability, scalability, and communications disparity. Enterprise service bus (ESB) is comprised of the co-existent application of many service design and composition patterns such as service adapter, service agent, asynchronous service messaging, publish-and-subscribe messaging, policy centralization, and rules centralization patterns. Refer to: Ibid.
Service Orchestration: Service orchestration integrates multiple services together to automate a process, creating a composite application. Orchestration environments such as Business Process Management Suite (BPMS) products supporting BPMN 2.0 modeling, BPMN 2.0 execution, and WS-BPEL execution support sophisticated and complex service composition logic that can result in a long-running runtime process. The orchestration pattern is a composite pattern comprised of several other service design, composition and inventory patterns including process abstraction, process centralization, rules centralization, service adapter, service agent, atomic service transaction, compensating service transaction, and state repository patterns, and often is used together with the ESB pattern. Refer to: Ibid.
Service Choreography: Service choreography is another way to create a composite application in service-oriented architectures. A service choreography model works without a central orchestrator. In service choreography, the participating services each know the business logic and sequence and timing of message exchanges, while in service otchestration, the participating services don’t know that they are being orchestrated as part of a higher-level service; only the central controller knows the business logic and messaging sequence. In service choreography, the logic of the message-based interactions among the participants is specified from a global perspective, while in service orchestration, the logic is specified from the local point of view of one single participant, called the orchestrator.
We have to deal with the problem of managing business processes that stretch across the boundaries of individual services. With microservices we hit this limit sooner than usual. While with orchestration we rely on a central coordinator like the conductor in an orchestra, with choreography each service work out the details like dancers in a ballet. A service publishes an event in an asynchronous manner, and other services subscribe to the event and react accordingly. This approach based on the publish-and-subscribe messaging pattern is more decoupled because some other services needing to react to the event can just subscribe to it. However, a service always needs to know which events published by other services it should subscribe to. In this aspect, choreography makes services tightly coupled.
BPMN 2.0 includes diagrams to model service choreographies. W3C has specified Web Service Choreography Description Language (WS-CDL) and Web Service Choreography Interface (WSCI) for modeling choreographies.