RE: Same model for both Public and Private process ??

The external behavior of a system (its interface) is best described as:

- A model of its behavior in which information is arbitrarily removed (a
strict subset)

Let's look strictly at activities. The behavior of a system would consist of
a finite set of activities. The external behavior of the system would
consist of a subset of that set of activities. How much information is
"removed" is a matter of best practice. Some people would argue for less
information, others would argue for more information.

If a system A is interacting with two other systems B and C, you may decide
to have an external behavior that contains only interaction between A and B,
only interactions between B and C, interactions between A, B and C (since
they may be dependent on each other), and in fact all three at the same
time.

Just as you can have multiple implementations to support the interface, you
could have multiple interfaces to describe a set of possible implementations
(this is where inheritence comes into play).

If you are willing to accept that information is removed arbitrarily, i.e.
subject to best practice, then a good option would be to have a uniform
model which can represent both behavior and external behavior, with the
following constraint:

- Behavior is not executable unless computationally complete
- External behavior is not necessarily (and most often not) computationaly
complete

There's a long debate whether external behavior should or should not include
certain pieces of information. This is purely an arbitrary decision and does
not reflect on the model.

For example, one may say that any condition is an implementation detail. On
the other hand, it is fair for a supplier to indicate in their external
behavior why certain purchase orders will not be processed. For example,
because a credit card is rejected. So an opaque condition becomes part of
the external behavior. Opaque in the sense that a condition is named
(creditCardValidate) but not detailed (the manner in which the condition is
evaluated).

Let's look at eBay as a typical example which anyone can go to and
experience (and one could easily see how this would be extended to a B2B
marketplace dealing with automotive parts, chemicals, etc). Some auctions
indicate that a sale would be made only if the buyer has positive feedback.
How positive feedback is determined is not detailed (an implementation
detail), but the external behavior does express that an opaque condition
(named but not detailed) would affect the flow.

There's a fine line between what a choreography language would want to
express and what an exectuable language would have to express, and the only
hard rule I could think of is:

- An executable language must be computationally complete

arkin


> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Ricky Ho
> Sent: Sunday, February 02, 2003 5:36 PM
> To: Mayilraj Krishnan
> Cc: public-ws-chor@w3.org
> Subject: Re: Same model for both Public and Private process ??
>
>
>
> Thanks for your feedback !
>
> Can you elaborate what do you mean by "dynamic behavior" ?  Can
> you give me
> an example of an "external behavior" that you cannot be modelled in state
> transition diagram so that I can understand better why activity
> diagram is
> a better choice ?  In a state transition diagram, every transition is
> either a "send message" or "receive message" to another party, which will
> have a "role" defined.  I failed to say why "role" is unclear in state
> transition diagram.
>
> I guess I'm talking about the opposite.  I think a "private process" is
> richer than a "public process".  By taking away the "process variables",
> "conditions", a "private process" will become a "public process".
>  Is that
> true ?
>
> Best regards,
> Ricky
>
> At 10:32 AM 2/2/2003 -0800, Mayilraj Krishnan wrote:
>
> >Ricky
> >
> >Even though the state transition diagram can represent the
> dynamic behavior,
> >the activity diagram could be the better choice for describing the
> >external behavior.
> >(public or abstract process). You can represent the roles clearly.
> >In case you want to represent the dynamic behavior of operation
> you could
> >choose
> >either activity or state transition diagram (Whether you want to put
> >emphasis on the
> >control of flow on activity or state).
> >Yes you are correct. If you remove the dynamic properties like
> >transitions, process variables
> >from the state machines (activity or transition diagram) then it becomes
> >private process that you
> >can model it using flowchart.
> >
> >Thanks
> >Mayilraj
> >At 10:52 PM 2/1/2003 -0800, Ricky Ho wrote:
> >
> >>I have some confusion as described below ...
> >>
> >>"Private process" is providing an internal implementation view
> of a party
> >>in a long running business interaction when the party is
> implementing its
> >>behavior using orchestration engine.  "Private process" is about
> >>specifying the activities he takes in responding to an event (which can
> >>be receive a particular message or send a particular message).  The
> >>process variables, routing decisions... etc, describe the detail
> >>implementation logic is clearly specified.  The modeling language (e.g.
> >>BPEL, BPML) is semantically equivalent to a flow chart.
> >>
> >>"Public process" is providing an external view of a party in a long
> >>running business interaction regardless of whether that party is
> >>implementing his behavior using an orchestration engine.
> Public process
> >>is about specifying all possible states of that party.  And
> then for each
> >>state, what events are legitimate (event can be receive a particular
> >>message or send a particular message) ?  And after that, what
> is all the
> >>"possible" next states ?  The major difference is "public
> process" is NOT
> >>to describe which route to take under what conditions.  Instead, it
> >>describe what are the possibilities.  It seems to me a "state
> transition
> >>diagram" is a natural fit to describe the "public process".
> >>
> >>Therefore, I have a question if the "public process" should be
> based on a
> >>completely different model (a "state transition diagram") than the
> >>"private process" (a "flow chart diagram").  Correct me if I
> >>misunderstand, it seems HP's WS-Conversation-Language is taking
> this approach.
> >>
> >>But I also hear that "public process" can be described as a subset of a
> >>"private process".  If you take out the "process variable", "assign
> >>statements", and the "conditions" in the switch blocks and
> loops ... etc
> >>from the "private process", then you will have the "public
> process".  In
> >>other words, public process can be just use the same model of "private
> >>process".  It seems WSCI and BPEL-private process is taking
> this approach.
> >>
> >>I also heard that the "flow-chart" is equivalent to "state
> >>diagram".  They are just a dual-representation to each other.
> >>
> >>Any comments and thoughts ... ?
> >>
> >>Best regards,
> >>Ricky
> >

Received on Monday, 3 February 2003 00:11:10 UTC