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

Re: Abstract Bindable Choreography

From: Assaf Arkin <arkin@intalio.com>
Date: Fri, 04 Apr 2003 15:07:22 -0800
Message-ID: <3E8E102A.6020407@intalio.com>
To: jdart@tibco.com
CC: public-ws-chor@w3.org

Jon Dart wrote:

>
> UML diagrams may be useful for the examples, especially activity 
> diagrams. Stephen's BPMN diagrams also looked pretty readable to me - 
> this notation is better suited to business processes than UML, IMO.
>
> The XML representation of UML is horribly complex, and isn't directly 
> readable unless you have a tool that imports it. So I wouldn't really 
> advocate producing those files. If the purpose is to convey a diagram, 
> there is a standard called JPEG that works pretty well for that :-). 
> Re the choreography standard itself, I think the cost of trying to fit 
> it into something like XMI is greater than the benefit.

I wouldn't rule out PNG or SVG ;-)

I definitely agree with your assesment. If I wanted to specify a WS 
choreography language that allows tools to know what the hell is going 
on but use XMI, the resulting specification would be incredibly complex 
and practically unusable.

At one end of the spectrum there's the abstract definition of some 
possible flow that is not grounded to any technology. Just saying that 
activity A is followed by activity B. When the definition is that 
abstract, then XMI becomes quite usable. You really only import/export a 
subset of XMI and only handle very generic elements (activity, 
transition, etc), so it's not an unsourmountable problem.

In my experience there is need for a language for expressing WS 
choreographies. But I don't think there's a need for yet another 
language for just expressing abstract flows of activities.

arkin


>
> --Jon
>
> Assaf Arkin wrote:
>
>>
>>>
>>>
>>> 6. So which should you use, UML or XML? Now UML does have an XML 
>>> represenation, but it is proprietary (I think) to Rational and 
>>> focuses on describing the structure of any UML document rather than 
>>> the structure of a choreography. On the other hand using XML to 
>>> define a choreography would provide a development environment 
>>> neutral definition which is specifically designed for the purpose. 
>>> It would be easier to feed into a state machine that was validating 
>>> that a choreography was being correctly followed at run-time.
>>>
>> UML can be represented using XMI. XMI is standardized by the OMG, 
>> it's not proprietary, and I am aware of a few tool vendors that 
>> support it. There are also several APIs (OMG and Java) for handling 
>> XMI-based documents. So an XML representation of UML does exist and 
>> can be used by vendors.
>>
>> XMI is indeed very generic, but when you use XMI to represent UML 
>> activity/statechart diagrams it becomes specific to expressing these 
>> kind of flows. At this level it is "typed" enough to define the flow 
>> of activities for both design time and run time.
>>
>> It becomes complicated if the interaction is typed in terms of Web 
>> service types as expressed by WSDL/XSD and related technologies. In 
>> this case it becomes more efficient to both propose a framework that 
>> is based on WSDL/XSD and specific to WS choreography, and also to 
>> propose a language that is constrained by that framework.
>>
>> In my opinion the utility comes from a framework for addressing 
>> choreography of Web services. It's new and it's interesting. 
>> Addressing abstract flows is also interesting, but it can be done 
>> using existing technologies, so it's not new. I simply don't see the 
>> utility in re-inventing UML/XMI.
>>
>> arkin
>>
>>> Thoughts?
>>>
>>> David
>>>
>>> -----Original Message-----
>>> From: Martin Chapman [mailto:martin.chapman@oracle.com]
>>> Sent: Friday, April 04, 2003 10:12 AM
>>> To: 'Burdett, David'; 'WS Choreography (E-mail)'
>>> Subject: RE: Abstract Bindable Choreography
>>>
>>>
>>> David,
>>>
>>> I have a strong feeling that you can get what you want by exstiing
>>> technologies such as UML. In the past I have used use cases and 
>>> activity
>>> diagrams to express reusable interactions between parties. Diagramtic
>>> notations are explicitly out of scope of our charter, and I'm not sure
>>> if there is any benefit in a specific xml language  to express the same
>>> thing.
>>>
>>> Martin.
>>>
>>> > -----Original Message-----
>>> > From: public-ws-chor-request@w3.org
>>> > [mailto:public-ws-chor-request@w3.org] On Behalf Of Burdett, David
>>> > Sent: Thursday, April 03, 2003 11:09 AM
>>> > To: WS Choreography (E-mail)
>>> > Subject: Abstract Bindable Choreography
>>> >
>>> >
>>> > There has been some discussion around the idea of an abstract
>>> > bindable choreography so I thought I would provide an example
>>> > in the form of a diagram (PDF) which shows the flow
>>> > associated with the placement of an order and an XML
>>> > representation of the same in a declarative style. I strongly
>>> > suggest you look at the diagram first.
>>> >
>>> > Comments welcome ;-)
>>> >
>>> > David
>>> >  <<PlaceOrderChoreography.pdf>>
>>> >  <<PlaceOrderChoreography.xml>>
>>> >
>>> > Director, Product Management, Web Services
>>> > Commerce One
>>> > 4440 Rosewood Drive, Pleasanton, CA 94588, USA
>>> > Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
>>> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
>>>
>>
>>
>
>


-- 
"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, 4 April 2003 18:08:37 UTC

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