W3C home > Mailing lists > Public > public-ws-chor@w3.org > February 2003

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

From: Ricky Ho <riho@cisco.com>
Date: Sun, 02 Feb 2003 17:35:52 -0800
Message-Id: <>
To: Mayilraj Krishnan <mkrishna@cisco.com>
Cc: public-ws-chor@w3.org

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,

At 10:32 AM 2/2/2003 -0800, Mayilraj Krishnan wrote:

>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 
>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.
>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,
Received on Sunday, 2 February 2003 20:36:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:29:54 UTC