RE: Internal processes and/or external choreographies

Steve,
 
I'm hoping that the formalism used to define the language and constraints on
the models is not particularly visible to the users of the language.  As
where a CAD designer is not aware that the tool requires the lines and
services to describe a valid solid geometry, and a curved surface is
specified with sophisticated mathematical formulas.
 
I'm hoping that the choreography concepts developed by this group will map
directly into the conceptual model (meta model) for business process
definitions integrated into UML by the OMG effort.  I believe we can achieve
that if the choreography is at a business exchange level of abstraction that
does not attempt to deal with the message exchange protocol that may involve
a variety of interactions to accomplish reliable messaging (or not) using
various communication protocols.  In the OMG solution, it likely that the
internal processes and the choreography will have different visual
representations, that are derived from a shared, integrated model.  In these
models, however, it is likely that an internal process typically will be
defined by importing a choreography and then developing the internal
business process to support the choreography for a particular participant.
 
So, the choreography language, if expressed in XML, may not be ready for
business people, but I belive the concepts should be appropriate to business
people.  The exchange of messages will establish the rights and obligations
of the participants, and the manner by which those are established should be
understood by business people the same as they would understand the steps in
a transaction conducted by exchange of paper through the postal mail.
 
Fred

-----Original Message-----
From: Stephen White [mailto:swhite@SeeBeyond.com]
Sent: Friday, April 11, 2003 7:50 PM
To: Cummins, Fred A; Assaf Arkin; Patil, Sanjaykumar
Cc: Martin Chapman; 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 ...


Fred,
 
Based on the interest in pi-calculus and the languages that have used
pi-calculus as a model (e.g., BPEL, BPML, WSCI), I was expecting that the
language produced by this group would be similar to these past efforts.
IMHO, such languages are for business people who implement the technology
(programmers) and not for the business people who manage and design them.
Putting a one-to-one graphical front-end within a tool that has nice
usability features will not help with this situation. 
 
The work of OMG through a business process definition metamodel and BPMI
through BPMN will provide the abstraction layer that will business users and
managers to design, manage, and monitor both internal processes and
choreographies. But this kind of work is out of scope for this working
group.
 
I know that we haven't fully clarified the scope of work for this group, but
from following the discussion and seeing the complexity of the use cases, I
wasn't expecting a ready-for-business people language from this particular
working group. 
 
-Steve

-----Original Message----- 
From: Cummins, Fred A [mailto:fred.cummins@eds.com] 
Sent: Fri 4/11/2003 4:09 PM 
To: Stephen White; Assaf Arkin; Patil, Sanjaykumar 
Cc: Martin Chapman; 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 ...


Steve,
 
I believe the choreography language should express the exchange at the level
of abstraction that is appropriate for business people to understand.  This
does not mean that the form of expression is appropriate for business
people.  I beleive we should focus on the XML form of expression as that is
the form that will be appropriate for retrieval from registries and
exchanged between potential participants in a web services exchange.  A form
suitable for business users should be deferred since this requires different
skills and can be done in different ways by different tools without adverse
impact on the computational web services protocol specifications and
implementations.
 
Fred

-----Original Message-----
From: Stephen White [mailto:swhite@SeeBeyond.com]
Sent: Friday, April 11, 2003 1:48 PM
To: Assaf Arkin; Patil, Sanjaykumar
Cc: Martin Chapman; 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 believe that there is another layer of work to be done to create a
presentation layer for the business people. If BPEL and BPML are examples of
the language that might be developed (in style, not in content), a direct
presentation of this kind language will not be suitable for the business
user or manager. Especially if the choreography is based on the pi-calculus
model. There needs to be a higher level of abstraction for the presentation
and then a binding to the lower-level language. Unless this group comes up
with an XML language that can be canonically notated and still be acceptable
to the business user, then the output of this working group will not address
the business user directly. That would be a nice feature of the language,
but should probably not be a requirement.
 
-Steve

-----Original Message----- 
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Fri 4/11/2003 10:31 AM 
To: Patil, Sanjaykumar 
Cc: Martin Chapman; 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 ...




+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 <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.