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

Re: Internal processes and/or external choreographies (was RE: Events and States ...

From: Assaf Arkin <arkin@intalio.com>
Date: Fri, 11 Apr 2003 10:31:25 -0700
Message-ID: <3E96FBED.3010603@intalio.com>
To: "Patil, Sanjaykumar" <sanjay.patil@iona.com>
CC: Martin Chapman <martin.chapman@oracle.com>, "Burdett, David" <david.burdett@commerceone.com>, "Cummins, Fred A" <fred.cummins@eds.com>, jdart@tibco.com, public-ws-chor@w3.org

+1

We don't expect business people to write XML documents, whether it's a 
simple language or a complex one. Nor do we expect them to write 
specifications using some BNF syntax or pseudo code. We expect them to 
use high-end modeling tools with clear visual notation, something that 
makes it very easy to express and communicate intent.

The question is, how do you get that high level representation of the 
business process down to the IT level and ensure that the implementation 
conforms to the business intent? One way to do it is to agree on some 
abstract model that is common to the modeling tool and the execution 
tools, and use XML as a way to transform the key parts of the 
information, i.e. the sequencing rules - colors and shapes are not 
important in the choreography definition.

arkin

Patil, Sanjaykumar wrote:

>I am wondering whether this "glue" (or silver line, etc) also address the much blamed for Busienss-IT divide issue. I mean, does the discussion around external/internal also apply to solving the use case where - the sole responsibility of IT is to take care of the nitty-gritty of standalone services, and the Business folks are empowered with "building and owning" the dynamic, flexible business processes.
>
>I have seen in numerous recent articles (and books also, see Howard Smith's book, I forgot the name) an outcry for supporting business processes as first class applications and not necessarily to be perceived as a solution for integrating legacy applications. 
>
>In doing so, a critical requirement it seems is that the designer, user and manager of the business processes should be the business folks themselves. I guess we don't expect the business people to read XML language itself, but perhaps we can serve them better by limiting the details when it comes to providing them a limited but complete view.
>
>Sanjay Patil
>Distinguished Engineer
>sanjay.patil@iona.com
>-------------------------------------------------------
>IONA Technologies
>2350 Mission College Blvd. Suite 650
>Santa Clara, CA 95054
>Tel: (408) 350 9619
>Fax: (408) 350 9501
>-------------------------------------------------------
>Making Software Work Together TM
>
>
>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com]
>Sent: Friday, April 11, 2003 9:57 AM
>To: Martin Chapman
>Cc: 'Burdett, David'; 'Cummins, Fred A'; jdart@tibco.com;
>public-ws-chor@w3.org
>Subject: Re: Internal processes and/or external choreographies (was RE:
>Events and States ...
>
>
>
>I agree.
>
>We have different opinion on how much capabilities we want in the 
>language in terms of what it can describe. Some want a language that is 
>only capable of expressing shared states that are general enough but 
>satisfactory for most B2B use cases. Others want more capabilities that 
>*in addition* to the above and not as replacement, also support more 
>complex scenarios, e.g. the ones you would see in A2A or optionally 
>exposing part of the white/black box.
>
>We can go either way, but if we fail to consider the importance of the 
>"glue" requirement, I have the feeling we will end up with a superb 
>specification that has no practical use.
>
>arkin
>
>
>Martin Chapman wrote:
>
>  
>
>>Maybe the answer is staring us in the face:
>>
>>When we talk about external definitions we seem to be implying a shared
>>state machine. There is a common understanding between all parties about
>>who is playing what role, what states each role can  get into, the
>>(shared) state of the process itself etc. [is this what is commonly
>>called a global model?]
>>
>>On the other hand an internal defintion seems to define a state machine
>>that is not shared  (tho may or may not be visible i.e. could be black
>>box or white box). So what states you need, what tranistions you make,
>>how you name other parties is totally private.
>>
>>Obviously the two have to be glued together at some point.
>>As a group we have to decide whether we are working on shared state
>>machines vs priavte ones, or both. In all case we will have to look at
>>the "glue" requirements.
>>
>>Martin.
>>
>> 
>>
>>    
>>
>
>
>  
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.
Received on Friday, 11 April 2003 13:33:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:58 UTC