building an soa with infrastructure, application, and ... · building an soa with infrastructure,...

Building an SOA withInfrastructure, Application,and Orchestration Servicesfrom the Ground Up

by Max Dolgicer, Senior Consultant, Cutter Consortium; and Gerhard Bayer

A large amount of information is available describing the potential

benefits of service-oriented architecture (SOA) as well as the best

practices, architecture guidelines, and design patterns to achieve them.

However, putting SOA to the test in a real-world project always

provides the most valuable insights. This Executive Report discusses

a comprehensive case study based on a project that was conducted

for one of the world’s leading chauffeured services companies.

Enterprise Architecture

Vol. 11, No. 9

http://www.cutter.com

The Enterprise Architecture AdvisoryService Executive Report is publishedby the Cutter Consortium, 37 Broadway,Suite 1, Arlington, MA 02474-5552,USA. Client Services: Tel: +1 781 6419876; Fax: +1 781 648 8707; E-mail:[email protected]; Web site: www.cutter.com. Group Publisher: Kara Letourneau,E-mail: [email protected] Editor: Cindy Swain, E-mail:[email protected]. ISSN: 1530-3462.

©2008 Cutter Consortium. All rightsreserved. Unauthorized reproductionin any form, including photocopying,faxing, image scanning, and downloadingelectronic copies, is against the law.Reprints make an excellent training tool.For more information about reprintsand/or back issues of Cutter Consortiumpublications, call +1 781 648 8700 ore-mail [email protected].

Cutter Consortium is a unique IT advisoryfirm, comprising a group of more than 100internationally recognized experts who havecome together to offer content, consulting,and training to our clients. These expertsare committed to delivering top-level, criti-cal, and objective advice. They have done,and are doing, groundbreaking work inorganizations worldwide, helping compa-nies deal with issues in the core areas ofsoftware development and agile projectmanagement, enterprise architecture, busi-ness technology trends and strategies, inno-vation, enterprise risk management, metrics,and sourcing.

Cutter offers a different value propositionthan other IT research firms: We give youAccess to the Experts. You get practitioners’points of view, derived from hands-on expe-rience with the same critical issues you arefacing, not the perspective of a desk-boundanalyst who can only make predictions andobservations on what’s happening in themarketplace. With Cutter Consortium, youget the best practices and lessons learnedfrom the world’s leading experts — expertswho are implementing these techniquesat companies like yours right now.

Cutter’s clients are able to tap into itsexpertise in a variety of formats, includingprint and online advisory services andjournals, mentoring, workshops, training,and consulting. And by customizing ourinformation products, training, and con-sulting services, you get the solutions youneed while staying within your budget.

Cutter Consortium’s philosophy is that thereis no single right solution for all enterprises,or all departments within one enterprise,or even all projects within a department.Cutter believes that the complexity of thebusiness technology issues confronting cor-porations today demands multiple detailedperspectives from which a company canview its opportunities and risks in order tomake the right strategic and tactical deci-sions. The simplistic pronouncements otheranalyst firms make do not take into accountthe unique situation of each organization.This is another reason to present the severalsides to each issue: to enable clients todetermine the course of action that best fitstheir unique situation.

Expert ConsultantsCutter Consortium products and servicesare provided by the top thinkers in ITtoday — a distinguished group of inter-nationally recognized experts committedto providing top-level, critical, objectiveadvice. They create all the written deliver-ables and perform all the consulting. That’swhy we say Cutter Consortium gives youAccess to the Experts.

For more information, contact CutterConsortium at +1 781 648 8700or [email protected].

ABOUT CUTTER CONSORTIUM

Access to the Experts

Enterprise Architecture

Rob Austin Ron Blitstein Christine Davis Tom DeMarco Lynne Ellyn Jim Highsmith Tim Lister Lou Mazzucchelli Ken Orr Mark Seiden Ed Yourdon

Cutter Business Technology Council



mailto:[email protected]



1©2008 Cutter Consortium Vol. 11, No. 9 ENTERPRISE ARCHITECTURE

Building an SOA with Infrastructure,Application, and Orchestration Servicesfrom the Ground Up

THE BUSINESS CASE

This case study is based on a project that was conductedby our company, International Systems Group, Inc.(ISG), for one of the world’s leading chauffeured ser-vices companies (the company wished to remain anony-mous). This company operates globally, and there is nomajor city in the US that does not have its service cover-age. The clientele of the company includes individualsand corporate clients as well as travel agencies. Its valueproposition is based on delivering a highly personalizedlevel of service and mission-critical reliability, with ahigh level of consistency and safety.

Figure 1 illustrates a business process that covers thetypical phases of a car service booking (excluding excep-tion processing). This business process consists of thefollowing nine steps:

1. A customer or travel agent requests a newreservation.

2. The reservation system creates a new reservation.

3. The dispatching system picks up the newreservation.

4. A dispatcher uses the dispatching system to senda job allocation to a driver.

5. The driver receives the job allocation.

THIS MONTH’S AUTHORS

IN THIS ISSUE

1 The Business Case

4 Adapting a Traditional DevelopmentMethodology for a Service-OrientedSDLC

7 Top-Down vs. Bottom-Up Approach

8 The B2B Gateway Architecture

16 The Data Architecture

18 Conclusions

21 Endnotes

21 About the Authors

Max DolgicerSenior Consultant, Cutter Consortium

Gerhard Bayer

Portal orCall Center

Reservations andProfiles Services

DispatchingServices

BillingServices

76

5 4

3

21

8

9

International Systems Group (ISG), Inc.

Figure 1 — Typical business process to book cars.


www.cutter.comEXECUTIVE REPORT 2

6. The driver reports end-of-job billing information backto the corporate systems.

7. The billing system receives the end-of-job informationand calculates the bill.

8. The billing system sends an invoice to the customer.

9. The customer receives the invoice.

Many of these steps were not automated but wereconducted through manual, error-prone activities.For example, reservation requests were received in callcenters through the phone and from business partnersthrough e-mail. The requests then had to be keyed intothe back-office applications. The dispatchers needed tointeract with the drivers via phone calls and had to per-form manual data entry. Finally, there was no way forcorporate clients to directly retrieve billing informationbetween the regular billing cycles. A business mandateto expand into new B2B revenue channels was the majordriver for this project, and the lack of automation andthe cost of one-off integration solutions was an impedi-ment for IT to meet the business requirements.

Business Objectives of the B2B Gateway

The company had been defining and implementinga new component and service-oriented architecture(SOA) for its core applications, which handles job dis-patching, billing, and trip reservations. The new appli-cations and services that are based on this architectureimprove the IT capabilities “behind the firewall.”

At the same time, there was an urgent need to moveaway from mostly manual or semimanual interactionwith business partners (e.g., some of the company’ssubsidiaries) and most importantly to enable growth ofthe business by entering into automated B2B relation-ships with new business partners. The multitude andcomplexity of these automated B2B interactions war-ranted the implementation of a B2B gateway, whichshields the core applications from external partner sys-tems and, on the other hand, provides a uniform andstandardized interface that the external partner systemscan access. Figure 2 shows an overview of the involvedsystems.

Figure 2 also shows the core applications and services(depicted to the right) that handle reservations, dispatch-ing, and billing. The B2B gateway provides a uniforminterface to the different user constituencies (depictedto the left). Those include some of the large customerswho want to automate the way the company is billingthem, supply chain partners (i.e., chauffeured serviceproviders that subcontract with the company), as wellas global distribution systems (GDSs) such as Sabre andApollo, which can be accessed through a system pro-vided by the Ground Travel Technology Team (GT3).GT3 provides technologies to automate the groundtransportation industry. It is a vendor-neutral infra-structure company that delivers advanced reservationsand confirmations. It connects chauffeured serviceproviders, travel agencies, and corporations.

Booking Agents

Dispatch

Chauffeurs

Back Office/ Customer Service

BusinessAviationSystems

Travel Web Sites

Customers

GDS Systems

Electronic Distribution

Channels

Customer Intranet

Sites

Supply Chain

Partners

Service Network

B2B Gateway

Core Application Services

Reservations

Reservations andProfiles Services

Passengers

Accounts

Price Quotes

Service Providers

Locations

DispatchingServices

BillingServices


Figure 2 — Systems overview.



Furthermore, the company wanted to receive reserva-tion requests directly from travel Web sites that offersearch engines (e.g., Orbitz) and from a number ofprivate aviation companies (e.g., NetJets).

Another requirement for the B2B gateway was to sup-port wireless communication with chauffeurs througha third-party system (“Vettro”). This system interactswith handheld devices that the drivers use to receive,display, and respond to job allocations. On the otherhand, the wireless system utilizes two-way interactionwith the B2B gateway (i.e., it acts as a client of the gate-way in order to relay data to the back-office applica-tions, and it acts as a service that the gateway calls topush information to the wireless system to forward itto a driver).

In the first phase of the project, the B2B gatewayenabled the company to receive reservation requestsfrom a multitude of partners electronically and acceptthem into the back-office reservations application auto-matically. The system was required to support thefollowing functionality:

Create reservation. A request for a new reservationis received from a business partner.

Modify reservation. A request for the modificationof an existing reservation is received from a businesspartner.

Retrieve reservation. A request to retrieve informa-tion about an existing reservation is received from abusiness partner.

Cancel reservation. A request to cancel an existingreservation is received from a business partner.

Quote request. A request for a rate quote is receivedfrom a business partner.

Provider modifies reservation. A business partnerneeds to be informed about reservations that havebeen made originally through one of the B2B chan-nels but subsequently the customer cancelled thereservation directly with the company.

How Business Objectives Are Fulfilled by IT

The business sponsors had agreed with the CIO on a listof high-priority objectives that they wanted to achievethrough their SOA effort. Table 1 provides an overview ofthese business objectives and how they were addressedby IT, in particular through the migration to SOA.

Some examples of the business objectives include newservice offerings (e.g., sharing a limousine service withanother customer and cross-selling by enabling a servicerep to offer a customer who is going to the airportcar service at his or her destination city). In terms ofimproving customer service, the company wanted tooffer direct access to billing information for its corporatecustomers as well as reduce pricing inconsistencies thatwere a result of duplicated business logic in differentapplications that handle price quotes versus invoicing.

Total cost of ownership (TCO) and risk managementwere objectives that originated on the IT side. Stream-lining the application portfolio and reducing the

Business Objectives Addressed by IT

Revenue enhancement:

• New service offerings

• Cross-selling

• Acquisitions

Customer service enrichment:

• Single view of the customer

• Better customer self-service

• Improved business process consistency

Allow travel agents to book

with The Company using

major GDS systems

TCO

Risk management

• Better leverage of the IT infrastructure

• Increased extensibility and adaptability

of the core applications

• Avoid one-off integration solutions

• Creation of a centralized reservation

system with customer profiles

• SOA enables efficient integration of

a portal with back-office systems

• Centralized SOA leads to improved

business process consistency

Automated B2B integration with

major GDSs and other types of

business partners

Service reuses, decreased complexity

Core services (foundation and some

application) are implemented by

highly skilled designers/developers

Table 1 — Business Objectives Addressed by IT


integration points should reduce the TCO, while theseparation of services into clearly distinct categoriesallowed utilizing highly skilled software engineers formission-critical service implementations (e.g., servicesthat deal with low-level infrastructure coding versusthose that are mainly concerned with business logic).

Project Scope

The overall goal of the B2B gateway project was toimplement a central gateway in such a way that busi-ness partner integration becomes a repeatable, low-riskeffort that allows the company to capitalize on partner-ing opportunities in a timely fashion. The scope of theproject included:

Encapsulation of the legacy reservation system.Since the legacy reservation system was beingmigrated to a new system in several phases, it wasessential that business partners were shielded fromany incompatibilities that may be caused during themigration phases.

Connectivity to GT3. The GT3 GDS presented a sub-stantial business opportunity for receiving automatedreservation requests. The B2B gateway needed to sup-port the proprietary B2B protocol employed by GT3.

Definition and implementation of a B2B protocolstandard for the chauffeured services industry.Many business partners want to utilize a standard,Web services–based protocol that the companydefines and maintains. To that end, the companyhas defined the Chauffeured Service Interface (CSI),which is a collection of XML schema–based servicesfor the B2B interactions that pertain to reservations(e.g., create and retrieve).

Definition of a common XML-based data architec-ture. The diversity of systems that are connected tothe B2B gateway (i.e., partner systems, legacy sys-tems, and newly developed applications) necessitatedthe definition of a comprehensive data architecturewith clearly defined data-format boundaries andmappings between proprietary or legacy formatsand standard formats.

Integration with a third-party wireless system.Chauffeurs use a third-party wireless system sotheir smart phones can connect to the company’scorporate systems. The B2B gateway needed tomediate between the third-party system and theback-office applications.

Implementation of an SOA foundation. The itemslisted above constituted the primary goals of theproject. However, the company wanted to capitalizeon the opportunity and build an SOA foundationconsisting of common services that could be reusedacross several business partner integration solutions.

ADAPTING A TRADITIONAL DEVELOPMENTMETHODOLOGY FOR A SERVICE-ORIENTED SDLC

Building a successful SOA requires an appropriatedevelopment methodology. Most development organi-zations have been utilizing a “traditional” methodologyfor their object or component-based projects. The majorsoftware development project tasks in an SOA projectare the same as in traditional (component-oriented)projects. They can, for example, be governed by a RUPapproach. However, the traditional RUP needs to beextended in order to address the SOA-specific issues.Figure 3 shows the typical breakdown of RUP activitiesand phases.

At the center of traditional development methodologiesare the concepts of OO analysis and design (OOAD),which usually focus on a level of granularity that is toosmall compared to what is needed for service-orientedanalysis and design (SOAD). In other words, class-levelmodeling doesn’t fit well with business-service model-ing, and SOAD must be predominantly process-driven.A service-oriented development methodology mustcombine OOAD and SOAD since services and compo-nents need to be combined for a complete solutionimplementation.

Adaptation of the Activities

This following sections address the RUP activities oneby one and provide an introduction to the adaptationsthat are required to make them feasible for developingservice-oriented applications.

Business Modeling Activities

SOA takes a process-centric approach to development,and the focus should be on the composition of processflows that orchestrate services into a business process(in contrast, OO development is focused on componentdesign). An SOA that follows this approach should lend

SOA takes a process-centric approach to develop-

ment, and the focus should be on the composition

of process flows that orchestrate services into a

business process.



itself for better alignment with the requirements of thebusiness. However, aligning business strategy to IT hasoften failed due to lack of traceability from businessmodels to IT architecture and implementation. A suc-cessful SOA must start with an architectural representa-tion that the business sponsors can understand. Next,one has to create an audit trail from business modelsthrough IT architecture to project implementations.

In many cases, the problem with this approach is howto obtain the business models. Ideally, they would havebeen created before a particular IT project is even initi-ated. They should identify coarse-grained businessfunctions and processes first, which might span severalapplication areas or lines of business, before they drilldown into detailed business processes that will be thefocus of a specific IT project. An example of a coarse-grained business function is “inventory management,”which should be defined so that it includes an identifi-cation of the owner of the business function; his orher role and responsibilities; the priorities in fulfillingthis function (e.g., minimize inventory); the actors thatrelate to this function; the tasks that the business func-tion performs (e.g., shipping and restocking); and pre-and post-conditions for each task.

Although the company had already mapped out itsmajor business processes, it was mostly concerned withthe operation of the back-office systems. There wereonly limited, manual B2B interactions in place, and themajority of B2B business processes were defined duringthe B2B gateway project. This was a workable scenariosince it allowed IT to cooperate with the business sideon the creation of the process models.

Requirements Activities

Since a major focus of SOA is reusability, the require-ments activities need to account for a wider scope thanin traditional development methodologies. They shouldat least take into account cross-project requirements,and, in some cases, address the enterprise as a whole.This necessitates bringing a variety of different stake-holders to the table, including business owners, projectmanagers, and IT managers.

The company had already negotiated with a numberof potential business partners regarding the integrationof their respective reservation systems. Therefore, high-level requirements were known, and for some ofthe partners, even detailed requirements such as thespecifics of the B2B interfaces and communicationprotocols had been laid out.

In general, setting the project scope becomes a morecritical activity. This is more important in SOA sinceaddressing the immediate business requirement (e.g.,of one particular line of business) has to be balancedagainst building services that are of enterprise value forlater reuse. Business process–agnostic requirements needto be determined, particularly for the services that willbe designed as application or infrastructure services.

Analysis and Design Activities

The business models should guide the service-modelingprocess so that high-level service modeling can be per-formed with a focus on business processes. This is anarea where SOA provides an opportunity to improve


Figure 3 — RUP activities and phases.


the alignment of business and IT, and it should beemphasized during the analysis and design activities.

Next, candidate services should be defined, classified,and separated into the three layers of the SOA, namelyorchestration (business) services, application services,and infrastructure services. Functionality that is logi-cally related should be grouped into one application orinfrastructure service, and the service interfaces shouldbe defined, including the service contracts and anyrequired service-level agreements (SLAs). At the sametime, an inventory of existing services that can bereused for the project has to be created (this couldpotentially include services outside the enterprise),and the potential for encapsulating legacy systems asservices needs to be analyzed.

The B2B gateway project reused several existingservices that had been developed as part of the coreapplication project (e.g., the security service and thetransformation service). The project also capitalizedon the opportunity to reduce some of the redundanciesin the existing applications by introducing the City ofService Calculation service, which could then be usedby several applications both within the B2B gateway aswell as the core applications.

During the analysis and design of services, it is impor-tant to repeatedly verify that the core principles and bestpractices of SOA are being adhered to. The major SOAprinciples are self-containment, reusability, stateless-ness, and loose coupling.

Self-containment is achieved by well-defined boundariesof application logic (business logic) that is only pro-vided by one particular service, not by another serviceor application. In the case of a wrapper service thatencapsulates a legacy application, there is only partialself-containment since the legacy application is used(without the wrapper) by its legacy clients.

In order to achieve reusability, it is important to distin-guish between orchestration, application, and infra-structure services and to keep an eye on future reuse(i.e., by designing functionality that goes beyond the

requirements of one project such that broader reuseopportunities are enabled).

Services should be stateless. This refers to client stateand not service state, meaning that a service shouldnot remember at what point a client is in regards to asequence of service invocations. Whatever informationis required to identify a particular step in a conversationshould be passed to the service by the client.

Loosely coupled services minimize the dependenciesbetween service provider and service requestor. Thisallows new business processes to be composed easierand more quickly from existing services and existingbusiness processes to be adapted to new requirementsfaster since there are fewer dependencies betweenservices.

Another service-oriented design activity is the encap-sulation of legacy applications, which is achieved bybuilding wrappers that provide a service-based inter-face to access existing application logic. However, inmany cases, this will require restructuring the legacyapplications (i.e., breaking legacy applications apart inorder to achieve a modularization that is aligned withthe service model). This may require a substantial effortand as such necessitates an ROI estimate. Also, it is usu-ally not desirable to maintain two code bases for thelegacy application (i.e., one based on the modularizationfor integration with the SOA and another code base tosupport the existing clients of the legacy application).

Another issue to consider when wrapping legacysystems is the impedance mismatch that often arisesbetween the design principals of the SOA and howthe legacy application was designed. Examples includesynchronous service invocation versus asynchronousapplication processing and the SOA mandate of state-less services versus the design of stateful legacyapplications.

Furthermore, reusing existing business logic and datastores to create services often requires a strategy ofhow to deal with business logic and data that reside inmultiple places. This must be addressed through anenterprise-wide analysis to determine what systemwould be best suited to provision the service such thatduplicate systems could be retired in the long termand which system is considered the “master” (i.e.,the authoritative source of business rules or up todate data). One of the solutions that can be applied isto introduce a form of rationalization via the servicewrapper (e.g., to transform legacy data into a newenterprise standard representation).

An issue to consider when wrapping legacy sys-

tems is the impedance mismatch that often arises

between the design principals of the SOA and how

the legacy application was designed.



One of the major challenges of the B2B gateway projectwas the different data formats employed by the variouslegacy systems, which was amplified by the differentformats that one of the first business partners required.The challenge was not just the data formats; a biggerdifficulty was to determine the semantics — the exactmeaning and requirement for information of some ofthe legacy systems was not documented and had to beobtained from the original application developers in arather time-consuming process. A more detailed expla-nation of the construction of a “wrapper” for the legacyreservation system is covered in a later section.

Since a major focus of SOA is adherence to standards,the decisions made in the analysis and design phaseneed to follow the standards that have been establishedby the overall enterprise architecture (e.g., based onXML schema, WSDL, and SOAP).

Services typically communicate via XML-based mes-sages, which essentially represent the interface of theservice. The messages/interfaces need to be definedas part of the analysis and design activities. In a sense,they can be compared to class interfaces, but theyhave to be designed in a context that goes beyond oneservice. They should be decomposed into a hierarchy ofreusable message component layers so that new servicescan be defined more rapidly through these messagecomponents (this will be discussed in more detail in alater section).

Implementation Activities

During the implementation activities, the platform-specific support for services in general, and Web servicesin particular, need to be taken into account. Examplesinclude the automatic mapping from SOAP-based Webservice invocation onto method execution of componentsthat is provided by all major application servers, thecapabilities of the Windows Communication Foundation(WCF) that is part of .NET, and the host of functionalitythat is available today in the form of open source soft-ware (e.g., Enterprise Service Bus).

Some of these platform-specific characteristics obviouslyneed to be considered during the analysis and designactivities as well. Another example is the question asto whether the orchestration services should be imple-mented in a regular programming language or if high-level tools should be employed (i.e., BPEL/BPMN-based tools).

The initial orchestration services of the B2B gatewayproject only dealt with reservation requests from

business partners. They implemented fairly simple busi-ness processes, and as such, didn’t warrant the deploy-ment of a BPEL tool. However, since they contain arelatively small amount of Java code, it would be easyto migrate them into a tool, should the company make astrategy decision to implement business processes usingBPEL.

Test and Deployment Activities

Since a major focus of SOA is reusability, the testingphase needs to account for usage scenarios that gobeyond the requirements of the current project. Thisincludes different types of clients, a much larger varietyof exception scenarios, interoperability requirements, andso on. Not all service requestors and usage scenarios willbe known to the service development team. Therefore,particular focus must be given to test service versioning,and a greater emphasis on performance and scalabilitytests is required. The deployment issues are similar tothose that have to be considered during testing.

During the B2B gateway project — as with any B2Bproject — the company had to manage two releasecycles: that of its own software and the cycle imposedby the business partners. Managing software releasecycles is also a good example of the benefits that can beachieved with an SOA that follows a proper separationof concerns and a clean service layering.

TOP-DOWN VS. BOTTOM-UP APPROACH

The question as to whether a project should beapproached with a top-down or bottom-up strategy isnot part of any particular RUP activity. Rather, it leadsto a decision that determines which activities might becut short and which activities might deserve greateremphasis. Service-oriented development is significantlydifferent from component-based development in thisregard since it focuses (or should focus) on businessprocesses (i.e., orchestration) and not just the codifica-tion of business functions.

Top-Down Strategy

A top-down strategy typically starts with a businessprocess analysis, focusing on alignment of the SOA withthe business models. This analysis includes businessprocesses, business functions, and business owners andtheir roles and responsibilities. It depends on the avail-ability of business models, or at least well-defined andwell-documented business processes. This analysis


feeds into the modeling of orchestration services, whichwill form the implementation of the business models.

The definition and design of new services (or reuseof existing ones) that will provision the required busi-ness functionality that are orchestrated into businessprocesses follows later. This means that the servicedesign is an outcome of the business process modeling,and the services should therefore not determine theoverall structure of the SOA.

In addition, the service interfaces (i.e., data) should bealigned with an enterprise data model, meaning that theservice interface schemas should follow existing datamodels — again, the enterprise models come first; thetop-down strategy does not encourage a service designto come up with its own data model. This ensures thatservice semantics are aligned with enterprise standards.In the long run, it will simplify data transformationrequirements.

Bottom-Up Strategy

A bottom-up strategy typically focuses on application-centric requirements of one particular business processor one project. This strategy is also often employedin an application integration context, which includesbuilding wrapper services for legacy systems and usingauto-generation of service wrappers for recently devel-oped component-based applications.

This approach focuses on fulfilling particular require-ments of one (narrow) project, usually within aggressivetime and cost constraints. It does not consider the biggerpicture of an SOA; rather, it starts with the servicedesign and often propagates legacy structures into aflawed SOA. Table 2 summarizes and compares thepros and cons of the two strategies.

THE B2B GATEWAY ARCHITECTURE

The SOA for the B2B gateway has been developedfollowing best practice guidelines for service analysis,modeling, and design as outlined in the previous sec-tion. Key architectural principles that were applied arethe separation of concerns and design for reusability.This is achieved by a separation of functionality intolayers.

Service Layering

The breakdown into distinct layers facilitates decou-pling of the services. A typical service layer model forSOA is comprised of an orchestration services layer, anapplication services layer, and an infrastructure serviceslayer, as illustrated in Figure 4.

The top layer of the SOA is comprised of orchestrationservices. An orchestration service acts as a controller,composing application services and infrastructure ser-vices to implement a business process. For the mostpart, an orchestration service is made up of workflow

Bottom Up Top Down

Pro

Con

• Achieves business and IT alignment

• More likely to create an SOA that is not

constrained by legacy architectures

• Enables standardized, repeatable,

enterprise-scale integration solutions

• Can align services with the enterprise

data architecture

• Ensures that key goals are met in the

long term (development and operational

efficiency, business efficiency)

• High up-front cost

• Lengthy timelines could conflict with

business demands

• Often difficult to obtain required

information (e.g., business models).

• Achieves only limited reuse; creates

service silos

• No adherence to enterprise data models

• No strategic alignment between business

and IT

• Recreates existing architectures that are

not truly SOA

• Proliferates more one-off integration points

• Cheaper and faster, since there is less

up-front analysis and design effort

• IT can demonstrate quick, albeit perceived,

success

Table 2 — Top-Down vs. Bottom-Up Approach



logic and calls to lower-level services. This allowsorchestration services to be changed and adapted tonew business process requirements without affectingthe underlying application and infrastructure services.

The middle layer is comprised of application servicesthat implement business logic. They should representa business entity such as a reservation or an invoice,including the operations that can be performed on thatentity (e.g., create new reservation, cancel existing reser-vation, or retrieve invoice). If designed properly, theywill be aligned with the corporate business model andthey can be reused in any business process that requiresaccess to that business entity.

The bottom layer of the SOA contains infrastructure ser-vices. They implement technology-specific functionality(e.g., security, transformation, communication, and per-sistence service) and do not include business logic.

Conceptually, one can think of components and legacysystems forming an additional layer below the three ser-vices layers. They represent popular choices for imple-menting services.

The interactions between services consist of calls from ahigher to a lower layer in the stack, as illustrated by thethick arrows in Figure 4. For example, an orchestrationservice can call an application or infrastructure servicesbut not the other way. It should be noted that orchestra-tion services should not invoke components or legacysystems; those should be encapsulated by application

services. Furthermore, the services within one layer cancall each other, which allows for aggregate services tobe developed.

High-Level B2B Gateway SOA

These architectural guidelines were applied to the defin-ition of the company’s service-oriented B2B gatewayarchitecture. Figure 5 provides an overview of the ser-vice layers of the B2B gateway, including some of theservices that are part of each layer, and the interactionbetween the layers. The following sections offer a briefdescription of each layer.

Business Partners Layer

Business partners use their own proprietary B2B clientsoftware to connect to the company over the Internetusing different means of communication. The logicalentity consisting of a B2B client and the software withinthe B2B gateway that supports a particular B2B client isalso referred to as a “channel.” Figure 5 shows three dif-ferent partners: Vettro, the wireless service used to com-municate with drivers in their cars; GT3, the GDS thatsends reservation requests to the company; and “FuturePartners,” which denotes a number of B2B relationshipsthat the company has been negotiating.

Orchestration Services Layer

The interaction with each business partner is managedby a particular orchestration service (e.g., GT3, CSI).

Component 1Component 1

Component 1

Orchestration Services

Application Services

Infrastructure Services

Components Legacy Systems

Service 1

Service 2 Service 3

Service 4 Service 5 Service 6

Component 1 Legacy 1


Figure 4 — Service layering.


Although each channel implements somewhat differentfunctionality, all channels follow the same high-levelpattern: they consist of an orchestration service thatmanages the flow of business transactions between thecompany and a partner for the typical reservationrequests (e.g., create, modify, and cancel reservation).The orchestration service also maps the reservationrequests to activities that are internal to the company,that is, they coordinate which application services(e.g., the Reservation service or the City of ServiceCalculation service) and which infrastructure services(e.g., the Security service) have to be invoked and inwhat sequence.

The Vettro Inbound Request service implements a busi-ness process that receives messages from chauffeurs viathe Vettro wireless network provider. The flow logic inthis orchestration service and the business logic that issubsequently executed is completely different from allthe reservation processes, yet the structure of the SOAensures that the Vettro service fits seamlessly into thearchitecture.

Application Services Layer

The application services are agnostic of the specific part-ner and can be called within the business process con-text of any of the B2B channels. This enables reusabilityand allows adding new partners with rapid time tomarket. The Reservation service encapsulates some of

the functionality of the legacy reservation applicationand makes it available through a high-level, service-oriented API, thus creating an abstraction to the legacysystem. It allows different B2B channels to use a com-mon interface for making reservations. This abstractionof the legacy reservation system delivers the followingbenefits:

The ability to provide an easier-to-use interface formaking or changing reservations

The ability to enhance or change underlying businessrules without changing the business logic in theB2B channels

The ability to minimize the exposure of the com-pany’s internal business rules to the B2B channels

The company uses the concept of City of Service (i.e., foreach reservation, the closest service center is determinedbased on information that is provided by the channelpartner as part of the request to create a new reservationor to change an existing reservation). This process ishidden from the B2B channel partners; as a result, eachchannel has the requirement to calculate the correct Cityof Service, and this calculation is performed in the Cityof Service Calculation service, which is part of the appli-cation services layer and thus business process–agnosticand reusable across all channels. Finally, the Invoice ser-vice encapsulates the billing system in order to provideexternal partners access to their invoices.

CSI Reservation

Services

CSI Reservation

Services

CSI Reservation

Services

CSI Reservation

Services

CSI Reservation

Services

Business Partners

VettroInboundRequestService

GT3Reservation

RequestService

GT3Customer

CancelService

CSIReservation

Services

ReservationService

Wrapper

City ofService

Calculation


Orchestration Services Application Services

Vettro GT3Future

Partners

Sockets, Web Service (HTTP)

Message Store SecurityCommunication Notification Transformation

Invoice Service


Figure 5 — High-level B2B SOA.



Infrastructure Services Layer

The infrastructure services are also partner-agnostic;they can be called within the business process contextof any of the B2B channels (i.e., from any orchestrationservice). This also reduces time to market and cost toimplement new partner integrations.

Message Store Service

All requests received from business partners are writtento persistent storage (message store) in their raw, unal-tered format in order to maintain an audit trail of allcommunication with business partners. All responsemessages sent from the company to business partnersare written to the message store as well. The MessageStore service is used to maintain the message store. Thesupported functionality includes store messages in themessage store, and the messages can be of differenttypes — for example, request message, response mes-sage, as well as pertain to different channels (i.e., havevarious formats); retrieve messages from the store; andperform a search for messages based on a set of criteria.

Communication Service

The Communication service provides an abstraction todifferent communication protocols. When two servicesneed to communicate with each other, they use the API ofthe Communication service to exchange data in the formof the common XML format. As a result, the services arenot concerned with the intricacies of the underlying com-munication protocols. The Communication service sup-ports data exchange over HTTP, SOAP, RMI, and JMS.

Notification Service

The Notification service can be used to inform an inter-nal or external user of a business event (e.g., a problemwith the data that has been received in a reservationrequest). The notification can be sent via differentcommunication media (e.g., through e-mail or fax). TheNotification service is an example of a service that hasbeen developed as part of the core applications projectand was reused in the B2B gateway project.

Transformation Service

The Transformation service translates data from theformat that a particular business partner uses to thecompany’s internal common XML format. It alsotransforms between the common XML format and theproprietary format of the legacy reservation system.The Transformation service can handle different dataformats, including XML-based data and binary data.Furthermore, since the data that is supplied by a partner

in a reservation request in many cases needs to beenriched with data that is stored in the company’s data-bases, the Transformation service performs databaselookups to retrieve the appropriate data for the enrich-ment.

Security Service

The functionality provided by the Security serviceincludes the following: validating the user ID and pass-word provided by a business partner; validating thecertificate provided by the requestor to make sure that itis the business partner represented in the request (sincethis was not required for the first release of the B2Bgateway, the functionality has been designed but notimplemented); and encryption of the entire responsemessage that is to be sent to a business partner. TheSecurity service is another example of a service that hadbeen developed as part of the core applications projectand then reused in the B2B gateway project.

Service Layer Example for GT3

Figure 6 shows the service model of the GT3 channel asan example of the service layering in the B2B gateway.This service model implements a business processwhere the GT3 system sends a request to the companyin order to create a new reservation. The process returnsa reservation number or a negative response codeaccompanied by a textual explanation to GT3.

The GT3 Reservation Request orchestration service is theonly service in this model that is specific to the GT3 B2Bchannel. It contains business logic that implements theparticular requirements of the GT3 interface and usescommon services (Reservation, City of Service, MessageStore, Security, Transformation, Notification, andCommunication) to conduct tasks that are not specific toGT3. In addition to invoking the appropriate applicationand infrastructure services, the orchestration service per-forms the following functionality:

Checks for duplicate message. The service checks ifa particular message has already been received fromGT3 before and performs actions according to busi-ness rules.

Checks if data is valid. The system checks if the datain the reservation request XML document receivedfrom GT3 contains all required information and if thedata is valid.

Checks the response from the reservation service.The system checks if the reservation service per-formed the requested action or declined it andformulates a response to GT3 accordingly.


Approach to Business Partner Integration

The B2B gateway supports business partners that wantto utilize automated reservation requests, as well asother automated B2B interactions such as billing orobtaining car status information. From a technical per-spective, integrating with a business partner requiresaddressing three issues:

1. Data. Some business partners use different data for-mats, which require data transformation/translationfrom the partner’s format to the company’s internalstandard format.

2. Connectivity. This involves establishing a connectionwith a business partner over the Internet using differ-ent mechanisms (e.g., HTTP, SOAP, or Sockets).

3. Business process. This involves implementing thebusiness rules that a partner follows in order to con-duct a specific transaction (e.g., to modify a reserva-tion or to cancel a reservation) and mapping thisprocess to internal activities.

These business partner integration issues can be consid-ered a pattern, and the layered SOA of the B2B gatewayis structured to match this pattern. As a result, any newB2B integration becomes a repeatable and thus pre-dictable effort, and each new project benefits greatly,both in terms of cost and time to market, by followingthe architecture pattern. In addition, the company hasstrived to standardize the B2B communication protocolsand data formats.

Some of the partners demand that the company adaptto their particular B2B protocol. One example is GT3.Since GT3 connects many chauffeured service pro-viders, travel agencies, and corporations, it did not wantto adhere to a particular B2B protocol that the companywould want to utilize. On the other hand, there were

many business partners who wanted to utilize a stan-dard, Web services–based protocol that the companymaintains. To that end, the company has defined theCSI. The CSI allows the company and its partners tointegrate their respective reservations systems in a con-sistent, reliable, and cost-effective manner. The benefitsof this standardized automation include:

Reduced cost, effort, and risk related to buildingcustomized interfaces with channel partners

Improved customer service resulting from best prac-tice business processes reflected in the CSI consis-tently applied across an ever-increasing numberof reservation requests from different partners

The CSI server, which is part of the B2B gateway,exposes an API that the CSI client (i.e., a business part-ner) invokes in order to make a new reservation, cancelan existing reservation, and so on. Associated with eachtype of request is a well-defined, XML-based messagestructure that contains all the information that isrequired to conduct one particular business transactionbetween a business partner and the company. The CSIprovides specifications for the following components:

Internet protocol–level connectivity

Security (authentication and authorization of businesspartners, message encryption)

Definition of business transactions (e.g., create reser-vation and cancel), as well as request and responsemessage structures for each transaction

Legacy System Integration

Since the legacy reservation system was being migratedto a new system in several phases, it was essentialthat business partners were shielded from any

CommunicationMessage Store Security Transformation

Reservation

GT3 Reservation Request

Notification

Orchestration Services



City of Service


Figure 6 — Service layer example for GT3.



incompatibilities that might have been caused duringthe migration phases.

The Reservation service encapsulates some of thefunctionality of the legacy reservation application andmakes it available through a high-level, service-orientedAPI, thus creating an abstraction to the legacy system. Itallows different B2B channels to use a common interfacefor making reservations. In addition to the B2B chan-nels, the new interface to the legacy reservation systemis also used by different client applications, specificallya Swing-based client and a Web client. Figure 7 showshow the different client implementations and B2B chan-nels utilize the new reservation service API (referred toas the unified code base) and compares it to legacy Webfront-end code.

Exposing specific business functions of the legacy reser-vation system as services was not a simple matter ofimplementing wrapper code around a number of object-based APIs. The reservation system was tightly coupledto a Web application, such that the code consisted ofintermingled presentation logic and business logic. Thislogic had to be broken apart, restructured, and partiallyreimplemented in order to create a service wrapper,which could then be used not only by the B2B gateway,but also by the Swing client and the Web front end.

Service Reusability

Reusability is achieved by designing application ser-vices and infrastructure services that are autonomousand agnostic of the business process context withinwhich they are executed. This increases the potentialfor reusing them when a new business process is com-posed. Orchestration services typically have a limitedpotential for reuse since they implement particular

business processes. However, when business processesare aggregated as subprocesses into larger businessprocesses, there is also an opportunity for reuse oforchestration services.

Application and Infrastructure Services Reuse

The reuse of application services is based on identifyingfunctionality that is common to a particular businessdomain. The B2B gateway is not specific to any particu-lar business domain, and it can be considered more of amiddleware system than software that is related to busi-ness applications. The number of application servicesthat have been developed as part of the B2B gatewayproject is therefore limited.

There are two application services that have been devel-oped specifically for this project but are targeted forenterprise-wide reuse (in fact, they are deployed out-side of the physical domain of the B2B gateway): theReservation Service wrapper and the City of ServiceCalculation service. An additional application service,the Invoice service, was defined during the project butscheduled to be implemented in another project.

In order to illustrate one of the design decisions thateffect reusability, consider the Reservation Servicewrapper. Besides other logic, it also contains businesslogic that handles requests to change an existing reser-vation. Under certain circumstances, a change reserva-tion request will require a cancellation of the existingreservation followed by a rebooking (i.e., creation of anew reservation). The initial design consideration wasbased on the requirements of only one business partner(GT3), and one option was to put this logic into theGT3 orchestration service, which would coordinate can-celling the existing reservation and creating a new one.

GT3Orchestration

Service

CES Interface Object APIs

CSIOrchestration

Service

Old WebApplication Reservation Service Wrapper

JSP

Struts

UtilityServices

BusinessDelegates

SessionBean

Facades

Unified CodeBase

WebClient

SwingClient

New Reservation Service Interface


Figure 7 — Legacy system integration.


However, this orchestration service is specific to theGT3 business process, which makes it nonreusable forother business processes (e.g., the CSI channel). It wastherefore decided to implement this business logic inthe Reservation Service wrapper (i.e., an applicationservice), which is business process–agnostic and canbe reused across all channels that are part of the currentor future projects.

The City of Service Calculation service is another exam-ple of an application service that is highly used by sev-eral business processes. Although it was designed andimplemented as part of the B2B gateway project, therequirements of other applications that would be usingit in the future had to be considered.

Infrastructure services generally have the highest reusepotential since they provide functionality that is neededin most applications. The degree to which the infra-structure services have been reused depends on the cus-tomization that was required for the different businessprocesses. Some infrastructure services are very genericin nature; the Message Store service and the Notificationservice, for example, are always utilized in the sameway. The Transformation service, on the other hand,does require a fair amount of customization since itprovides data transformation functionality that goesbeyond self-describing formats like XML. It has to dealwith a variety of proprietary legacy data formats.

An important consideration for enhancing the reusepotential is to anticipate and model additional function-ality that goes beyond the requirements of the currentproject. One example is the Security service. The firstphase of the B2B gateway project only required authen-tication based on user ID and password. The capabilityto authenticate a business partner through certificateswas anticipated and considered during service model-ing. Another example is the Notification service, whichonly had to support user notifications based on e-mailbut was modeled so that it could also send out notifica-tions to a pager.

Reusing the B2B Gateway for the Vettro Project

As described earlier, the Vettro system is utilized tofacilitate interactions between the drivers in the field

and the back-office systems, and the role of the B2Bgateway is to function as a conduit. At first glance, theredoesn’t seem to be much similarity between the func-tionality of the Vettro system (dispatching drivers,exchange of status and billing information) and theprimary goal of the B2B gateway (integrating with thereservation systems of B2B partners). However, theVettro project benefited from the B2B gateway SOA inthree ways: (1) by reusing the architecture as a blue-print; (2) by reusing individual services; and (3) throughreuse of schema components (i.e., data definition).

Although it is always difficult to quantify the benefit ofreusing an architecture as a blueprint for a new project,it did become very obvious how the well-defined SOAof the B2B gateway accelerated the design of the Vettrointegration. There were a significant number of archi-tecture patterns in place that determined most of thedesign. These included exposing a service to a partnersystem as a Web service based on XML over HTTP com-munication, the separation of the required services intothe three layers of the SOA, the boundaries of the dataarchitecture, and the interaction with the back-officesystems, to name a few.

The Vettro project could also reuse several of the existingservices, like the Security service and the Transformationservice. Finally, there was a high level of reuse in termsof the data architecture (i.e., the XML schemas). This maysound surprising since dispatching drivers is a very dif-ferent business function compared to managing reserva-tions. However, many of the essential data entities arethe same in both cases. Examples include basic customerinformation (e.g., name, address, and contact informa-tion), pick-up and drop-off addresses, pricing, flightinformation, and so on. The key design element thatmade this level of reuse possible was to break down theXML schemas in small entities (e.g., an address), whichthen allowed composing many different types of schemasbased on these core entities.

Reusing the SOA foundation that has been laid out bythe B2B gateway for the Vettro project is one exampleof how service reuse can improve the responsiveness ofIT to the requirements of the business. The next sectionillustrates in more general terms how service reusabilityrelates to business agility.

Service Reuse and Business Agility

There are different approaches in how SOA can beemployed to facilitate the alignment between businessand IT. Of particular interest to the company is theincrease of business agility, which an SOA can facilitatethrough reduced application portfolio complexity andthrough service reuse.

Infrastructure services generally have the highest

reuse potential since they provide functionality

that is needed in most applications.



Most companies face an increasing complexity of theirenterprise application portfolios. They fulfill businessdemands by adding new applications and packages andby building more connections between systems in orderto achieve integration. Therefore, the application portfo-lio complexity increases, which in turn slows down theresponsiveness of IT to business requests. The result isa negative effect on business agility since many IT orga-nizations spend most of their budget on maintenanceinstead of innovation.

The company has experienced a similar evolution andis in the process of reducing the total number of appli-cations by about 50% while at the same time restruc-turing business functions into reusable services. SOAallows streamlining the application portfolio by reduc-ing redundancies among different applications and bysimplifying the connectivity across internal and externalenterprise boundaries through standardization. A keycontributing factor to achieve this is the reusabilitygained by a thorough design and implementation ofservice layers. This is exemplified in Figure 8.

As illustrated in Figure 8, the company is implementingmore application services and infrastructure servicesacross a number of projects, including both the coreapplication projects and the B2B gateway project.Essentially, a service repository is built over time,which eventually will comprise most of the lower-layer

services (i.e., application and infrastructure services)that are required by the majority of business processes.This allows rapid implementation of new businessprocesses as well as easy modification of existingprocesses.

New business processes are implemented as neworchestration services. As a result of the expansion ofthe service repository, a high degree of reusability isachieved and none or just a few additional applicationand infrastructure services need to be developed, thusspeeding up the delivery of new business processes (orapplications, in traditional terminology). Furthermore,services implemented for use by internal processes canbe reused for B2B processes. (It should be noted thatexternal partners do not utilize specific application orinfrastructure services directly but connect to orchestra-tion services that have been exposed for external use.)

“REST-like” but Not “REST-ful”

Web services–based systems that follow the concepts ofrepresentational state transfer (REST) have enjoyed a lotof publicity and attention over the last couple of years.A growing number of high-profile companies are pro-viding their services in a REST form including Yahoo!,eBay, Amazon.com, Flickr, and YouTube.

REST is an architectural style for distributed hyperme-dia systems (i.e., the Web). The term originated in a

Business Process(Orchestration Service)

Service Registry


The Company

?


Portal

Business Partner

Business Process

Service Registry

Internal Systems

?

Partner-Facing Orchestration

Services


Figure 8 — Service reuse and business agility.


2000 doctoral dissertation about the Web written by RoyFielding, one of the principal authors of the HTTP pro-tocol specification.1 The basic concepts are addressableresources (instead of functions in the traditional Web ser-vices model) and uniform interfaces (instead of custominterfaces). Resources are entities (e.g., a bank account)that can be accessed through a standard linkage, specifi-cally through URLs. A REST-based system thereforebenefits from the proven addressing scheme of the Web.Another characteristic of resources is that they shouldnot maintain client state, which exploits the capabilityof the Web to be highly scalable.

The second concept of REST is uniform interfaces.Client-server systems usually have custom interfaces.For example, a “bank account” Web service interface isdifferent from the “rental car reservation” Web serviceinterface, and in distributed object systems, the objects(i.e., classes) are called on their methods. Both Web ser-vices and objects typically expose several operations toclients. In contrast, there is only one REST interface forall services that follow this architectural style. It consistsof the standard HTTP commands: get, put, post, anddelete (this can conceptually be mapped to the often-used CRUD operations).

The growing popularity of REST is therefore motivatedby the fact that it exploits the proven concepts of theWeb; its general simplicity makes it easy to get startedwith SOA projects without limiting their extensibility(REST-based systems can be migrated to full Web ser-vices implementations); and the fact that the complica-tions of having to use SOAP and WSDL are avoided.

Building the SOA for the B2B gateway as a “REST-ful”architecture has been a consideration for the project.However, the company wanted to follow an industrystandard, namely the standard promoted by theOpenTravel Alliance (OTA), which can be describedas “REST-like,” but not strictly REST-ful (moreinformation on the standards promoted by theOTA are presented later).

For example, there are six business functions that areprovided by the Reservation Request service. The con-crete service interface could have been designed as oneservice (i.e., one interface) with six operations and theassociated input and output data items. It was decidedto have six different services (and interfaces), wherebyeach interface has no explicit operation — invokingthe service constitutes an implicit function call. Thisachieves overall simplicity since the different servicescan evolve independently.

Another example that illustrates the advantages of thisdesign is the Rate Quote service. It has different securityrequirements than creating or changing a reservation,and it is not as important and therefore may run on aserver with less performance (i.e., separation of SLArequirements).

Many of the services that make up the B2B gatewayhave been designed in a REST-like fashion, but theyare not completely REST-ful since they don’t follow therules for utilizing the HTTP commands. They are allbased on the HTTP post command (e.g., the CancelReservation service should be based on HTTP deletecommand, and the Retrieve Reservation service shouldbe based on HTTP get command). Furthermore, theydo not follow a strict addressing of resources based onURLs. To be REST-ful, all reservations that the systemmaintains should be made addressable as individualresources.

THE DATA ARCHITECTURE

The diversity of systems that are connected to the B2Bgateway (i.e., partner systems, legacy systems, andnewly developed applications) necessitates the defini-tion of a comprehensive data architecture. This dataarchitecture deals with the interfaces of the services andthe messages that are being exchanged between serviceproviders and consumers. It should not be confusedwith the permanent storage of the data entities that aretypically maintained in a system of records.

For example, a passenger name data entity is defined inthe data architecture of a system of records and it physi-cally exists in a relational database, but the semanticallyequivalent data entity is also defined in the data archi-tecture that describes service interfaces and it physicallyexists in messages that a service receives or returns. Thelatter is the data architecture that is the topic of the fol-lowing section.

Loose Coupling Through Canonical Data Format

The canonical data format is typically introduced inintegration solutions as a message format for the infor-mation that flows through the integration infrastructure.It is a standardized superset of information that theintegration endpoints (i.e., applications or services)employ. The canonical format is independent of allapplication-specific data formats, and it reduces thenumber of point-to-point transformations that need tobe built and maintained. Instead of building data trans-formation logic for each pair of applications/servicesthat communicate, only one transformation is required



between the proprietary format of each application/service and the common format. Furthermore, moreof the applications/services should adopt the commonformat over time, such that the need for transformationbecomes even less (the CSI and all new business part-ners who will adhere to the CSI format are an exampleof this standardization).

In addition, since the canonical format is based on XML,it can be extended without affecting the applicationsor services that have already been integrated. Changesin the data format of one application will not ripplethrough to the transformations that other applicationsuse. This concept is referred to as logical decoupling.Figure 9 illustrates three applications, whereby twoapplications employ a proprietary data format inter-nally and one application has been designed for thecanonical format.

Figure 10 shows the realm and the boundaries ofstandard (i.e., canonical) and proprietary data formatsacross the company’s business partners, the B2B gate-way, and the core applications.

Some of the company’s “inbound” business partners(GT3 and Vettro, depicted at the top of Figure 10) useproprietary data formats, which are transformed tothe common XML format (i.e., the internal companystandard) when the data enters the B2B gateway. The

business partners that conform to the CSI, however,are adhering to this standard, and the data that isexchanged with them does not have to be transformed.The “outbound” partners (Hudson and Vettro) useproprietary formats that do require transformation.

The orchestration services within the B2B gatewayexchange data encoded in the common XML formatwith the application services. Finally, the core applica-tions that handle billing and dispatching also utilizethe common XML format when they communicatewith the B2B gateway (and for some of the internaldata exchanges as well), so there is no need fortransformation. The legacy reservation applicationuses its own proprietary format, which is transformedinto the common format on the boundary of the B2Bgateway.

Company Standard Format and OTA Formats

The company’s common XML format is XML-based andfollows the guidelines provided by the OTA.2 Foundedin May 1999, the OTA is a consortium of suppliers in allsectors of the travel industry, including air, car rental,hotel, travel agencies, and tour operators, as well asrelated companies that provide distribution and tech-nology support to the industry. The OTA now hasmore than 125 members representing influential namesin all sectors of the travel industry.

Application 2

Application 1 Application 3

MetadataRepository

Canonical Data Formats

ProprietaryData Format

ESB

Canonical DataFormat


TransformationRouting




ProprietaryData Format


Figure 9 — Canonical data format.


The OTA defines open messages in XML that make itpossible to exchange business data seamlessly amongdifferent systems, companies, and industries over theInternet. For each of the business transactions that atravel company would typically conduct with a B2Bbusiness partner (e.g., making a reservation), onerequest and one response message is defined throughXML schemas. One company would send an XMLrequest message (adhering to the appropriate XMLschema), and the partner company would reply withthe corresponding response message.

OTA schemas are arranged in several layers, as shownin Figure 11. The OTA has defined a set of commondata types that can be (and should be) reused acrossthe different travel sectors. On top of that, each sectortypically defines a set of common types that can bereused across the different business transactions withinthe particular sector. Finally, there are schemas for eachbusiness transaction in a particular travel sector.

As illustrated in Figure 11, the company’s standardcommon XML format consists of schema definitions thatare part of the OTA common types, the ChauffeuredServices common types, and the Chauffeur Transactionschemas.

Reuse of Schema Definitions

Figure 12 provides an abbreviated example how schemacomponents that are defined as common types in theOTA common types and the Chauffeured Services com-mon types are being reused to define the schemas forthe Chauffeured Services transactions.

The schema for the response message of the reservationtransaction (“create reservation” operation) containsa PassengerOfRecord complex element. This elementdoes not have to be defined from scratch for theresponse message schema; it can be assembled outof the AddressType element, the CustLoyaltyTypeelement, and the PersonNameType element, all ofwhich are part of the OTA common types.

Similarly, the ReserveConfirmation element in the Reservation Response schema reuses theReserveConfirmType element from the ChauffeuredServices common types, which in turn reuses theRateQualifierCoreType from the OTA common types.

CONCLUSIONS

The B2B gateway provides two key benefits to the com-pany: insulation and automation. It insulates business

GT3 CSI

OrchestrationServices

ApplicationServicesGT3

FuturePartners

City ofService

Calculation

Reservation

Billing

Dispatching

CoreApplications

ReservationInboundService

Hudson

Vettro

Vettro

Vettro

Hudson Vettro

Common XML Format

Common XML Format

Proprietary Data Formats

Proprietary Data Formats

ProprietaryData Formats

ReservationOutbound

Service

InvoiceService

ProprietaryData Formats


Figure 10 — B2B gateway data format boundaries.



partners from the intricacies of the company’s internalapplications and business processes. A business partnerdoes not have to deal with proprietary application dataformats. A partner can exchange information with theB2B gateway either in its own (potentially proprietary)

format or can utilize the standard chauffeured servicesXML notation that the company has defined.

At the same time, the B2B gateway insulates thecompany’s internal (core) applications from anydependencies on business partners. They can evolve

OTA Common Types

Car RentalCommon

Types

AirlineCommon

Types

HotelCommon

Types

ChauffeuredServices

CommonTypes

Car Rental Transactions

Airline Transactions

Hotel Transactions

Chauffeur Transactions

Company StandardFormat


Figure 11 — OTA schema layers.

OTA Common Types

ReserveConfirmType

PersonNameType

GivenNameSurName

MiddleName NameTitle

AddressType

CountryCityName

StreetNmbr PostalCode

CustLoyaltyType

RateQualifierCoreType

FlightNumberType

Chauffeured Services Common Types

RateQualifierCoreType

VehicleRateTotal

CancelPolicy

ReservationID

Reservation Response

Chauffeured Services Transactions

PickUpLocation PassengerOfRecord

ReserveConfirmationDropOffLocation


Figure 12 — Schema component reuse example.


independently, relying on the B2B gateway to “makeup” for any API changes. They are also protected frombusiness-partner client applications from a securityperspective.

The second key benefit that the B2B gateway providesis the automation of a diversity of business processes.They range from dealing with reservation requests overexchange of billing information to wireless communica-tion with drivers. This illustrates how a well-definedSOA can be utilized to support a variety of businessrequirements with an efficient low-cost approach.

This approach depends to a large degree on servicereusability. The potential for reusing a service is signifi-cantly improved when the SOA follows a proper layer-ing of the services into orchestration, application, andinfrastructure services. Application and infrastructureservices provide business process–agnostic functionalitythat can be leveraged across different business processes.

While SOA is often discussed from a code perspective(i.e., the relevant aspect of a service is its code), theimportance of the data architecture can not be overemphasized. (As described earlier, the data architecturedefined in this project addresses the schemas for theservice interfaces.) The data architecture is a key con-tributor to reusability in an SOA. Once a hierarchicalstructure of reusable data entities has been defined, theprocess of developing schemas for new service inter-faces as well as the code that implements a servicebecomes a predictable task that follows repeatablepatterns.

All newly developed services adhere to this XML-basedstandard for the data entities that are input and output

of a service. Legacy systems continue to use proprietarydata formats, but they are integrated into the SOAthrough wrapper services that transform the data tothe standard formats. In addition, the mapping to thedata formats exchanged with business partners can beachieved with the same efficiency.

Reusability and interoperability have been key to thisproject, and the company is clearly benefiting fromstandards like XML — in particular in this B2B gatewayproject — since it includes a variety of external system.However, too many standards can lead to complexityand inhibit achieving the benefits of SOA. AddingSOAP, WSDL, BPEL, UDDI-based repositories, andsome of the extended Web services standards (WS-*)will continue to be carefully considered but only imple-mented if there is a clear value proposition.

We’ve witnessed a growing plethora of standards,different versions of standards, and different vendorimplementations. It speaks for itself that the “standardof standards” has been created in form of the WS-I, andthat OASIS has formed a committee to simplify SOA,while at the same time they complicate matters byadopting the Service Component Architecture (SCA).For now, the B2B gateway project has tried to keep itsimple and focus on delivering tangible ROI.

Achieving ROI is one thing, but the success of SOA andthe efforts it takes to get there also need to be conveyedto the business sponsors. We have found that a bubblechart, as shown in Figure 13, provides an efficientmeans to illustrate this.

The vertical axis in the chart indicates to what degreeone particular project contributes to the SOA, either

-2

0

2

4

6

8

10

12

-2 0 2 4 6 8 10 12 14

Co

ntr

ibu

tio

n t

o S

OA

Exploitation of SOA

GT3 V1.0

Architecture

Unified eResCode Base

CSIGT3 V2

VettroVirgin Atlantic

Bubble size = cost of project

GT3 Web Service

GT3 V1.9

Hudson

Partner XPartner YPartner Z


Figure 13 — Bubble chart for B2B gateway project.



by providing reusable assets (e.g., services, schemadefinitions) or by enhancing the architecture and thedevelopment processes toward increased SOA maturity(e.g., policies, best practices). This contribution can notbe quantified in a completely objective way; it involvesa significant amount of estimation. The horizontal axisshows the level of reuse of existing SOA assets (e.g.,services) in a particular project. This exploitation canbe measured more objectively than the contribution,based on cost-saving calculations, leaving a relativelysmall degree of uncertainty. Finally, the size of eachbubble is a measure of the cost of that project, which isa well-known number.

The first three projects (bubbles labeled GT3 V1.0, V1.9,and Hudson) did not follow an SOA and consisted ofone-off implementations that reused code only occa-sionally when a developer found an asset that could beshared. These projects also did not create any significantamount of reusable services. This puts the projects intothe left bottom corner of the chart (i.e., the “worstspot”). Ideally, initial projects should be on the left toppart, contributing heavily to the SOA, followed by proj-ects that are found on the bottom right, exploiting theexisting SOA assets and show (relatively) smaller bub-bles (i.e., reduced cost). The project called Architecturewas a pure architecture definition project. As such, itconstitutes an initial investment into the definition ofthe SOA, which represents a high value in terms ofcontributing to the SOA.

The next six projects (moving from the top left of thechart down to the right bottom) continued to contributeadditional reusable services to the overall architecture;at the same time, it became possible to exploit more ofthe existing assets for reuse, thus reducing the cost ofthese projects. Finally, there was a series of plannedprojects labeled Partner X, Y, and Z, which revolvedaround integration of new business partners. Since thecore requirements for these projects were known, theirimplementation effort could be estimated, and it couldbe shown that they could be highly efficient based on aplug-and-play approach.

Using this kind of bubble chart to illustrate the progres-sion of the IT organization along increasing SOA matu-rity was well received by the business side. It allowedthem to visually comprehend how their money hadbeen spent and what benefits had been derived.

ENDNOTES1Fielding, Roy Thomas. “Architectural Styles and the Designof Network-Based Software Architectures.” PhD dissertation,University of California, Irvine, 2000 (www.ics.uci.edu/~fielding/pubs/dissertation/top.htm).

2The OpenTravel Alliance (www.opentravel.org).

ABOUT THE AUTHORS

Max Dolgicer is a Senior Consultant with Cutter Consortium’sEnterprise Architecture practice and a Technical Director withInternational Systems Group, Inc. (ISG). With more than 24years’ management and technical experience, he is an inter-nationally recognized expert who specializes in IT strategy,business and IT alignment, enterprise architectures, and devel-opment/integration of large-scale applications using SOAs.

As a Technical Director with ISG, Mr. Dolgicer has beeninvolved in leading management and technical roles for manyof ISG’s clients, including Carey International, US Patent Office,New York Stock Exchange, Credit Suisse, Federal Reserve,Allstate, Financial Times Interactive, MetLife, PrincipalFinancial Group, Cigna, CitiGroup, Morgan Stanley, DeltaAirlines, Goldman Sachs, and McKenzie Financial Corporation.

Mr. Dolgicer is a recognized speaker, instructor, and lecturer.He presents extensively at most industry conferences. His SOAtutorials, including “SOA — an IT Managers Guide”; “SOA:Organization, Architecture, Technologies, and Design”;“Service-Oriented Analysis, Modeling, and Design”; and“Service-Oriented Integration — Technologies and BestPractices,” have educated many senior managers, architects,and developers worldwide. He is also a contributing editor forseveral major trade publications. Mr. Dolgicer holds a master’sdegree in computer science from Technion, Israel Institute ofTechnology. He can be reached at [email protected] [email protected].

Gerhard Bayer is a Senior Consultant and Principal Architectwith International Systems Group, Inc. (ISG). His activitiesinclude performing leading architectural role on large-scaleSOA and enterprise application integration projects for numer-ous ISG’s clients. He is also responsible for the developmentand delivery of ISG’s broad education curriculum as well asproduct competitive analysis and evaluation to assist clients inthe major software products selection process.

Prior to joining ISG, Mr. Bayer was Director of TechnologyPlanning with Software AG Americas, responsible for theevaluation of new technologies and the planning of productdirections. In this function, he also coordinated the exchangeof technology with business partners. Mr. Bayer holds an MSin physics and a BS in computer science. He can be reached [email protected].


Abou

t the

Pra

ctice Enterprise Architecture

PracticeToday the demands on corporate IT have never been greater. Cutting costs andaccelerating time to market for individual line-of-business projects are still priorities,but even that’s not nearly enough anymore. Companies are now looking forstrategies to better leverage their entire IT infrastructure. They want IT to deliversophisticated enterprise applications that can provide value across many lines ofbusiness and provide marked differentiation from their competitors. The EnterpriseArchitecture Practice provides the information, analysis, and strategic advice to helporganizations commit to and develop an overarching plan that ensures their wholesystem fits together and performs seamlessly.

The Enterprise Architecture Practice offer continuous research into the latestdevelopments in this area, including Web services, enterprise applicationintegration, XML, security, emerging and established methodologies, Model DrivenArchitecture, how to build an enterprise architecture, plus unbiased reports on thevendors and products in this market. Consulting and training offerings, which arecustomized, can range from mapping an infrastructure architecture to transitioningto a distributed computing environment.

Products and Services Available from the Enterprise Architecture Practice

• The Enterprise Architecture Advisory Service• Consulting• Inhouse Workshops• Mentoring• Research Reports

Other Cutter Consortium PracticesCutter Consortium aligns its products and services into the nine practice areasbelow. Each of these practices includes a subscription-based periodical service,plus consulting and training services.

• Agile Product & Project Management • Business Intelligence• Business-IT Strategies• Business Technology Trends & Impacts• Enterprise Architecture• Innovation & Enterprise Agility• IT Management• Measurement & Benchmarking Strategies• Enterprise Risk Management & Governance• Social Networking• Sourcing & Vendor Relationships

Senior ConsultantTeamOur team of internationally recognizedspecialists offers expertise in security issues,e-business implementation, XML, e-businessmethodologies, agents, Web services, J2EE,.NET, high-level architecture and systemsintegration planning, managing distributedsystems, performing architecture assessments,providing mentoring and training, overseeingor executing pilot projects, and more. Theteam includes:

• Michael Rosen, Practice Director• Paul Allen• Douglas Barry• Dan Berglove• Max Dolgicer• Don Estes• Pierfranco Ferronato• Clive Finkelstein• Michael Guttman• David Hay• Tushar K. Hazra• J. Bradford Kain• Bartosz Kiepuszewski• Sebastian Konkol• Jean Pierre LeJacq• Arun K. Majumdar• Thomas R. Marzolf• Jason Matthews• Terry Merriman• James Odell• Ken Orr• Wojciech Ozimek• Jorge V.A. Ronchese• Oliver Sims• Borys Stokalski• John Tibbetts• Sandy Tyndale-Bisco• William Ulrich• Mitchell Ummel• Jeroen van Tyn• Jim Watson• Tom Welsh• Bryan Wood


building an soa with infrastructure, application, and ... · building an soa with infrastructure,...

Documents