Service Agent

How can event-driven logic be separated and governed independently?

Problem Service compositions can result in numerous extended scenarios, requiring numerous composition members resulting in increased composition logic complexity and performance overhead.
Solution Event-driven logic can be deferred to event-driven programs that donÕt require explicit invocation.
Application Service agents can be designed to automatically respond to predefined conditions without invocation via a published contract.	Impacts The complexity of composition logic increases as it gets distributed across services and event-driven agents. Increased reliance on service agents can further tie an inventory architecture to vendor technology.
Principles Service Loose Coupling, Service Reusability	Architecture Inventory, Composition

Table 6.23 – Profile summary for the Service Agent pattern.

Problem

Service composition logic consists of a series of service invocations; each invocation enlisting a service to carry out a segment of the overall parent business process logic. Larger business processes can be enormously complex, especially when having to incorporate numerous Òwhat ifÓ conditions via compensation and exception handling sub-processes.

Furthermore, each service invocation comes with the performance overhead of having to explicitly invoke and communicate with the service itself. The performance of larger compositions can suffer from the collective overhead of having to invoke multiple services to automate a single task.

Figure 6.101 – A service sequentially composing several others to carry out a particular capability.

Solution

Service logic that is triggered by a predictable event can be isolated into a separate implementation capable of automatic invocation upon the occurrence of the event. This reduces the amount of composition logic that needs to reside within controller services and furthermore decreases the quantity of service invocations for a given composition.

Figure 6.102 – By deferring common logic to service agents, the overall quantity of explicitly invoked services decreases. Note that the tube symbols are used to show that although service agents are positioned between business service layers, they are not actually considered as part of those layers.

Application

The chosen service logic is implemented as part of a program capable of automatically responding to predefined events. Within a Web services framework, this is most commonly accomplished by the creation of service agents; event-driven programs with no published contract.

Service agents automatically intercept incoming or outgoing messages and carry out their capabilities without requiring explicit invocation. They are most commonly positioned as extensions of the utility service layer, although agents with a business-centric context can also be designed.

Vendor runtime platforms commonly provide service agents equipped with cross-cutting logic for common utility functions such as authentication, logging, and load balancing. As first introduced in the Service Architecture section of Chapter 3 (Figure 3.x), the message processing logic that is a natural part of any Web service implementation actually consists of a series of system (and perhaps custom) service agents that collectively carry out functions associated with message exchanges.

Impacts

Event-driven agents provide yet another layer of abstraction to which multiple service compositions can form dependencies. Although the perceived size of the composition may be reduced, the actual complexity of the composition itself does not decrease. Composition logic is simply more decentralized as it now also encompasses service agents that automatically perform portions of the process logic.

Overuse of this design pattern can result in an inventory architecture that is difficult to build services for. With too many service agents transparently performing a range functions, it can become too challenging to design service and composition architectures without forgetting to take all possible agent-related processing into account.

Governance can also become an issue in that service agents will need to be owned and maintained by a separate group that needs to understand the inventory-wide impacts of any changes made to agent logic. For example, system service agents can be subject to behavioral changes as a result of runtime platform upgrades. An agent versioning system may be required to address these challenges.

Relationships

The event-driven programs created as a result of applying this pattern become a common and intrinsic part of service-oriented inventory architectures. The type of logic they encapsulate is comparable to utility logic and therefore similar design considerations can be applied. For example, instead locating security logic into a utility service, the Security Centralization pattern can be applied to service agents instead.

Either way, the Service Agent patternÕs most fundamental relationships are with Service Messaging and Messaging Metadata, as service agent programs are almost always designed to intercept and process message contents.

The overuse of this pattern can lead to an undesirably high level of dependency on a vendor platform, as per the strained relationship with the Vendor-Agnostic Context pattern. This can be due to the need to build custom service agents with proprietary programming languages or because services rely too heavily on the proprietary agents provided by vendor runtime environments. Canonical Resources considerations can alleviate this, but do not directly regulate the quantity of produced service agents.

Figure 6.103 – The Service Agent pattern is responsible for produce service agent programs, which end up relating to a range of architectural design patterns.

Case Study Example

Case study content is not available on this Web site.