Jwbt251-Sweeney March 22, 2010

system is not responding to the integration service request, the timeout failure could

be reported back to the “CreateAnOrder” business service, which could apply a rule

to attempt to resubmit the order two more times and if unresolved inform the order

business process, which may apply rules to hold the order at the Process layer level

until it can be successfully submitted and generate a follow-up confirmation e-mail

to the customer.

The problem with this approach is that a complex and resource-intensive busi-

ness process initiated through a user login session now has to maintain its state

after the user exits the process and more than likely after the user close the session

by logging out. Because it is being managed at the Business Process layer, it must

reinvoke the Business and Integration layer services over and over again until a

successful commit is received.

If, alternatively, the integration service consumed a service from the exception

handling framework that (1) queued the request for resubmission and commit by

the legacy application and (2) published a notification containing the commit results

and confirmation number using the logging framework services, the integration

service could notify the business service of this exception. The “CreateAnOrder”

business service can now invoke the exception handling service that will maintain

its state until the commit from the exception service is published. Once the commit

P1: OTA/XYZ

P2: ABC

appB

JWBT251-Sweeney

March 22, 2010

11:15

Printer Name: Hamilton

318

Appendix B: Service Categories and Types

is published, the “CustomerOrderNotification” service can generate the customer

notification e-mail. The “CreateAnOrder” business service notifies the order business

process of this event, which in turn triggers the process to tell the customer about

the e-mail that will be received. When the user exits the order process, the business

process and the “CreateAnOrder” business service can be closed and shut down.

System or Utility Services

System or utility services are services that perform discrete, low-level processes.

Many SOA documents classify some of the provider framework services listed ear-

lier as utility services. If described in the context of designing and implementing a

service, they are utility services. If described in the context of an enterprise architec-

ture approach, however, they are much more than a utility. As described earlier, they

not only provide the shared capabilities that utility services provide but also play an

intricate role in the interoperability of services. Utility services are not designed to

provide interaction mechanisms with other services beyond the service that invoked

them. Utility services have little or no routing or decision logic embedded in them.

They do not apply any business rules and perform a task one way with no variations.

File transfer services move files from one location to another. Many traditional

applications use scripting languages or other tools outside the applications realm to

handle file transfers. Under SOA, we need a service mechanism to provide these

capabilities. Some ESB technologies provide these capabilities, as do some ETL tools.

An ESB or ETL platform that can wrap FTP/SFTP activities in Web services would

be the best solution.

Encryption/decryption services can be used to process lower-level encrypted

data. In the health industry, the Health Insurance Portability and Accountability

Act is requiring “personal health information” (PHI) to be encrypted when it is

stored or transported. This means that integration services accessing data stores

containing PHI directly need a mechanism to decrypt the data being delivered.

Encryption/decryption services at the system data level can be developed to support

this requirement.

Data format transformation services are those that transform data from one

format to another (e.g., flat file to XML and vice versa). For transaction and low-

volume data, this can be provided by an ESB. For higher volumes of data and large

file transformations, this is better handled by the use of an ETL tool.

Monitoring services are low-level system services that provide useful information

to higher-level SOA services. A monitoring service to “check available disk space”

may be used by a logging service to validate space availability for log entries.

Building these as services isolates the service consuming them from any physical

changes that may occur later on.

Service Types

Service types apply to the Business Process, Business Service, and Integration Service

layers. Since services in these three layers fall within the Business Domain category

of services, they reflect the different variations of business activities. Services of the

same type have common characteristics that are reflected in the design patterns

P1: OTA/XYZ

P2: ABC

appB

JWBT251-Sweeney

March 22, 2010

11:15

Printer Name: Hamilton

Appendix B: Service Categories and Types

319

developed by the enterprise architects. Services constructed in each of these three

layers should have a design pattern developed for each of the service types defined

below. When a developer is developing a service that is one of type transactional in

the Business Service layer, the design pattern for transaction services at the Business

Service layer defines all the core capabilities required for those transaction services.

The service type definitions are also helpful to solutions architects when esti-

mating the scope and cost of initiatives. More complex service types take longer and

cost more to develop; therefore, the cost estimates and delivery timelines for these

services will be higher and longer. Over time, experience gained from developing

the different types of services and the postinitiative “lessons learned” analysis will

help you to fine-tune the data used for estimating services, resulting in more accurate

estimates.

The service types are:

Transaction services

Inquiry services

Data services

Reporting services

Image services

Content and document services

Transaction Services

Transaction services are those that result in the creation, update, or deletion of

business records in the core transaction systems of the company. They involve

changes to the official systems of record within the company. In an SOA environment

transaction services need to ensure that all of the system of record changes are

completed and in the proper order. Transaction services need to understand what

actions need to be taken in the event that a failure in a commitment occurs, including

the capability to roll back previously successful commitments in other systems. SOA

applications may also have to accommodate the fact that the SOA transaction service

may be available even when the underlying system of record is not available.

Since three Business Service Domain layers (Business Process, Business Service,

and Integration Service) may be involved in processing a business transaction, all

three layers will be involved in handling exceptions encountered when processing

the transaction. As the example provided in the “Provider Enterprise Framework

Services” section suggests, there are multiple ways transaction exceptions can be

handled. There may be significant performance hits if not done properly. If you do

not have a defined exception handling framework and defined transaction service

design pattern at these three Business Domain layers, every transaction process

developed may handle exceptions differently.

Transaction services design patterns at each domain layer will ensure that trans-

action processing activities, including exception handling, will occur at the right

level and be consistently applied at those levels.

The Integration layer design pattern for transactions should specify that updates

or commits to individual systems or databases are controlled by Integration layer

logic. Resolutions to exceptions to those individual system commits should be han-

dled at this layer as well through the use of Integration-layer exception handling

P1: OTA/XYZ

P2: ABC

appB

JWBT251-Sweeney

March 22, 2010

11:15

Printer Name: Hamilton

320

Appendix B: Service Categories and Types

framework services. Specifications for the number of retries when individual sys-

tem connections cannot be established, metadata about system of record availability

windows, transaction queuing mechanisms for persisting updates during outage win-

dows, and submitting them once the system is back on line should all be specified

in the Integration layer transaction service design pattern.

The Business Service layer design pattern for transactions defines how to handle

transaction processing and exception handling activities that occur above the Inte-

gration layer and below the Process layer. If a Transaction business service invokes

more than one transaction integration service or other transaction business services,

it must manage the commit and exception handling process defined for all those

services as a group. For example, assume that a specific transaction business service

calls an integration service to update one system of record and another transaction

business service (which in turn calls another integration service) to update a second

system of record. The two integration services will handle any exceptions at the

individual system commit level. The second business service invoked may provide

specific actions that were undertaken to provide an alternate resolution to the excep-

tion. If the business rule specifies that both of these systems of record updates need

to be committed, and if one fails, the other needs to be rolled back, this exception

process needs to occur at the Business Service layer.

Note

An Integration layer service should never be consumed directly by a Business

Process Service layer. It should always be consumed through a business service.

The design pattern at the Business Process Service layer defines how business

transactions are choreographed from start to finish. Any exception handling or roll-

backs occurring at this level are at a coarse business process level.

In the Business Process Service layer example, assume the two updates

were to:

Create an account record in the account master file for a new customer.

Set up a credit limit for the customer.

The customer had been recently acquired but decided to create a new account

for its subsidiary, even though the subsidiary was planning to order under the

parent’s volume discount contract.

This business service was consumed in the first step of the business process.

After this step is completed, the user can invoke the process step that invokes

the “PlaceAnOrder” business service. A rule in the “PlaceAnOrder” service threw

an error exception after determining that a different customer account from the one

entered on the order was associated with the volume discount contract number

entered. The user entered the parent’s account number, and the order was validated

and placed. The business process should take the user back to the “Create/Maintain

Account” business service used previously to set up the subsidiary account invoking

P1: OTA/XYZ

P2: ABC

appB

JWBT251-Sweeney

March 22, 2010

11:15

Printer Name: Hamilton

Appendix B: Service Categories and Types

321

the revalidate account option within the service. The revalidate account rules in

the service determine that the reason it was invoked was to resolve a duplicate

account number. The exception record in the exception handler log file provides

the subsidiary, parent account, and contract number keys as well as the order

exception reason. The business service will ask the user if the user wants to keep

the new subsidiary account or delete it. It will inform the user that no volume

contract exists for this account. If the user elects to delete the subsidiary account, the

account number record previously created needs to be deleted. The “Create/Maintain

Account” business service will accomplish this by calling the integration service for

deleting account master file records.

Inquiry Services

Inquiry services simply provide read access to the data in the legacy systems of

record. There are no create, update, or delete actions involved. Inquiry services do

not have to be persisted or committed. Inquiry service design patterns seldom queue

inquiry requests that fail due to system availability windows. They can, however,

invoke other actions to accommodate for these outages. They can be designed to

provide data from a near-time data store when the primary system is unavailable.

For example, an order operational data store (ODS) can provide an order status that

is up to four hours old during the four-hour batch processing window of the order

system.

Therefore, the Integration Service layer design pattern for inquiry services that

need or will need higher availability than the primary source system should specify

a second source to provide the data during the outage period. This design pattern

should also specify that the higher-layer service consuming the Integration layer

inquiry service is informed that the data was retrieved from the secondary source

and why the secondary source was used (batch window, scheduled maintenance

window, or unavailability reason unknown).

The design pattern at the Business Service layer defines the rules to accept the

secondary source or issue a new request if the reason was not a batch or maintenance

outage. The design pattern may also specify a lookup in the exception log for an

entry generated by the inquiry integration service and use this information to help

make the decision.

The design pattern at the Business Process layer will support a combination of

a system- and user-driven decision process. If the cause is a batch or maintenance

window, the user will be given the near-time value and will be informed to try again

at a later specified time if more accurate status is wanted. If the reason was due to a

system outage, the user can accept the status that is up to four hours old or initiate

a new request.

The design patterns for Integration and Business Service layer inquiry services

should specify a framework for caching data where appropriate. For example, a

business service that could potentially involve multiple product description and

pricing lookups should be designed to cache the product price file (or a subset of

the file) to improve the performance of the service.

If an inquiry integration service uses translation tables to convert cryptic code

values stored in the system of record to intelligent values in the semantic data model,

these code tables should be cached as well.

P1: OTA/XYZ

P2: ABC

appB

JWBT251-Sweeney

March 22, 2010

11:15

Printer Name: Hamilton

322

Appendix B: Service Categories and Types

The design pattern for inquiry services should specify integration with the en-

terprise SOA security framework to provide role-based policy challenges when the

inquiry service is invoked at the Business Service layer.

Data Services

Data services are either data distribution or data acquisition services. Data distri-

bution services place bulk data produced from an SOA component to a specified

location or locations. Data acquisition services provide bulk data to SOA components

for further processing or to support the processing of other transactions.

Data acquisition services are different from inquiry services in that data acquired

through an inquiry service is designed to support one transaction or event whereas

data acquired by a data acquisition service is designed to support multiple events.

For example, a customer’s order history inquiry could return a substantial number

of order records, but the records would be only for that customer and only as a

reply to that single inquiry request. A data acquisition service initiated by a district

office associate that extracts and downloads all the orders processed by that district

office during a specified time period to a local reporting server would be a data

acquisition service. This data will be used multiple times for analytical and reporting

purposes.

Design patterns for data acquisition services include specifications for:

Full refresh or incremental acquisition.

Encryption/decryption services for transport of the data.

De-identification of data.

Design patterns for data acquisition services specify integration with the enter-

prise SOA security framework for controlling authorization to the service and to

restrict the destination of the data being acquired (i.e., places the data in a secured

directory or database where user access is restricted to authorized employees). Data

acquisition services may reside on top of underlying data manipulation tools, such

as ETL tools that can aggregate data from multiple sources, provide transformations

of the structure and format of the data, and manage the full commit to the target

location.

An architecture framework for data services should be based on a Common In-

formation Model (CIM) that delivers standard canonical definitions utilizing standard

semantic models wherever possible. This framework would also include standard

rules for calculating and producing derived data that is commonly used by the

business.

The architecture framework should specify that data services utilize, whenever

possible, ODS, data warehouse (DW), or DW marts to source the data provided

rather than the core transaction system of record for the data to minimize the per-

formance impact on these systems. These secondary stores also help to isolate the

proprietary data structures and nonsemantic formats that exist in the legacy transac-

tion systems.

Ultimately, SOA Data services provide a standard mechanism for all data dis-

tributed throughout the corporation. All data is defined through a CIM and delivered

in standard formats based on the enterprise data model defined by the CIM. The

P1: OTA/XYZ

P2: ABC

appB

JWBT251-Sweeney

March 22, 2010

11:15

Printer Name: Hamilton

Appendix B: Service Categories and Types

323

CIM should be based on industry-standard terminology and definitions if they exist.

The high-level entities defined in the CIM will represent the enterprise data model

of the corporation.

Reporting Services

Reporting services are services that deliver defined sets of data through a presen-

tation layer delivery mechanism. Reporting services are different from data services

in that they are directly usable by the consuming constituent without additional

manipulation or formatting. Data services require additional processing capabili-

ties to convert the data to viewable information. Reporting services provide the

logic for presenting the data as information to the constituent. Data services de-

liver data that is intended for further processing by the business service or business

process consuming it. The data delivered by a data service may never be seen

by the person using the service, even if it was delivered to support a business

process.

Reporting services can be scheduled or ad hoc. They may also provide options

for sorting, limiting, or restructuring the formats the service provides. Reporting

services can also be designed to provide extracts of the report data into formats like

Excel or delimited files for further processing by the user or into formats like PDF

that cannot be processed further.

The design pattern for reporting services should specify integration with the

enterprise SOA security framework to provide role-based authentication of the con-

sumer. Depending on the underlying reporting tool used to generate the report and

the security granularity it supports, the authorization can occur at the report level,

at a defined sublevel of the report, or at the report line level.

You should think of a reporting service as a “container” that:

Encapsulates the formatted report data generated by the reporting tool.

Manages the integration of the enterprise SOA security framework with the

security platform within the reporting tool platform.

Provides the service invocation stub and its associated service contract used by

a business service or a business process to invoke the reporting service.

The value of this approach is to provide a loosely coupled abstraction from the

underlying reporting tool platform. If the reporting tool is replaced or the report is

generated from some other tool in the future, the only changes necessary will be

at the service provider side with no impact to the service contract exposed to the

service consumer.

Image Services

Image services provide an SOA framework for capturing, storing, and deliver-

ing images to SOA applications. If your company processes a lot of scanned or

faxed documents and multiple business units or multiple business processes use

those documents, you should develop an architecture framework to support image

services.

P1: OTA/XYZ

P2: ABC

appB

JWBT251-Sweeney

March 22, 2010

11:15

Printer Name: Hamilton

324

Appendix B: Service Categories and Types

Image services are similar to reporting services in that they:

Encapsulate the image display retrieved from the image storage location.