| VETO is a common integration pattern that stands for Validate, Enrich, Transform, Operate (Figure 11-1). The VETO pattern and its variations can ensure that consistent, validated data will be routed throughout the ESB. Figure 11-1. The VETO pattern 
- Validate
-
The Validate step is usually the first part of any ESB process and can be accomplished in a number of ways. It's important that this step happen independently if possible; this removes the burden of validation from all of the downstream service implementations and promotes reuse. Building validation directly into the first service of a process makes it difficult to insert an additional service in front of it without requiring that the new service also provide its own validation. The simplest form of validation is to verify that an incoming message contains a well-formed XML document and conforms to a particular schema or WSDL document that describes the message. This requires that the service use a validating parser and always have available the up-to-date XML schema for a particular message type. The schema and WSDL can be kept in the directory service and managed remotely by the management infrastructure of the ESB. A service may also have scripting associated with it. For example, in Chapter 7, scripting was used to call the isPO( ) helper function that was made available to the service through its configuration (Figure 11-2). Figure 11-2. XML schema, WSDL, and validation scripts can be made available to a service through configuration 
If the target data is not in XML format or if there is no schema or WSDL available, then a custom service can be used to validate the incoming message.
- Enrich
-
The Enrich step involves adding additional data to a message to make it more meaningful and useful to a target service or application. As you recall from the PostalCode example in Chapter 4, the Enrich step was used to put the serviceLevel="overnight" attribute on the PostalCode element, and to put the new data structure with the additional digits beneath the PostalCode data element. The Enrich service could be implemented to invoke another service to look up additional data, or it could access a database to get what it needs (Figure 11-3). Figure 11-3. The Enrich step adds additional data from external sources 
- Transform
-
The Transform step converts the message to a target format. This often involves converting the data structure to an internal canonical format, or converting from the canonical format to the target format of the Operate step. The target system may have its own built-in validation rules requiring that the transformation step modify the incoming data in order to prevent the target system from rejecting the message. In this sense, the transformation step is also providing prevalidation protection in a separate service that can be separately managed. While this may mean redundant logic in the short term, it provides more flexibility in the long term because it allows the Operate step to focus on business logic.
- Operate
-
The Operate step invokes the target service or interacts in some way with the target application. If the operation is a service that is written to conform to the agreed-upon canonical data format, the transformation converts from the incoming format to the canonical format, if it isn't already in that format. If the target operation is an enterprise application that requires its own data format, then the transformation step converts the message to the target format required by the application.
The VETO concept is profoundly simple, and is at the heart of what an integration architect does regularly with an ESB. An ESB provides an event-driven SOA to applications in an integration fabric. Regardless of the process routing and orchestration method being used itineraries, sophisticated process modeling using an orchestration service, or the XML pipelining model discussed in Chapter 7 it is the VETO pattern and its variations that provide the overall value and flexibility to the integration fabric. The stages of the VETO pattern can be implemented as separate services that can be configured, reused, and independently swapped out for alternate implementations (Figure 11-4). Figure 11-4. The VETO pattern as independent services 
11.1.1 Variations: The VETRO Pattern The VETO pattern has many variations. One such variation is the VETRO pattern, which includes a Route step such as a CBR service (Figure 11-5). Figure 11-5. The VETRO pattern includes a Route step, such as a content-based router 
In some cases the validate, enrich, and transform steps can be accomplished in one service implementation. The CBR service discussed in Chapter 7 used the script-based validation directly in the service itself instead of using a separate service. In many cases, this is not advised because it does not promote loose coupling and service reuse, and does not allow the validation to be separately defined and managed. However, it may sometimes be convenient, particularly if the context of validation can't easily be applied to other uses. |
