THE WORLD’S LEADING MAGAZINE DEDICATED TO WEB SERVICES TECHNOLOGIES
                                                  www....
FROM THE EDITOR


                                                                                                        ...
INSIDE
                    2   How to Sell an SOA
                        SEAN RHODY




                    6   BPEL Comi...
BPEL


                                                                                                  www.SOA.SYS-CON.c...
BPEL




                                            was formed and started working on the two specifications.             ...
BPEL




BPEL4People specifications, the specifications do include enough               Also, within the broader umbrella of...
GOVERNANCE




                                                                                                           ...
Infrastructure
Infrastructure
Infrastructure
Infrastructure
Infrastructure
Infrastructure
Infrastructure
Infrastructure
Infrastructure
Infrastructure
Infrastructure
Infrastructure
Upcoming SlideShare
Loading in...5
×

Infrastructure

781

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
781
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Infrastructure

  1. 1. THE WORLD’S LEADING MAGAZINE DEDICATED TO WEB SERVICES TECHNOLOGIES www.SOA.SYS-CON.com SEPTEMBER 2008 / VOLUME: 8 ISSUE 9 Managing Your BPEL Infrastructure DEBU PANDA AND ARVIND MAHESHWARI 16 12 Getting a Handle on SOA Risk PAUL C. BROWN 24 The Case for Coordinated EDM & SOA Strategies KEITH R. WORFOLK
  2. 2. FROM THE EDITOR www.SOA.SYS-CON.com How to Sell an SOA 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 WRITTEN BY SEAN RHODY TECHNICAL ADVISORY BOARD JP Morgenthal, Andy Roberts, Michael A. Sick, Simeon Simeonov A s you can imagine, I spend a lot to implement and thus less costly by some EDITORIAL of time speaking to people about factor is in most cases not a sufficient jus- Editor-in-Chief Sean Rhody sean@sys-con.com service-oriented architecture (and tification. The idea of tacking it on to some XML Editor its variants for infrastructure and enterprise) in-flight project usually creates howls from Hitesh Seth and about how best to create a true imple- the business owner who somehow is being Industry Editor mentation (or at least, an effective one). asked to pay much more than the base Norbert Mikula norbert@sys-con.com There is a great deal of detail in creating such project should cost. Product Review Editor an artifact – design yes, but also implementa- Really, there has to be another way. And Brian Barbash bbarbash@sys-con.com tion, operational details, governance, and a there is – making the business a partner. .NET Editor myriad of other tasks that can easily take up a SOA is something that enables changes to Dave Rader davidr@fusiontech.com chief architect’s entire day. These tasks are all how the IT organization reacts to business Security Editor Michael Mosher wsjsecurity@sys-con.com vital to the actual creation of the architecture, requirements and new functionality re- but for all that they may seem the fundamen- quests, making them easier to accomplish, Research Editor Bahadir Karuv, Ph.D Bahadir@sys-con.com tal first steps in evolving the IT shop, and and therefore both faster and cheaper. Technical Editors yet there are even more necessary first steps Building a case with the business that these Andrew Astor andy@enterprisedb.com – selling the concept in the first place. changes are important and justify slightly David Chappell chappell@sonicsoftware.com SOA in many ways reminds me of rela- hire costs for the first few projects is helpful. Anne Thomas Manes anne@manes.net Mike Sick msick@sys-con.com tional database technology. At its first incep- Finding a large scale transformation project Michael Wacey mwacey@csc.com tion, the concept of an RDBMS must have is even better. International Technical Editor had a hard sell. Sure it made perfect sense In a large scale transformation, many IT Ajit Sagar ajitsagar@sys-con.com A LT E R N AT 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 : to arrange the data and ensure that the rela- tionships between the data were enforced, systems are going to be touched, re-aligned, or replaced. New data models will come Executive Editor Nancy Valentine nancy@sys-con.com Rethink The Architecture, Rethink The Business. but what was the business case that enabled the purchase of this new and expensive into being, and new services will be needed. This is not to say that it’s justification for Associate Online Editor Lindsay Hock lindsay@sys-con.com (Rethink Your Bottom Line.) technology? You certainly couldn’t say that throwing the kitchen sink into the IT budget by introducing a relation database, you were during a transformation, but a case can eas- Alternative thinking is shifting your SOA strategy to focus on business initiatives going to make the company $20 million a ily be made based on the integration needs PRODUCTION rather than technology initiatives. (Head in the game, not on bits and bytes.) year annually. So the RDBMS slowly made its that are without a doubt going to be part of ART DIRECTOR way into the IT arsenal a little at a time, with the program. Instead of some cost savings Abraham Addo abraham@sys-con.com justifications added in a variety of ways. in the future, by going with SOA in a trans- It’s using governance to speed the adoption and reuse of services—keeping ASSOCIATE ART DIRECTOR SOA is even more complex – it affects al- formation, the cost savings can be realized Tami Beatty tami @sys-con.com everything from getting out of hand. most every aspect of the enterprise if done within the program. to the fullest, and yet the basic premise is This isn’t what the IT world wants to hear It’s building quality and management into every step, from idea through very similar to the RDBMS – it’s a better – there’s a strong push from vendors and EDITORIAL OFFICES SYS-CON MEDIA execution, to help ensure you’re always up and running smoothly. way to work. I imagine the discovery of the platform providers to go SOA – but it is the 577 CHESTNUT RIDGE ROAD, WOODCLIFF LAKE, NJ 07677 wheel engendered similar thought – “Duh, reality of software systems. The concept of TELEPHONE: 201 802-3000 FAX: 201 782-9637 why didn’t I think of that, it’s so simple.” a system that constantly requires renewal SOA World Magazine Digital Edition (ISSN# 1535-6906) It’s capitalizing on software that works across platforms, so your business Is published monthly (12 times a year) And yet there’s a mountain of legacy code, is foreign for some reason to financial folks, By SYS-CON Publications, Inc. operates efficiently through mergers and acquisitions and alliances 50 years worth in some cases, that prevents even though there are countless examples Periodicals postage pending and massive growth. Woodcliff Lake, NJ 07677 and additional mailing offices a simple rip and replace. Not to mention of the concept in the world. Software has POSTMASTER: Send address changes to: the cost problem. a life cycle, and if you don’t feed your invest- But the real challenge in SOA is finding ment, it dies. Nevertheless, in order to SOA World Magazine, SYS-CON Publications, Inc. 577 Chestnut Ridge Road, Woodcliff Lake, NJ 07677 It’s choosing the right SOA partner so you can get on with the business the ROI in IT. The logical statement that move to an SOA environment, we need to of the business. (Hello, tomorrow.) spending $20 million (I’m just picking a recognize the need to involve the business big number here, not stating that an SOA side of the organization in our activities and ©COPYRIGHT Copyright © 2008 by SYS-CON Publications, Inc. All rights reserved. No part of this publication may be conversion should cost that) on conversion make a case in a language they understand 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 will in the future make all IT projects easier in order to be successful. 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 About the Author the companies or products covered in Web Services Journal. Technology for better business outcomes. hp.com/go/soa 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. sean@sys-con.com www.SYS-CON.com ©2008 Hewlett-Packard Development Company, L.P. 2 SEPTEMBER 2008 www.SOA.sys-con.com www.SOA.sys-con.com SEPTEMBER 2008 3
  3. 3. 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 12 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 16 Appliance SHIVA BHAJEKAR 4 SEPTEMBER 2008 www.SOA.sys-con.com
  4. 4. BPEL www.SOA.SYS-CON.com CORPORATE President and CEO Fuat Kircaali fuat@sys-con.com Senior VP, Editorial & Events BPEL Coming to People Jeremy Geelan jeremy@sys-con.com ADVERTISING Increasing the market adoption of BPM by Senior VP, Sales & Marketing Carmen Gonzalez carmen@sys-con.com mainstream enterprises Advertising Sales Director Megan Mussa megan@sys-con.com Advertising & Events Manager Corinna Melcon corinna@sys-con.com BY MANOJ DAS AND BHAGAT NAINANI Events Associates Krisandra Russo krisandra@sys-con.com Susan Wechtler susan@sys-con.com B usiness 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 CUSTOMER RELATIONS (WS-BPEL) standard. Most real-world processes involve some human interaction, Circulation Service Coordinators for example, for approvals or exception handling. While WS-BPEL addresses the industry’s Edna Earle Russell edna@sys-con.com 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 specifications 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. SYS-CON.COM Consultant Information Systems BPEL and People Robert Diamond robert@sys-con.com BPEL is a standard owned by OASIS that provides rich and comprehensive orchestration Web Designers Stephen Kilmurray stephen@sys-con.com semantics. At a high level, BPEL is a language that provides a rich set of activities and ex- Richard Walter richard@sys-con.com 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 ACCOUNTING be needed to make some decisions and approvals, perform tasks that are inherently man- Financial Analyst ual (such as talk to a customer) or have not yet been automated, and manage exceptions in Joan LaRose joan@sys-con.com a process. People also need to be notified of interesting state changes and exceptions in a Accounts Payable process. Betty White betty@sys-con.com BPEL’s rich support for asynchronous services enables calls to an external workflow 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 Workflow.” However, there are certain aspects of human interactions that are unique. For example, a process SUBSCRIPTIONS must specify which task needs to be performed, as well as who the stakeholders are (and SUBSCRIBE@SYS-CON.COM 1-201-802-3012 or 1-888-303-5282 their interests), the expectations around performance of the task, and what should happen For subscriptions and requests for bulk orders, if the task is not performed within specified deadlines. Although BPEL can facilitate human please send your letters to Subscription Department Cover Price: $6.99/issue interactions, its failure to fully grasp such interactions and their associated characteristics Domestic: $99/yr (12 issues) leads to two problems. First, every implementation achieves these goals by using propri- (U.S. Banks or Money Orders) etary extensions. Second, a lack of specific human interaction features makes the modeling of such interactions less intuitive and more verbose than it needs to be. For list rental information: BPEL4People and WS-HumanTask Overview Kevin Collopy: 845 731-2684, kevin.collopy@edithroman.com; Frank Cipolla: 845 731-3832, frank.cipolla@epostdirect.com In April 2007, BPEL finally 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 SYS-CON Publications, Inc., reserves the right to revise, republish and authorize its readers to use the articles group of six vendors — Active Endpoints, Adobe, BEA, IBM, Oracle, and SAP — published submitted for publication. a set of two complementary proposed specifications, “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 www.SYS-CON.com 6 SEPTEMBER 2008 www.SOA.sys-con.com www.SOA.sys-con.com SEPTEMBER 2008 7
  5. 5. BPEL was formed and started working on the two specifications. ing attachments or forwarding the tasks. They can also perform Timeouts and Escalations The goals of these specifications are to enable both portability business administration functions such as suspending tasks or A key benefit and requirement of managing human activities and interoperability by providing a standard definition of: resolving missed deadlines. Task stakeholders are only assigned using a process or task engine is the ability to manage the timely • BPEL extensions that define human interactions in BPEL process- to a specific task instance; business administrators are assigned performance of tasks and associated escalations. es to all instances of a task type. The BPEL4People specifications allow multiple deadlines to be • Models that define human tasks • Notification recipients — Anyone included on a notification list associated with a task. These deadlines can be start deadlines or • Programmable interfaces that allow client applications to work is classified as a notification recipient. completion deadlines. Both deadlines can be specified as a dura- with human tasks tion (period of time), or a deadline (point in time), and are calcu- Assignments lated from the time the task is created. Expressions can be used to WS-HumanTask defines human tasks, including their properties, To assign actual people to these various roles, the compute the deadlines at runtime, enabling both context-based behavior, and set of operations needed to manipulate them. Al- BPEL4People specifications support the static binding, late bind- deadlines (for example, deadlines based on order amounts or a though WS-HumanTask is a sister specification to WS-BPEL4People ing, and dynamic binding of people to roles. Assignments are customer’s premium status) and the integration of a business cal- and is expected to be widely used in conjunction with BPEL, it is made via: endar (for example, to compute the number of calendar days that designed to be a standalone specification, enabling invocation of correspond to three working days). tasks from any business process (BPEL or otherwise), as well as • Literals — In its simplest form, people are literally assigned to One or more escalations, with associated conditions, can be from any Web Services client. (Note that throughout this article, we roles using user identifier(s) and group name(s). This form of associated with a deadline. An escalation is triggered if the point of use task as shorthand for WS-HumanTask task.) assignment is most common when tasks are assigned to named time specified as a deadline has been reached or the duration has BPEL4People uses BPEL’s extension mechanisms to layer human groups (or work queues). elapsed, and the associated condition evaluates to true. Escalations Figure 1 BPEL4People logical architecture interaction capabilities on top of BPEL. At the core of these exten- • Logical people group — A logical people group represents a can use notifications to inform people of the status of the task or sions is People Activity, which enables a task to be invoked from a person or set of persons, or one or more named groups. A logical reassign the task to different users or groups. BPEL process. Other extensions bind people assignments to people people group is bound to actual people and groups at deploy- Deadlines and escalations are illustrated in Figure 2. directories, assign task properties, and manipulate tasks in BPEL ment using a query, with zero or more query parameters, against processes. a people/identity directory. This form of assignment is useful in Task Lifecycle Figure 1 shows the logical architecture of the BPEL4People scenarios such as skill-based assignment. To understand these task concepts as a complete picture, it helps specifications. A BPEL process invokes a People Activity (task). A • Expressions — Expressions can be used in both a task defini- to visualize the various task states and transitions. Figure 3 shows a WS-HumanTask engine manages the lifecycle of the task and pro- tion and in the invoking BPEL process to assign people to roles. simplified view of a task’s lifecycle. vides interfaces to the client application for operating on the task. This form of assignment is most common when an assignment All tasks start in the Created state. A task remains in the Created This separation of the process and the task engine allows both to be depends on the actual performer of a previous task, as when state until it is activated (if scheduled activation is used) and has deployed, managed, and scaled independently. It also enables the implementing the 4-eyes principle. potential owners. If there are no potential owners, the task remains use of a unified task engine working with multiple BPEL and other in the Created state until the business owner has performed nomi- process engines, possibly from different vendors. WS-BPEL4People Delegation and Nomination nation. also enables inclusion of the task definition inline in the BPEL pro- BPEL4People specifications support the assignment of task Once activated, a task moves into the Ready state if it has multi- cess. instances at runtime, particularly two common workflow patterns: ple potential owners (for example, when it is assigned to a group or delegation and nomination. a queue) or into the Reserved state if there is only a single potential People Roles The BPEL4People specifications enable the definition of con- owner. Tasks in the Ready state move into the Reserved state when A key aspect of human interactions in a process is the definition straints on delegation. A task definition can specify that it can be one of the potential owners claims it. of who is responsible for doing what. The BPEL4People specifica- delegated to anyone, to only potential owners as determined by as- Once the actual owner starts working on the task, it transitions tions go beyond the notion of a task performer and include the signment, to a specific set of people or named groups, or to no one. into the In Progress state. Upon successful completion, it transi- Figure 2 Deadlines and escalations following human roles: By default, tasks can be delegated to anyone. tions into the Completed state. As mentioned earlier, task stakeholders can assign task instances A task in the Reserved or In Progress state can be released by the • Actual owner — The actual owner of a task is the person doing at runtime. This, in conjunction with the fact that a task can be cre- owners, moving it back to the Ready state, where it waits for an- the task. The actual owner can perform actions associated with ated without an owner being assigned, enables a pattern commonly other potential owner to claim it. A task in the In Progress state can the task as well as forward, suspend, and resume a task. known as nomination in which business users overseeing the pro- be stopped by the owner, which moves it back into the Reserved • Potential owners — The concept of potential owners is useful cess nominate users to perform a task on an instance-by-instance state. when multiple people — usually members of a named group basis. Tasks in an active state — Ready, Reserved, or In Progress — can — work on shared tasks. A potential owner becomes the actual also be delegated and forwarded by actual owners, potential own- owner by claiming the task. Notifications ers, and business administrators. This transitions the task to the • Excluded owners — When a task is assigned to a defined group Notifications inform people of noteworthy events, call their Ready or Reserved state, as appropriate. Business data associated of people, some users can be explicitly excluded from being a attention to an action they need to take, or advise them of a with the task is maintained, including any updates. potential owner. This is particularly useful when having to ensure change in status. The BPEL4People specifications treat notifica- The BPEL4People specifications allow some tasks to be skipped. that the person reviewing a task is not the person performing it tions as a special case of human tasks; most of the task discus- A task, if skipped, moves into the Obsolete end state. Tasks can (the 4-eyes principle). sions in this article also apply to notifications. There are a few also be terminated, usually by the surrounding business process; • Task initiator—A task initiator is the person initiating the task or differences between notifications and tasks, for example, notifi- terminated tasks also move to the Obsolete state. The BPEL4People the business process. The initiator can track the status of the task; cations are essentially one-way — the progress of the caller isn’t specifications also allow any active task to be suspended and collaboration with the initiator can also be needed to close the blocked for the notification the way it is for a task. Notifications resumed. Suspended tasks resume to the state in which they were task. can be sent to multiple recipients and can be managed by one suspended. • Task stakeholders and business administrators — Task stake- or many business administrators; the other roles do not apply holders and business administrators are ultimately responsible to notifications. Notifications also don’t have attachments, Task Presentation and User Interaction for the oversight and the performance of the task. They can comments, or deadlines (these concepts, as applied to tasks, While the presentation of tasks via a client application or participate in the performance of the task, for example, by add- are discussed later in this article). other mechanisms such as e-mail is outside the scope of the Figure 3 WS-HumanTask task lifecycle 8 SEPTEMBER 2008 www.SOA.sys-con.com www.SOA.sys-con.com SEPTEMBER 2008 9
  6. 6. BPEL BPEL4People specifications, the specifications do include enough Also, within the broader umbrella of related standards in the Listing 1 <extension namespace=http://www.example.org/WS-HT mustUnderstand=”yes”/> ... </extensions> definition that enables a standard interface for task presentation. business process management (BPM) area, the next frontier is <htd:task name=”ResolveTicketTask”> ... Presentation elements in a task define how information about standardization of notation and its alignment with BPEL and ... <b4p:humanInteractions> <!-- Define How Task is Presented to Users --> <htd:logicalPeopleGroups> tasks is made available in a human-readable way. They include a BPEL4People. Significant efforts are underway at the Object Man- <htd:presentationElements> <!-- Service Agents logical people group --> <!-- Name: A short title --> <htd:logicalPeopleGroup name=”ServiceAgents”> name (a short title of a task), a subject (a longer text describing the agement Group to define a Business Process Modeling Notation <htd:name xml:lang=”en-US”> Resolve Trouble Ticket <htd:documentation xml:lang=”en-US”> task, and a description (a long description of the task, which can (BPMN) 2.0 specification. Group of service agents for a </htd:name> region able to support a product. be in HTML). Both the subject and the description can be param- <htd:name xml:lang=”de-DE”> </htd:documentation> eterized. Values for the presentation elements can be specified for Summary </htd:name> Behebung der Problemmeldung <htd:parameter name=”region” type=”xsd: string” /> multiple languages. Listing 1 illustrates the concept of presentation The field of Business Process Management (BPM) is experiencing <htd:parameter name=”product” type=”xsd: <htd:presentationParameters> string” /> elements with an example. renewed effort, propelled by the success of BPEL as a standard and <htd:presentationParameter name=”product “ type=”xsd:string”> htd:getInput(“serviceRequest”)/product </htd:logicalPeopleGroup> A task definition can include rendering elements, which provide its adoption by mainstream vendors and enterprises. BPEL skills, </htd:presentationParameter> ... an extensible mechanism for specifying UI renderings for tasks. training, and resources are now widely available and the move away <htd:presentationParameter name=”user” type=”xsd:string”> </b4p:humanInteractions> htd:getInput(“serviceRequest”)/user ... The BPEL4People specifications also support attachments and from proprietary skills and technologies is driving a lower total cost </htd:presentationParameter> <sequence> <htd:presentationParameter name=”issueAbstract” type=”xsd:string”> ... comments, which are stored in the task operation data along with of ownership (TCO). <!-- Invoke people activity Resolve Ticket --> htd:getInput(“serviceRequest”)/issue/abstract <extensionActivity> information on when they were added and by whom. Attachments The BPEL4People specifications address BPEL’s lack of explicit </htd:presentationParameter> <b4p:peopleActivity name=”ResolveTicket” and comments can also be shared between tasks and enclosing support for human interactions and remove one of the very <htd:presentationParameter name=”issueDetails” type=”xsd:string”> inputVariable=”serviceRequest” outputVaria htd:getInput(“serviceRequest”)/issue/details ble=”serviceResolution” ...> BPEL processes, as well as between different tasks. few objections to BPEL. The BPEL4People architecture, which </htd:presentationParameter> </htd:presentationParameters> <!—use Task Resolve Ticket Task --> The BPEL4People specifications also define standard pro- separates the task engine from the process engine, also signifi- <!-- Subject: A short description; typically displayed in <b4p:localTask reference=”tns: gramming interfaces that a task list client application can use cantly reduces customer risk, because many customers can have ResolveTicketTask”/> Task List views --> <htd:peopleAssignments> to work against any WS-HumanTask–compliant implementa- multiple process engines but prefer to have a unified task list <htd:subject xml:lang=”en-US”> <!-- Use logical people group to tion. application. Resolve problem with $product for $user assign Resolve Task ticket to </htd:subject> Service Agents based BPEL4People, along with BPMN, will complete the BPEL story for <htd:subject xml:lang=”de-DE”> on region and product --> Behebung des Problems von Produkt $product für An Example: Help Desk process management. We believe it will significantly increase the $user <htd:potentialOwners> <htd:from logicalPeopl Listings 2 and 3 illustrate the concepts discussed in this article market adoption of BPM by mainstream enterprises. </htd:subject> eGroup=”ServiceAgents”> using a help desk scenario. (Listing 3 can be downloaded from this <htd:description xml:lang=”en-US” contentType=”text/plain”> <htd:argument name=”region”> User $user is having following problem with product article online at http://soa.sys-con.com.) The Help Desk BPEL pro- References $product $serviceRequest/region cess invokes three human activities: Resolve Ticket (task), Approve • WS-BPEL Extension for People, Version 1.0. http://xml.coverp- Abstract: $issueAbstract </htd:argument> Resolution (task), and Notify User (notification). ages.org/BPEL4People-V1-200706.pdf. Details: $issueDetails <htd:argu- The use of logical personnel groups to perform skill-based as- </htd:description> ment name=”product”> signments is illustrated in Resolve Ticket task, which also illustrates • Web Services Human Task (WS-HumanTask), Version 1.0. http:// <htd:description xml:lang=”en-US” contentType=”text/html”> $serviceRequest/product <p> the concept of potential owners (all service agents with matching xml.coverpages.org/WS-HumanTask-V1-200706.pdf. <b>User</b> : $user <br> <b>Product</b>: $product </htd:argument> skills) and business owner (the service center manager). The 4-eyes </p> </htd:from> principle is illustrated in the invocation of the Approve Resolution • OASIS WS-BPEL Extension for People (BPEL4People) Techni- <h1>Abstract</h1> </htd:potentialOwners> <p>$issueAbstract</p> </htd:peopleAssignments> task in which we exclude the performer of the Resolve Ticket from cal Committee. http://www.oasis-open.org/committees/ <h1>Details</h1> </b4p:localTask> <p>$issueDetails</p> </b4p:peopleActivity> potential owners. The Resolve Ticket task also illustrates the use of bpel4people/charter.php. </extensionActivity> </htd:description> ... deadlines and presentation elements. • InfoQ Interviews BPEL4People Representatives. http://www. <htd:description xml:lang=”de-DE” contentType=”text/plain”> <!-- Invoke people activity Review Resolution --> Der Benutzer $user hat das folgende Problem mit dem Produkt <extensionActivity> What’s Next infoq.com/articles/bpel4people-tc. $product <b4p:peopleActivity name=”ReviewResolution” ...> People often ask whether the BPEL4People specifications will Kurzbeschreibung: $issueAbstract <b4p:localTask reference=”tns:ReviewReso- Nähere Angaben: $issueDetails lutionTask”> cause changes to the BPEL specification itself. We do not anticipate • A Close Look at BPEL 2.0. http://www.sys-con.com/read/434430. <htd:peopleAssignments> </htd:description> <!-- Note: Potential Owners are such an impact. BPEL was designed with extensibility in mind, and htm. fixed to a named group ‘ResolutionReviewers’. the BPEL4People specifications comply with BPEL’s extensibility <htd:description xml:lang=”de-DE” contentType=”text/html”> Potential Owners as- <p> signed to this group in Task definition and not here --> mechanisms. • BPEL’s Growing Up. http://websphere.sys-con.com/read/346372. <b>Benutzer</b> : $user <br> <!-- Exclude the person doing <b>Produkt</b>: $product the resolution from reviewing --> According to the OASIS BPEL4People Technical Committee htm. </p> <h1>Kurzbeschreibung</h1> <htd:excludedOwners> charter, the standardization should take about 18 months. During <p>$issueAbstract</p> <htd:from>b4p: this period, it’s reasonable to expect that the standard will not only • BPEL Processes and Human Workflow. http://webservices.sys- <h1>Nähere Angaben</h1> getActualOwner(“tns:ResolveTicket”)</htd:from> <p>$issueDetails</p> </htd:exccludedOwners> become more rigorous but also include more functionality. Two con.com/read/204417.htm. </htd:description> </htd:peopleAssignments> </htd:presentationElements> </b4p:localTask> enhancements that we hope will make it to the final standard are </b4p:peopleActivity> patterns and policies. We’d like to see support for common routing ... <!-- Notify User of Resolution --> patterns (such as management chain approvals and group votes) About the Authors </htd:task> <extensionActivity> ... <b4p:peopleActivity name=”NotifyUser” ...> in a simple, intuitive, and declarative fashion. Likewise, support for Manoj Das is director of BPM product management at Oracle. His focus is on BPMN, BPEL, hu- <b4p:localNotification reference=”tns: policies such as automatic skip and exception handling would be a man workflow, and business rules. He is one of the co-authors of the BPEL4People specifica- Listing 2 ResolutionNotification”> <htd:peopleAssignments> welcome addition. tions published in June 2007. Manoj joined Oracle with the Siebel acquisition, where he was <!—Send notification to user <process submitting Help Desk ticket --> While it’s reasonable to expect that meaningful implementa- responsible for driving the next-generation process-centric application platform, leveraging name=”HelpDesk” <htd:recipients> tions of BPEL4People will be available only when the specification BPMN and BPEL. ... <bpel: xmlns:b4p=”http://www.example.org/BPEL4People” from>$serviceRequest/user </bpel:from> approaches the finish line, there are vendors, including Oracle, xmlns:htd=”http://www.example.org/WS-HT”> </htd:recipients> ... </htd:peopleAssignments> that essentially implement very similar concepts in a very similar Bhagat Nainani is a senior development director in the Oracle Fusion Middleware division. <!-- Declare that BPEL engine must understand BPEL4People to run this </b4p:localNotification > architecture. In fact, the BPEL4People specifications were created He currently leads the development of BPM and human workflow features. He has more than process --> </b4p:peopleActivity> <extensions> ... by leveraging customer scenarios and requirements learned from 14 years experience with BPM, application integration technologies, distributed systems, and <extension namespace=http://www.example.org/BPEL4People </process> mustUnderstand=”yes”/> support of such implementations. databases. 10 SEPTEMBER 2008 www.SOA.sys-con.com www.SOA.sys-con.com SEPTEMBER 2008 11
  7. 7. GOVERNANCE planning whereby ideas for new projects are evaluated and pri- lem. To determine whether a service makes sense, other potential oritized. Budgetary estimates are prepared, outlining the antici- uses need to be examined. Who has the proper perspective to do pated project cost and time to complete. Finally, these proposals this exploration? are compared against the available budget, and a certain number The answer should be the most experienced architects in your of projects are funded. Depending on the organization and how organization — people who know the landscape of the enterprise budgets are allocated, this may be a singular centralized activity or and can determine whether the service will fit. These are the senior a series of planning activities, one for each IT organization holding systems architects for infrastructure services, and the senior busi- a development budget. ness process architects for business services. Most of the time these To be successful with services, you have to extend this planning people are not actively involved in the current project, so you need activity a bit. Recognizing that you won’t get an ROI from the first a procedure to get them involved and to make their response to the use of a service, it is prudent to think about the portfolio of projects request a priority. in terms of which ones will create services and which ones will For efficiency, the involvement of senior architects should be be consumers of services. This obviously creates dependencies structured into two distinct tasks: justification and specification. between projects, impacting the sequence in which the projects Justification should focus on weeding out the proposals that don’t will be executed. It may also influence your thinking about project make sense as services. When justification concludes that a service priorities. If a major project requires a service that does not yet does make sense, a deeper exploration of these uses is required so exist, for example, the creation of that service must become part of that the service and its operations can be fully specified. Once the the portfolio plan, whether it is in that project or another. architects have completed the specification then responsibility for There is a measure of speculation in this exercise — about what the implementation of the service can revert back to the project is important to the business, about what the project cost and team. Specifically, governance of service justification and specifica- schedule will be, and about what services will be created and used. tion requires: Because of this, expect that reality will render some of these specu- lations inaccurate and alter priorities. 1. A procedure to get the appropriate senior architects involved in The typical project portfolio planning process has an annual cycle evaluating and specifying proposed services. that is synchronized with the fiscal calendar of the enterprise. At a 2. Prioritization of senior architects’ time to ensure responses to minimum, you need to integrate services planning into this annual evaluation and specification requests in a timely manner. process. You also need to add an activity for developing a cross-proj- 3. Well-defined criteria for evaluating service proposals and specify- ect services plan, and a governance step for reviewing this plan before ing services. Getting a Handle on SOA Risk the project portfolio is finalized. Besdies this annual exercise, it is pru- 4. A checklist item in the project’s architecture review to ensure that dent to add a quarterly or semi-annual checkpoint. This governance proposed new services have been appropriately justified. step compares the actual project progress against the plan, as well as cost and schedule progress, and determines whether adjustments to Service Architecture, Implementation, and Deployment Governance is the process of risk management the project portfolio are warranted. Because the operation of other application components depends on the proper operation of services, more stability is expected from 2. Service Design Governance services in terms of functionality, performance, and reliability. Deciding to build a service is an investment decision, and should These expectations increase demand for service implementation be treated as such. Implementing functionality as a service always governance in two areas: architecture and testing. With a service BY PAUL C. BROWN requires more work than a basic implementation of the function- architecture, performance and capacity require particularly close ality. The service, by itself, provides no value. Its value lies in its attention. The obvious aspect of this is ensuring that the design is use, and its return on investment relies on its continued use in the capable of providing the specified performance when loaded to its 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 light of business process and systems changes. So the decision to planned capacity. Not as obvious is the need to design the ability to build a service requires weighing the savings to be derived through measure into the service and to report the actual demands that are are financial, while others are operational. Fortunately, all of this risk can be satisfactorily mitigated through appropriate gover- continued use (i.e., avoiding subsequent modifications) against the being put on it while it is in use. These measurements will enable you incremental cost of converting the functionality into a service. to determine when the demands being put on the service are begin- nance activities. ning to approach the design limits and additional capacity is needed. Service Justification and Specification Another challenge to service architecture is scalability. The an- Justifying a service means making a determination that the ad- ticipated future use of the service may call for capacity well beyond S imply put, governance is the process of risk management. The important thing to remember is that the governance ditional cost involved in implementing functionality as a service is the initial demand — so far beyond that it is not cost-effective to Without proper governance, services may be built that are processes you put in place must not only determine the points justified by anticipated future cost avoidance. deploy full service capacity initially. In such cases, it is prudent to missing the basic functionality required, that only satisfy at which you will assess risk, but confirm that the appropriate Specifying a service means defining it so that it will support antici- design the service in such a way that capacity can be incrementally one use (a waste of the cost and resources involved in creating a risk management strategies have been employed. But before you pated future use without further modification. Accomplishing this added as new service users come on line. Documentation must service), or that require costly modifications to be reused. Even can define the governance, you have to define the process that is requires a due diligence analysis of these anticipated usages — a bit be provided describing how capacity can be incrementally added, when services are well-designed and appropriate for a variety of being governed. The actual processes used will vary greatly from of “crystal ball” gazing. including instructions for calculating the resources required to sup- applications, they may not be reused simply because the chain enterprise to enterprise, driven by both cultural and organizational While some projects may be chartered exclusively to build new port different demand levels. Finally, thorough testing of the service of communication breaks down — the advertising of available differences. Despite these variations, successful SOA processes all services, most arise during the course of ordinary development prior to its integration into the overall SOA — although sometimes services is inadequate, or the indexing and documentation associ- share some common features and governance points at which SOA initiatives when the project team recognizes that a particular set of tedious and time-consuming — will cost less than discovering and ated with them is insufficient to support effective identification and risks are evaluated and mitigated. functionality might make sense as a service. The problem that these fixing problems after integration. deployment. Finally, changing business circumstances are also a project teams generally face is that the only use of the proposed risk factor, since they can end up changing the requirements for a 1. Project Portfolio Planning Governance service that they are intimately familiar with is the one associated Service Documentation particular service. Most enterprises already have some form of project portfolio with the present project. This narrow perspective presents a prob- Because services should be designed to support future use, an 12 SEPTEMBER 2008 www.SOA.sys-con.com www.SOA.sys-con.com SEPTEMBER 2008 13

×