“service-oriented world” cheat sheet · find that soa has both business and it advantages....

210 Commercial Street, Boston, MA 02109 • Phone 617.742.5200 • Fax 617.742.1028 • www.psgroup.com

Patricia Seybold Group Trusted Advisors to Customer-Centr ic Execut ives

“Service-Oriented World” Cheat Sheet A Guide to Key Concepts, Technology, and More…

By Brenda M. Michelson Sr. VP and Sr. Consultant, Patricia Seybold Group

UNAUTHORIZED REDISTRIBUTION OF THIS REPORT IS A VIOLATION OF COPYRIGHT LAW Direct link: http://dx.doi.org/10.1571/bda6-2-05cc

Customer Scenario and Customers.com are registered trademarks and Customer Flight Deck and Quality of Customer Experience (QCE) are service marks of the Patricia Seybold Group Inc. • Business-Driven Architecture is a service mark of Elemental Links • 210 Commercial Street, Boston, MA 02109 USA •

www.psgroup.com • Unauthorized redistribution of this report is a violation of copyright law.

Patricia Seybold Group / Business-Driven ArchitectureSM

“Service-Oriented World” Cheat Sheet A Guide to Key Concepts, Technology, and More…

By Brenda M. Michelson, Sr. VP and Sr. Consultant, Patricia Seybold Group June 2, 2005

IT’S A SERVICE-ORIENTED WORLD

It’s no secret that we are fans of services and ser-vice-oriented architecture. For years, we have been proclaiming the significance of service-oriented ar-chitecture and Web Services technology in creating an adaptive IT architecture for customer experience.

More recently, we have shared our belief that the current uses of SOA for integration and customer- (user-) facing applications are merely the first stages of the service-oriented evolution. Over the next few years, SOA will be the springboard for innovative IT shops to move towards business scenario develop-ment. In business scenario development, IT business solutions will be compositions of services, business events, and business processes. These compositions match the interactions of your business—with cus-tomers, partners, employees, and regulatory agen-cies—in support of commerce, collaboration, and information exchange.

Now, everyone is talking SOA, services and Web Services. If you Google “service oriented architec-ture,” you get almost 12 million hits. 12 million hits for an IT concept with “architecture” in it! And if you Google “Web Services,” over a billion hits! While that’s no indication of true adoption, it cer-tainly does validate the buzz factor.

In fact, so many people are talking SOA, and la-beling their products and services accordingly, OASIS has recently formed an SOA reference model technical committee. According to the May 3, 2005, OASIS news release1, “the SOA reference model will offer an understanding of the core elements within a service oriented environment and the asso-ciations and relationships among those elements.”

1 See http://www.oasis-open.org/news/

oasis_news_05_03_05.php.

Essentially, the intent of the reference model is to separate fact from fiction—to provide software and application architects a starting point to delivering SOA solutions. This is good, but as we all know, it will take time (perhaps a lot) to complete.

In the meantime, as a service to our clients who are interested in, or are pursuing a service-oriented strategy, we have developed this overview report on services and SOA. This “SOA Cheat Sheet” report includes key service concepts, information on sup-porting technologies, a view of the SOA landscape, and some keys to SOA success.

SERVICE AND SOA BASICS

What Is a Service? Simply stated, a service is a thing that fulfills a

purpose. A service is, in essence, a “worker,” em-ployed to achieve a specific end goal for a requester. The end goal may be small in scope, such as retriev-ing information, or large in scope, such as executing a business process. Most services are in the middle, completing a function. The scope of a service is re-ferred to as its grain, or level of granularity.

WHAT KIND OF THING IS A SERVICE? A service is an abstract resource that has a name, a job, job tasks, contact information and policies regarding security and service levels. To use (request) a ser-vice, you send a message—in accordance to the con-tact information and policies—and then (if appropriate), receive a reply message.

A SERVICE’S JOB. The job of a service is limited to a single distinct business concept, function, or proc-ess. This characteristic is referred to as the bounds of a service. Finding the correct bounds is a key factor in service definition. A service may call upon other

2 • “Service-Oriented World” Cheat Sheet

A Customers.com® Research Service © 2005 Patricia Seybold Group • Unauthorized redistribution of this report is a violation of copyright law.

services if it needs assistance to complete its job. This service-to-service relationship is called collabo-ration.

SERVICE COLLABORATION. Services collaborate through orchestration, business interaction, or inter-ception:

• Orchestration is a type of collaboration in which the primary service directly invokes other services. The primary service knows the se-quence of actions and the interfaces, responses, and return states of the called services.

• Business Interaction is a type of collaboration in which some coordination mechanism knows the sequence of actions, pos-sible states, and paths of in-teraction among one or more services. The business inter-action is usually long-lived involving requests/messages from multiple parties. The coordination mechanism may be a business process execution engine, a work-flow engine, an event han-dler, or an enterprise service bus.

• Interception is a type of collaboration in which an intermediary service receives and acts on a request (or reply) and then forwards the request (or reply) to the original target. Interception is used to perform common functions such as security, policy, audit, and translation. In many interception scenarios, the requesting and providing parties are unaware of the intermediary service.

NOT ALL SERVICES ARE ALIKE. Not all services are simple information-oriented requests/replies. Beyond request/reply, a service may be a worker, a monitor, an agent, an aggregator, or even a process.

• Request/Reply is an information-bearing ser-vice. The service either retrieves information and/or performs a calculation/manipulation on behalf of the requester to produce a result. The Request/Reply may perform information update

tasks, but it often calls upon a worker to add, change, or delete information.

• Worker performs a function, most likely chang-ing the state of the thing it works on.

• Monitor is a service whose job it is to observe something and report on its findings based on monitoring and notification rules.

• Agent is a service whose job it is to observe something and then act on its findings. An Agent shares behavior with a Monitor in that it ob-serves based on monitoring rules, however an Agent differs from a Monitor in that it may take action(s) based on its findings.

• Intermediary is a service that intercepts a service re-quest (or reply), performs a value-added function (usu-ally translation or policy), and then forwards the en-hanced message to the origi-nal target.

• Aggregator is a service that combines results from feder-ated sources or services. A Request/Reply service may

use the Aggregator. Aggregator services will play a role in right-time architecture, business activity monitoring (BAM), and the Grid.

• Process is a long-running service, coordinating the actions of multiple parties through a series of work steps. The work step activities may also be services.

What Is SOA? The term SOA is used interchangeably for three

distinct concepts: the architectural concept, the style of the resulting business solutions, and the support-ing infrastructure. In this section, we describe each concept.

SERVICE-ORIENTATION. Service orientation is an architectural concept that refers to the loose coupling of a service (an abstract resource with a defined job) and its provider (the physical asset(s) that perform

The term SOA is used interchangeably for

three distinct concepts: the architectural concept, the style of the resulting business solutions, and the supporting

infrastructure.

Business-Driven ArchitectureSM • 3

© 2005 Patricia Seybold Group • Unauthorized redistribution of this report is a violation of copyright law. A Customers.com® Research Service

the job tasks). A requestor only knows what the ser-vice’s job is and how to request it. The service is the only one that knows its implementation.

Typically, service-orientation is applied to func-tional assets that correspond to business concepts (Open Customer Account) or system concepts (Au-thenticate User). However, service-oriented thinking can apply to any domain, including integration, net-work, platform, or even programming services. If a requester knows what a service offers (job, service levels) and how to use it (contact, security), then it really is not important (to the requester) how that service works, as long as the results meet expecta-tions.

SERVICE-ORIENTED ARCHITECTURE. SOA is an IT architecture strategy for business solution (and infrastruc-ture solution) delivery based on the concept of service-orientation.

SOA STYLES FOR BUSINESS SOLUTIONS. The two primary styles of SOA used in business so-lution development are composite application development and flow.

Composite Application Devel-opment. In composite applications, the user interac-tion drives a request for one or many services. Most of the service invocations are synchronous in nature. A composite application typically serves one busi-ness domain. Composite applications are often de-livered in a portal.

Flow. In flow, business process and/or events drive the service invocations. The service invocations are a mix of asynchronous and synchronous; however, the overall flow is usually long running and asyn-chronous. A flow typically crosscuts business do-mains and often extends outside of the enterprise.

• Business Process-Driven. In business process-driven architecture, the flow of work, as a series of activities, drives the requisite application and human behavior to complete a business transac-tion or process. The process is typically long running in nature, involving multiple parties and/or applications within an enterprise or across enterprises.

In business process-driven SOA, a business process may implement as a service, and/or a business process step (activity) may invoke one or more services.

• Event-Driven. In an event-driven architecture, a notable thing happens inside or outside your business, which disseminates immediately to all interested parties (human or automated). The in-terested parties then take action. The event-driven action may include the invocation of a service (thus event-driven SOA) or the trigger-ing of a business process or workflow.

Closing the loop on flow, any service may gener-ate an event or be invoked via an automated transac-

tion (business process step, event-driven activity). We believe this is the true power of SOA, combining services, events, and business proc-ess for human and automated (agent-based) interactions.

SOA ENVIRONMENT. Refers to the collective environment that al-lows services to be defined, devel-oped and used by other services,

and to be assembled into solutions by adding process, interaction mechanisms, user interface, and/or rules. In addition to service development and solution as-sembly, the SOA environment provides runtime and management functions such as service discovery, policy definition and enforcement, quality of service (performance, availability, reliability and load), transaction management, audit, and usage metering.

Why SOA? Certainly, everyone is talking about SOA, but

talk doesn’t justify adoption. In our experience, we find that SOA has both business and IT advantages.

Business advantages consist of the following:

• Consistent Experience. An SOA can provide a consistent experience for customers and partners across channels and lines of business.

• Business Agility. An SOA can add new func-tionality, expose functionality to new channels,

The two primary styles of SOA used in business

solution development are composite application development and flow.



and vary functionality based on context (cus-tomer, partner, entry point).

• Mix and Match. An SOA can compose busi-ness solutions from a reusable service collection, leveraging internal and external services.

• Optimize Interactions. An SOA can optimize business interactions for customers, partners, and internal constituents through the implemen-tation of business scenarios (process, events, and services) versus traditional applications.

IT advantages include:

• Reduction of Costs. Reuse of services reduces IT development and maintenance time and costs.2

• Leverage Existing IT Investments. Your ser-vice providers are existing code (objects, com-ponents, legacy modules, and application package APIs) and information assets (data-bases, files, and documents).

• Transition Strategies. An SOA can provide application and portfolio transition strategies.

TECHNOLOGY LANDSCAPE

There are two pieces to the technology landscape. The first is the set of technology and standards re-lated to service implementation. The second is the technology that comprises the SOA environment.

Services Technology EXTENSIBLE MARKUP LANGUAGE (XML). XML is a standard (tags based) markup language used in document and message definition and processing. XML also serves as the base for many special pur-pose languages such as RSS (Really Simple Syndi-cation) and WSDL (Web Services Description

2 Note that the ROI from reuse typically occurs be-

tween the second and third use of the service. This note is based on industry metrics that consider the increased de-sign and development time to “get the service right” to be reusable.

Language). XML and the following supporting stan-dards are fundamental to the service-oriented world.

• XML Schema (DTD, XSD): A schema de-scribes the names, types, and occurrence pat-terns of elements or attributes in an XML document. Document Type Definition (DTD) is the original schema language, which has been superseded by XML Schema. XML Schema de-fines the document characteristics using XML.

• XSLT: A stylesheet-based mechanism to trans-form XML documents from one format to an-other. The output can be XML, HTML, or text.

• Xquery: A query language for XML documents and XML databases.

• Xpath: Provides a mechanism for searching within nodes of an XML document. XPATH is used in conjunction with XSLT and XQuery.

BASIC SERVICE INVOCATION PATTERN. In Il-lustration 1 we show the basic service invocation pattern. First, the service has to advertise its exis-tence, which it does by publishing an entry to a reg-istry (“I exist!”). Once the service is registered, it sits and waits. Next, a requestor comes along that wants to use the service. Currently most requestors know the name of the service they want (“Find ser-vice x for me!”). In the future, requestors want the ability to ask for any service that performs a specific function, such as Get Stock Quote. Once the registry returns the service description and location, the re-questor can prepare and make the request (“Do your job!”). The service then interacts with its providers, and prepares and returns a result (“Did it!”).

WEB SERVICES. Web Service refers to a standard implementation model for services. The Web Ser-vice Basic Profile3 is WSDL for description, UDDI for registry, and SOAP for message protocol.

Web Services Description Language (WSDL). WSDL is an XML document format for describing Web Services. In WSDL, services are described us-ing six major elements:

3 See http://www.ws-i.org/Profiles/BasicProfile-1.1-

2004-08-24.html



• Types: Describe the data types for exchange between the requestor and the service.

• Message: An abstract definition of the message, with name and, optionally, input parameters or return values.

• portType: A set of abstract operations, each mapping to an input and/or output message. A service typically has more than one operation defined. Each operation has one of four types: request-response, one-way (client messages the service), solicit-response (service messages cli-

ent, gets reply) and notification (service mes-sages client).

• Binding: Binding is the association of an opera-tion and messages to a concrete network proto-col—such as SOAP or HTTP. If you have multiple operations, you will have multiple bind-ings.

• Port: The port specifies an address for a bind-ing, thus defining a communication endpoint. If you have multiple bindings, you will have mul-tiple endpoints.

Basic Service Invocation Pattern

Registry

“Find Service X for Me !”-OR-

“Find me a Service that does Z !”

Service Description with Location (WSDL and URI)

“Do

your

job!”

(SOAP/H

TTP, X

ML/HTT

P, SOAP/R

EL*, X

ML/JMS)

“Did

it! H

ere a

re th

e res

ults i

n XML f

ormat.

”

Provider Application 1

Provider Application 2

Service Requestors

ServiceApplication

Agent/Sensor Process

Service X

Provider Database

A

“I Exist! Here’s my information” .A

B

C

D

F

E1 E3E2

© 2005 Patricia Seybold Group Inc.

Illustration 1. In this diagram, we show the basic service invocation pattern, starting at “A,” with Service X an-nouncing its existence to the registry; ending at “F,” with the service returning results to the requestor.



• Service: The service is an aggregation of end-points. Simple services, with only one operation, will only have one endpoint.

The best way to understand WSDL is to look at one. Illustration 2 is an abridged version of the WSDL for Amazon’s E-commerce Service (ECS). We left the overall structure of the WSDL intact, but

we edited and annotated the content to focus on the ItemSearch operation. For the full ECS WSDL, and information on Amazon’s Web Services program, please refer to Amazon Web Services site4.

4 See http://www.amazon.com/webservices

Amazon Ecommerce Service WSDL Snippet

WSDL Root:

Namespaces for SOAP, XML, Web

Service

Data Types to be Transmitted .

Defined with XML Schema.

Messages to be Transmitted

Part = Parms

Supported Operations.

Message to Operation mapping .

How the Messages are Transmitted on

the Wire.

SOAP-specific details.

Where is the Service?

Input Message Followed by Output Message = Request-Response Pattern

Other WSDL Operation Patterns :≅ Input Only = One-way ≅ Output Only = Notification≅ Output Followed by Input = Solicit Response

Illustration 2. This is an abridged version of the WSDL for Amazon’s E-commerce Service (ECS). The annota-tions on the left hand-side describe the WSDL sections. The yellow boxes within the WSDL highlight key elements, such as data elements, messages and bindings, and their recurrence in the various sections.



Universal Description, Discovery, and Integration (UDDI). UDDI offers a standard mechanism to clas-sify, catalog, and manage Web Services to enable discovery and consumption. A UDDI registry is built on the UDDI information model and provides an UDDI API set for inquiry and publication, and optional UDDI APIs for security, custody transfer, subscription, replication, and value setting.

The UDDI information model contains the fol-lowing entity types, as described in the UDDI 3.0 specification5:

• businessEntity: Describes a business or other organization that typically provides Web Ser-vices.

5 For more information, see the latest release of the

UDDI spec: http://www.uddi.org/pubs/uddi-v3.00-published-20020719.htm

• businessService: Describes a collection of re-lated Web Services offered by an organization described by a businessEntity.

• bindingTemplate: Describes the technical in-formation necessary to use a particular Web Service.

• tModel: Describes a "technical model" repre-senting a reusable concept, such as a Web Ser-vice type, a protocol used by Web services, or a category system.

• publisherAssertion: Describes, in the view of one businessEntity, the relationship that the businessEntity has with another businessEntity.

• subscription: Describes a standing request to keep track of changes to the entities described by the subscription.

Illustration 3 shows the relationship between business entities, business services, and binding tem-plates. We have notated the model elements that

UDDI Information Model: Business Service

Network Address of Service, typically a URL

“Technical Fingerprint” of service . Contains protocols, formats , exchange patterns etc.

Business Entity represents the business or provider .

Business Service represents a logical GROUP of related services .

Binding Template represents INDIVIDUAL(executable ) services .

Illustration 3. This illustration, from the UDDI 3.0 specification, shows the relationship between business entities, business services, and binding templates.



contain the concrete service elements, location, and technical implementation.

It is important to note that you can use both UDDI and WSDL in conjunction with non-SOAP (non Web Service) services.

SOAP. SOAP6 is an XML-based message protocol for Web Services. SOAP consists of three parts: an envelope that defines a framework for describing message content and processing, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.

The SOAP envelope has a header and a body. The SOAP header contains information on how a message recipient should process the message. Items contained in the header may in-clude: transaction management, authentication, and payment. The SOAP body contains the message content: the information required to execute a request (message, request parameters) or process a response (message, return values). SOAP transports using HTTP, or, more recently, using reliable mes-saging (WS-REL*)7.

ADDITIONAL WEB SERVICE STANDARDS. There are at least 50 ratified and proposed standards di-rectly related to Web Services. That doesn’t even count important consumed standards, such as XML. The standards work is in the following areas:

• Presentation: Portal, Portlet

• Business Process: Business Process Definition and Execution, Choreography, Orchestration

• Business Domain Specific: Document Formats, Business Processes, Business Lexicons

6 See http://www.w3.org/TR/2000/NOTE-SOAP-

20000508/#_Toc478383497 7 WS-ReliableMessaging and WS-Reliability are two

(overlapping) Web Services specifications that describe how to use SOAP over a reliable, asynchronous transport, such as message-oriented middleware (MOM).

• Quality of Service: Context and Transaction Management, Management

• Quality of Protection: Security (Authentication, Authorization, Encryption)

• Messaging: Protocol, Reliable Messaging, Routing, Addressing, Events, and Notification

• Metadata: Policy, Service Definition and Dis-covery

To keep abreast of each standard, the intent, specification, status, adoption rate, and competing standards could be a full-time job. We recommend you leverage the Web sites of the major standards

bodies: W3C, OASIS, and IETF and vendors (IBM, Microsoft, BEA, Sun) for up-to-date infor-mation.

FOLLOW/TRY THESE. Specific Web Service standards beyond those included in the basic pro-file that you should be watching (experimenting with) are:

• Business Process Execution Language (BPEL)8. BPEL is the leading standard to define and manage long-lived service orchestrations. BPEL is an XML-based language. BPEL allows the collaborating services to be either Java Ser-vices (BPELJ) or Web Services (BPEL4WS).

• Reliable Messaging (WS-REL*). WS-ReliableMessaging and WS-Reliability are two (overlapping) Web Services specifications that describe how to use SOAP over a reliable, asyn-chronous transport, such as message-oriented middleware (MOM).

• WS-Security. WS-Security describes enhance-ments to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentica-tion. WS-Security also provides a general-

8 See ftp://www6.software.ibm.com/software/

developer/library/ws-bpel.pdf.

There are at least 50 ratified and proposed standards

directly related to Web Services.



purpose mechanism for associating security to-kens with messages, and for encoding binary se-curity tokens.

• Web Services for Remote Portlets (WSRP)9. A user-facing Web Service that will provide content, marked for display, to a portal or other aggregating Web application. This moves Web Services out from the back-end model layer.

REPRESENTATIONAL STATE TRANSFER (REST). REST, introduced by Ray Fielding in his doctoral

9 See http://www.oasis-open.org/committees/

tc_home.php?wg_abbrev=wsrp.

dissertation10, has become a popular alternative im-plementation model to SOAP Web Services. In his dissertation, Fielding describes REST as the under-lying architecture style for the modern Web.

REST emphasizes stateless interactions, uniform interfaces (HTTP), and the concept of resources: A resource (information entity) has a unique identity (URI). A resource is manipulated via its representa-tion (information exchanged). All resources respond

10 Fielding, Roy Thomas. Architectural Styles and the

Design of Network-based Software Architectures. Doc-toral dissertation, University of California, Irvine, 2000. see: http://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf.

RESTful Service: Yahoo! Local Search

http://api.local.yahoo.com/LocalSearchService/V1/localSearch?appid=YahooDemo&query=pizza&zip=02109&results=2

Host Name Service Name Version Method Query Arguments with Values

Illustration 4. This Illustration shows a RESTful service invocation and result. The service interface is called out and annotated in the red box at the bottom of the picture.



to the same small set of operations (HTTP GET, PUT, POST, DELETE).

RESTful Web Service. When the REST style is applied to “Web Services,” SOAP is replaced by a simple XML-over-HTTP message protocol. In a RESTful Web Service, all of the information re-quired to invoke the service is encoded in the URL. An example of the Yahoo! Local Search service (with results) is shown in Illustration 4. As you can see, the entire interaction took place within the browser. My entering the service’s URL in the browser address line returned an XML document with the name and location of pizza shops near our office. The simplicity offered by REST makes it at-tractive to developers.

Resource vs. RPC. However, there is more to REST than the simple interaction model. REST focuses on the resources (the nouns) rather than the actions

(verbs, operations) on the resource. In a pure REST model, every resource (pizza joint) would be acces-sible by its unique identifier (URI). We would di-rectly GET Ernesto’s Pizza or directly GET the collection of pizza joints in Boston, instead of asking an RPC-style local search service to find the pizza joints in Boston.

Removing the complexity of search and collec-tions, imagine that each of your customer accounts is treated as a resource with a URI. To access a cus-tomer’s account information, you wouldn’t use a typical RPC approach (service, method, parameters); you would just link to the customer account resource using the URI.

REST, Web Services, and SOA. This last point, resources (nouns) versus RPC (verbs), is why REST isn’t typically associated with SOA, because pure REST obviates the need for services. (Although, not without great effort). Most often, REST is imple-

SOA Environment

♦ M o d elin g T o o ls

♦ D evelo p m en t T o o ls

♦ D ep lo ym en t /P u b lish in g T o o ls

♦ T estin g T o o ls

♦ C h an g e M an ag em en t T o o ls

♦ R ep o sito ry

♦ P o licy A d m in is tra tio n

♦ U n ified M an ag em en t C o n so le

♦ C ap acity P lan n in g

♦ U sag e R ep o rtin g

♦ C h arg e B ack

B U S IN E S S S E R V IC E S

C h o re o g ra p h y & C o m p o s itio n S e rv ice s :

O rch estratio n , C o o rd in atio n , S tate , E ven t H an d lin g

In fra s tru c tu re S e rv ic e s :

D isco very , R eg is try , R o u tin g , S ecu rity , T ran sactio n , M an ag em en t A g en ts , C ach in g , P o licy, A u d i t, T ran slatio n

( D ata , P ro to co l ) , T ran sfo rm atio n (D ata ), R eso u rce C o n n ectio n , R eso u rce A d ap ters

U ser A p p licat io nPro cess F lo w Even t F lo w

D E S IG N , D E V E L O P M E N T & D E P L O Y M E N T

S Y S T E M S, A P P L IC A T IO N S &

S C E N A R IO M A N A G E M E N T

SERVICES LAYER

PR O VIDER LAYERB u sin ess

A p p lica tio n s

B u sin ess D ata

R eg istry

E n terp rise S erv ice B u s (E S B )

S O A F ab ric

A p p l icatio n S erver

W eb S ervices P la tfo rm

M essag e O rien ted M id d lew are

S ecu rity In fras tru ctu re

W eb S ervices M an ag em en t

E n terp rise S ystem s

M an ag em en t

B P E L S erver

E n terp riseM etad ataR e pos itory

© 2005 Patricia Seybold Group Inc.

Illustration 5. In this diagram, we show the SOA environment, using service-orientation. In the center of the dia-gram, in the services layer, alongside the business services, we show the core “SOA” services, supporting solu-tion assembly (choreography and composition) and infrastructure functions (discovery, routing, registry, security etc.). Below the services layer, there is a provider layer, which represents the major infrastructure options to sup-port the services layer and, therefore, your SOA environment.



mented in the manner Yahoo! has adopted, as a sim-ple interface to a (RPC style) service. Other syndi-cated services 11 that offer a REST interface are Amazon, eBay, Flickr, and Bloglines. Google (to date) only offers SOAP Web Services.

SOA Environment Technology

As we discussed in the service SOA basics sec-tion, the SOA environment refers to the collective environment that supports the entire service lifecycle (define, design, build, deploy, consume, replace, and retire). In addition, the SOA environment must pro-vide for quality of service and quality of protection.

In Illustration 5, we take a service-oriented view to the SOA environment. In the center of the diagram, in the services layer, alongside the business services, we show the core “SOA” services, supporting so-lution assembly (choreography and composition) and infrastruc-ture functions (discovery, rout-ing, registry, security etc.).

Below the services layer, there is a provider layer, which represents the major infrastruc-ture options to support the ser-vices layer and therefore your SOA environment. Note the “options” qualification on infrastructure. You don’t have to go out and pur-chase a ton of technology to get started in SOA. As we discussed with the RESTful interface, you can start slow, and even (as we showed) with other peo-ple’s services.

However, as your business solutions evolve from simple service invocations to composite applications and process/event driven scenarios, you should in-vest in infrastructure for an extensible SOA envi-ronment and a well-managed service catalog.

11Please see resource section for specific syndicated

service developer sites.

Hot SOA Technology Areas The hot SOA technology areas right now are

SOA fabric (Web Services platform and manage-ment), enterprise service bus (ESB), and regis-try/repository.

SOA FABRIC. SOA fabric is a new (cooler) name for the combination of a Web Services platform and a Web Services management environment. Essen-tially, in an SOA fabric, intermediary (agent) ser-vices are employed to perform the routing, transformation, security, and management tasks re-quired for effective implementation of an enterprise-scale SOA. The intermediaries intercept requests (messages) as they traverse between client (con-

sumer) and service (producer). The SOA fabric consists of in-termediaries, registry, and policy components. The intermediaries are deployed in the Web Service execution environment in the J2EE or .Net container. The un-derlying assumption in SOA fab-ric is that all services participating in the SOA are Web Services.

SOA fabric is best suited to composite application develop-ment—the first SOA style, which has primarily synchronous

interactions. While some SOA fabric vendors are starting to implement asynchronous support to com-ply with the WS-Rel* specs, many more are adver-tising their ability to integrate with ESBs to support integration and the second SOA style: event-driven/process-driven SOA.

ENTERPRISE SERVICE BUS. An ESB is an open standards, message-based, distributed, integration solution that provides routing, invocation, and me-diation services to facilitate the interactions of dispa-rate distributed information technology resources (applications, services, information, platforms) in a reliable manner. That’s a lot to take in, so let’s break down the key terms in our ESB definition, as fol-lows:

• Open Standards. Open standards refers to both the ESB solution components (runtime con-

The underlying assumption in SOA fabric is that all services participating in the SOA are

Web Services. SOA fabric is best suited to

composite application development—the first SOA style, which has primarily synchronous interactions.



tainer, messaging infrastructure, integration ser-vices, design-time notations) and the mecha-nisms for integrated resources to participate (attach, request, respond) on the bus.

• Message-Based. The communication mecha-nism of an ESB is messaging, using standard message notation, protocols, and transports.

• Distributed. The ESB runtime environment can be distributed across a networked environment for the purposes of quality of service, quality of protection, and economics.

• Routing, Invocation, and Mediation. Routing, invocation, and mediation are the basic functions of the ESB. Routing includes ad-dressability and content-based routing. Invocation re-fers to the ability to make requests and receive re-sponses from integration services and integrated re-sources. Mediation refers to all translations and transfor-mations between disparate resources including security, protocol, message nota-tion/format, and message payload (data/semantics).

• Facilitate. The ESB must coordinate the interac-tions of the various resources and provide trans-actional support.

• Reliable. The ESB must guarantee message de-livery.

ESB Usage. There are two major uses of the ESB. The first is for enterprise integration, the connection of disparate resources to fulfill customer and busi-ness scenarios. The ESB is a standards-based inte-gration alternative to traditional proprietary enterprise application integration (EAI). The ESB has gained popularity in IT shops that have adopted a service orientation, since the integrated resources in an ESB and the integration functions act as ser-vices. The role of an integrated resource as a service is critical, because now the integrated resource can

easily participate in a service-oriented architecture, as described below.

The second use of the ESB is as an infrastructure backbone for service-oriented architecture (SOA). The ESB serves the two primary styles of SOA: composite application development and event-driven/process-driven SOA, as follows:

• In composite application development, the ESB provides service request routing, invocation, mediation, and inter-service orchestration.

• In event-driven SOA, in addition to the func-tions mentioned above, the ESB serves as the

event processor, interpreting and handling events based upon content, rules, and sub-scriptions, to initiate the ap-propriate downstream actions.

• In process-driven SOA, the ESB performs the functions mentioned above, and it can also host a business process execution engine to control the long-running process.

FABRIC vs. ESB? While there are overlapping functions be-

tween ESB and SOA fabric, we believe these tech-nologies are more complements than competitors. Many organizations will use SOA fabric as the backbone for composite application development while connecting to an ESB as the backbone for in-tegration and event-driven/process-driven SOA.

If your first priority is integration or event-driven/process-driven SOA, start with an ESB. If your first priority is composite application develop-ment, investigate portals for the user interaction layer and, depending on your architectural prefer-ence (HTTP, messaging) and service catalog (Web Services or non-Web Services), either SOA fabrics or ESB for service interaction.

Over the next three to five years, we expect to see coalescing of some of the technology components supporting fabric and ESB. This will be great, be-cause how many messaging infrastructures, regis-tries, repositories, and management tools does an

If your first priority is integration or event-driven/

process-driven SOA, start with an ESB. If your first priority is

composite application development, investigate

portals for the user interaction layer and either SOA fabrics or

ESB for service interaction.



organization really need? Since both technologies have service-oriented underpinnings with standards-based interfaces, any changes to the underlying im-plementations (if done correctly) should be non-invasive to the consumers.

REGISTRY/REPOSITORY. In SOA, the terms regis-try and repository are often used interchangeably, but they are, in fact, two distinct (at least logically) entities. A registry is an index. In SOA, a registry stores the description (name, purpose, endpoint, in-vocation, and interface) and runtime and manage-ment policy information (security, usage, service levels, fees, etc.) for services advertised for con-sumption. A registry entry has a reference to the ac-tual service code, which is stored in a repository.

Repository. A repository then, stores the actual ser-vice objects, along with information to support the service lifecycle (define, design, build, deploy, con-sume, replace, and retire). Of course, your IT envi-ronment extends beyond SOA, so your shared IT repository should:

• Advertise your services to business solution builders/integrators. Include service metadata such as name, purpose, classification, disposi-tion, current uses, and service levels.

• Advertise your non-service resources, to com-municate existing assets and identify candidate service providers.

• Feed your runtime environment: registry and any enterprise policy and service level opera-tions.

• Interface with all IT Metadata management en-vironments (business terms, taxonomies, sche-mas, business rules, processes, event definitions, event routings, integration routings, etc.)

• Assist in capacity planning and service perform-ance analysis. Keep service level metric targets. Relate repository metadata to runtime data from scenario and service instrumentation, usage, and logging data.

KEYS TO SOA SUCCESS

There is great potential with SOA, but, as with any technology strategy, if done wrong, opportunity can turn into failure. To start you on the path to suc-cessful SOA, we recommend the following:

1. Make sure SOA is right for your business. (SOA is not the only architecture strategy, nor is it mandatory!)

2. Start with a specific business prob-lem/opportunity in mind.

3. Create a strong services catalog:

- Define a collection of services that (over time) will match the functional depth and breadth of your business.

- Adopt service definition practices that ad-here to best practices of naming, purpose, boundaries, and granularity.12

- Use a common business lexicon for seman-tic compatibility of services, applications, processes, and information stores.

- Plan in (directly or through collaborators) systems management, security, service us-age, and business performance instrumenta-tion, error handling, transaction management, and logging.

- Make it easy for your developers to assem-ble services into business solutions.

4. Remember, there is more than one style of SOA: composite applications and flow (event/process-driven SOA). Understand which you are doing, and make your SOA environment choices ac-cordingly.

5. Be smart with runtime and management infra-structure investments. Build your SOA envi-ronment incrementally, with a vigilant eye

12 We offer a Services Discovery and Definition work-

shop to get you started. For more information: http://dx.doi.org/10.1571/soawork.



towards future scale and extensibility. Follow standards whenever possible.

6. Prepare your organization (business and IT) for the implications of shared services and infra-structure, such as the ramp-up period, service ownership, standards and governance, distrib-uted problem detection, project interdependen-cies, and new loads on provider resources.

7. Recognize that sometimes the underlying service providers (applications, objects, information stores) are broken and need repair. Slapping a service interface on a broken provider will only make things worse.

8. Start small, start slow.

RESOURCE LIST

Standards and Technical Committees

1. OASIS Web Services and SOA: http://www.oasis-open.org/committees/tc_cat.php?cat=ws

2. OASIS SOA Reference Model: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

3. OASIS UDDI: http://www.uddi.org/

4. W3C Web Services: http://www.w3.org/2002/ws/

5. W3C Web Services Glossary: http://www.w3.org/TR/ws-gloss/

6. W3C XML Protocol (SOAP 1.2): http://www.w3.org/2000/xp/Group/

7. W3C SOAP 1.1: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383497

8. W3C WSDL 1.1 Specification: http://www.w3.org/TR/wsdl

9. OASIS Cover Pages, SGML/XML family: http://xml.coverpages.org/

10. OASIS Web Services for Remote Portlets: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp.

11. BPEL Specification: ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf

12. CBDI Forum’s Summary of Protocols related to Web Services: http://roadmap.cbdiforum.com/reports/protocols/summary.php

Technology

13. Web Services Interoperability WS-I: http://www.ws-i.org/

14. Apache Axis (SOAP Implementation): http://ws.apache.org/axis/

15. REST: http://en.wikipedia.org/wiki/Representational_State_Transfer and Roy Fielding’s REST Dissertation: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

16. Web Services Community: http://www.webservices.org/, http://www.looselycoupled.com/, http://webservices.xml.com/

17. XML Community: http://www.xml.com/



Syndicated Services:

18. Amazon: http://www.amazon.com/webservices 19. Google: http://www.google.com/apis/ 20. eBay: http://developer.ebay.com/ 21. Yahoo: http://developer.yahoo.net/ 22. Flickr: http://www.flickr.com/services/api/

Patricia Seybold Group:

23. Web Services and SOA landing page: http://www.psgroup.com/research_webserv.aspx

24. Evolution of Service-Oriented Architecture: http://dx.doi.org/10.1571/soa1-6-05cc

25. Service Discovery using Customer Scenario Mapping: http://dx.doi.org/10.1571/soa1-20-05cc

26. Integration and Customer Experience: http://dx.doi.org/10.1571/bda3-31-05cc

27. Integration Scenarios and the Networked Integration Environment: http://dx.doi.org/10.1571/bda4-14-05

28. Enterprise Service Bus Q&A: http://dx.doi.org/10.1571/bda5-19-05cc

29. BEA Answers the Vision Question(s): http://dx.doi.org/10.1571/psgp4-28-05cc

30. L.L. Bean Architecture Evolution Case Study: http://dx.doi.org/10.1571/CS9-9-04CC

31. Web Services Backplane: Infrastructure for Web Services, by Susan E. Aldrich, January 2, 2003, http://dx.doi.org/10.1571/LA1-2-03CC

“service-oriented world” cheat sheet · find that soa has both business and it advantages....

Documents