yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Computing
Conference & Expo
November 2-4, 2009 NYC
Register Today and SAVE !..

2008 West
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
Red Hat
The Opening of Virtualization
User Environment Management – The Third Layer of the Desktop
Cloud Computing for Business Agility
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Return on Assests: Bringing Visibility to your SOA Strategy
Managing Hybrid Endpoint Environments
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
How Can AJAX Improve Homeland Security?
Beyond Widgets: What a RIA Platform Should Offer
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
In many cases, the end of the year gives you time to step back and take stock of the last 12 months. This is when many of us take a hard look at what worked and what did not, complete performance reviews, and formulate plans for the coming year. For me, it is all of those things plus a time when I u...
The Flesh and Bone of SOA
BPEL & Role Activity Diagrams

The overall disputes process that ACME intends to build is shown in Figure 5. (This figure shows the process in Oracle's graphical editor. The actual XML BPEL code for this example, as well as the Design example described above, will be available at under this issue/article .) The process begins when ACME receives a dispute from a customer (receiveDisputeFromCust). ACME then ensures that the dispute is fully captured (which might involve contacting the customer to get supporting information such as receipts) and then splits in two directions, one of which is normal processing, which ACME already supports (the normal chargeback cycle that follows rigid business rules). The other path is the RAD path, in which a sales-savvy disputes specialist makes the right choices to ensure that the customer wins the dispute and buys something along the way.

The RAD path is actually a collaboration involving three roles, In Figure 5, the main process sets this collaboration in motion: the invoke activity createCollab calls a Web Service known as CollabService to initialize the collaboration; the invoke activity startSpecialistRole launches a second BPEL process that manages the primary role in the collaboration, the Dispute Specialist role. The top-level process is now complete, and the RAD collaboration, implemented as three interacting BPEL processes representing the three RAD roles, now commences.

Before turning to those processes, let's examine the nature of the required RAD collaboration by studying its RAD diagram, shown in Figure 6. The dispute specialist begins by assessing the dispute (Assess Dispute) and deciding on an upsell strategy. If he thinks the dispute is invalid and would typically be rejected (the Upsell Reject refinement path), he instead writes it off (because rejections don't sit well with high-value customers) and makes a "level 3" (or "L3") sales offer (e.g., offer the gold card and waive the first-year membership fee). If he thinks the dispute would typically be written off (Upsell Writeoff), he writes it off and makes a slightly better, "level 2" ("L2") offer (e.g., a line of credit at a favorable rate). In the final two cases (Upsell Possible Loss and Upsell Likely Win), the specialist decides to chargeback the item to the merchant to try to recover the charges. If the dispute seems likely to win (i.e., the merchant's bank will probably concede), the dispute specialist assigns a sales specialist (Assign to Sales Specialist) to find a good "level 1," or "L1," offer (e.g., a retirement catch-up loan with the no payments for the first 24 months), makes the offer to the customer, and assigns to a Dispute Lackey (the colloquial term at ACME for a dispute specialist who knows the ins-out-outs of disputes management but doesn't interface with customers) the task of managing the chargeback; if the dispute is lost, the specialist unhappily writes it off. In the case where the dispute specialist thinks the dispute might lose but is worth charging back anyway, he makes an L2 offer and has the lackey follow through with the chargeback. If it loses, the specialist writes it off; if it wins, the dispute specialist asks sales to prepare an L1 offer and extends it to the customer. (Notice that the customer in this case is made two offers: an L1 and an L2. Because a dispute can drag on for weeks or months, ACME prefers to have the specialist make a modest L2 offer immediately, then the more lucrative L1 when the dispute is won.)

The need for RAD arises because of the adaptive nature of this collaboration. In the first place, many activities may be interleaved; in Upsell, Likely Win, for example, the specialist may assign tasks to sales and the lackey in parallel. Furthermore, if the specialist doesn't like the L1 offer prepared by sales, he may decide to make an L2 offer instead. And that's just the tip of the iceberg. In the future, more refinement paths could be added, more activities added, more roles added. The typical BPEL control structure can't easily support this.

Our strategy is to throw a sensible combination of workflow patterns and business rules at the problem. Figure 7 shows the disputes specialist BPEL process in the Oracle editor. The process begins by receiving its start event from the top-level disputes process (startMeUp), and then it calls CollabService to add itself to the collaboration (addRoleToCollab). Next (in the scope configureMyRole shown collapsed in the figure), the process calls the CollabService to configure its tasks, associating each task with its role in the collaboration; these tasks are AssessDispute, WriteOff, MakeL1Offer, MakeL2Offer, MakeL3Offer, AssignLackey, and AssignSales. The process then starts a while loop that runs for as long as the role is in the enabled state. In the first step in the loop, the process calls CollabService to run business rules (runRules) to determine the enablement status of the role and each of its tasks. This leads into a pick, in which the process waits for one of three events to occur. The first is a signal from the end user that one of the enabled tasks has now been completed. If that task is AssignLackey or AssignSales, the process sends a message to the BPEL process representing that role to join the collaboration. The other two events in the pick are callbacks from the Lackey and Sales processes indicating that their work is done. In each case, the process enriches the role's data with information about the event. That data is input to the business rules in the next iteration of the loop. Next time around, the set of enabled tasks might change, or the role itself might be considered complete, and thus disabled.

The processes for Lackey and Sales are similar, but simpler. Each role has only one task. The process adds its role to the collaboration, adds its task to the role, and waits for that task to be executed, on which it calls back the Dispute Specialist process to indicate that the work has completed.

Figure 8 shows the end-to-end sequence of interactions for the Upsell, PossibleLoss path. At this point, we can make the following observations on this design of RAD in BPEL:
• The primary purpose of the BPEL processes is to manage role interactions. Roles run in separate processes and communicate by Web Services on partner links in a natural SOA manner. Using this mechanism, to start a role is to call the startMeUp entry point of the role's process. To execute a role's task is to call the process's executeTask entry point. Roles interact with each other by calling each other's entry points, as in the case where the Lackey process invokes the callback lackeyDone to interact with the Dispute Specialist process.
• The processes make heavy use of the CollabService. This service, as we'll see shortly, manages the state of the collaboration and oversees the execution of enablement rules. Significantly, the BPEL processes are not designed in the usual naïve way in which tasks are laid out as invoke activities. Rather, the processes tell CollabService what their tasks are and use CollabService to apply rules to determine their execution path.

The while loop in the Dispute Specialist process exhibits two common workflow patterns: Multiple Instances and Milestone.
Multiple Instances: In a sense, the goal of a role is to get through its tasks, and the while loop's job is to iterate until all required tasks have been executed. Each iteration waits for a task completion event, which gets the role one step closer to this goal. In the Disputes example, all tasks are known at design time. In the Design example, an initial set of tasks is established upfront, but additional tasks may be added at runtime; on a given iteration, the role might get one step closer or one step further from completion. In other words, tasks are instances, and the challenge is to complete those instances.
Milestone: In contrast to the naïve BPEL approach in which a task is enabled when its predecessor has completed, in RADish BPEL, a task is enabled whenever its enabling, or milestone, condition is met. The process does a full sweep through the tasks on each iteration of the loop, enabling or disabling tasks according to rules. (The actual execution of an enabled task occurs outside of the process, aided by a UI tool. That tool sends an event to the BPEL process when the execution is complete.)

(For more information on workflow patterns, see

Finally, CollabService is a Web Service that uses a set of database tables, shown in Figure 9, to maintain the state of the collaboration. As the figure shows, a collaboration, identified by a collabID, has one or more roles. A role that participates in a collaboration is identified by its name (roleName) and an instance number (in case multiple instances of the same role are required, as with the Designer role in the Design example considered above). A role also has data (consisting of several pieces of structured, unstructured, and control information meaningful to the role), as well as a rule class and an enablement status. The rule class is a pointer to a class (e.g., Java, C#) or rule-set containing rules that decide, based on the role's current data, the enablement status of the role and each of its tasks. The tasks themselves are identified by name and instance (multiple instances of the same task occur when a role has iteration, as in the Manager role of the Design example above).

The collaboration service provides four methods to update this data: three - createCollaboration, addRoleToCollaboration, and addTaskToRole - to add new records to it, one - runRulesForRole - to update, based on business rules, role data and role and task enablement status. The service doesn't provide queries, although they could be added. A RAD UI tool should have read-only access to the tables to perform desired queries.

The behavior of the service method runRulesForRole is best understood by example. Consider the rules for enablement in the dispute specialist role specified in Table 1. When runRulesForRole is run, it tests the enablement condition for each of that role's tasks, as well as the role itself. On its first run, runRulesForRole will enable the task AssessDispute, because that task satisfies its condition that it hasn't been executed yet. No other tasks can be enabled initially.

When the specialist completes AssessDispute, he also specifies an assessment decision (i.e., one of the upsell strategies examined above). Assuming that decision is UpsellReject, next time the rules are run the following enablement changes are made:
-  AssessDispute is disabled because it no longer satisfies the condition "task not done."
-  WriteOff is enabled because it hasn't been completed yet and the assessement is UpsellReject
-  MakeL3Offer is enabled because it hasn't been completed yet and the assessment is UpsellReject.

The dispute specialist can work WriteOff and UpsellReject in any order. When these are completed, the role itself is disabled, because its enablement condition of having at least one enabled task or pending work from sales or the lackey fails.

Considering a more complicated scenario (shown in Figure 8), assume the specialist's decision in AssessDispute is UpsellPossibleLoss. The next enabled tasks are AssignLackey and MakeL2Offer. The specialist might then execute both tasks right away, which leaves no enabled tasks for the specialist role, but does trigger the lackey role. The dispute specialist role is still enabled, because it's waiting for information from the lackey. When the lackey completes his work, if the dispute was won the dispute specialist role is disabled, because no tasks are enabled and no activity is pending. On the other hand, if the dispute was lost, the WriteOff task is enabled, and the dispute specialist role waits for its completion.

RAD-like human interaction can be modeled in BPEL using business rules and common workflow patterns, and the implementation isn't as onerous as critics claim. The approach is ideal for hybrid processes, whose automation requirements demand an SOA stack built on BPEL, but which infuse ad hoc human work. The people who participate in hybrid processes, like the opportunistic dispute specialists at ACMEBank, are the "flesh and bone" of SOA. Their contribution is significant, but their effort is not quite the "heart and soul" of the BPM envisaged by Harrison-Broninski.

1.  Keith Harrison-Broninski. Human Interactions: The Heart and Soul of Business Process Management. Meghan-Kiffer. 2005.
2.  "Business Process Modeling Notation Specification." Object Management Group.

About Michael Havey
Michael Havey is a Chordiant consultant with 10 years of industry experience, mostly with application integration. Michael's book Essential Business Process Modeling was published by O'Reilly in August 2005.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

SOA World Latest Stories
The dynamic nature of the cloud means that change is a constant when it comes to modern cloud-based infrastructure. Delivering modern applications to end users, therefore, is a constantly shifting challenge. Delivery automation helps IT Ops teams ensure that apps are providing an optim...
"We started a Master of Science in business analytics - that's the hot topic. We serve the business community around San Francisco so we educate the working professionals and this is where they all want to be," explained Judy Lee, Associate Professor and Department Chair at Golden Gate...
There is a huge demand for responsive, real-time mobile and web experiences, but current architectural patterns do not easily accommodate applications that respond to events in real time. Common solutions using message queues or HTTP long-polling quickly lead to resiliency, scalability...
We call it DevOps but much of the time there’s a lot more discussion about the needs and concerns of developers than there is about other groups. There’s a focus on improved and less isolated developer workflows. There are many discussions around collaboration, continuous integration a...
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is founda...
"CA has been doing a lot of things in the area of DevOps. Now we have a complete set of tool sets in order to enable customers to go all the way from planning to development to testing down to release into the operations," explained Aruna Ravichandran, Vice President of Global Marketin...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)!

Advertise on this site! Contact advertising(at)! 201 802-3021

SYS-CON Featured Whitepapers