OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel-uc message

[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]