by
Yaron Y. Goland
BEA Systems, Inc
5/16/2003 3:56 PM
The goal of this paper is twofold. First, to illustrate the existence of two distinct choreography related standards problems that require complementary but separate solutions - choreography programming languages (cPls) and choreography description languages (cDls). Second, to provide a set of requirements and motivating use cases for the design of a cDl. It is a non-goal to provide an exhaustive list of requirements but rather to identify a few key ones critical to the creation of an effective cDl.
A cPl, examples of which include WSBPEL, BPML, Java, etc., is a programming language specifically designed to address long running asynchronous logic such as that commonly used in business process scenarios. A participant in a choreography would be expected to implement their executable code using a cPl.
The goal of a cDl is to define a common view of a multi-party business process where the roles and message choreography are defined in a manner that allows for each participant to automatically validate their own compliance with message exchanges specified in the part of the message choreography visible to them.
cDls typically describe a directed graph where each node in the graph represents a state in the message choreography and where each transition in the graph encodes a message transmitted from one participant to another. cDl graphs generally support both exclusive and parallel outgoing and incoming state transitions. E.g. a state's outgoing transition may either say "one of the following transitions will be take" or "all of the following transitions will be taken." Similarly a state's incoming transitions can be specified such that the state will only execute if a message is received on all of the transitions or in only one transition. Shortcut formats such as N of M in/out transitions are also usually supported.
As cDls are not executable and as they only display messaging behavior the logic that controls a particular transition is given in prose rather than in an executable form. That is, a cDl with two mutually exclusive outgoing transitions may have a text note saying "The first transition will be used if it's a priority order and the second if it is a low priority order" but no executable code would be provided. Executable logic in a cDl doesn't make much sense as the cDl only captures a global view of messaging activity and so is not designed to efficiently provide information about how participants implement their individual. That is a task best left to cPls.
By defining the clear differences between cPls and cDls and providing a set of minimum requirements this paper hopes to enable the creation of a useful cDl standard.
The following is a summary of the requirements for the design of a cDl motivated by the use cases given below. This list is not intended to be complete but rather a minimum set without which a cDl design would be incomplete.
Included in this section are three use cases that are intended to provide motivation for the requirements listed in [See 2 Requirements].
The first use case describes the different techniques a large corporation used to grapple with their business process design problems eventually culminating in the use of cPl and cDl based tools. The use case is intended to motivate the separation between cPl and cDl as well as the non-executable, prose, multi-party global view, segmented and hierarchical requirements.
The second use case describes two companies attempt to collaborate on the design of a bridge. The use case is intended to illustrate how one would use a BPEL style abstract process in conjunction with a cDl as well as provide motivation for the annotated and WSDL 1.2 requirements.
The third use case looks more deeply into the relationship between business analysts and business process developers, in so doing it illustrates the full life cycle a cDl goes through during design/development/deployment. The use case also provides the motivation for the skeleton generation and run time validation requirements.
This use case charts a major corporations' efforts to gain control over the message choreographies used between its various systems.
At first the corporation tries to create a single document that describes all the systems, messages and choreographies but quickly finds that the complexity of the document is so great that it can't be used for any practical purpose and will be out of date long before it's finished.
They next try to use a cPl, Java, to describe the choreography behavior but quickly find that the result is so complex that no one can really understand it.
Eventually the corporation realizes that they need a cDl. The corporation tries to design its cDl by starting with a cPl and removing features. First the control logic is vastly simplified to the point where it just encodes a graph. Then the cDl is made to encode a global view rather than the participant level view required by cPls. They then add in the ability to segment the cDl so that participants can be given cDls that only show them the part of the message choreography they need to know about. Finally, they add the ability to abstract away sub-systems so that it is easier to understand the over all logic of the cDl without drowning in the details.
Really Big Corporation (RBC) - A major multi-national behemoth that does business with a large number of tiny companies.
Tiny Company 1..N - A collection of small companies with limited resources that communicate electronically with the RBC.
RBC sells the Really Big Product (RBP) that requires the cooperation of approximately 100 different tiny companies. The main activities involved in creating the RBP are order handling, manufacturing, shipping and billing.
Each of the four activities may involve 20 to 30 different systems, some of which are internal to RBC, Tiny Company partners run the rest. When the RBP was first being produced RBC handled communication between the systems, both internal and external, in an ad-hoc manner. The operators of any two systems that needed to communicate would write down on a piece of paper what messages they expected, give some description of the acceptable order and then go write code and test until things finally worked.
Eventually RBC decided they wanted to get a coherent view of each of their four main activities so they could:
RBC decided to start their efforts by getting their order handling system fully documented. Once that was complete they would then tackle the remaining three activities. RBC found out that not only were there the expected 20 to 30 different systems involved but that there were in excess of 100 different unique message types being used between some or all of the communicating systems.
At first, trying to make sense of this avalanche of systems and message types, RBC decided to create a central document that described in prose all of the systems and messages involved along with associated choreographies but the complexity of the document was so overwhelming that they quickly gave up.
The next thought was to try and define the relations between the systems by using a choreography programming language (cPl). Unlike generic programming languages such as Java the cPl source code only describes choreography related behavior. It was felt that by providing a coding framework that just focused on the choreography aspects of the problem and hid the other details it would be possible to robustly and programmatically describe how systems interoperate. In practice using source code as a tool for understanding the end-to-end behavior of the system resulted in a spaghetti like mess of code that no one could understand or properly analyze. [See 4.1 Source Code and Interoperability] To make matters worse using cPl source code as a basis for interoperability turned out to produce brittle implementations that could not be readily versioned. [See 4.2 Building Robust Systems].
Eventually RBC realized that what they really needed was not so much a cPl as a choreography description language (cDl). Not sure how to build a cDl they decided to start with a cPl and see what changes they needed to make.
The first change RBC made was obscuring the control logic. RBC realized that most of the information provided by the cPl, even though it was just about choreography, wasn't actually necessary for understanding the system's behavior. No one really needed to know, for example, the gory details of how a message was ripped apart before being processed. The easiest way to hide this kind of information was to remove control logic from the cDl. So all the control statements in the IFs, WHILEs and other program elements were removed in the cDl. In the cDl programmers would have to annotate the logic with human readable statements in order to explain their intent. [See 4.3 Non-Executable Logic]
The second change RBC made was to switch to a multi-party global view. cPls, by their very nature, provide a view on the choreography from the perspective of a single participant. To understand the system end-to-end using cPls one has to stitch together all the participant views to create a coherent whole. By writing the cDl using a global view that could show all the parties interacting at once it made it much easier to understand the system's end-to-end functionality. [See 4.4 Multi-Party Global View]
The challenge with using a global view is that it makes it harder to hide information. After all, if one can see all the participants simultaneously then how does one hide anything? For example, Tiny Company 1 may talk to RBC who then talks to Tiny Company 2. While RBC needs to have a complete global view of all of its activities it only wants to show each Tiny Company the part of the global view relevant to then. The solution RBC choose was to make their cDl support segmentation, e.g. enable multiple cDls to reference each other and describe their overlapping parts. [See 4.5 Segmentation].
The sum total of these changes caused a rebellion amongst the choreography programmers. The programmers had grown to like their cPl as a way to express control logic for long running aspects of business processes. The cDl was no substitute for the cPl.
RBC understood that what they really needed was two different solutions. One solution to make it easier to write long running programs, a cPl, and another solution for describing the choreography between systems, a cDl.
With both solutions in place RBC was able to use the cDl to document the full choreography for all message exchanges in their entire order processing system including the ability to segment the picture so that partners only saw the parts they needed. They were then able to repeat the procedure for the other three activities and to hook all the choreographies for all the activities together using segmentation.
However RBC still had a problem, the final picture was too complex. With 100 different systems and 400 different messages across all four activities no one could understand the whole picture. RBC needed some way to abstract away sub-systems which didn't need to be understood in detail in order to see the over all system flow. Segmentation didn't solve this problem because segmentation allows one to hide information not add a level of indirection. The solution RBC choose was to make their cDl hierarchical, e.g. allow the cDl format to wrap cDl functionality inside of a function call. [See 4.6 Hierarchy]
The end result of RBC's efforts is that they had implemented and deployed two solutions. A cPl to make it easier to write long running logic and a cDl to make it easier for different systems to understand their messaging obligations to each other.
In this use case two companies are working together to design a bridge. In order to improve communication the two companies want to connect their document management systems.
This leads to problems with the selection of a reliable messaging protocol that are resolved by allowing the cDl to be annotated with information about what reliable messaging protocol is to be used rather than building the reliable messaging protocol's messages directly into the cDl.
However the main concern of the two companies is legal and criminal liability. In their area there are very strict legal requirements for who must review and approve any changes to the bridge's design. Engineers must receive specific certifications in order to provide certain levels of review. Failure to have the right sort of engineer review the design change at the right time could minimally result in civil liability (e.g. they could be taken to court and made to pay money), potential loss of license (e.g. they won't be able to work again) and in the most extreme case criminal liability if anyone is hurt and it is shown that they were negligent by failing to follow the legally mandated review process.
The potential liabilities lead the two companies to use a combination of a cDl, which provides high level messaging details and a cPl abstract process that enables them to define in exquisite detail exactly how each participant is to implement the message choreography and so ensure that all legal requirements are met.
The Bridge Superstructure Company (BSC) - Builds the superstructures for bridges
The Deck Company (DC) - Builds decks for bridges
BSC and DC were sub-contractors on a project to build a new bridge. Recognizing the need to work closely together they decided to implement a series of web services to enable the companies to submit proposed changes to the bridge's design. The web services accepted changes, drove the process of getting the appropriate approvals and then altered the central design and notified the appropriate parties.
The first step in the design process for the new web services was for safety engineers from both companies to get together and agree on what the high-level approval process would look like. The joint group specified what information a change request needed to have, what sort of change requests could be made, what steps needed to be taken to approve each different kind of change request, how the change requests were to be applied against the central design and for each approved change request, what sort of people needed to be notified. The safety engineers were experts in safety processes, not programmers so their output was a business logic design document that consisted of prose and graphs showing, at a high level, how the system was to work.
The business logic design document was then handed off to a joint team of choreography programmers from both companies. The choreography programmers had the job of writing the choreography in the selected cDl.
Both companies had existing approval processes and document management systems so as the joint choreography was designed each team used segmentation to integrate the joint choreography with their local systems.
One of the first problems the joint team ran into was that they wanted to use a reliable messaging system to allow them to transfer messages. At first they tried to include the reliable messaging related messages directly into the choreography but that proved to be a mess. Especially when, half way through the project, they decided to change their reliable messaging algorithm when a new group in some standards organization started up and they felt they needed to be standards compliant. Eventually the joint group decided to enhance their cDl to support annotations [See 4.7 Annotations]. This allowed them to mark a message exchange as reliable using an identifier without having to actually include all the reliability details. They used a similar strategy to deal with message correlation. That is, rather than trying to invent a generic correlation language they used an annotation to specify what correlation algorithm they were using.
One problem the joint team didn't run into was selecting what web service description language to use. The joint team, wanting to be strictly standards compliant, was only interested in using Web services. So they were happy to find a Web services cDl working group. By definition Web services means WSDL, in this case WSDL 1.2. Rather than taking precious working group time to invent a generic description framework that could potentially host any and all descriptors including ones for ebXML, RosettaNet, EDIINT, etc., thus causing the group to likely never ship while they busily re-invented the work of the WSDL working group, the Web services cDl working group that the joint team choose focused exclusive on WSDL 1.2.
A problem the joint team did run into was that by law certain change approvals must be signed off in a certain order. While the general rule for interoperability is be generous in what you accept, whose corollary is be flexible in your processing, such cannot be where the law is concerned. A cDl can only provide so much detail and in some limited cases more detail is needed, but not so much detail as to write the actual code. This is where abstract processes in choreography programming languages (cPl) come in.
An abstract process is a cDl program that has been stripped of some logic. More complete abstract processes may show variable handling but hide certain types of variable handling behind opaque functions. More bare bones abstract processes do not even specify what variables are to be used. A bare bones abstract process is similar to a cDl in the sense that it is not executable but unlike a cDl an abstract process can deal with issues beyond sending and receiving messages as well as specifying its behavior from the perspective of a single participant. A cDL on the other hand exclusively illustrates messaging behavior and only from a global view, that is, from the perspective visible to multiple participants rather than a single participant.
After the joint team created the cDl to describe the messages involved in the legally mandated change approval process they then created two abstract processes. The abstract processes provided the details of exactly how each participant was to process a change request. The abstract processes went beyond just describing the messaging behavior and also dealt with issues such as the actual logic used to route messages and some of the transformations involved. This level of detail provided by the abstract process was necessary to ensure that both teams behaved exactly as legally required and since it is impossible to express this level of detail in a cDl an abstract process was necessary.
The joint team chose an abstract process over an executable process in order to not hinder each company's ability to implement the logic in the way they saw fit. What was needed was only a detailed description of the desired behavior, not actual running code. This made the abstract process the more desirable choice.
By using annotations to specify their reliable messaging and correlation behavior the joint team was able to produce a flexible cDl that could focus on their business logic rather than lower level infrastructure issues. By using both a cDl and an abstract process the joint team was able to provide the level of detail needed to write a cPl that would enable both companies to interoperate.
In this use case a group of business analysts and developers are working together to design and implement a business process. The exact nature of the business process is not discussed, rather the use case focuses on the steps followed in the design/implementation/deployment life cycle.
The use case pays particular attention to how business analysts communicated with the developers, how developers used cDl templates provided by industry consortia, the generation of cPls skeletons from cDl, some discussion of round tripping issues and the use of the cDl for run time validation of correct messaging behavior.
Business Analysts: Specify the high-level business logic to be implemented by the choreography.
Developers: The people who have to write the code that implements the choreography.
The business process began life when the business analysts produced a series of document describing what it was they wanted the business process to do. The design documents explained what steps where needed, what information had to be available, etc. The design documents consisted of graphs and associated prose. The graphs were not detailed enough nor complete enough to be used to generate code skeletons. Business analysts don't think that way, they aren't trained to work at that level of detail and frankly working at that level of detail is a waste of their time. They are paid to understand the business, not software.
The development team then took delivery of the business analyst's documents. Their first step was to read through them, make sure they understood them and then go ask the business analysts a ton of questions. After iterating through this process a few times the developers were ready to identify all the company systems they would have to interface with. They worked with the teams at the company who owned the systems they needed to integrate with in order to figure out what interfaces their systems already supported and which ones would have to be added to support the new program.
In order to help them avoid re-inventing the wheel the developers used a number of pre-defined templates provided by dedicated standards organizations. These templates consisted of files containing cDl data along with the associated WSDLs, message definitions, etc. While the developers did not use the templates exactly as is they were able to use them as a starting point that they adapted to their particular needs.
The developers then put all the information about various systems to talk to, messages to support, etc. together and using their favorite graphical tools started writing their cDls and associated WSDLs. They started off with cDls because cDls provide the easiest to understand high-level view of how all the systems would communicate together.
It is at this point that the developers called back in the business analysts and walked them through the cDls and associated messages. Although the business analysts did not necessarily understand all the details of the cDl it was still abstract enough to give them a good idea of how the over all system worked and how various processes were implemented. With the information in the cDl the business analysts gave a tentative thumbs up to the developers that the cDls did appear to properly implement the business logic.
The developers then downloaded their cDls into their choreography programming language (cPl) tools. The cDls used roles or a similar construct to differentiate between the participants in a choreography. The developers told their cPl tools which role they were developing code for so the cPl tool was able to use the cDl to generate a cPl code skeleton for the specified role. The skeleton was obviously missing large chunks of functionality but it gave the developers a good start.
Once coding inside of the auto-generated cPl skeletons began it was inevitable that bugs would be found in the cDl. This created one of the hardest challenges for the programmers - how to propagate changes in the cDl to the cPl. At a minimum what the programmers desired was a way to programmatically propagate a change from the cDl to the cPl. In an ideal world it would be possible to do the opposite as well, propagating changes in the cPl to the cDl.
Programmatically propagating changes in either direction, much less full round tripping, is almost certainly impossible in the general case. The developers did approach the web service cDl working group whose cDl they were using and strongly suggest that the working group investigate the problem and determine what subset of the cDl would, at a minimum, allow them to automatically propagate changes in the cDl to an arbitrary cPl. The developers also asked that the working group investigate what characteristics a generic cPl subset would have to have in order to allow changes in the cPl to be programmatically propagated back to the cDl. The developers understood that in the general case they couldn't hope to programmatically propagate changes back and forth but they wanted to understand just how limited a subset of the language they would have to restrict themselves to in order to enable propagation and then decide if they could live with those limits. For specific sections of a choreography that were expected to frequently change working with only a subset of the cPl and cDl may be an acceptable tradeoff in return for the ability to programmatically propagate changes.
Once the cPl was completed the time came for test deployments. This is where the cDl made its next appearance. The test deployment system had a message filter that it put in front of cPl deployments. The message filter took as input a cDl and the role the associated cPl it was filtering was supposed to implement. The filter watched real time messaging behavior and determined if the messages and choreography mandated by the cDl were being properly implemented by the cPl. If a divergence was detected then an appropriate error was raised causing a log entry to be created or an administrator to be notified or other appropriate action to occur. Note that this type of validation is not dependent on analyzing the cPl's code but rather on watching real time messaging behavior.
By working iteratively with the business analysts the programmers were able to clarify exactly what goals the business analysts were attempting to achieve and upon producing a cDl were able to walk the business analysts through the cDl in order to convince them that the proposed system, at least at the messaging level, would behave as the business analysts intended. By using cDl templates from industry organizations the developers were able to save time in developing their own solutions and by importing their cDls into their cPl tools they were able to generate cPl code skeletons to kick off their coding efforts. Finally, by using the cPls to drive message filters they could run real time tests to determine if the systems messaging behavior was correct.
Enabling interoperability by sharing source code seems reasonable. And, while it can be useful to share source code, it is rare that source code forms the foundation for interoperability. It is usually, at best, an adjunct to a separate set of dedicated interoperability documents.
The first problem in sharing source code is when reading a partner's source code it is necessary to pick out the parts of the code that are relevant to interoperability. The introduction of choreography programming languages (cPls) simplifies this task somewhat by isolating the choreography related logic from the rest of the program's logic. But often even this simplification is not enough.
For example, imagine a travel agent system that works with travelers and with travel companies. The travel agent's choreography source code will have sections dealing with both talking to the traveler and the travel companies. It isn't possible to fully separate out the code the travel agent uses to talk to the traveler and the travel companies as the travel agent needs to move data from one to the other. As such when the traveler and travel companies both download the travel agent's source code to figure out how to work with the travel agent each one will have to figure out which parts of the code are relevant to them.
Even if the logic is fully and properly segregated there is still the problem that source code is primarily concerned with programming computers, not with being readable. Given the manifest difficulties programmers have in reading their own source code what hope can one reasonably have for a system that depends on the ability of programmers to read other people's source code?
Many interoperability problems arise from misunderstandings on the part of the parties attempting to communicate. Providing choreography source code would seem to be a great way to prevent these misunderstandings. With the source code in hand an implementer knows exactly what the systems they are trying to interoperate with is doing.
However the art of interoperability is often about what not to say. In a sense choreography programming languages (cPls) make it too easy to release too many details.
For example, imagine an order processing system that implements the following logic:
ReceiveMessage(PO) {
For Each ITEM in PO {
/* Lookup which warehouse is responsible
for stocking this type of item. */
Warehouse = LookUp(ITEM);
SendAsynch(ItemLookupRequest,ITEM,Warehouse);
}
For Each ITEM in PO {
ReceiveAsynch(ItemLookupResponse);
}
}
The PO processing system takes in a purchase order (PO), breaks out the items being purchased, looks up the warehouse that is responsible for stocking that item and sends an asynchronous request asking if the item is in stock. The PO processing system then waits until it gets all the responses back and then uses that information to respond to the PO.
After deployment the folks running the PO processing system realized that their performance was not particularly good. They recognized that one of the problems was that they were sending out way too much messages to the warehouses. However there was a simple solution, the message format used to make stock lookup requests supported listing more than one item at a time. So all they needed to do was re-write their code to queue up items that were supposed to be in the same warehouse and then send a single request listing all the items to the warehouse. Using this technique they could turn N message exchanges into 1.
Unfortunately the folks who wrote the warehouse code had seen the PO processing system code and knew that the PO processing system would never send more than a single item in a lookup request. So even though the message format required them to handle multiple requests they didn't bother to implement that feature since they 'knew' that their customer, the PO processing system, would never use it. One can just imagine the fun of trying to disentangle that mess.
Of course one could argue that the code used to issue the item look-ups should not have been exposed in the cPl. But this is exactly the sort of realization that tends to come after the problems are discovered.
If one wants robust systems then generally one needs to hide as much logic as possible so as to stop each side from making dangerous assumptions about the behavior of their partners. The trick is to provide enough information to enable interoperability but not so much information as to cause the system to be brittle. The cost for getting the trade off wrong is that while the first version of the system may deploy without incident the second version will be a disaster.
In trying to describe a message choreography, details of the control logic such as the control value in an IF statement or the iteration value in a WHILE statement, usually just distract the reader from an understanding of the message flow. Reading code, as previously discussed [See 4.1 Source Code and Interoperability], is extremely difficult and understanding a message flow by trying to read control statements, understanding their variable references, etc. is not likely to lead to understanding as the code is more focused on programming a computer than explaining itself to humans. It is also likely to lead to the robustness issues discussed elsewhere [See 4.2 Building Robust Systems].
However removing the control code is not enough, one needs to replace it with textual comments that are specifically targeted at humans and intended to make it easy for them to understand the choreography. One could reasonably argue that the best of both worlds would be to include the control code and include comments but decades of practice teaches that in such scenarios one is more likely to end up with control code and no comments than both.
Removing the control code has other benefits in terms of creating a message choreography format, it makes the format much simpler. Without control code there is no real difference between a for-each, a while or a do-until so all three constructs can be reduced into one. The same reduction is possible with if and switch statements. Also, without control code there is no longer any need for explicit variable handling so variables can be safely removed from the cDl.
In a choreography programming language (cPl) one, by design, describes a single participant's activities. To get an end-to-end view of the system's functionality one has to take the cPl source code for all of the participants, apply a mapping that shows how output messages from one participant map to inputs of another participant and then try to play ping pong. Ping pong, in this context, is played by putting one's finger on a line of code in one participants cPl, following that code until a message is sent and then putting another finger on the line of code in the destination participant's cPl and continuing to follow the code there. If the system is simple enough one may only need four or five fingers, although dealing with parallelism can quickly require one to borrow other people's hands.
Given the downsides to ping ponging a choreography description language (cDl) will generally be written from the global view. That is, the cDl will simultaneously describe the activities of multiple participants in a single document versus the cPl approach of having source code for each participant and then trying to glue the source code together with input/output maps.
In theory it is possible to generate a global view automatically by taking in multiple local views and an input/output map. But by starting with local views one tends to drag in logic that is only of relevance to a single participant. By starting out with a global view one restricts one's concerns only to issues of mutual relevance to communicating participants and so helps to simplify the complexity of the description.
In creating a global view there is always a tension between the simplicity of only allowing binary global views versus the completeness of a multi-party global view. In a binary global view the global view is only allowed to express communications between two parties. So, for example, if one has a situation in which party A communicates with party B and C then one needs two different binary global views, one to address A and B and another to address A and C. What is lost however is the relationship between the messages sent to B and C. One no longer has a true global view, rather one has a slice of a global view. In such a system there is no way to say things such as B will always get its message after C gets its message.
The only way to express multi party behavior is with a multi-party global view. This is a global view in which it is possible to simultaneously describe the communications between an unlimited number of participants. Such views are more complex than binary global views because they require the assignment of roles and careful management of who is communicating with whom but such complexity is generally justified by the need to fully describe non-trivial communication patterns.
For privacy, security and just good architecture reasons it is often desirable to hide parts of a choreography description from some participants.
For example, participant A may talk to B who talks to C. Unless there is a compelling technical reason to do otherwise it is quite likely that participant A will only be aware of the choreography relevant to talking to B. B will be aware of both A and C. And C would only be aware of B.
A choreography description language (cDl) that supports segmentation is able to break a single choreography into multiple segments that can then be reconnected in part or in whole. In many cases there will never be a 'single choreography' at all. In the previous example C may talk to D in which case:
A would know about the A-B choreography
B would know about the A-B-C choreography
C would know about the B-C-D choreography
and
D would know about the C-D choreography
No one player would have a complete picture of the entire system but the system behavior would still be consistent from end-to-end and if all players wanted to they could join their segments to provide a complete picture.
Using segmentation it is possible for participants to get together and extend an existing choreography definition without having to inform participants who aren't involved with the extension. For example, A and C could potentially find out about each other and decide they want to communicate. In that case they could create a new B-A-C-B choreography that would capture the aspects of A-B-C they could both see as well as their own A-C communications that B is not aware of.
There are many mechanisms to support segmentation but perhaps the simplest is to assign globally unique identifiers (GUIDs aka UUIDs) to each entry in a cDl instance. By matching the GUIDs one can determine when two entries in two different cDl instances are actually the same. Using GUIDs along with a set of mechanical rules one can automatically perform tasks such as taking a choreography as input, identifying a particular role(s) and then generating a segmented version of the choreography that only contains the entries relevant to that role(s). Similarly one can take any two arbitrary segments of a choreography and automatically determine what overlapping parts, if any, they have between then. Also, by using GUIDs, one is able to extend segments with new entries without having to coordinate with anyone. The previous description is not intended to require the use of GUIDs but to give the reader a stronger understanding of what is meant by the term segmentation.
Segmentation is about removing information, not abstracting it away. When one has a choreography with three participants and one wants to segment it into two participants then the third participant disappears from the new segment.
However in many cases what one wants is not to remove information but to abstract it. For example, an order processing choreography may have a large section addressing how to perform a credit check. Someone trying to understand the overall order processing choreography doesn't necessarily need to understand all the details of how the credit check happens, but they do need to know that a credit check occurs.
Adding hierarchy to a choreography description language (cDl) enables the cDl to abstract away a section of its functionality. Conceptually one can imagine drawing a circle around a section of the choreography and replacing all the entries in the circle with a single entry. All the messages that would have crossed the boundary of the circle will now be shown going into and out of that single entry. There would then be a link from that entry to the full choreography of all the entries in the circle.
There are limitations on exactly what can be abstracted, for example, the boundary of the circle must not cross a loop, but the general concept holds.
Hierarchy is therefore about abstracting information while segmentation is about making information inaccessible.
The Web Services stack is being built using components with lots of re-usable and replaceable parts. For example, today there exist at least three different published Web Service based reliable messaging protocols. There exist at least four different published correlation mechanism, two of which use XPATHs and two of which use dedicated SOAP headers. Security, routing and the rest are likely to go the same way.
As such, building in knowledge of the exact messages and mechanisms of a particular component directly into a choreography is likely to end in tears when, inevitably, the component has to be swapped out and replaced.
Proposals such as WS-Policy foresee using an annotation based system in which one "includes by reference" identifiers to describe specific components one wishes to use rather than "including by value" the specific details of that component.
In the case of reliable messaging this would mean that the choreography wouldn't directly record, even using hierarchy to hide the details, all of the messages involved in reliable messaging. Instead a message exchange would be annotated with an identifier uniquely identifying the reliable messaging protocol, if any, used for that message exchange.
Annotations are not a complete solution as in some cases it is necessary to surface behaviors occurring in a component. For example, if a reliable messaging system cannot deliver a message then the sender may take some alternate action so it may be necessary to somehow surface the message that indicated a delivery failure. However, it isn't currently clear if this scenario needs to be explicitly modeled. For example, one could imagine have an entry that is allowed to send out one of two possible messages. The first message is sent reliably. If the message isn't successfully delivered (e.g. it wasn't successfully sent) then the other message, which deals with error recovery, is sent instead. The choreography does not need to programmatically explain how this decision process occurs; a simple text note will do quite nicely.
Still, it is quite likely that in some cases lower level behaviors, especially signal messages, will need to be surfaced. A signal message is a message like any other message. It is only interesting in that it carries status information. A typical signal message is 'your message has been successfully processed'.
It may be worth investigating the introduction of generic signal messages that could be bound to particular profiles at run time. For example, one could have a 'message has been delivered' signal that could be used in the cDl. At run time, when one of the three available reliable messaging protocol specifications is selected the system would then bind that protocol's exact signal syntax to the generic signal message used in the cDl.
In either case it isn't immediately clear that the working group needs to address the issue of signal messages in the first version of the specification. It is quite likely that this feature could be added later as an extension.