[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: My concerns about USE CASES
Folks, I wanted to share with group my concern with the development of the use cases. There are Three areas of concern that I have: aim, communication and approach. 1. AIM This group should provide documents that further help solve issues with the spec. Other activities (like aligning other business standards to BPEL) are activities that could be considered further down the line and are, perhaps, more suited to a marking effort - rather than the technical development of the specification. I don't think there is anything wrong with looking at other business standards. It is that it is not the right time yet. Suffice it to say that, for now, we should: I) Not attempt to find hi-level business use cases that match the spec (Rubber Stamping The Specification, or RSTS). Rather, we should define use cases - for some of which, inevitably, we will find known vertical business scenarios (some of which may already have been defined by some other organization). II) Not have, as our main goal, written "BPEL" XML (Cart Before The Horse, or CBTH). Rather, we should concentrate on a description of the use case with the aim of satisfying the logical and the practical considerations (see below) of USING the specification, ergo the title "USE CASES". 2. GROUP COMMUNICATION There is a need for a simple mechanism for soliciting use cases (technical and business). While this is still TBD. I do not see the need for complex forms, etc. - Especially for technical Use cases. We want feed back from the entire technical committee first - akin to the issue numbering system. 3. APPROACH Concentrate on the technical use cases first. I don't think there is anything wrong with looking at other business standards. It's just that it is not the right time yet. I would start by having two general axioms that would form a matrix. One side would be Practical Considerations (a) and the other, orthogonal to that, would be logical Considerations (b). a) PRACTICAL CONSIDERATIONS: I wanted to have simple approach that quickly addresses a feedback mechanism to the technical needs of the specification. This would require that from a technical perspective we categorize the concerns. Here is a classification: BPEL PRACTICAL CONSIDERATIONS / \ / \ B2B AI | | | ----- Setup/ | ----- Setup/ | (Assumption) | (Assumption) / | \ / | \ / | \ / | \ Design | Run Design | Run | | Deployment Deployment b) LOGICAL CONSIDERATIONS: Each node of the above tree would then help to serve as point that needs to addressed in each of the technical use cases which can be abstracted into certain categories such as (this is just a cursory list): I) Communication Patterns: A. Synchronous: 1) Request/Response (one-to-one) 2) Solicit/Response 3) One way Notification (one-to-one) ... ... B. Asynchronous: 1) Request/Response (one-to-one) 2) Polling (one-to-one) 3) Broadcast/response (one-to-many) ... ... ||) Process Composition: A. Services Composition B. Service Exclusion C. Nested Processes ... ... |||) Process Categories: A. Fail-safe B. Temporal Dependant C. Time Dependant D. Transactional E. Stateless Transformational ... ... |V) Process Compensation A. Default Compensation B. Explicit Compensation C. Business Level Compensation ... ... V) Process Execution (Pre setup condition) A. Definition B. Registry C. Discovery D. Notification/update ... V|) Process Execution (Post setup condition) A. Concurrent B. Parallel C. Long Running D. Correlation ... ... ... ... In this way, we can form a matrix of "PRACTICAL" and "LOGICAL" considerations that together form the fundamental use cases that are critical in addressing the technical needs of the spec (I should think that some cells would be marked "NA"). We can use this document to not only much more easily solicit use cases but to generate our own. This is in-line with not wanting to commit CBTH or RSTS. At a much later date, once the technical needs have been met, we can turn to address the more hi-level business USE CASES - some of which, I imagine, would have been covered by osmosis and may span many cells. My 0.2 $ Sid Askary
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]