Infrastructure

SEPTEMBER 2008 / VOLUME: 8 ISSUE 9

THE WORLD’S LEADING MAGAZINE DEDICATED TO WEB SERVICES TECHNOLOGIES

www.SOA.SYS-CON.com

12 Getting a Handle on SOA Risk PAUL C. BROWN

24 The Case for Coordinated EDM & SOA Strategies KEITH R. WORFOLK

DEBU PANDA AND ARVIND MAHESHWARI 16

Managing Your BPEL Infrastructure

2 SEPTEMBER 2008 www.SOA.sys-con.com SEPTEMBER 2008 3 www.SOA.sys-con.comwww.SYS-CON.com

www.SOA.SYS-CON.com

INTERNATIONAL ADVISORY BOARD Andrew Astor, David Chappell, Graham Glass, Tyson Hartman, Paul Lipton, Anne Thomas Manes, Norbert Mikula, George Paolini, James Phillips, Simon Phipps, Mark Potts, Martin Wolf

TECHNICAL ADVISORY BOARDJP Morgenthal, Andy Roberts, Michael A. Sick, Simeon Simeonov

EDITORIAL Editor-in-ChiefSean Rhody [email protected] XML EditorHitesh Seth Industry EditorNorbert Mikula [email protected] Product Review EditorBrian Barbash [email protected] .NET EditorDave Rader [email protected] Security EditorMichael Mosher [email protected] Research EditorBahadir Karuv, Ph.D [email protected] Technical EditorsAndrew Astor [email protected] Chappell [email protected] Thomas Manes [email protected] Sick [email protected] Wacey [email protected] International Technical EditorAjit Sagar [email protected] Executive EditorNancy Valentine [email protected]

Associate Online EditorLindsay Hock [email protected]

PRODUCTION ART DIRECTORAbraham Addo [email protected]

ASSOCIATE ART DIRECTORTami Beatty tami @sys-con.com

EDITORIAL OFFICES SYS-CON MEDIA577 CHESTNUT RIDGE ROAD, WOODCLIFF LAKE, NJ 07677TELEPHONE: 201 802-3000 FAX: 201 782-9637SOA World Magazine Digital Edition (ISSN# 1535-6906)Is published monthly (12 times a year)By SYS-CON Publications, Inc.Periodicals postage pendingWoodcliff Lake, NJ 07677 and additional mailing offices

POSTMASTER: Send address changes to:

SOA World Magazine, SYS-CON Publications, Inc.

577 Chestnut Ridge Road, Woodcliff Lake, NJ 07677

©COPYRIGHT Copyright © 2008 by SYS-CON Publications, Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy or any information storage and retrieval system without written permission. For promotional reprints, contact reprint coordinator. SYS-CON Publications, Inc., reserves the right to revise, republish, and authorize its readers to use the articles submitted for publication. All brand and product names used on these pages are trade names, service marks, or trademarks of their respective companies. SYS-CON Publications, Inc., is not affiliated with the companies or products covered in Web Services Journal.

How to Sell an SOA

FROM THE EDITOR

WRITTEN BY SEAN RHODY

About the Author

Sean Rhody is the editor-in-chief of SOA World Magazine. He is a respected industry expert and a consultant with a leading

consulting services company. [email protected]

As you can imagine, I spend a lot of time speaking to people about service-oriented architecture (and

its variants for infrastructure and enterprise) and about how best to create a true imple-mentation (or at least, an effective one). There is a great deal of detail in creating such an artifact – design yes, but also implementa-tion, operational details, governance, and a myriad of other tasks that can easily take up a chief architect’s entire day. These tasks are all vital to the actual creation of the architecture, but for all that they may seem the fundamen-tal first steps in evolving the IT shop, and yet there are even more necessary first steps – selling the concept in the first place. SOA in many ways reminds me of rela-tional database technology. At its first incep-tion, the concept of an RDBMS must have had a hard sell. Sure it made perfect sense to arrange the data and ensure that the rela-tionships between the data were enforced, but what was the business case that enabled the purchase of this new and expensive technology? You certainly couldn’t say that by introducing a relation database, you were going to make the company $20 million a year annually. So the RDBMS slowly made its way into the IT arsenal a little at a time, with justifications added in a variety of ways. SOA is even more complex – it affects al-most every aspect of the enterprise if done to the fullest, and yet the basic premise is very similar to the RDBMS – it’s a better way to work. I imagine the discovery of the wheel engendered similar thought – “Duh, why didn’t I think of that, it’s so simple.” And yet there’s a mountain of legacy code, 50 years worth in some cases, that prevents a simple rip and replace. Not to mention the cost problem. But the real challenge in SOA is finding the ROI in IT. The logical statement that spending $20 million (I’m just picking a big number here, not stating that an SOA conversion should cost that) on conversion will in the future make all IT projects easier

to implement and thus less costly by some factor is in most cases not a sufficient jus-tification. The idea of tacking it on to some in-flight project usually creates howls from the business owner who somehow is being asked to pay much more than the base project should cost. Really, there has to be another way. And there is – making the business a partner. SOA is something that enables changes to how the IT organization reacts to business requirements and new functionality re-quests, making them easier to accomplish, and therefore both faster and cheaper. Building a case with the business that these changes are important and justify slightly hire costs for the first few projects is helpful. Finding a large scale transformation project is even better. In a large scale transformation, many IT systems are going to be touched, re-aligned, or replaced. New data models will come into being, and new services will be needed. This is not to say that it’s justification for throwing the kitchen sink into the IT budget during a transformation, but a case can eas-ily be made based on the integration needs that are without a doubt going to be part of the program. Instead of some cost savings in the future, by going with SOA in a trans-formation, the cost savings can be realized within the program. This isn’t what the IT world wants to hear – there’s a strong push from vendors and platform providers to go SOA – but it is the reality of software systems. The concept of a system that constantly requires renewal is foreign for some reason to financial folks, even though there are countless examples of the concept in the world. Software has a life cycle, and if you don’t feed your invest-ment, it dies. Nevertheless, in order to move to an SOA environment, we need to recognize the need to involve the business side of the organization in our activities and make a case in a language they understand in order to be successful.

OK

Prepared by Goodby, Silverstein & Partners 2008. All rights reserved. 415.392.0669

Released on 07.14.08Print Output at 100% Reader 1

ClientJob Number

Ad Number

Ad-ID

Job Title

File Name

File Format

Start Date

Color / Media

1st Close

1st Insertion

Vendor

Pubs

B

T

L

G

S

PeopleCreative Director

Associate CD

Art Director

Copywriter

Proofreader

Account Manager

Asst. Account Manager

Print Producer

Project Manager

Client

Production Artist

Mechanical SpecsHP TSGHPTSG-281000084EQUP11610000SOA Software DG - Resize B PageHPTSG-281_SOA Software DG_B pg.inddAdobe InDesign CS37/11/08 2:40 PM4/c MagNoneNoneXYZ GraphicsNone

8.625 in x 11 in8.375 in x 10.75 in7.875 in x 10.25 inNone1 in = 1 in

Bill to HPTSG-201

Keith AndersonNoneBrian GundersonBrian ThompsonShannon / Sage / JenLiz HolperLeigh Mc DanielKatie BorzcikLisa NicolayNoneJessica Pettigrew @ 7/14/08 3:46 PM

Notes

©2008 Hewlett-Packard Development Company, L.P.

Technology for better business outcomes. hp.com/go/soa

A LT E R N A T I V E T H I N K I N G A B O U T S E R V I C E - O R I E N T E D A R C H I T E C T U R E :

Rethink The Architecture, Rethink The Business. (Rethink Your Bottom Line.)

Alternative thinking is shifting your SOA strategy to focus on business initiatives rather than technology initiatives. (Head in the game, not on bits and bytes.)

It’s using governance to speed the adoption and reuse of services—keeping everything from getting out of hand.

It’s building quality and management into every step, from idea through execution, to help ensure you’re always up and running smoothly.

It’s capitalizing on software that works across platforms, so your business operates effi ciently through mergers and acquisitions and alliances and massive growth.

It’s choosing the right SOA partner so you can get on with the business of the business. (Hello, tomorrow.)

1722907.14.08

GSPcl

150FortuneM17229_HPTSG-281_SOA_Sftwr_DG_Bpg

Cyan Magenta Yellow Black

S:7.875 inS:10.25 in

T:8.375 inT:10.75 in

B:8.625 inB

:11 in

http://www.hp.com/go/soa

4 SEPTEMBER 2008 www.SOA.sys-con.com

INSIDE

2 How to Sell an SOA SEAN RHODY

6 BPEL Coming to People MANOJ DAS AND BHAGAT NAINANI

12 Getting a Handle on SOA Risk PAUL C. BROWN

15 Should You Fire Your CIO? DAVID LINTHICUM

16 Managing Your BPEL Infrastructure DEBU PANDA AND ARVIND MAHESHWARI

22 Discoverig Process Agility & the Significance of Regulatory PRAVEEN K. CHHANGANI AND R.C. CHHANGANI

26 The Case for Coordinated EDM & SOA Strategies PART 1 KEITH R. WORFOLK

32 The Million Dollar SOA Question: Software ESBs or Hardware Appliance SHIVA BHAJEKAR

12

16

http://www2.sys-con.com/webservices/pdf2/SOA_09_08_print.pdf

http://www.roguewave.com

6 SEPTEMBER 2008 www.SOA.sys-con.com SEPTEMBER 2008 7 www.SOA.sys-con.com

CORPORATEPresident and CEOFuat Kircaali [email protected]

Senior VP, Editorial & EventsJeremy Geelan [email protected]

ADVERTISINGSenior VP, Sales & MarketingCarmen Gonzalez [email protected]

Advertising Sales DirectorMegan Mussa [email protected]

Advertising & Events ManagerCorinna Melcon [email protected]

Events AssociatesKrisandra Russo [email protected] Susan Wechtler [email protected]

CUSTOMER RELATIONSCirculation Service CoordinatorsEdna Earle Russell [email protected]

SYS-CON.COMConsultant Information SystemsRobert Diamond [email protected]

Web DesignersStephen Kilmurray [email protected] Walter [email protected]

ACCOUNTINGFinancial AnalystJoan LaRose [email protected]

Accounts PayableBetty White [email protected]

[email protected] or 1-888-303-5282For subscriptions and requests for bulk orders, please send your letters to Subscription DepartmentCover Price: $6.99/issueDomestic: $99/yr (12 issues)(U.S. Banks or Money Orders)

For list rental information: Kevin Collopy: 845 731-2684, [email protected]; Frank Cipolla: 845 731-3832, [email protected]

SYS-CON Publications, Inc., reserves the right to revise, republish and authorize its readers to use the articles submitted for publication.

www.SYS-CON.com

www.SOA.SYS-CON.com

BPEL

BPEL Coming to People

BY MANOJ DAS AND BHAGAT NAINANI

Business systems and IT architectures have evolved to include process orchestra-tion as a fundamental layer, due in no small part to the emergence and wide-spread adoption of the Web Services Business Process Execution Language (WS-BPEL) standard. Most real-world processes involve some human interaction,

for example, for approvals or exception handling. While WS-BPEL addresses the industry’s need for rich and standard service orchestration semantics, it does not cover human inter-action with processes. Efforts are underway to address this gap in WS-BPEL with a set of specifi cations commonly referred to as BPEL4People. In this article, we provide an overview of the BPEL4People standards and explore how this standards area will emerge over the next few years.

BPEL and People BPEL is a standard owned by OASIS that provides rich and comprehensive orchestration semantics. At a high level, BPEL is a language that provides a rich set of activities and ex-ecution semantics to describe an executable business process. The processes and activities can be synchronous or asynchronous, short-lived or long-running. Many articles have been written on BPEL including “BPEL’s Growing Up” and “A Close Look at BPEL 2.0,” respec-tively, in the March 2007 and October 2007 issues of this magazine. Typical business processes involve a mix of system and human interactions. People can be needed to make some decisions and approvals, perform tasks that are inherently man-ual (such as talk to a customer) or have not yet been automated, and manage exceptions in a process. People also need to be notifi ed of interesting state changes and exceptions in a process. BPEL’s rich support for asynchronous services enables calls to an external workfl ow engine just as to any other asynchronous service. This architecture was detailed in an April 12, 2006 Web Services Journal article, “BPEL Processes and Human Workfl ow.” However, there are certain aspects of human interactions that are unique. For example, a process must specify which task needs to be performed, as well as who the stakeholders are (and their interests), the expectations around performance of the task, and what should happen if the task is not performed within specifi ed deadlines. Although BPEL can facilitate human interactions, its failure to fully grasp such interactions and their associated characteristics leads to two problems. First, every implementation achieves these goals by using propri-etary extensions. Second, a lack of specifi c human interaction features makes the modeling of such interactions less intuitive and more verbose than it needs to be.

BPEL4People and WS-HumanTask Overview In April 2007, BPEL fi nally became an OASIS standard. With standardization in place, it was time to start the process to standardize human interaction with BPEL. In June 2007, a group of six vendors — Active Endpoints, Adobe, BEA, IBM, Oracle, and SAP — published a set of two complementary proposed specifi cations, “WS-BPEL Extension for People” and “Web Services Human Task (WS-HumanTask),” together known as BPEL4People. In Febru-ary 2008, the OASIS WS-BPEL Extension for People (BPEL4People) Technical Committee

Increasing the market adoption of BPM by mainstream enterprises

http://wso2.com/welcome/esb


BPEL

was formed and started working on the two specifications. The goals of these specifications are to enable both portability and interoperability by providing a standard definition of:• BPEL extensions that define human interactions in BPEL process-

es• Models that define human tasks• Programmable interfaces that allow client applications to work

with human tasks

WS-HumanTask defines human tasks, including their properties, behavior, and set of operations needed to manipulate them. Al-though WS-HumanTask is a sister specification to WS-BPEL4People and is expected to be widely used in conjunction with BPEL, it is designed to be a standalone specification, enabling invocation of tasks from any business process (BPEL or otherwise), as well as from any Web Services client. (Note that throughout this article, we use task as shorthand for WS-HumanTask task.) BPEL4People uses BPEL’s extension mechanisms to layer human interaction capabilities on top of BPEL. At the core of these exten-sions is People Activity, which enables a task to be invoked from a BPEL process. Other extensions bind people assignments to people directories, assign task properties, and manipulate tasks in BPEL processes. Figure 1 shows the logical architecture of the BPEL4People specifications. A BPEL process invokes a People Activity (task). A WS-HumanTask engine manages the lifecycle of the task and pro-vides interfaces to the client application for operating on the task. This separation of the process and the task engine allows both to be deployed, managed, and scaled independently. It also enables the use of a unified task engine working with multiple BPEL and other process engines, possibly from different vendors. WS-BPEL4People also enables inclusion of the task definition inline in the BPEL pro-cess.

People Roles A key aspect of human interactions in a process is the definition of who is responsible for doing what. The BPEL4People specifica-tions go beyond the notion of a task performer and include the following human roles:

• Actual owner — The actual owner of a task is the person doing the task. The actual owner can perform actions associated with the task as well as forward, suspend, and resume a task.

• Potential owners — The concept of potential owners is useful when multiple people — usually members of a named group — work on shared tasks. A potential owner becomes the actual owner by claiming the task.

• Excluded owners — When a task is assigned to a defined group of people, some users can be explicitly excluded from being a potential owner. This is particularly useful when having to ensure that the person reviewing a task is not the person performing it (the 4-eyes principle).

• Task initiator—A task initiator is the person initiating the task or the business process. The initiator can track the status of the task; collaboration with the initiator can also be needed to close the task.

• Task stakeholders and business administrators — Task stake-holders and business administrators are ultimately responsible for the oversight and the performance of the task. They can participate in the performance of the task, for example, by add-

ing attachments or forwarding the tasks. They can also perform business administration functions such as suspending tasks or resolving missed deadlines. Task stakeholders are only assigned to a specific task instance; business administrators are assigned to all instances of a task type.

• Notification recipients — Anyone included on a notification list is classified as a notification recipient.

Assignments To assign actual people to these various roles, the BPEL4People specifications support the static binding, late bind-ing, and dynamic binding of people to roles. Assignments are made via:

• Literals — In its simplest form, people are literally assigned to roles using user identifier(s) and group name(s). This form of assignment is most common when tasks are assigned to named groups (or work queues).

• Logical people group — A logical people group represents a person or set of persons, or one or more named groups. A logical people group is bound to actual people and groups at deploy-ment using a query, with zero or more query parameters, against a people/identity directory. This form of assignment is useful in scenarios such as skill-based assignment.

• Expressions — Expressions can be used in both a task defini-tion and in the invoking BPEL process to assign people to roles. This form of assignment is most common when an assignment depends on the actual performer of a previous task, as when implementing the 4-eyes principle.

Delegation and Nomination BPEL4People specifications support the assignment of task instances at runtime, particularly two common workflow patterns: delegation and nomination. The BPEL4People specifications enable the definition of con-straints on delegation. A task definition can specify that it can be delegated to anyone, to only potential owners as determined by as-signment, to a specific set of people or named groups, or to no one. By default, tasks can be delegated to anyone. As mentioned earlier, task stakeholders can assign task instances at runtime. This, in conjunction with the fact that a task can be cre-ated without an owner being assigned, enables a pattern commonly known as nomination in which business users overseeing the pro-cess nominate users to perform a task on an instance-by-instance basis.

Notifications Notifications inform people of noteworthy events, call their attention to an action they need to take, or advise them of a change in status. The BPEL4People specifications treat notifica-tions as a special case of human tasks; most of the task discus-sions in this article also apply to notifications. There are a few differences between notifications and tasks, for example, notifi-cations are essentially one-way — the progress of the caller isn’t blocked for the notification the way it is for a task. Notifications can be sent to multiple recipients and can be managed by one or many business administrators; the other roles do not apply to notifications. Notifications also don’t have attachments, comments, or deadlines (these concepts, as applied to tasks, are discussed later in this article).

Timeouts and Escalations A key benefit and requirement of managing human activities using a process or task engine is the ability to manage the timely performance of tasks and associated escalations. The BPEL4People specifications allow multiple deadlines to be associated with a task. These deadlines can be start deadlines or completion deadlines. Both deadlines can be specified as a dura-tion (period of time), or a deadline (point in time), and are calcu-lated from the time the task is created. Expressions can be used to compute the deadlines at runtime, enabling both context-based deadlines (for example, deadlines based on order amounts or a customer’s premium status) and the integration of a business cal-endar (for example, to compute the number of calendar days that correspond to three working days). One or more escalations, with associated conditions, can be associated with a deadline. An escalation is triggered if the point of time specified as a deadline has been reached or the duration has elapsed, and the associated condition evaluates to true. Escalations can use notifications to inform people of the status of the task or reassign the task to different users or groups. Deadlines and escalations are illustrated in Figure 2.

Task Lifecycle To understand these task concepts as a complete picture, it helps to visualize the various task states and transitions. Figure 3 shows a simplified view of a task’s lifecycle. All tasks start in the Created state. A task remains in the Created state until it is activated (if scheduled activation is used) and has potential owners. If there are no potential owners, the task remains in the Created state until the business owner has performed nomi-nation. Once activated, a task moves into the Ready state if it has multi-ple potential owners (for example, when it is assigned to a group or a queue) or into the Reserved state if there is only a single potential owner. Tasks in the Ready state move into the Reserved state when one of the potential owners claims it. Once the actual owner starts working on the task, it transitions into the In Progress state. Upon successful completion, it transi-tions into the Completed state. A task in the Reserved or In Progress state can be released by the owners, moving it back to the Ready state, where it waits for an-other potential owner to claim it. A task in the In Progress state can be stopped by the owner, which moves it back into the Reserved state. Tasks in an active state — Ready, Reserved, or In Progress — can also be delegated and forwarded by actual owners, potential own-ers, and business administrators. This transitions the task to the Ready or Reserved state, as appropriate. Business data associated with the task is maintained, including any updates. The BPEL4People specifications allow some tasks to be skipped. A task, if skipped, moves into the Obsolete end state. Tasks can also be terminated, usually by the surrounding business process; terminated tasks also move to the Obsolete state. The BPEL4People specifications also allow any active task to be suspended and resumed. Suspended tasks resume to the state in which they were suspended.

Task Presentation and User Interaction While the presentation of tasks via a client application or other mechanisms such as e-mail is outside the scope of the

Figure 1 BPEL4People logical architecture

Figure 2 Deadlines and escalations

Figure 3 WS-HumanTask task lifecycle


BPEL

BPEL4People specifications, the specifications do include enough definition that enables a standard interface for task presentation. Presentation elements in a task define how information about tasks is made available in a human-readable way. They include a name (a short title of a task), a subject (a longer text describing the task, and a description (a long description of the task, which can be in HTML). Both the subject and the description can be param-eterized. Values for the presentation elements can be specified for multiple languages. Listing 1 illustrates the concept of presentation elements with an example. A task definition can include rendering elements, which provide an extensible mechanism for specifying UI renderings for tasks. The BPEL4People specifications also support attachments and comments, which are stored in the task operation data along with information on when they were added and by whom. Attachments and comments can also be shared between tasks and enclosing BPEL processes, as well as between different tasks. The BPEL4People specifications also define standard pro-gramming interfaces that a task list client application can use to work against any WS-HumanTask–compliant implementa-tion.

An Example: Help Desk Listings 2 and 3 illustrate the concepts discussed in this article using a help desk scenario. (Listing 3 can be downloaded from this article online at http://soa.sys-con.com.) The Help Desk BPEL pro-cess invokes three human activities: Resolve Ticket (task), Approve Resolution (task), and Notify User (notification). The use of logical personnel groups to perform skill-based as-signments is illustrated in Resolve Ticket task, which also illustrates the concept of potential owners (all service agents with matching skills) and business owner (the service center manager). The 4-eyes principle is illustrated in the invocation of the Approve Resolution task in which we exclude the performer of the Resolve Ticket from potential owners. The Resolve Ticket task also illustrates the use of deadlines and presentation elements.

What’s Next People often ask whether the BPEL4People specifications will cause changes to the BPEL specification itself. We do not anticipate such an impact. BPEL was designed with extensibility in mind, and the BPEL4People specifications comply with BPEL’s extensibility mechanisms. According to the OASIS BPEL4People Technical Committee charter, the standardization should take about 18 months. During this period, it’s reasonable to expect that the standard will not only become more rigorous but also include more functionality. Two enhancements that we hope will make it to the final standard are patterns and policies. We’d like to see support for common routing patterns (such as management chain approvals and group votes) in a simple, intuitive, and declarative fashion. Likewise, support for policies such as automatic skip and exception handling would be a welcome addition. While it’s reasonable to expect that meaningful implementa-tions of BPEL4People will be available only when the specification approaches the finish line, there are vendors, including Oracle, that essentially implement very similar concepts in a very similar architecture. In fact, the BPEL4People specifications were created by leveraging customer scenarios and requirements learned from support of such implementations.

Also, within the broader umbrella of related standards in the business process management (BPM) area, the next frontier is standardization of notation and its alignment with BPEL and BPEL4People. Significant efforts are underway at the Object Man-agement Group to define a Business Process Modeling Notation (BPMN) 2.0 specification.

Summary The field of Business Process Management (BPM) is experiencing renewed effort, propelled by the success of BPEL as a standard and its adoption by mainstream vendors and enterprises. BPEL skills, training, and resources are now widely available and the move away from proprietary skills and technologies is driving a lower total cost of ownership (TCO). The BPEL4People specifications address BPEL’s lack of explicit support for human interactions and remove one of the very few objections to BPEL. The BPEL4People architecture, which separates the task engine from the process engine, also signifi-cantly reduces customer risk, because many customers can have multiple process engines but prefer to have a unified task list application. BPEL4People, along with BPMN, will complete the BPEL story for process management. We believe it will significantly increase the market adoption of BPM by mainstream enterprises.

References• WS-BPEL Extension for People, Version 1.0. http://xml.coverp-

ages.org/BPEL4People-V1-200706.pdf.

• Web Services Human Task (WS-HumanTask), Version 1.0. http://xml.coverpages.org/WS-HumanTask-V1-200706.pdf.

• OASIS WS-BPEL Extension for People (BPEL4People) Techni-cal Committee. http://www.oasis-open.org/committees/bpel4people/charter.php.

• InfoQ Interviews BPEL4People Representatives. http://www.infoq.com/articles/bpel4people-tc.

• A Close Look at BPEL 2.0. http://www.sys-con.com/read/434430.htm.

• BPEL’s Growing Up. http://websphere.sys-con.com/read/346372.htm.

• BPEL Processes and Human Workflow. http://webservices.sys-con.com/read/204417.htm.

About the AuthorsManoj Das is director of BPM product management at Oracle. His focus is on BPMN, BPEL, hu-

man workflow, and business rules. He is one of the co-authors of the BPEL4People specifica-

tions published in June 2007. Manoj joined Oracle with the Siebel acquisition, where he was

responsible for driving the next-generation process-centric application platform, leveraging

BPMN and BPEL.

Bhagat Nainani is a senior development director in the Oracle Fusion Middleware division.

He currently leads the development of BPM and human workflow features. He has more than

14 years experience with BPM, application integration technologies, distributed systems, and

databases.

Listing 1... <htd:task name=”ResolveTicketTask”> ...  <htd:presentationElements>  <htd:name xml:lang=”en-US”> Resolve Trouble Ticket </htd:name> <htd:name xml:lang=”de-DE”> Behebung der Problemmeldung </htd:name>

<htd:presentationParameters> <htd:presentationParameter name=”product “ type=”xsd:string”> htd:getInput(“serviceRequest”)/product </htd:presentationParameter> <htd:presentationParameter name=”user” type=”xsd:string”> htd:getInput(“serviceRequest”)/user </htd:presentationParameter> <htd:presentationParameter name=”issueAbstract” type=”xsd:string”> htd:getInput(“serviceRequest”)/issue/abstract </htd:presentationParameter> <htd:presentationParameter name=”issueDetails” type=”xsd:string”> htd:getInput(“serviceRequest”)/issue/details </htd:presentationParameter></htd:presentationParameters>

 <htd:subject xml:lang=”en-US”> Resolve problem with $product for $user </htd:subject> <htd:subject xml:lang=”de-DE”> Behebung des Problems von Produkt $product für $user </htd:subject>

<htd:description xml:lang=”en-US” contentType=”text/plain”> User $user is having following problem with product $product Abstract: $issueAbstract Details: $issueDetails </htd:description>

<htd:description xml:lang=”en-US” contentType=”text/html”> <p> <b>User</b> : $user <br> <b>Product</b>: $product </p> <h1>Abstract</h1> <p>$issueAbstract</p> <h1>Details</h1> <p>$issueDetails</p> </htd:description>

<htd:description xml:lang=”de-DE” contentType=”text/plain”> Der Benutzer $user hat das folgende Problem mit dem Produkt $product

Kurzbeschreibung: $issueAbstract Nähere Angaben: $issueDetails </htd:description>

<htd:description xml:lang=”de-DE” contentType=”text/html”> <p> <b>Benutzer</b> : $user <br> <b>Produkt</b>: $product </p> <h1>Kurzbeschreibung</h1> <p>$issueAbstract</p> <h1>Nähere Angaben</h1> <p>$issueDetails</p> </htd:description> </htd:presentationElements>

... </htd:task> ...

Listing 2<process name=”HelpDesk” ... xmlns:b4p=”http://www.example.org/BPEL4People” xmlns:htd=”http://www.example.org/WS-HT”> ...  <extensions> <extension namespace=http://www.example.org/BPEL4People mustUnderstand=”yes”/>

<extension namespace=http://www.example.org/WS-HT mustUnderstand=”yes”/> </extensions> ... <b4p:humanInteractions> <htd:logicalPeopleGroups>  <htd:logicalPeopleGroup name=”ServiceAgents”> <htd:documentation xml:lang=”en-US”> Group of service agents for a region able to support a product. </htd:documentation> <htd:parameter name=”region” type=”xsd:string” /> <htd:parameter name=”product” type=”xsd:string” /> </htd:logicalPeopleGroup> ... </b4p:humanInteractions> ... <sequence> ...  <extensionActivity> <b4p:peopleActivity name=”ResolveTicket” inputVariable=”serviceRequest” outputVariable=”serviceResolution” ...>

<!—use Task Resolve Ticket Task --> <b4p:localTask reference=”tns:ResolveTicketTask”/> <htd:peopleAssignments>  <htd:potentialOwners> <htd:from logicalPeopleGroup=”ServiceAgents”> <htd:argument name=”region”> $serviceRequest/region </htd:argument> <htd:argu-ment name=”product”> $serviceRequest/product </htd:argument> </htd:from> </htd:potentialOwners> </htd:peopleAssignments> </b4p:localTask> </b4p:peopleActivity> </extensionActivity> ...

 <extensionActivity> <b4p:peopleActivity name=”ReviewResolution” ...> <b4p:localTask reference=”tns:ReviewReso-lutionTask”> <htd:peopleAssignments>   <htd:excludedOwners> <htd:from>b4p:getActualOwner(“tns:ResolveTicket”)</htd:from> </htd:exccludedOwners> </htd:peopleAssignments> </b4p:localTask> </b4p:peopleActivity>  <extensionActivity> <b4p:peopleActivity name=”NotifyUser” ...> <b4p:localNotification reference=”tns:ResolutionNotification”> <htd:peopleAssignments> <!—Send notification to user submitting Help Desk ticket --> <htd:recipients> <bpel:from>$serviceRequest/user </bpel:from> </htd:recipients> </htd:peopleAssignments> </b4p:localNotification > </b4p:peopleActivity> ...</process>


Getting a Handle on SOA RiskGovernance is the process of risk management

planning whereby ideas for new projects are evaluated and pri-oritized. Budgetary estimates are prepared, outlining the antici-pated project cost and time to complete. Finally, these proposals are compared against the available budget, and a certain number of projects are funded. Depending on the organization and how budgets are allocated, this may be a singular centralized activity or a series of planning activities, one for each IT organization holding a development budget. To be successful with services, you have to extend this planning activity a bit. Recognizing that you won’t get an ROI from the fi rst use of a service, it is prudent to think about the portfolio of projects in terms of which ones will create services and which ones will be consumers of services. This obviously creates dependencies between projects, impacting the sequence in which the projects will be executed. It may also infl uence your thinking about project priorities. If a major project requires a service that does not yet exist, for example, the creation of that service must become part of the portfolio plan, whether it is in that project or another. There is a measure of speculation in this exercise — about what is important to the business, about what the project cost and schedule will be, and about what services will be created and used. Because of this, expect that reality will render some of these specu-lations inaccurate and alter priorities. The typical project portfolio planning process has an annual cycle that is synchronized with the fi scal calendar of the enterprise. At a minimum, you need to integrate services planning into this annual process. You also need to add an activity for developing a cross-proj-ect services plan, and a governance step for reviewing this plan before the project portfolio is fi nalized. Besdies this annual exercise, it is pru-dent to add a quarterly or semi-annual checkpoint. This governance step compares the actual project progress against the plan, as well as cost and schedule progress, and determines whether adjustments to the project portfolio are warranted.

2. Service Design Governance Deciding to build a service is an investment decision, and should be treated as such. Implementing functionality as a service always requires more work than a basic implementation of the function-ality. The service, by itself, provides no value. Its value lies in its use, and its return on investment relies on its continued use in the light of business process and systems changes. So the decision to build a service requires weighing the savings to be derived through continued use (i.e., avoiding subsequent modifi cations) against the incremental cost of converting the functionality into a service.

Service Justifi cation and Specifi cation Justifying a service means making a determination that the ad-ditional cost involved in implementing functionality as a service is justifi ed by anticipated future cost avoidance. Specifying a service means defi ning it so that it will support antici-pated future use without further modifi cation. Accomplishing this requires a due diligence analysis of these anticipated usages — a bit of “crystal ball” gazing. While some projects may be chartered exclusively to build new services, most arise during the course of ordinary development initiatives when the project team recognizes that a particular set of functionality might make sense as a service. The problem that these project teams generally face is that the only use of the proposed service that they are intimately familiar with is the one associated with the present project. This narrow perspective presents a prob-

lem. To determine whether a service makes sense, other potential uses need to be examined. Who has the proper perspective to do this exploration? The answer should be the most experienced architects in your organization — people who know the landscape of the enterprise and can determine whether the service will fi t. These are the senior systems architects for infrastructure services, and the senior busi-ness process architects for business services. Most of the time these people are not actively involved in the current project, so you need a procedure to get them involved and to make their response to the request a priority. For effi ciency, the involvement of senior architects should be structured into two distinct tasks: justifi cation and specifi cation. Justifi cation should focus on weeding out the proposals that don’t make sense as services. When justifi cation concludes that a service does make sense, a deeper exploration of these uses is required so that the service and its operations can be fully specifi ed. Once the architects have completed the specifi cation then responsibility for the implementation of the service can revert back to the project team. Specifi cally, governance of service justifi cation and specifi ca-tion requires:

1. A procedure to get the appropriate senior architects involved in evaluating and specifying proposed services.

2. Prioritization of senior architects’ time to ensure responses to evaluation and specifi cation requests in a timely manner.

3. Well-defi ned criteria for evaluating service proposals and specify-ing services.

4. A checklist item in the project’s architecture review to ensure that proposed new services have been appropriately justifi ed.

Service Architecture, Implementation, and DeploymentBecause the operation of other application components depends on the proper operation of services, more stability is expected from services in terms of functionality, performance, and reliability. These expectations increase demand for service implementation governance in two areas: architecture and testing. With a service architecture, performance and capacity require particularly close attention. The obvious aspect of this is ensuring that the design is capable of providing the specifi ed performance when loaded to its planned capacity. Not as obvious is the need to design the ability to measure into the service and to report the actual demands that are being put on it while it is in use. These measurements will enable you to determine when the demands being put on the service are begin-ning to approach the design limits and additional capacity is needed. Another challenge to service architecture is scalability. The an-ticipated future use of the service may call for capacity well beyond the initial demand — so far beyond that it is not cost-effective to deploy full service capacity initially. In such cases, it is prudent to design the service in such a way that capacity can be incrementally added as new service users come on line. Documentation must be provided describing how capacity can be incrementally added, including instructions for calculating the resources required to sup-port different demand levels. Finally, thorough testing of the service prior to its integration into the overall SOA — although sometimes tedious and time-consuming — will cost less than discovering and fi xing problems after integration.

Service Documentation Because services should be designed to support future use, an

GOVERNANCE

BY PAUL C. BROWN

Services have a lot of potential for providing value to the enterprise, but their use also brings a level of risk. Some of these risks

are fi nancial, while others are operational. Fortunately, all of this risk can be satisfactorily mitigated through appropriate gover-

nance activities.

Simply put, governance is the process of risk management. Without proper governance, services may be built that are missing the basic functionality required, that only satisfy

one use (a waste of the cost and resources involved in creating a service), or that require costly modifi cations to be reused. Even when services are well-designed and appropriate for a variety of applications, they may not be reused simply because the chain of communication breaks down — the advertising of available services is inadequate, or the indexing and documentation associ-ated with them is insuffi cient to support effective identifi cation and deployment. Finally, changing business circumstances are also a risk factor, since they can end up changing the requirements for a particular service.

The important thing to remember is that the governance processes you put in place must not only determine the points at which you will assess risk, but confi rm that the appropriate risk management strategies have been employed. But before you can defi ne the governance, you have to defi ne the process that is being governed. The actual processes used will vary greatly from enterprise to enterprise, driven by both cultural and organizational differences. Despite these variations, successful SOA processes all share some common features and governance points at which SOA risks are evaluated and mitigated.

1. Project Portfolio Planning Governance Most enterprises already have some form of project portfolio


GOVERNANCE

One of the things covered in the recent Burton report was an instance where a new CIO was needed to get SOA going. In essence, the culture needed

to change in order to accommodate the changes required to get a SOA rolling, and thus they changed out their CIO to change the culture. If you think about that, it makes perfect sense. The existing people and processes are typically

the largest hindrance to building a SOA, thus you need to address those issues before SOA will be successful. Typically, changing people and processes means changing leadership, thus changing the CIO is often the first logical step toward accomplishing those goals. The reality is that CIOs are very different animals from company to company. In many instances, I’ve found they do not have techni-cal backgrounds, but come instead from the finance or operations side of the house. I’ve even found instances where CIO meant “ca-reer is over” and it was a holding position for executives who were about to retire or be outplaced. However, I’ve also found many who are masters around the business processes within their enterprise and they know their way around the politics, which are typically a part of any large company. However, in many organizations the role of CIO has resolved itself as the person who keeps things running, not the agent of change. Indeed, when I speak with CIOs they typically tell me about uptime statistics and productivity metrics, and almost never how systemic improvements in the architecture will add value to the core business. If you look at the way their performance is measured and compensated, you can understand why they have this kind of behavior. Personally, I’ve been offered the role of CIO many times over

the last 20 years within large organi-zations. I balked at the opportunities when I found out that the roles came with no real power, thus no real ability to drive change. As one executive put it: “Dave, all you need to

do is keep your head down for 20 years.” I passed. When considering SOA, the role of the CIO is even more impor-tant. Someone needs to focus on the business processes and the culture, and good CIOs should be masters at those tasks. Indeed, their ability to do that leads to SOA success, according to Burton. However, most CIOs either can’t or won’t step up and make those changes in order to clear the way for SOA, thus SOA dies on the vine. If you’re in this state, perhaps it’s time to look for a new CIO: an executive that can be an agent of change and put a plan in place to improve the business going forward. Moreover, someone who can change the culture from a “won’t work,” or “not in my depart-ment,” to a “can do,” and “will do.” Thus they provide a clear path for change, or clear the way for fundamental architectural changes that will be painful and disruptive, but will drive much more value from the IT infrastructure. There are proven metrics and methods around the value this change can drive. The trouble comes with pulling the trigger on a change. You must have leaders within the company who are innovative about sys-temic business improvements, and make the tough calls in terms of who will drive that change. CIOs play a critical role when considering any change in IT, especially holistic changes required when doing SOA. If they can’t drive change, then perhaps you should change your CIO. Or, per-haps they are not empowered, not just for SOA, but for the future health of your IT infrastructure. Either way, change is often the best remedy.

About the Author

David S. Linthicum is an internationally known thought leader in the EAI, SOA, enterprise

architecture, and Web 2.0 spaces. He is a sought-after consultant, speaker, and writer, and

formed David S. Linthicum, LLC (www.davidlinthicum.com), a leading consulting organization

focusing on enterprise architecture, SOA, and use of the next-generation Web within the en-

terprise. He is the former CEO of BRIDGEWERX, CTO of Grand Central Networks, as well as CTO

of Mercator Software (now a part of IBM) and SAGA software (now a part of Software AG).In

addition, Dave was an associate professor of computer science for eight years, and continues

to lecture at major technical colleges and universities, including University of Virginia and

Arizona State University. He keynotes at many leading technology conferences, and has sev-

eral well-read columns and blogs, as well as a weekly Podcast. Dave has authored 10 books,

including the ground-breaking “Enterprise Application Integration” and “B2B Application

Integration.” You can reach Dave at [email protected].

[email protected]

investment must be made in providing enough information to support those future uses, and in putting that information in the appropriate places. The required information must span an entire spectrum of inquiry, from a simple “What is it?” to a detailed “Is it capable of performing the xyz operation at a rate of 273 transac-tions/second with a 0.5 second response time on a 24×7 basis with 99.9% availability?” At a minimum, documenting a service requires:

• A one-line functional description of the service. • A one-paragraph abstract of the service outlining its intended

purpose and important constraints. • A comprehensive description of the service, containing the

full specifications, explanatory material that characterizes the intended use of the service, examples, and instructions on how to prepare an application for using it.

• A formal specification of the service interfaces. If you are using SOAP, this is the WSDL description of the service.

Your enterprise will likely develop its own repositories for ser-vice-related information, and some (or all) of it may end up in a UDDI registry. But documentation, by itself, has no value unless people are able to find and use it efficiently. Whatever your strategy for disseminating information about your services, you must ensure that the documentation for each service finds its way into your service advertising, repositories, registries, and indexes. Thus, governance of service documentation requires:

1. A work thread in the implementation project to generate the required documentation.

2. A checklist item in the pre-deployment review to ensure that the required documentation has been created and deployed in the appropriate registries and repositories and has been indexed ap-propriately.

3. Service Utilization Governance As has been discussed, the existence of a service does not, in and of itself, provide any value. It is the use of the service that provides value, and the second and subsequent uses that provide the return on the services investment. The most convenient way to ensure service utilization is to integrate its governance with the normal project governance. As a result, there are two key places in the proj-ect lifecycle at which service utilization should be considered: the architecture review and the pre-deployment review.

The architecture review should determine whether services are being used appropriately, with reviewers (business process and system architects) considering whether new services have been justified and specified, as well as whether there is other functional-ity that ought to be evaluated as a potential service. The pre-deployment review for the project is the appropriate time to determine whether proper planning has been done for utilizing existing services. Has the organization responsible for each service been engaged to determine whether the service has the capacity required to support the intended utilization? Are there plans in place for granting access to the production version of the service and establishing access rights? In each instance, a checklist step in the project’s architecture review and pre-deployment review are essential to ensure proper governance.

4. Service Operational Governance Services typically require operational support after their deploy-ment, across three broad areas: performance monitoring, new usage planning, and upgrade planning. First, service monitoring is required to ensure proper operation — an important consideration given that many other components will be dependent on the service. Service performance must be measured to ensure that the service is meeting its service-level agreements. Service utilization levels must also be measured and compared against current deployed capacity. When demand begins to approach these limits, additional system resources will have to be deployed. This comparison must project far enough into the future to account for the time it will take to acquire the additional resources needed to increase capacity. Another operational responsibility is new usage governance, which covers activities that are required when new projects want to use existing services. These include: ensuring that the new use is appropri-ate for the service; capacity planning associated with the increased demand that will result; and managing the actual access to the service. Finally, the third operational governance responsibility is careful planning and coordination of service outages and upgrades (espe-cially since a service outage will impact all service clients) as well as the deployment of new versions.

Summary When it comes to SOA, the biggest financial and operational risks revolve around getting services used. It always costs more to build a service than to implement the functionality in a conventional manner. This additional cost is recovered by avoiding subsequent development use either through reuse of the service or the isolation of service clients from internal service implementation changes. But you won’t get the ROI you want unless the service interface represents a point of stability in the overall enterprise architecture — a result that requires a systematic, process-oriented approach to governance across project portfolio planning, as well as service design, utilization, and operation.

About the AuthorDr. Paul C. Brown is principal software architect at TIBCO Software. His model-based tool

architectures underlie applications ranging from process control interfaces to NASA satellite

mission planning. This article is an excerpt from a chapter in his book, Succeeding with SOA,

published by Addison-Wesley in 2007. A second volume of the book, Implementing SOA,

became available in May 2008.

Balancing Education and Enforcement in Governance Governance generally employs two techniques: education and en-forcement. The point of education is to ensure that things are done right the first time. The point of enforcement is to catch mistakes before they become serious. There is a tendency in services governance to rely too heavily on enforcement. For example, an architecture review can certainly catch a mistake in either the design or use of services, but by that point signifi-cant investment has already been made. Plus, fixing design mistakes still takes time and resources. For SOA efforts to be successful your enterprise-specific vision of SOA and best practices for achieving that vision must be captured and shared. This is where education comes in, but it does require investment. How to “do it right” has to be defined and documented by the SOA leadership team, and this knowledge must be transferred to the proj-ect design team through some combination of formal training, mentoring, and reading.

Should You Fire Your CIO?BY DAVID S. LINTHICUM

GOVERNANCE


INFRASTRUCTURE

dure over which you have immediate control. It might also be a Web service provided by a partner or vendor over which you do not have any control. The BPEL processes are run within a runtime environment called a BPEL server or engine. The availability and service level associ-ated with BPEL processes are completely dependent on the BPEL engine. BPEL engines can run within an application server envi-ronment. You can have a single instance or a clustered application server environment if your composite application requires high availability. A BPEL server may depend on some of the resources, such as data sources or messaging services, made available by the application server environment. BPEL processes are long-running, and hence they need a persistent store to persist state. Typically the persistence store is a relational database management system. This persistence store is called a dehydration store. All of these software components run on several nodes, or hosts, that constitute the critical piece of your BPEL ecosystem.

To summarize, a BPEL ecosystem comprises the following: • BPEL Processes and partner links• BPEL engine

• Dehydration store • Gateway to BPEL engine• The application server on which the BPEL server is running• Hosts on which the BPEL server, the dehydration store, and the

gateway are running

The health of a BPEL process that you manage is a function of any of the entities that constitute the BPEL ecosystem, and you need to concern yourself with managing and monitoring all of these entities. Let’s dive down into the management functions for each com-ponent and what approaches you should follow to manage them, starting with the management aspects of BPEL processes.

BPEL Runtime GovernanceBPEL Suitcase Deployment As an administrator, you are responsible for deploying BPEL pro-cesses to a single server or multiple servers. Think about transition-ing a BPEL process from test to production or deploying the process to additional BPEL engines to add scalability and availability to your system. Typically BPEL processes are packaged in an archive known as a BPEL suitcase, which contains a .bpel file, WSDL for partner links, and classes and schemas required by the BPEL process. If you are using an SCA-compliant composite application, it may contain a BPEL module. As an administrator, you may be deploying the BPEL suitcase to more than one BPEL engine. You may want to deploy BPEL processes during off-peak times, so you want to automate the deployment procedure. To automate deployment of BPEL processes, you can build scripts by using tools provided by your BPEL server vendors. If you are using a management tool, it may provide support for uploading the BPEL suitcases to the software library and then enable you to

Service-oriented architecture (SOA) has become main-stream technology for integrating disparate systems and applications. For building composite applications, Busi-ness Process Execution Language (BPEL) has emerged as

the standard for business process flow orchestration and appli-cation integration within organizations. Many IT organizations are deploying composite applications that use BPEL to automate critical business processes. If your application needs to be avail-able 24/7, you need a reliable BPEL infrastructure. In this article, we first present a typical BPEL engine architecture and then outline its manageable entities, and the typical management functions you need to worry about as an administrator. Finally, we conclude with approaches and best practices for managing your complete BPEL infrastructure. To effectively manage BPEL infrastructure, administrators need to manage all the components that make up the BPEL ecosystem.

Before diving into management functions you need to concern yourself with as an administrator, let us briefly look at the BPEL ecosystem.

The BPEL Ecosystem By BPEL ecosystem, we mean the system components and resources used for execution of the BPEL process and those that ensure guaranteed availability of the BPEL process. Although some of those systems may not be directly under your control, you need to take some action to monitor their availability. Unequivocally, if one or more of these components go down, it will put the business process execution at risk. Figure 1: depicts the architecture of a typical BPEL engine. A BPEL process typically depends on one or more partner links. A partner link might be a service owned by the organization, such as an EJB running an application server or a database stored proce-

Managing Your BPEL Infrastructure

BY DEBU PANDA AND ARVIND MAHESHWARI

You need the right tools and methodology

Figure 1: Typical architecture of a BPEL engine


deploy them as needed. Figure 2 outlines the deployment of BPEL suitcases from a software library. If your BPEL processes depend on resources such as adapters, it makes sense for you to automate the deployment and configuration of those if you want to avoid any manual errors.

Manage Versioning of BPEL Processes In a dynamic environment, BPEL processes may change, depending on business needs. You need to implement a method of storing different versions of BPEL that have previously been deployed to the BPEL engine. This will help you track changes between different versions and backtrack any changes, should you run into issues. You may need to compare different versions of processes within one BPEL server or across BPEL servers. Manage-ment tools may provide the ability to store/retrieve and compare versions of a process and dependent artifacts such as WSDL and XML schema that helps in quick resolution of issues. The software library will allow you to rollback to a previous version of the BPEL process, should the need arise.

Monitor BPEL Process and Partner Links Monitoring the health of BPEL processes is critical to meeting service-level agreements for your processes. You can probably ensure availability and meet service-level requirements by ensur-ing performance and functioning of the partner links your BPEL processes depend on and identifying problems in a proactive manner. You can develop some SOAP tests to verify the availability and performance of partner links. You can either use a SOAP testing tool provided by a vendor or use an open source web service testing tool such as soapUI (http://soapUI.org). The correct approach is to automate tests to be performed at regular intervals. You want to be alerted when a particular partner link has an unscheduled service shutdown or a longer-than-expected response time. If you are using a management tool to manage your BPEL infrastructure, check whether it provides such a capability.

SOAP Test Example The Elevation Query Web Service returns the elevation in feet or meters for a specific latitude/longitude (WGS 1984) point from the USGS Seamless Elevation datasets hosted at http://eros.usgs.gov.

WSDL: http://gisdata.usgs.gov/XmlWebServices/TNM_Elevation_service.asmx?WSDL

OperationgetElevation Input Parameter X: 45.890610 Input Parameter Y: 7.157390 other parameters: left empty

Output Parameter: elevation of latitude/longitude provided.

You can monitor this Web service by executing a SOAP test at a regular interval through automated tests. These SOAP tests monitor availability and perceived performance of the Web service. Figure 3 depicts automating testing of Web services.

Monitoring BPEL Processes from the End-User Perspective Your BPEL process may be accessed from different locations,

INFRASTRUCTURE

Figure 2: Automating BPEL deployment procedure

and you want to monitor the availability and performance from those locations. Say you are part of a global organization and users in North America, Europe, and Asia access your BPEL processes. Although it is challenging to monitor the performance of BPEL processes from the end-user perspective, you can create an agent at the customer locations to test the performance from their end. However, manually performing these types of tasks from a BPEL process that is accessed from multiple customer sites could be challenging. Hence, you can use the help of management tools to monitor the performance of your BPEL applications from the end-user perspective as depicted in Figure 3.

Error/Fault Monitoring A BPEL process may raise errors and faults for several reasons, including data exceptions or non-availability of partner links, al-though you need to limit the number of faults in BPEL processes by proactively monitoring the processes, as we described earlier. You need to drill down into the processes that have raised faults, and you should be able to diagnose the cause of the faults and make sure that this does not happen again. You may want to monitor the processes that failed and help diagnose issues by using tools provided by your BPEL vendor and take corrective action as ap-propriate. It will also help if you implement some methodology to monitor SOAP messages sent to and received by the BPEL process and the partner links.

Gateway to BPEL Engines BPEL process instances are created when invoked by a client and the traffic is routed through Web servers and load balancers. You want to be alerted when these Web servers or load balancers are not available or not meeting the expected performance goals.

Managing the BPEL Engine The BPEL engine is by far the most important part of the BPEL ecosystem. You have to monitor the availability and performance of BPEL engines and need to be alerted when a BPEL engine is not performing as expected. You may have multiple instances of clustered BPEL engines. Hence, you need to know if any one of the engines is not performing or whether the load balancer is working properly. More importantly you want to find out proactively when all the engines are not performing because it will lead to total dis-ruption of service.

Configuration Management and Versioning You may change the configuration of your BPEL engines from time to time. You may want to track any interim changes and may want to backtrack changes to a previous version. If you follow ITIL practices, this should sound familiar. You can store the configura-tion of a BPEL engine in a configuration management database (CMDB) or version control system. It can make your life easier to have your management tool provide integration with the CMDB in which you store your configuration. Keeping a gold image of your BPEL ecosystem configuration and using it to compare with your current configuration will help in identifying issues attributable to configuration changes. Also, keep-ing track of components added to and/or removed from your BPEL system will help in analyzing performance issues—for example, performance was bad during the first week of January but improved afterward, because there was one extra BPEL engine in the cluster after the first week of January. By comparing the current configura-

tion with the gold image, you can monitor changes in some param-eters that can have a big impact on BPEL instance throughput, such as dispatcher thread min/max parameters.

BPEL Engine Monitoring The health of the BPEL engine is critical for your applications. Besides the status of the BPEL engine, there are some statistics you should focus on. They include system statistics such as memory; CPU consumed; and business metrics such as open and closed in-stances, synchronous and asynchronous process latency, and load factors. In the event of abnormal behavior such as high process latency or load factors, you have to proactively resolve the issues before they affect BPEL processes deployed in the engine.As an administrator for your BPEL engine, you have to perform some of the following operations:• Archive information about completed BPEL processes • Remove from the database all XML messages that have been suc-

cessfully delivered and resolved • Purge stale instances • Re-execute failed processes

Ideally, these mundane takes should be automated in a pro-duction environment. You can build some automated scripts to perform these operations and schedule them to be performed at regular intervals. Many management tools help you with automa-tion by providing a graphical user interface.

Dehydration Store The BPEL engine stores process data in the dehydration store. This is a critical piece of the puzzle. As we discussed earlier, the dehydration store is typically a relational database. If you want high availability for your dehydration store, you will probably use a clustered database. Your database administrators should make sure that the database is available and performing properly.

Monitoring Adapters Your BPEL processes may depend on adapters that access resources such as databases, messaging services, and EIS that may reside locally or remotely. The status and performance of adapters may have a heavy impact on the response time of your BPEL engine and processes.

Managing the Application Server A typical BPEL engine runs in an application server environment. For example, Oracle BPEL Process Manager can be deployed on a J2EE-compliant application server such as Oracle Application Serv-er, Oracle WebLogic, IBM Websphere, or JBoss Application Server. The BPEL engine may depend on several resources and services provided by the application server, such as JDBC DataSource, JMS providers, JCA connectors, and shared libraries. The health of the application server, along with the performance of these resources, may directly influence the performance of your BPEL engine. Each application server provides several health indicator metrics. You should automate a mechanism that would proactively issue an alert before anything goes wrong with your application server.

Managing the Hosts/Nodes Your BPEL infrastructure may be running on several nodes or machines. These server nodes may run into several resource issues during runtime. For example, they may run out of disk space due to

Figure 3: Automated testing of partner links and BPEL processes

Figure 4: Oracle Enterprise Manager Grid Control


INFRASTRUCTURE

excessive logging or run out of memory or CPU due to a spinning process. You need to proactively monitor these metrics and fix any issues before they become a problem for your infrastructure.

Bringing It All Together It is now clear that the BPEL infrastructure includes a lot of enti-ties. Monitoring these as independent entities could be a challenge. A typical SOA environment will have hundreds of artifacts like Web services, BPEL processes, EJBs, adapters, and other resources. Monitoring a flat list of these artifacts is not productive. The depen-dency between these components and the impact of any changes you make is critical to determine. Distributed ownership of these components also requires that service level agreement be estab-lished between providers and consumers of these components. These issues are addressed with a runtime governance offering. Thus it is important to employ a management tool that provides:

• Translation of design-time discovery into production, to help manage all the components and their dependencies in context;

• SLA capabilities to capture and measure SL compliance of your SOA application and SOA components.

Think about a complicated BPEL process that uses several hetero-geneous systems and applications. Say you are using Oracle’s BPEL engine on an Oracle WebLogic server running on a Linux box. Your business processes involve partner links that depend on adapters that connect to IBM MQ Series applications and applications from Oracle’s PeopleSoft Human Resources product family that run IBM WebSphere. Your BPEL engine uses an Oracle Real Application Clusters Database as the dehydration store. You want to monitor all these products together from a single management console. There are several management products on the market that may meet your needs. Figure 4 shows how you can manage the Oracle BPEL engine running on an Oracle Web-Logic server from Oracle Enterprise Manager Grid Control 10g. An integrated management solution lets IT administrators man-age complexity within a BPEL and SOA environment. Without this management solution, IT will see an increase in incidents, lower service levels, and increased end user frustration. Moreover as IT scales out with a new BPEL infrastructure, new personnel will be re-quired to manage this complex distributed architecture. Addition-ally, a move from legacy to a SOA architecture can increase costs without a management strategy and toolset. You should consider investing in the right management product that makes sense for your infrastructure. Another compelling reason why you should consider a manage-ment tool is for alignment between IT and your business. As an IT administrator, you need to monitor and report issues in terms of business processes. You should have monitoring statistics aligned with business processes. To accomplish this you need have a view of business process flows that should be synced up with actual

flows in the BPEL server. BPEL Management tools provide you a view of business processes and reports monitoring statistics for each business process.

Best Practices Here are some of the best practices you can follow to ensure the availability of your BPEL infrastructure:

• Establish service level objectives for your BPEL processes and partner links;

• Keep a library of BPEL suitcases in your software library. It will help in rebuilding a system in case of server failure;

• Automate routine operations such as purging of old process instances;

• Monitor the performance of partner links;• Monitor the whole BPEL ecosystem, not just the BPEL engine;• Keep track of BPEL ecosystem membership/topology changes;• Keep a gold image of your configuration when everything is

stable and keep updating it after every configuration change. This will help you find the cause of any possible problem due to configuration changes;

• Monitor BPEL-server-specific J2EE artifacts such as the JMS queues and data sources used by the BPEL server in addition to J2EE constructs used by BPEL processes;

• Make sure that you select a management solution that can maxi-mize your productivity and help you deliver maximum service through automation.

Conclusion With SOA, managing the complete infrastructure—involving lots of heterogeneous components and products—has become challenging. For IT administrators, managing the service-level agreements for composite applications can be a monumental task. Using the right tools and methodology, to make sure your BPEL infrastructure is highly available, can make your job much easier.

About the Authors

Debu Panda, lead author of book EJB 3 in Action (http://manning.com/panda/), is a senior

principal product manager on the Oracle’s System Management Products development team,

where he drives development of the Oracle Fusion Middleware Control. He has more than 16

years of experience in the IT industry and has published numerous articles on enterprise Java

technologies and SOA and has presented at many conferences. Debu maintains an active blog

on enterprise Java at http://www.debupanda.com <http://www.debupanda.com/>. Also See

http://java.sys-con.com/author/debupanda.htm

Arvind Maheshwari is a Senior Software Development Manager for Oracle Enterprise Manager

development team; he is focused on building management solution for middleware. He has

14 years of experience in IT industry. He has played role of developer, consultant, architect,

manager in financial, manufacturing, telecom industry developing enterprise solutions which

are deployed in high availability architectures.

“A typical SOA environment will have hundreds of artifacts like Web services, BPEL processes, EJBs, adapters, and other resources”

http://www.dreamface-interactive.com


The healthcare industry, including hospitals, is one of the most significant public institutions in greatest need for sophisti-cated information systems because of the enormous amount of data it handles and because of its life-and-death responsi-

bilities. Yet the implementation of large-scale and robust-enough IT systems in public healthcare institutions can be challenging as well as ineffective. We know that several large American medical centers have not been successful in attempting to execute major upgrades or overhaul their processes. Without careful preparation and agile execution, some may experience a serious, expensive, and distracting fate. With the pace of today’s technological innovation and efficiency demands, healthcare organizations need enhanced customer service orientation, a multi-channeled marketing strategy, and an effective legal and regulatory compliance model. This article will describe both BPM and the legal aspects that together form a foundation for process discovery, improvement, and optimization, and thus organizational effectiveness. Among the legal aspects, we will discuss SOX and HIPAA, which is more closely affiliated to the healthcare model.

Discovering the Value of Business Process Management (BPM) as an Approach Leveraging Business Process Management (BPM) as a strategic approach and discipline to enable change will serve as a good catalyst that helps foster increased process awareness, transparency, and agility around the core business processes maintained by these healthcare institutions. Organizations have begun to learn the value in harness-ing the potential of the data as well as information they generate and consume on a regular basis, in ways that help their business model perform well and execute even better in the marketplace. It is this abil-ity to integrate content with core business processes that is significant in being able to progressively transform the efficiency states of an organization’s business model and the supporting enterprise line-of-business (LOB) applications that strengthen them as well as enable maximizing the value of IT-based solutions. As an approach BPM enables institutions to do a detailed analy-sis of their current process, also referred to as “Current-State” or an “AS-IS” model, and having performed a gap analysis, develop an implementation plan for the future, also referred to as the “Future-State” or the “TO-BE model.” The whole idea of a BPM discovery and development initiative in the context of process optimization is one that helps one manage and improve complex business processes using sophisticated, yet rapidly deployable and non-intrusive tech-

nological capabilities. By promoting the engagement of a problem-solving approach that aligns critical content with core processes and business solution applications, organizations can manage, track, expedite, and interlink information streams throughout the organi-zation. BPM as a concept and powerful catalyst for change is one that instills the core fundamental of first being able to go through an investigative approach by capturing a process and related scientific evidence, thus leading to a detailed examination of all core data, processes, information, and interdependencies, while looking for adaptable process-oriented solutions, some of which may consti-tute technology-oriented and -enabled solutions, such as the use of business process automation routines through workflow enable engine management systems. Other efficiency enablers may simply involve the optimization of worker and resource engagements and general process efficiency applications. Companies are finding many reasons to capture their business process. Companies that have built alliances via mergers and acquisitions want to be able to expose their enterprise process across their various sub-enterprise lines of busi-ness to discover champion best practices as potential solutions to other divisional applications. Engaging in this philosophy allows for healthcare organizations to remain cost-effective, competitive, and productive.

Organizational Goals and BPM Agile businesses have a need for dynamic Process Change, and whether that’s being able to react quickly to the unexpected, working toward a strategic organizational goal, or simply looking for areas in the core processes of the business model where potential inefficien-cies may exist and so have a need to be exposed and repaired. As a structured approach that unites software capabilities and business expertise, BPM is not just another methodology, but a discipline that promotes the collaboration of the organization’s people, systems, and information to speed up the amount of time between business process improvements and the facilitation of business innovation. Using a simple analogy, the goal of a business, generally speak-ing, is to conduct an n number of operations that typically start from point A and end at point B. For example:

Process AB = (Starting Point) A –> B (Finishing Point)

The fewer the interruptions, glitches, unnecessary loop-backs, and

REGULATORY

restarts, the better and more efficiently the process can run, minimizing operational cost while continuing to maximize operational efficiencies. A crucial reality factor is that “change” is an inevitable occurrence. What we tend to see is that typically, while the business processes function well (if well designed), they tend to slow down or develop process lags. This can happen for a variety of reasons including:

i. Business volume is too high when paired with older technology ii. Process change is cumbersomeiii. Processes are not well documentediv. Process bottlenecks inhibit efficiencyv. Complex integration across multiple processes

Standard Components of a BPM-based Approach to Problem-Solving Traditionally this is a phased approach; the overall structure is such that it follows a streamlined set of actionable iterations. Some of these phases may choose to employ traditional process improvement methodologies such as Six Sigma.

a. Develop a shared goal of understanding – Often various custom-ers of a process have different positions on how the process should be improved. It is imperative that before conducting any large-scale process-improvement initiatives that an overall “shared goal of understanding” is developed. If this does not happen, we tend to see that customers frequently have to revisit exactly what the goals of the process were to begin with.

b. Conduct a situational analysis – What is the situation today and what are the current or currently perceived factors that impact performance efficiencies. What business and technological plat-forms are involved? What process interdependencies exist? Are there sensitive areas of the process to be aware of? This part is vital to the investigation as it provides insight into the ecosystem of the process and participants. Having a sense of the current landscape in which the organization is operating the business process is a relevant study to be conducted.

c. Conduct an information analysis – Study data and information as they relate to the process and their significance to the notion of process change.

d. Conduct a solutions analysis – Study possible solutions and ideas that can be looked at to make an effective case for process change and optimization.

e. Conducting a solutions cost-benefit analysis – One of the most important junctures is the ability to build a portfolio of solutions in the solutions analysis phase and present it to upper management with a standard high and low estimate. If upper management ap-proves, the next steps can be initiated. Otherwise, previous phases may have to be revisited for scope limitation or expansion due to needs and/or budgetary concerns.

f. Conducting an implementation analysis – Study how solutions are going to be instantiated and the techniques, best practices, strategies, and contingency plans that are in place to come up with the best form of applicable implementations.

g. Performing the implementation development – One of the later stages in the process is to start the process of change by equipping the process or altering components of the process with elements of the new technology, Key Performance Indicators (KPIs), and automation solutions, for example, workflow.

Common Accessories in the BPM Portfolio and Toolkit1. Business Process Modeler – These are typically simple-to-use,

business user-oriented tools with a GUI to model things that affect performance and help measure the performance of the process. These tools typically provide comprehensive modeling and simula-tion capabilities along with reporting and documentation. A business process model can help you understand and transform your business process by validating enhancements prior to committing resources. It provides an interface for complex behavior. IBM’s WebSphere Busi-ness Modeler 6 is an example of a business modeling tool.

2. Business Process Monitor – These are process productivity and role-based dashboards. Common functions of a business monitor that is also a GUI-based thin or thick client include being able to monitor business events and situations and business performance, manage in-flight business processes, gather business intelligence from assimilated data, catch certain business events, and take any necessary corrective action. IBM’s WebSphere Business Monitor 6 is an example of a business monitoring tool.

3. Business Process Publisher – This is typically a product and plat-form that models can be published into. Once published models are exposed to various entities security can be enforced in various layers of the model. It makes for a powerful and rather “adaptive” mechanism for keeping models up-to-date by giving the business subject matter experts an access through which they may be able to make changes, updates, and suggestions, allowing the model to grow overtime and become closer to reality than before. One rea-son this is perhaps the most important tool in the industry is that it promotes adaptability and many SMEs find their time better spent than devoting a few hours a week to a meeting where they make suggestions to a bunch of people. Those kinds of sessions tend to be more productive for review and analysis, but we often tend to digress and lose sight of the big picture and get too deeply involved in the sub-processes. If you’re part of a workflow or process-based competency center, it’s a good idea to make this one of the core competencies to mature. IBM’s WebSphere Business Publisher is an example of a business publishing tool.

4. IBM WebSphere Integration Developer – This is a toolset de-signed to take an organization’s business process built earlier in the Business Process Modeler and begin the process of integrating core business processes and functions outlined in the model, with computer applications and systems also referred to as Services, within the context of a SOA. This tool is mostly used by integration developers and process engineers to build necessary workflows, automated error handling routines/procedures, compensation or roll-back features and so on. For example, the business has a requirement whereby they would like their agents out in the field to collect and capture customer data as customers show interest in the agent’s products being discussed. Instead of doing this on paper, they would like IT to provide a CRM (Customer Relationship Management) solution that is able to house customer data that the agents could publish to in a remote manner using a URL/web-page that simply transports the same data, but now electronically. Once transported and analyzed, the business would like to send an automated email to the customer acknowledging receipt of their information and request before additional steps in the core business workflow are invoked. A scenario like this is one can be handled in integration suites such as IBM’s WebSphere Integration

Discovering Process Agility & the Significance of Regulatory

BY PRAVEEN K. CHHANGANI AND R.C. CHHANGANI

Compliance in health care with Business Process Management


REGULATORY

Developer in association with either in-house custom solutions or with proprietary software options like Salesforce.com or Siebel Sales Force Automation solutions.

5. IBM WebSphere Process Server – This is a high-performance business engine to help form processes that meet the customer’s business goals. It’s built on open standards and extends the value of core applications and databases by centralizing business pro-cesses and sharing them across the enterprise, enabling maximum operational efficiency and ROI. Provides strong support for human workflow and fosters rapid process change for better business agility. Within the context of an IBM solution, this is the runtime platform upon which business models are executed.

The Four Common Steps in a Given Process Model and Potential Goals1. Human-to-Machine: These are typically initiation/creation and/or request-oriented tasks performed by the human, and could be asynchronous or syn-chronous in nature. Goal: Design interfaces that are easy for humans to comprehend and allow for efficient searches, logging, data profil-ing, etc. The request from a human being to a machine should be carefully planned so it doesn’t overburden the human to the point a manual strategy is preferred.

2. Machine-to-Machine These are usually the kinds of tasks that involve data, information, validity check, or some procedural handshake between two or more machines/systems/programs/applications. Goal: Enable efficient machine-to-machine interaction, promote use of speedy algorithms that enable sufficient response times and appropriate automated error-handling mechanisms and provisions for escalated human error-handling and intervention situations. Predictive models and algorithms are a good way to explore the intelligent communication pattern here.

3. Machine-to-Human These are steps taken to ensure that a human is notified of a response or an update that he requested earlier. It allows the machine to respond by providing a programmatic answer typically an alert or notification such as e-mails or pager. Goal: Use of proper response mechanisms and capabilities that can work around the human’s schedule.

4. Human-to-Human Obviously this is an organic interaction during the lifecycle of a given process model. Typically it consists of either manual or automated human-to-human interactions to ensure that the proper balances and checks are in place. Goal: As one of the most impor-tant tasks, you want to ensure that humans are involved as much as needed. Decisions sometimes demand human intervention instead of pre-built programmatic actions and responses.

Next-Generation BPM for Adaptable Compliance To enable an effective means of transformation using BPM and advanced IT implementation methodologies, we need a basic under-standing of the customer, the business model, the legal implications, and the privacy laws that solutions should comply with. So not only is a proper understanding of the solution needed, but also how the solution being built will co-exist with the privacy laws impacting healthcare, such as HIPAA. Process agility and transparency are key

parts of the entire solution, so careful consideration should be given to both during process modeling and/or optimization.

Significance of Government Regulations One of the keys to business success is the ability to stay competitive in a business sense, but also compliant with government regulations such as Sarbanes-Oxley, HIPAA, and ISO 9000. HIPAA is the legal and compliance model closely aligned to the healthcare industry and for purposes of this article I will talk about HIPAA model in greater detail. For organizations in some parts of the world government regulations require that their core business processes be properly documented. For example, the Sarbanes-Oxley Act of 2002 (Public Law No. 107-204) has introduced far-reaching reforms of American business practices. The legislation established new or enhanced standards for all U.S. public companies, boards, and public accounting firms. In short, it says certain processes must be well documented. It is one of the driv-ers making organizations take a closer look at their processes. Another relevant example is native to the healthcare industry. For example, the healthcare industry needs an effective way to adopt electronic storage, security, and transmission of patient care infor-mation through privacy-oriented laws such as the Health Insurance and Portability & Accountability Act or (HIPAA). Business Process Management is a good candidate since it subscribes to the basic notions of agility and adaptability. So as new business and technol-ogy models come into play, and any new government laws and legal regulations come into effect, BPM will be a catalyst for progressive change and successful regulatory compliance.

What Is HIPAA? The Health Insurance Portability and Accountability Act of 1996 (HIPAA), Public Law 1104-191, was enacted by the U.S. Congress in 1996. In HIPAA, the Congress directed the Secretary of the Depart-ment of Health and Human Services (HHS) to adopt regulations governing the privacy and security of health information, standard transactions and code sets, unique health identifiers, electronic signatures, and the transfer of information among health plans (col-lectively, the regulations). In sum, the major components of HIPAA Administrative Simplification address four specific areas: i. electronic transactions and code, ii. privacy, iii. security, and iv. identifiers. The Administrative Simplification subtitle of HIPAA is set forth in sections 261 through 264 of HIPAA. It is relevant to mention that HIPAA required the Secretary of Health and Human Services to issue privacy regulations governing individual identifiable health informa-tion, if Congress did not enact privacy legislation within three years of the passage of HIPAA. Because Congress did not enact privacy legislation, HHS developed a rule and released it for public com-ment on November 3, 1999. The agency received over 52,000 public comments. The final regulation, the Privacy Rule, was published on December 28, 2000. In March 2002, HHS proposed and released modifications to the Privacy Rule for public comment. The final modifications were published on August 14, 2002.

Who Does the Privacy Rule Cover? The HIPAA privacy standards ensure patients have access to their medical records and provide more control over how their personal health information is used and disclosed.

What Information Is Protected? The major goal of the Privacy Rule is to assure that an individual’s health information is properly protected while allowing the flow of

the data needed to provide and promote high-quality healthcare and to protect the public health and well being.

The Aftermath & Approach Needed It’s clear that there can be significant consequences not only for operating your business model inefficiently, but having a model that doesn’t comply with privacy regulations. Progressive business change calls for a scientific management-and-development approach. BPM is the kind of methodical approach that collaboratively helps expose the process and any inefficiencies and helps implement recommenda-tions to core organization pillars such as business, IT, HR, and legal to capitalize on building and maintaining a successful business model. Over the next few years electronic medical records and other healthcare-oriented models will need intelligent models to achieve business goals as they relate to customers and adapt to new industry and compliance standards. Process Model Adaptation is very signifi-cant from the standpoint of cost-effectiveness over time and also a challenge we face as process modelers and automation engineers. It is however part of a larger and broader challenge to foster and promote new ways of developing opportunities in process patterns, modeling techniques, and workflow automation scenarios individu-ally and combined all together.

About the Authors

As a certified IBM Specialist, Praveen K. Chhangani is part of SYSCOM (www.syscom.com), a

premier IBM Business Partner and part of a specialized team of WebSphere consultants whom

IBM calls upon to service its most challenging customer requirements by providing training,

customization, process analysis, architecture design, administration, development and deploy-

ment of distributed architectures. He has several years of experience and is well rounded as a

developer, analyst and solutions architect. His extensive experience with IBM WebSphere MQer-

ies WorkFlow, SOA, IBM WBI Modeler, Monitor, Integration Developer and Process Server has

proven invaluable in a full lifecycle of projects from requirements analysis, process design and

automation, solution design, development, testing and mentoring for clients such as Principal

Financial Group Inc., MCI WorldCom, HCSC and AIG.

[email protected]

A distinguished professor in the field of International Human Rights Law, Prof. R. C. Chhangani

has published several articles and a book dealing with contemporary issues relating to refugee

problems. His writings thus far have focused on a holistic approach from legal and humanitar-

ian perspectives. He has served as an attorney and has also taught undergraduate and graduate

classes around the world in leading universities in the Netherlands, America, India, Nigeria

and more. In recent years he taught at the John Marshall Law School of Chicago in areas of

International Law, and is currently the Dean, Faculty of Law at Nasarawa State University,

Keffi, Nigeria.

[email protected]

��

ISB

N 0

-977

7622

-0-3

from the World s̓ Leading i-Technology Publisher��

© COPYRIGHT 2007 SYS-CON MEDIA��

ISB

N 0

-977

7622

-2-X

ISB

N 0

-977

7622

-2-X

��

��

from the World s̓ Leading i-Technology Publisher��

© COPYRIGHT 2007 SYS-CON MEDIA��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

��

��

��

��

��

��

http://www.theriabook.com


The Case for Coordinated EDM & SOA Strategies PART 1

STRATEGIES

Strategies for enterprise data management (EDM) and Service Oriented Architecture (SOA) are often pursued as separate, disparate programs and initiatives within organizations, both as a business requirement as well as

an IT implementation perspective. However, there are important overlapping and interdependent components, processes, and quality checkpoints for each in which coordination is necessary to ensure the success of either strategy. Furthermore, by coordinating these strategies, organizations will realize opportunities to optimize:• The business value of enterprise data and services (e.g., increased

operational efficiencies/quality, increased business services utilization and profitability, and decreased development/mainte-nance costs)

• Economies of scale and synergies in key EDM/SOA processes, infrastructure, tools, and roles (e.g., increased organizational ef-fectiveness and decreased infrastructure costs)

There are several reasons driving the coordination of EDM and SOA strategies, including asset value, organizational efficiency, profitability, and cost optimization.

The CIO Perspective on Data and SOA Dependencies The need for coordinated data and services, under the guidance of coordinated EDM-SOA programs, has recently been raised to the executive office. As shown in Figure 1, CIOs are focusing on data-centric initiatives such as Customer Data Integration (CDI) and Master Data Management (MDM) as drivers for Service Oriented Architecture projects. Even traditionally non-SOA business analyt-ics or knowledge management programs are now key drivers for SOA, according to surveyed CIOs. This survey also demonstrates the realization by most CIOs that SOA creates interdependencies between systems requiring high-quality data, which further suggests that the full benefit of a SOA program cannot be gained without coordinated EDM strategy components.

The “Perfect Storm” for EDM & SOA Interrelated factors across industries are creating an environ-ment ripe for organizations to develop EDM and SOA strategies/programs in parallel timeframes and a coordinated fashion. Figure 2 lists major contributing industry trends resulting in corporate initiatives driving requirements for coordinated EDM and SOA capabilities, including joint governance programs.

EDM Framework & Component Considerations Let’s take a look at the EDM framework in Figure 3 to see which components have potential dependencies and synergies with SOA strategies/components. This will help identify where we should focus strategic efforts for coordinated EDM-SOA strategies. Enterprise Data Management initiatives generally consist of activities addressing several of these components, simultaneously or at least in coordination. When considering which EDM compo-nents have a significant impact on SOA strategies, and which are significantly impacted by SOA, we see that some have direct major considerations (primary coordination points) in joint EDM-SOA strategies, while others have a smaller impact (secondary). Organizations should start with identified primary (coordination) EDM components and SOA strategy impacts, dependencies, and synergies for emphasis then determine which secondary compo-nents are pertinent for coordination within that particular EDM-SOA environments and initiatives. Organizations that fail to coordinate EDM and SOA strategies appropriately will inherently cause enterprise data and services to evolve disparately rather than synergistically as part of a well-man-aged enterprise architecture, and should ask:

• How will the master data and metadata used in services/transac-tions be managed?

• How will SOA services be developed/maintained to use only stan-dardized master data, metadata, and “gold standard” data?

• How will processes and data integration, as well as overlapping

BY KEITH R. WORFOLK

And what strategic EDM and SOA components require attention to facilitate the appropriate coordination ��

��

24/7

Visit the ��

Website Today!

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

24/7

http://www.sys-con.com


STRATEGIES

roles/responsibilities and ownership/stewardship concerns for data utilized or made available by services, be managed between parallel data and SOA governance programs?

These are important issues from the EDM perspective that may go unmanaged when organizational data and service strategies, governance, architecture, and development go uncoordinated. The Enterprise Information Architecture (EIA) component, a pri-mary coordination point, is relatively recent to EDM organizations. It:

• Comprises information, business processes, and architectures• Includes information knowledge worker “bridge” staff who un-

derstands the business, and communicates with technical staff• Determines type, content, and quality of enterprise information

delivered by SOA (via data/SOA governance)• Creates policies/standards for enterprise information usage

Figure 4 shows how EIA works with organizational business pro-cesses and the SOA, under the guidance of data/SOA governance. It is directly leveraged by the SOA and includes the enterprise data model that service designs will leverage. Hence, the EIA works with and contains the enterprise-level aspects of MDM and metadata management. It coordinates pertinent data integration and quality issues, best practices, and tools between EDM and SOA strategies as

a primary EDM component for coordination with SOA strategies.

SOA Framework and Component Considerations Looking similarly at a SOA framework, it becomes clearer where dependencies and synergies between EDM and SOA strategies exist. SOA initiatives generally address several of the components shown in Figure 5, simultaneously or at least in coordination. Considering how EDM components are impacted in a SOA environ-ment, most SOA components play some role in coordinated EDM-SOA strategies/programs. Key cross-impacts of EDM and SOA components in a SOA envi-ronment are:

• SOA Governance – Data governance ensures that services use the right data/metadata, and any proliferation of data for or by services is managed for quality/consistency. For service-related data/metadata, coordinated data-SOA governance is needed

• Workflow Management and Business Rules – Metadata manage-ment includes common automation and workflow routing rules, business rules, and SLAs

• Access and Security Services – MDM includes security classifica-tions for master data and user entities, while metadata manage-ment includes descriptions and rules for handling service/data classifications

• Enterprise Business Services – MDM ensures the availability and evolution of master data supporting fine-grained data and com-posite business services. Metadata management ensures services use appropriate workflows, business rules, SLAs, etc. Meanwhile, EIA (e.g., data architecture) is referenced by service releases

• ESB – metadata management drives configuration rules of the ESB for transaction/message processing

• Enterprise Data Platform Services – MDM and EIA are refer-enced

SOA Best Practice Considerations Another way to consider SOA strategy impacts on and synergies with EDM is in addressing how organizations achieve SOA best practices. Significant dependencies between an organization’s EDM and SOA strategies will surely reveal themselves and must be taken into account when pursuing SOA best practices. The following are among key best practices for SOA strategies, and most/all can also be applied as EDM best practices.

1. When thinking about services, don’t forget to consider the data Systematically designing a service model is like designing a data model. For either, its impact should be considered long-term, and the level of normalization of designed components, services, or data is considered a sign of quality and maturity. Figure 6 shows service-Data normalization from immature to mature organizations:1. “Wild West” – Non-existent or ad hoc and uncoordinated nor-

malization2. Ownership/Stewardship – Service designs built on data designs3. Encapsulation – Service and data designs coordinated in devel-

opment/maintenance initiatives; either may drive the other as long as they are coordinated

4. Object – One and the same service/data designs. Normalized de-signs are within EIA designs; service implementations take data ownership to another level where master data value is known

only in service designs/implementations.

Most organizations pursuing services-data normalization have progressed to ownership/stewardship levels, yet need to reach en-capsulation before realizing major benefits in efficiencies, mainte-nance costs, and asset business value. The highest level of service-data normalization, object, may not make sense for some organizations, especially where master data or business services change frequently. Depending on their stability, the more possible an object level may be. However, cost/benefit analysis may make encapsulation preferred for some organizations. Transitioning to advanced service-data normalization is a process of increasing organizational maturity toward coordinated EDM-SOA strategies. This is facilitated through coordinated:

• Data and SOA governance organizations and programs• MDM, metadata management, and EIA with SOA initiatives’

enterprise services architecture/development

2. Focus on avoiding the proliferation of services that can’t be shared SOA strategies have little business value if their enterprise ser-vices aren’t shared (i.e., reused) among multiple user groups and business domains in the enterprise and sometimes outside the immediate enterprise. Not coordinating data with SOA initiatives (e.g., via governance), services may inadvertently propagate non-“gold standard” data to service consumers when developed by the initiatives. Such services become, OR SHOULD BE, unable to be shared! Worse, the absence of coordinated data and services may tempt developers to create their own data stores/marts to support their services’ domain, causing unnecessary propagation of potentially unmanaged databases. This will damage both your EDM and SOA strategies! Avoiding services that can’t be shared is facilitated by coordinat-ed:

• Data and SOA governance organizations and processes• EIA and enterprise data model, with SOA services portfolio and

releases• MDM and metadata management with SOA services’ initiatives

architecture/design

3. Reward both reusability and reuse Reusability and reuse applies to services and data in develop-ment, deployment, and consumption cycles. Services and data should be normalized for reuse (see SOA Best Practice #2), and developers and consumers of either should be rewarded. This is a delicate balance that should be managed by data-SOA governance and processes to ensure appropriate reuse when it makes business sense (i.e., unless service/data requirements are new or existing designs/implementations are obsolete). SOA governance will sometimes advocate development of new or improved services when it makes sense. Similarly, data gover-nance will almost always advocate reuse of existing master data or managed metadata, but decreasingly over time as managed data stabilizes, there may be reasons to extend or change “gold stan-dard” data. Reuse and reusability should also be enforced, and best practices

Figure 1 The CIO perspective that data issues are key drivers of SOA initiatives is growing

Prop

erty

of

Hit

achi

Con

sult

ing

Figure 2 The “Perfect Storm” for EDM and SOA

Prop

erty

of

Hit

achi

Con

sult

ing

Figure 5 Typical SOA conceptual framework

Prop

erty

of

Hit

achi

Con

sult

ing

Figure 4 EIAcomponent and subcomponents in EDM

Prop

erty

of

Hit

achi

Con

sult

ing

Figure 3 Typical EDM framework and components

Prop

erty

of

Hit

achi

Con

sult

ing


STRATEGIES

established, by coordinated data and SOA governance programs. Governance should include the identification of which data and services can potentially be reused for a given initiative, and the criteria for when new data/services should be created or modified. Rewarding reusability/reuse is facilitated by coordinated:

• Data and SOA governance organizations and processes• EIA, MDM, and metadata management processes/tools with SOA

services’ initiatives architecture and design processes/tools

4. When establishing governance, stay away from dictatorships As shown in Figure 7, there are three general governance ap-proaches for organizations:

1. “Wild West” – Non-existent or ad hoc and uncoordinated governance. Lack of enterprise-level coordination, with minimal governance pro-cesses/roles developed out of necessity in selected domains.

2. Federated – Coordinated independent efforts between domains. Selective enterprise coordination, but standards, best practices,

and tools are inconsistent between domains. Also inconsistent coordination points with business requirements, etc. between domains.

3. Dictatorship – Centralized control of all data or service assets; all assets considered from an enterprise perspective, which is not as effective for domain-specific assets. Here, everything is coordi-nated at the cost of domain flexibility.

The goal is not to progress to dictatorial governance. While “Wild West” is a problem with lack of control/coordination, dictatorships swing the pendulum too far toward centralized control of all deci-sions regarding enterprise-wide and domain-specific assets (data or services). Establishing balanced governance is facilitated by coordinated:

• Data and SOA governance roles and processes• Enterprise-level EDM assets (EIA, MDM, metadata management)

with enterprise-level SOA assets (enterprise architecture, SOA services model, and services portfolio)

• Enterprise-level EDM and SOA architecture and design process-es/tools

5. Establish a Center of Excellence (COE) to provide guidance, governance, and coordination A well-organized and managed EDM or SOA environment should establish a COE to:

1. Involve appropriate stakeholders (business/IT) early and often 2. Facilitate necessary coordination between interdependent proj-

ects, programs, and organizational divisions

Mature EDM/SOA strategies include development and manage-ment of a supporting COE. However, there is the danger of organi-zations developing disparate EDM/SOA COEs when pursuing both strategies, despite overlapping roles, dependencies, and synergies. As Figure 8 demonstrates, an Integration Competency Center (ICC) does more than a traditional COE by providing a design, de-velopment, prototyping, and testing sandbox for data and services integration. An ICC provides processes/tools for EDM and SOA environ-ments, and facilitates coordinated services and information archi-tecture and development to achieve, among other things, service-data normalization. An ICC coordinates with data-SOA governance and the EIA, as well as overall enterprise architecture concerns. It identifies key components managed within governance for which instances will reside in the ICC and/or production implementations. Establishing a services-data COE/ICC for stakeholders and inter-dependent projects is facilitated by coordinated:

• Data and SOA governance roles and processes• EIA and its enterprise data model, with SOA services portfolio

and releases• EIA, MDM, and metadata management processes/tools with SOA

services’ initiatives architecture and design processes/tools• Enterprise-level EDM assets (EIA, MDM, and metadata manage-

ment) with enterprise-level SOA assets (enterprise architecture, services model, services portfolio)

• Enterprise-level EDM and SOA architecture and design process-es/tools

6. Start with the right program size in the right area of emphasisStarting too big with EDM or SOA can lead to mistakes. Think stra-tegically, but act tactically with an emphasis on launching a realistic program that can become successful initially and grow. Develop a coordinated long-term vision for your EDM/SOA programs, and implement these incrementally in support of each other. Coordi-nated data-SOA governance programs, and a supporting COE/ICC that addresses data and services (see Best Practice # 5), can support the scoping and launch of a “right-sized” program. For example, you can design sets of services around selected business and data models. The data model can be used to encapsulate business data, and the business model can link further business processes of applications with its software implementation (i.e., services). Business services typically consume data services that are usually not exposed outside the enterprise. Alternatively, the data model may become primary design crite-ria for an application; the data model would be the best choice on which to base application services, user interfaces, and business process designs. Implementing an appropriately sized and focused EDM-SOA program is facilitated by coordinated:

• Data and SOA governance organizations and processes• EDM/SOA COEs (or ICCs) with the EIA and enterprise data

model, and the SOA services portfolio and release management

7. Invest in systematically designed core services initially, allow-ing for rapid opportunistic extensions later An SOA program may be launched tactically with flexibility and scalability to systematically incorporate program scope under the guidance of governance and an ICC. Key intermediary services that intercept and handle operations common across services that should be reused include: authentica-tion, logging, monitoring, and routing. A common data services layer:

• Provides abstraction between producers and consumers of data; service and data consumers are insulated from complexity, loca-tion, and changes in source systems

• Presents services/data consumers, whether human, application, or services, with aggregated views from multiple sources

• Manages, monitors, and reports on the enterprise views of data/metadata

SOA strategies cause organizations to implement an EIA and in-frastructure in support of services, including common data services capable of supporting producers and consumers with timely and consistent information. The main categories of data services include:

• Enterprise Data Services – Directly around the data (e.g., re-trieve, update). Also enablement of traditional MDM functional-ity (e.g., data quality/harmonization across systems exposed as services).

• Enterprise Metadata Services – Around metadata (e.g., retrieve master data schema). SOA designers/developers creating busi-ness services, and those consuming them, reference organiza-tional master data schemas via services.

• Enterprise Data Platform Services – Around services/data plat-

forms, including management, monitoring, and reporting.

Within other services, and across the data services layer, com-mon infrastructure methods for search, access, creation, update, and deletion functionality are made available. Systematically/progressively designing services is facilitated by coordinated:

• Data and SOA governance organizations and processes• EIA and its enterprise data model, with SOA services portfolio

and releases• EIA, MDM, and metadata management processes/tools with SOA

services’ initiatives architecture and design processes/tools• EDM/SOA COEs (or ICCs) with the EIA and enterprise data

model, and SOA data with infrastructure services releases

Conclusion This article demonstrates the case for coordinated EDM and SOA strategies and capabilities in organizations. It further shows what strategic EDM and SOA components require attention to facilitate appropriate coordination. This article shows that organizations should develop a coordi-nated data-SOA governance program, as coordination needs to be established at leadership levels to enable the optimal value of their services and data. This is the highest priority toward coordinated EDM-SOA capabilities. Initial data/SOA governance models should be coordinated for processes, checkpoints, and ownership. We rarely develop these strategies and governance models in coordination from scratch though hopefully this article will spark this. Hence, it’s important to adapt appropriate processes and checkpoints between separate models and (re)define roles to support coordinated data-SOA gov-ernance. Organizations should scale progressive EDM-SOA initiatives with shared data-SOA governance, processes, and communica-tions complemented by educating EDM/SOA resources/stake-holder to effectively leverage each other in joint data-services development. Ensure business- and data-modeling analysts are involved in services design (e.g., not just services analysts), so business functionalities are reflected rather than technical partitioning of software/data. An appropriate COE/ICC will facilitate diverse stakeholders working proactively to drive phases of coordinated EDM-SOA initiatives. Lastly, promote a culture of collaboration as an underpinning of successful EDM, SOA, and coordinated programs.

• • •

Next Issue: Part Two of this series on EDM and SOA will intro-duce the coordinated service-oriented data architecture framework and the capability maturity model (CMM), including how to use the C-SODA framework and CMM to drive assessments and improve-ment roadmaps for organizational maturity.

About the Author

Keith R. Worfolk is a senior architect with Hitachi Consulting. He has more than 21 years of

senior IT management and executive-level success in strategic enterprise architecture, soft-

ware development, and large-scale systems integration. He has strong international and Big 5

project experience. Keith earned an MBA from Duke University.

Figure 7 Governance approaches

Prop

erty

of

Hit

achi

Con

sult

ing

Figure 6 Service-data normalization levels

Prop

erty

of

Hit

achi

Con

sult

ing

Figure 8 Relationships of COE/ICC to data-SOA governance

Prop

erty

of

Hit

achi

Con

sult

ing


ARCHITECTURE

The Million Dollar SOA Question: Software ESBs or Hardware Appliances?

BY SHIVA BHAJEKAR

Service-oriented architectures have now become the norm for IT to deliver value to their respective businesses. A SOA-based approach promises an environ-

ment of agility, loosely coupled integration, and a composition-based approach, all of which results in faster adaptability to the demands of the business, lower operational costs, and the increased “pluggability” of standards-based

applications. A service is nothing but an abstraction of something that does some business unit of work. This could be something like placing an order, retrieving customer information, or modifying personal information. Technically these services could be exposed with any binding/protocol/interface with request/response param-eters being structured or ad-hoc data. Standards-based services have their payloads structured as XML. In a traditional old school infrastructure, business functions were encompassed in packaged or customized applications with their predefined user interfaces. In a SOA, these traditionally “trapped” business functions tend to add more value when encompassed within a much larger scoped entity and then used by a more mod-ern interaction mechanism. The true emancipation of these busi-ness functions required the transition of traditional IT infrastruc-ture toward a new class of technology components. The two major roles of this new services infrastructure are a service brokering role and a gatekeeping role. There are other auxiliary roles, including that of a repository, endpoint management, and some higher-level roles such as orchestration in this new services infrastructure. However, the remainder of this article discusses the primary roles of service brokering and gatekeeping in detail and addresses the different technology components that can fulfill the roles.

The Primary Roles in Services InfrastructureThe Service Brokering Role Service brokering is key to the success of SOA. Service brokering aims to abstract access to the business functions and at the same time allows for the implementation of complex integration patterns including service façade, message enrichment, message filter, con-

tent-based routing, dynamic routing, and splitter-aggregator. The service brokering role is also responsible for performing tasks such as protocol bridging, message transformations, and bridging differ-ent messaging paradigms. This role is also suitable for authorizing access to services based on the message or request context.

The Gatekeeping Role This role is akin to a firewall in network security. Sometimes it’s referred to as an XML firewall role. The primary agenda of a gatekeeper is to keep the rogue requests out and protect the busi-ness services. This is the first line of defense as far as security is concerned and authenticating requests coming in is an obvious requirement. The other subfunctions in this role include validat-ing requests (against defined XML schemas), throttling access to a service, and preventing denial of service attacks.

The Physical Components for Satisfying These New Roles As SOA was getting baked, technology vendors used different approaches to address the requirements posed by this new services infrastructure. There are the web services management (WSM) vendors who focused on the end-point management of business services. Hardware appliance vendors started off addressing the pe-rimeter space by creating an XML firewall and subsequently adding security functions to it. Last, the technology vendors with a mes-saging and/or Enterprise Application Integration (EAI) background either evolved their offering or, with their technology expertise, created a software-based middleware solution called Enterprise Service Bus (ESB). While there was no comprehensive solution available, each of the three product types played an important role in the reference architecture. As each of these solutions started to evolve, they all tried to ad-dress the functionality of what we know as the modern ESB. The Web Services Management (WSM) tools did not make significant advancements in messaging and service mediation, but newer hardware appliances started emerging that could function as a service mediator and an integration appliance. Let’s take a look at the hardware appliances and software ESBs,

Addressing the different technology components

their characteristics, and the pros and cons of each approach for services infrastructure.

Hardware Appliances It’s difficult to categorize all hardware appliances in the same bucket. There are a number of appliances in the market; a represen-tative list is available at http://en.wikipedia.org/wiki/XML_appli-ance. Usually the hardware appliances have the following strong char-acteristics. • XML acceleration: Assisted by a chipset, the appliances can

perform fast XML processing including message transformations and schema validations.

• Fast SSL offloading, encryption/decryption of payloads: Once again the ability to use “on the wire” techniques makes these operations efficient in an appliance.

• XML firewall: The ability to keep the “bad guys out” is well en-forced by an appliance. It also supports authentication mecha-nisms to ensure that the entity making the request is indeed the asserted entity.

• Simplicity of setup/operation: As the appliance is a pre-config-ured box with limited access to actual internals and no peripheral connectivity, it’s fast and easy to set up in the IT infrastructure. It also has a web-based configuration making operational tasks simple as well.

With the pros, come the cons. The hardware appliance suffers from the following drawbacks:• Upgrades/refreshes: Firmware upgrades especially in band in a

production environment can cause disruption. This also plays into the inability to support the latest standards in the SOA space as soon as they are available.

• Stuck with hardware and chipset: The appliance approach is un-able to take advantage of new and emerging hardware technolo-gies. You tend to get stuck with the hardware you get. The Moore’s Law effect will naturally force the deployed appliances to become outdated and sluggish in performance.

• Appliance sprawl: A plethora of hardware appliances results in hardware sprawl and increased data center costs. This solution is unable to take advantage of the software virtualization wave that is resulting in lower power consumption and an effective use of capacity.

• Limited integration capability: Even though the hardware ap-pliances are sometimes presented as integration appliances, there is limited support for complex integration patterns (if at all). There is also the inability of extensibility using software (coding) exits.

• Disconnected with the software development process.

It should be noted that there are some hardware appliances that have emerged to address a specific niche problem in services infra-structure.

Software ESBs The concept of the Enterprise Service Bus has emerged from the popular message buses of the Enterprise Application Integration world. With EAI as part of their heritage and with enterprise class messaging and a well-developed software development life cycle, the software ESBs boast the following advantages. • Flexibility: They support extremely complex integration pat-

terns. They not only have standards-based connectivity, but also the ability to expose business functions in a legacy or packaged application as a reusable service. Their support for emerging standards is usually stronger and accelerated in a timetable.

• Strong software development life cycle: The software ESBs usually include an integrated development environment with strong debugging, tracing abilities, and integration with source control environments. The deployment of new message flows for software ESBs can be part of the overall software development process.

• Efficient interoperability with architectural tools: To illustrate this point, let’s look at Service Component Architecture (SCA), which is a model for building systems using the SOA approach. With SCA, software ESBs may have the ability to consume the Service Assembly Models (SAM) created by architects to model services integration. SCA is a language independent mechanism to compose and deploy service networks.

• Tight integration with service registries and repositories: This

Figure 1: A Service Assembly Model

Figure 2: Service dependencies through a meta-data repository


ARCHITECTURE

makes it possible to introduce strong governance in deploying message flows as well as the automated service dependency as-sociations.

• Virtualized environments: One of the strongest advantages of the software ESB is its ability to take advantage of the virtualiza-tion wave that is sweeping data centers to make effective use of physical hardware and to reduce operational costs.

The software ESB approach comes with drawbacks too. It is unable to process XML at wire speed; it lacks the gatekeeping functions and depends on hardware for its setup. The use of a hardware ap-pliance as a co-processor for the ESB can alleviate the limitation of wire speeds.

The Reference Architecture From the discussion in the previous section, it should be clear that a hardware appliance is well suited for simple, high traffic, repeatable, brokering operations. It will perform the gatekeeping functions as an edge gateway. On the other hand, the software ESB fits well in providing service brokering, complex message process-ing, and comprehensive integration functionality.

Key Takeaways Coming back to the title of the article, what do we get for our SOA – a hardware appliance or a software ESB? The answer is the usual: “It depends!” You may start with the software ESB when service brokering and integration is the primary driving factor for a project, especially when services use is internal within an organization. For a smaller deployment in an organizational unit, it is possible to stick with just a software ESB, with the more traditional network firewalls provid-ing the missing gatekeeping functions. Start with the hardware appliance when perimeter security is a concern, the service consumers are in the extranet or a different organization, and the services have already been enabled for reuse. For small organizations where integration needs are very simple, it might suffice for service brokering as well. Ultimately the lack of the appliance’s flexibility and an inability to support complex integra-

tion patterns will result in experiencing the need for a software ESB.The hardware appliance is a perfect gatekeeper at the perimeter while the software ESB is a perfect services broker. A full-blown in-frastructure will typically deploy a hardware appliance–based solu-tion at the perimeter with a software ESB doing service mediation, routing, protocol bridging, and services/application integration. Eventually for a fully baked SOA, both the appliances and software ESBs will play important and distinct roles. It should also be noted that because of the stove-piped orga-nizational structures in a lot of companies, federated ESBs will be inevitable. There could be a distinct ESB deployed for each organization or application domain. Not only can the ESBs be from different vendors, they could easily be a mix and match of hardware appliances and software ESBs in this federation.

About the Author

Shiva Bhajekar, a Master Principal Sales Consultant in Oracle’s North America technology

organization, advises Fortune 1000 companies to define and implement their SOA and BPM

strategies and/or application virtualization while evangelizing Oracle’s solutions. He plays

the role of a Business Solutions Architect creating customized solutions for companies that

add immediate business value to their operations. Having been in customer-facing roles for

the last 13 years, he previously delivered several mission-critical solutions at Netscape Profes-

sional Services to companies such as S&P, Sony and Warner Music.

[email protected]

Figure 3: Conceptual architecture for gate keeping and service brokering roles

Advertiser Index ADVERTISER URL PHONE PG

General Conditions: The Publisher reserves the right to refuse any advertising not meeting the standards that are set to protect the high edito-rial quality of .Net Developer’s Journal. All advertising is subject to approval by the Publisher. The Publisher assumes no liability for any costs or damages incurred if for any reason the Publisher fails to publish an advertisement. In no event shall the Publisher be liable for any costs or damages in excess of the cost of the advertisement as a result of a mistake in the advertisement or for any other reason. The Advertiser is fully responsible for all financial liability and terms of the contract executed by the agents or agencies who are acting on behalf of the Advertiser. Conditions set in this document (except the rates) are subject to change by the Publisher without notice. No conditions other than those set forth in this “General Conditions Document” shall be binding upon the Publisher. Advertisers (and their agencies) are fully responsible for the content of their advertisements printed in .Net Developer’s Journal. Advertisements are to be printed at the discretion of the Publisher. This discretion includes the positioning of the advertisement, except for “preferred positions” described in the rate table. Cancellations and changes to adver-tisements must be made in writing before the closing date. “Publisher” in this “General Conditions Document” refers to SYS-CON Publications, Inc. This index is provided as an additional service to our readers. The publisher does not assume any liability for errors or omissions.

HP www.hp.com/go/soa 2

Managed Methods www.managedmethods.com 36

Rogue Wave www.roguewave.com 5

SYS-CON Books www.theriabook.com 202-802-3020 25

SYS-CON Events www.events.sys-con.com 202-802-3020 35

WSO2 http://wso2.com/welcome/esb 7

DreamFace http://www.dreamface-interactive.com 21

SYS-CON Media www.sys-con.com 201-802-3020 27

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

http://www.events.sys-con.com

http://www.managedmethods.com

Date post:	18-Dec-2014
Category:	Documents
Upload:	zubin67
View:	731 times
Download:	9 times

Infrastructure

Documents