[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: IIC 11/2/2005: Starting on ebBP Profile...ComplexBTA and Patterns
As we discussed on Monday (31 October 2005), there are several important parts to the profile. One key component is the scope, use and decisions between parties about the BT patterns. I mentioned that originally and even since that time, templates have been created. These are available for reference. One of the more salient examples is included in Robert Glushko's [1]. Chapter 9 shows some high level starting templates to define business transactions (we can add/expand these). It helps communities start to see the business process, its name, the involved parties, the conditions whereby the process proceeds, the documents used, etc. In Chapter 9 [1], there is also a good description of the relevance, context and use of business documents in a business process. In addition, Chapter 10 also talks about defining your own patterns (and is related to ebBP Data Exchange element for partner-specific pattern definition), compose different patterns (collaboration), apply context (restrictions, selections) and use a checklist sort of definition paradigm. Similarly, the updated UMM user guide (not N090, R10 but R12) uses a template model. [2] Both references are indicative of the pattern matrices we developed that are found in ebBP v2.0.1. Secondly, on the question regarding ComplexBTA, see Section 3.4.10.1 in the v2.0.1 Committee Draft. See [3]. The use case was to identify in a business collaboration and associated BTA that one party may have visibility to another party that supports them, although the latter partner not a part of the defined activities. For example, a distributor is queried by a seller before the seller responds to a buyer. The parties of seller and distributor and their activities may actually be specified in another process definition. However, the seller wishes visibility to this serial occurrence in the current process definition. This shows that the seller has visibility to other sub-parties and has the responsibility for the performance of the sub-parties (who are not first class citizens of the business collaboration), who are not specifically constrained by the business collaboration. Sub-parties are identified in the ComplexBTA but are not parties to the binary collaboration. The original requirements stemmed from financial services domain. Meeting minutes from editor's F2F where more information is available is located at: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=7691. This differs from multiparty collaboration. It may also be seen as a partitioning mechanism that may support multiparty collaboration in some way (with more to be determined). Let me know if you have more questions or need more details. Thanks. [1] Reference (shameless plug for Bob et al): http://www.sims.berkeley.edu/~glushko/DocumentEngineeringBookDraft/ Chapter 9: http://www.sims.berkeley.edu/%7Eglushko/DocumentEngineeringBookDraft/DEBook/ch9_FINAL.pdf Chapter 10: http://www.sims.berkeley.edu/%7Eglushko/DocumentEngineeringBookDraft/DEBook/ch10_FINAL.pdf If we use these, I'd suggest some attribution. [2] Reference: http://www.ifs.univie.ac.at/untmg/artifacts/UMM_User_Guide_2003-09-22.pdf. See for starters, page 39, 96. [3] Extracted from Section 3.4.10.1. A Complex Business Transaction Activity (ComplexBTA) allows for nested BTAs to happen in a recursive manner. This concept is a pure sequencing concept and does not affect the atomicity of the Business Transaction. The choreography mechanisms for the Business Collaboration allow for Business Transaction Activities to happen in parallel, however there MAY be a need to express that a BTA can happen only after the request of the other BTA has been entirely processed (including the return of acknowledgements). This is precisely the purpose of Complex Business Transaction Activity. When multiple activities are nested within ComplexBTA, these activities MUST be executed in series. The model supports for any number of nesting levels. Each activity element is associated with a StatusVisibility element that specifies which state (Success, Failure and document exchanged) are visible at the level of the parent ComplexBTA. The ComplexBTA provides a mechanism to implement and communicate the dependencies between an actual business process (semantic process) and systems implementation of business processes (service choreography). An actual business process may subscribe to events happening in the services layer, and update the actual state when the event is received. This functionality allows a complete decoupling of the implementation, as well as clear view of the required information at the actual (real world) business layer. This mechanism allows the status to be known and published in a Business Collaboration with the default being no status visibility. When status visibility is desired for a ComplexBTA, a simple scenario is provided: Assume a Buyer and Seller are parties to the Business Collaboration. The Seller may have visibility to other sub-parties, such as Suppliers, and is responsible for the performance of the sub-parties. In this sense, the sub-parties neither are not first class citizens to this particular Business Collaboration nor constrained by it. Another Business Collaboration may exist elsewhere that defines the interaction of the parties that are sub-parties visible in this Business Collaboration. Conversely, in a Multiparty (Business) Collaboration, the parties are responsible in that Business Collaboration. For example, the Supplier would be responsible for the performance of the sub-parties. A brief example of a ComplexBTA is shown in Figure 10. Figure 10: Status Visibility Status Visibility is included in order to specify which status values of the embedded processes are considered, if any, when returning the status value to the context in which the parent ComplexBTA was included. Condition expressions and guards govern the incoming transitions on links (FromLink from a parent ComplexBTA for example). Each of the FromLinks can be specified to transition to the CompletionState (Success or Failure) as a result of the satisfying condition guard. This allows, for example, exposing technical failures. If expected, failures can also be modeled. The parties specify how it is handled. Condition expressions and variables are described in Section 3.4.11. Expected (choreographed) and unplanned (General Exceptions) are described further in Section 3.6.2.3. As described later in Section 3.5.8.1, these linking constructs, or movements between states (which were previously called pseudo-states), would be Start, CompletionState (and sub-specializations of that, Success and Failure), Fork, Join, Decision (or Choice), and Transition. They correspond to bundles of labeled edges of a directed possibly cyclic graph. At their core, they are collections of pairs of nodes, and describe the potential paths of a ebBP definition. In the ComplexBTA, this nesting and the associated constraints allow monitoring of the state model of the collaboration and specifies event visibility of the service layer model. The ebBP state model and expression enumerate semantic business events and the complexities of service events are mapped at a technical layer onto business events (semantic business occurrences). This decoupling is extremely powerful as incremental improvements in both service and business layer evolve. If a business process designer specifies the Document Flow from another sub-party, it becomes visible. This allows incremental progress in order to anticipate and accommodate future development needs by enabling status visibility in a nested process. Other capabilities evolving in the messaging layer (such as in future versions of ebXML Messaging Service) may also support this projected status requirement. Such capabilities allow more effective monitoring of the activities defined. The process designer may choose to use the status visibility details as input to make decisions on other business logic used in this enclosing BTA. Industry sectors such as logistics processes (particularly for international trade) may make use of this mechanism to allow migration to global, potentially fully visible, collaborations between many parties. In the v2.0 and v2.0.1 technical specification, the nesting for status visibility and transitions in a ComplexBTA is unbounded. More business requirements are being gathered to determine the need and use of status visibility in other activities such a Business Collaboration (Multiparty) and the utility of administrative monitoring. In the future, it is also anticipated that managing coordinated, complex activities and visibility will be expanded for Business Collaboration of more than two abstract partner roles and for ComplexBTA. Such coordination may expand the relationship of the ebBP technical specification to other emerging specifications and technologies, in order to support specialized status visibility, particularly to further enhance monitoring capabilities.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]