Yo! BPEL4People Specifications released - and WS-Humantask too!

[former_member181875]

*transcript added* Human integration in the Web Service-orientated AKA SOA world is gets one more dimension of reality. Business Process Management has that gaping hole called human-integration not just plugged with a stopper but plugged with a standardized funnel to just about every type of software involving human interaction. BPEL4People and WS-HumanTask It's no longer mythical. Like Dr Who's Tardis - it's landed - and it's a quantum leap in making business process management truly accessable - the missing link between Service Orchestration and traditional workflow. More modular, more interoperable, more support from other vendors than the white paper - this is one standard that was worth the wait. It's a great development showing SAP's commitment to SOA (remember the Service Component Architecture (SCA) release a short time ago) and Business Process Management (remember the reseller agreement with IDS Scheer announced last week, too). In a nutshell:

• The BPEL4People specifications put down in writing exactly which XML messages flow through your enterprise to enable human interaction in processes in a standardized (cross-vendor) way.
• The specifications deliver the promise setup two years ago in SAP and IBM's BPEL4People whitepaper. All the proposed constellations are supported.
• Virtually all definition aspects; tasks, notifications, escalations, who may perform a task, who may not... and operations; query, forwarding, nominating, attachments, are supported, too.
• But it's been split into two for super-charged modularity:

1. The BPEL4People socket to enable human activities to be plugged into processes.
2. The WS-HumanTask plug to attach tasks/todos to processes, inboxes, or even hard-coded composites requiring task-like interaction.

• It's been supported by not just IBM (and ourselves) who wrote the initial whitepaper, but also by other BPM software vendors - specifically Active EndPoints, Adobe, BEA and Oracle.
• And, it covers interoperability where previously the focus of BPEL had been portability.

Are we excited? You bet we are. Take a look around your home to see just how important plug and socket standardization is compared to standardizing a single entity. It's the fact that this standard is a pair, a brace of standards that makes it so unusual and compelling. In this podcast, which you can download and listen to on your PC or MP3 player, you can hear two of the authors who've been with the initiative from the very beginning explain the impact as well as the intricacies of this brace of standards. Click on the icon at the top right to download the discussion and explanations as well as hearing just a smidge of visioneering. (Diagram showing the constellations, column by column, described in the podcast) The specifications themselves and initial white paper can be read at WS-BPEL Extension for People (BPEL4People) And here are the links to the preceeding podcasts in this series if you're new to BPEL.

1. BPEL in a Nutshell
2. BPEL Glossary for Developers
3. WS-BPEL 2.0 from OASIS - How it has progressed since BPEL 1.1
4. BPEL4People White Paper Overview
5. yet to come: BPEL-SPE - Explanation of the joint SAP/IBM sub-proces white paper

That's all you need to be fully informed - so lean back - listen - and take in the consequences, Alan Rickayzen and Ivana Trickovic *new 27th June 2007 we've added this transcript* BPEL4People and WS-HumanTask Published This podcast continues our series preparing you for the latest developments taking place in BPEL. Today, SAP, together with other leading technology vendors published the long awaited specifications initially proposed in the BPEL4People white paper by SAP and IBM two years ago. In the previous podcasts we gave an overview of what BPEL is used for, how it completes the SOA picture and what is new in the WS-BPEL 2.0 release. Today’s podcast explains how both the WS-BPEL Extension for People and Web Services HumanTask specifications published today enable human interactions in service-orientated processes and applications. Alan, BPEL4People was described as being the biggest buzz-to-bang ratio even though it was only a whitepaper – We’ve topped this by publishing two specifications instead of one – BPEL4People and WS-HumanTask. Whereas BPEL and BPEL4People are process-centric – covering software that deals with orchestrating and driving business processes, WS-HumanTask is about task model and task integration. Tell us about the motivation, reasons for having two specifications instead of one? Directly after of the publication of the white paper, we decided to split the specs into two. It is a tricky thing to do because you have to keep an eagle eye out for dependencies and sometimes go out of your way to find a good solution which would have been easy if it was all combined into one – but the advantages of doing this are huge. Tasks crop up in just about any software you deal with, approvals, help-desk tickets, request for information, carry out a repair… and often the software dealing with the task side of things was then forced to go out and enhance its capabilities (e.g. 2 step approvals) until eventually it found itself spending more and more time-developing workflow software. It’s as if the tyre manufacturers were being forced to develop their own cars. With this brace of specifications – you split the two nicely. You plug the tasks into the processes instead of replicating the tasks into the process infrastructure which is what previously a lot of workflow software forced you to do. Replicating sounds easy – but in effect you’re having to replicate the user interfaces, too, which is a huge amount of work and inevitably cuts the links to the business context of the task. No – that’s a thing of the past. It cost too many companies too much money and made workflow projects long and expensive – I don’t think you’ll see that happening any more. The tyre manufacturers can concentrate on making the best tyres, and the car manufacturers create cars with the flexibility to use whichever tyre manufacturer they prefer and the customer can switch later if they choose to. The two specifications follow the modular approach taken in other Web services specifications and they do not overlap. There is no redundancy. What exactly is the relation between the two specifications and what type of software do they apply to? Each offers its own distinct plug and socket. Taking WS-HumanTask first – it’s about task infrastructures – either stand-alone technology or as part of a business application. This specification covers the operations controlling task’s life-cycle and it’s interaction withthe task list clients because the users need to access and control their tasks as well as execute them. BTW: If you’ve never heard the term before, a task list client is the list of tasks that you see. It’s either a generic inbox or something more specific like SAP’s universal worklist. That’s very important because in practice this software often comes from a different vendor than the vendor that developed the task infrastructure or engine. Also, you want to be able to show tasks from different task engines in a single task list client. The second specification, BPEL4People – describes how the tasks can be embedded in processes. BPEL-based processes. So BPEL and WS-HumanTask are prerequisites for implementing BPEL4People. WS-HumanTask does not have dependencies (other than standard Web Service interfaces, such as WSDL). Standards aim to enable portability and interoperability. BPEL is mainly about portability. You define a BPEL process – it runs on one BPEL infrastructure – you’re protecting your investment because you know that you can transfer it to another, later, if you want to. The goal of this specification pair is to enable not just portability but also run-time interoperability. Ivana, that’s probably the biggest bang in today’s announcement. BPEL4People and WS-HumanTask cover this portability aspect, but in addition they cover interoperability. Interoperability means you can use the task infrastructure with one vendor together with the process infrastructure from another and the task list client from a third. That’s a whole different value proposition to customers. Mix and match however you like. Of course we should not underestimate the value of a unified task model. So it will be easier for customers to choose their best-of-breed for everything. Also it will be easier to combine tasks coming from, say, an SAP ERP system with tasks coming from another provider and integrate them into a composite application which is orchestrated through a proprietary (but BPEL-capable) infrastructure. Yes. A different vendor can deliver another composite mixing and matching tasks from different ISPs, but orchestrate through a different, say open source, or existing ERP, BPEL software. And both composite vendors don’t need to dictate which task list client is used – that’s up to the customer’s deployment. By the way, I’m sure the different vendors will provide benefits when you stick to one breed for all three infrastructures – but the beauty of these specifications is that they enable the 80% case when different vendors interoperate – so in practice that’s going to save customers and ISVs money and time, especially in situations where the missing 20% is more about bells and whistles and has no real business impact. The original white paper introduces five different composition options (constellations) for tasks and processes representing the complete spectrum of human-to-process interaction. They are relevant in different software situations. For example, a process infrastructure may include task capabilities or they are implemented by a separate, stand-alone component, called task infrastructure. How are these constellations covered by these specifications? The specifications cover all 5 constellations. 4 described in the BPEL4People specifications and the fifth described in two variants in the WS-HumanTask paper. If you have a process infrastructure, without the need to interoperate with third-party task infrastructures or one that encompasses task capabilities, then constellations one to three describe your situation and you will implement bpel4people and ws-humantask, without the Web services-based coordination protocol. If you develop a stand-alone task infrastructructure, such as a help desk application, in other words constellations 4 or 5, then it is ws-humantask that you will be interested in. Scenario 5 is relevant if you are only interested in loose integration based in basic Web services-protocols. If you develop a task list client, then it is the programming interface in ws-humantask that covers your needs. What does this new paradigm mean for SAP customers? Do they have to redo all their workflows? No – the paradigm is not new for SAP. In fact, since the early days it’s been the applications building their own tasks with their own user interfaces with an underlying mechanism linked to the organization management (that’s logical – a person is linked to a job- and the job description is a set of task descriptions) and these were plugged into the workflow as and when needed. The same methodology is used in SAP NetWeaver and other SAP products, too. WS-HumanTask differentiates between rendering of task meta data done by task list clients and task execution which is launched by task list client. The rendering of the tasks meta data (subject line, description of what has to be done, notification text) is part of the WS-HumanTask specification. So the user can be presented with this information using one user interface irrespective of how many different task infrastructures deliver the tasks. However, it is up to the task infrastructure how the task execution is rendered - in other words what the screen looks like when the user has to input, and what context information can be displayed as part of the task. What are the advantages of this separation? The task itself is more often than not a complete application in itself rather than a simple form to fill in so a lot of this context will be opaque to the task but important to the person processing it. The specifications enable the tasks to behave this way, but also offer support for more UI control. For example your commonal garden approval which in some cases requires no extra business context. Because WS-HumanTask allows you to specify a UI rendering if you want, this means you can define this in such a way that the task list client can use this rendering description instead of invoking the task infrastructure – bingo – you have enabled your task for offline processing and a familiar UI for the user that isolates users from the different software below the surface. In fact, WS-HumanTask is flexible enough for you to delegate the rendering to the task list client even when no UI rendering is specified as part of the task infrastructure. We use this technique in SAP’s universal worklist and Duet so that simple approvals appear identical to the end user, irrespective of the source of the approval. WS-HumanTask introduces a programming interface that helps to build task list client (i.e. todo-list). This interface is exposed by the task infrastructure and is used to perform different operations on tasks, e.g. to claim task, complete task, reject task, delegate or forward it, and so on. This interface is platform independent. Such a standardized interface allows building task list clients that may show tasks from different WS-HumanTask compliant engines. Before readers start to search in vain, it’s worth explaining why you won’t find a start Task APIs? That’s the paradigm of Web Services. It’s like when you shout to someone “can you catch?” – “right - catch!” they catch the keys, ball even egg – whatever it is you’re throwing. There’s no complicated handshaking (you know – shall I throw it to your left hand?...) You just throw. That’s the whole idea behind Web Services. So you just say “release that sales order”. Whether or not that’s an automatic service, a complete process or a simple task you don’t need to know. It’s up to the receiver to deal with it. So, task is invoked as any other Web service. Web services which are implemented by tasks are annotated using a human task policy assertion(in practice this will probably display an icon in the service repository) and you know you can do even tighter linkage with the sales order release service. So if it is being driven by a bpel process you know that you can specify additional information, such as deadlines or even who should perform the task, if you want to in your people activity. And the lifecycle of the task can be controlled and reacted on even more tightly than if the service does not support WS-HumanTask. So it’s an enhancement of the service, rather than forcing you do determine up front how you want the service to be executed. Not only is there no need for the start Task API, but it would seriously limit your implementation if you forced service providers to provide it. So, once the task has been instantiated, its life-cycle is controlled by communication between the task and the invoking infrastructure using the coordination protocol described in the specifications. This means that from an implementation point of view the control of tass’s life-cycle is delegated to the underlying infrastructure and have to be implement only once in the platform, rather than implementing it for every service as part of the business logic. This means that you have complete Web-Service enablement of your application, and the WS-HumanTask specifics can be handled simply and separately from the underlying business application which handles the business processing of the service. For the development team this means code-once-use-many. And this applies whether the invoker is a process, some sort of user interface for generating stand-alone tasks, or whether it is a business application in itself. This is what we called constellation 4 in the BPEL4People specification (and also the original white paper). We really went out of our way to make sure the specifications mirrored what we proposed in the original white paper. This took two years to complete, but the benefits especially in terms of the different constellations that this supports makes this investment worthwhile. Of course, if your task infrastructure is part of your process infrastructure then you already have your own private implementation of the synchronization between task and process and you do not need to expose these private services. The idea being to keep it as simple as possible to plug together the necessary components as opposed to a complex standard to enable a human workflow with all manor of complex patterns to be completely portable. That would have been unnecessarily restrictive. The specifications are out for all to see and use. Someone may argue that this is similar to proprietary specifications already in place by different vendors. But this was an undertaking between some of the worlds leading bpm companies simply get something useful and workable in a reasonable time period. It does not really target a specific platform but could be seen as a lowest common denominator. So we can start with implementations and perform interoperability tests. At the same time, it now needs a single open body to look the standard’s lifecycle so we are planning to submit them to a standards organization, to give all commercial companies and also all academic bodies the chance to improve it. OASIS is the standards body that deals with BPEL so this fits pretty well. It can be seen as a true BPEL extension so it does not have to be part of the next version of BPEL. It is up to the technical committee to suggest what would be the best approach. Alan, do you think the three standards bpel, BPEL4People, WS-HumanTask complete the spectrum and commoditize BPM, task and workflow software to the extent that the differentiators are insignificant? Are tyres or cars commodity? Quite the opposite. Putting plugs on the software, making them interoperable, simply makes it easier to deploy them together in different configurations. Ivana, the fact that they’re pluggable means engineers and customers alike can concentrate on which tooling fits which environment best without burning any bridges. It’s back to the horses-for-courses way of looking at bpm. There will be agnostic task engines, intended to be plugged into composite applications so that the task-handling aspects are outsourced from the application logic, and other applications which are built with limited task capabilities will simply use the WS-HumanTask plugs to simplify integration when they are used in more sophisticated scenarios. It will make composite building easier. And it will really simplify acquisitions because (looking at SAP’s recent acquisitions) most applications already have a task or simple workflow infrastructure in them but if these infrastructure support these standards, they can be plugged into the existing software from day one and the proprietary added-value can be added bit by bit following the initial standards-based docking. I think this standard paves the way for a very bright and diverse future including the evolution of additional bpel extensions. Thank you Alan, that concludes this podcast. Thank you for listening, and enjoy the rest of your day.