RE: [hyades-dev] New group

[Michael.Norman@xxxxxxxxxxxxx]

Hi Serge
 
I was intending to clarify a few things with you before putting the 
document out, but had to go home and in any case it's best we do this on 
the open mailing lists.  For convenience I refer to the choreography 
engine and its associated interfaces as the "Platform" layer (to 
distinguish it from the Agent layer and the Model layer).  Most of this 
I think can be addressed by tightening up some loose language, and 
making a clear statement that the Platform Layer is optional.
 
First, your concerns about UML2.  The statement that I made about the 
Hyades Behavioural Model was in error.  It actually refers to the 
"Platform Subset of the Hyades Behavioural Model".  The Hyades 
Behavioural Model is UML 2 Behaviours, the Platform defines a subset of 
that which it implements.  I don't see the logic in Hyades itself going 
out to define how BPEL sits in  UML2.  I think we need to feed into 
other parts of the community to get this to happen.  We are, of course, 
exposed if nobody takes up the challenge, so maybe we should set up a 
group to encourage this - Antony won't be running this one!
 
Then there is a clarification required on the useage of the web services 
standards.  Textual XML of the various standards is not used as the 
persistence layer inside Hyades.  They may be used as interchange 
formats but they are used to define restrictions of the Hyades models 
which the Platform will work with, so the only requirement the Platform 
has on the testability interface in the Model is that it is capable of 
expressing the way that WSDL interfaces are mapped into UML2. The 
platform group expects to negotiate with the test model group over this 
issue, but I think the specification of a Model-Level testability 
interface is still with the Test Model Group (not Antony, although he'll 
probably have to go along to some meetings :-) ).
 
On the issue of compliance.  I have always taken the view that there are 
a wide range of interoperability points in Hyades and the key compliance 
point is the model. Despite my initial protests the model allows (and 
will continue to allow) external behaviors, but in practical terms these 
restrict tool interoperability.  What we are doing here is providing a 
standard implementation of a choreography layer which gives people a 
low-cost option to move away from proprietary external behaviours, but 
which doesn't implement the whole of UML2 behaviours.  If there is 
richness in the UML2 behaviours outside of the Platform Subset that 
people require, then they can provide an alternative choreography layer 
amd charge extra for it.  Clearly if that layer uses a superset of the 
Platform Subset (as it would be if it covered the whole of UML2 
behaviours), that engine will also execute behaviours defined in the 
Platform Subset.  In addition it is unlikely that the choreography 
engine in the Platform will be the most scalable and performant such 
engine on the planet.
 
However, on the question of universality,  I believe the combination of 
BPEL and related standards is capable of expressing any distributed 
behaviour. My vague recollection of Hoare's CSP stuff from the late 70s 
is that this is true of any language that has variables, an expression 
syntax, a Flow and a Pick (to use the BPEL terms), although there are 
other combinations of language elements that achieve the same 
universality. If this is the case, the desire to work with behaviours 
not expressed in the Platform Subset is likely to be rooted in 
convenience not necessity.
 
On the question of the runtime interface to the Platform. I think your 
suggestion that we simply use the behaviour editor to view the instance 
of the behaviour at runtime is probably right (it has a nice elegance to 
it, you already have the tree), and whatever appears here will replace 
statcon (and in some configurations may perhaps not look all that 
different :-) ). The key issue is that the platform layer provides UI 
editors/monitors/controllers or whatever which are universal over the 
set of behaviours expressible in the Platform Subset.  Another 
interesting point is that we have processes which operate inside the 
Workbench (doing things like event aggregation and filtering), which if 
they exposed a Platform -accessible interface could be choreographed.
 
I hope this helps.  More  discussion will doubtless follow
 
Mike

-----Original Message-----
From: slucio [mailto:slucio@xxxxxxxxxx]
Sent: Monday, March 01, 2004 11:24 PM
To: hyades-dev
Cc: hyades-dev; hyades-dev-admin
Subject: Re: [hyades-dev] New group




Mike, 

I think we need to clarify some elements of the document. My initial 
reading left a number of issues unspoken (:-)): 
1. On your comment "the test profile allows arbitrary UML behaviours 
which are not practical for execution". Althought it is correct that UML 
behaviors are rich, I think stating the following is not correct: 
"The Hyades Behavioural Model is defined as the subset of UML2 that 
corresponds to BPEL, or more precisely to a concrete representation of 
BPEL concepts provided in EMF." 
Eclipse is embracing the UML family of standards (MOF, UML 2.0). 
Therefore, the Hyades behavioral model is and should remain UML 2.0 
behaviors, without restrictions. The restriction to BPEL should apply 
only to the generic execution engine. 
2. On the statement "The SUT is modelled as a WSDL interface – if the 
SUT does not provide a WSDL interface a “wrapper” can be built 
around the actual interface of the SUT". An interface specification of 
the SUT should be a UML 2.0 model of it, and should be part of the 
"test" model. Providing a  mechanism to import this model from a WSDL 
interface is desirable. 
3. On the runtime UI "This, together with the ability of the runtime UI 
to modify variables in the BPEL, defines a new runtime control and 
monitoring UI which replaces statcon (and probably won’t look that 
different)." I am not sure that stacon is the most suitable interface 
for that. Why is this interface different from the generic behavior 
editor you are proposing? 

I think we are trying to achieve a number of distinct things here that 
should probably trigger the creation of several working entitties: 
1. Formalization of a testability interface (i.e. provide a model of the 
SUT). This is absolutely required for the test model to be complete. 
This must be based on UML 2.0 standards. WSDL is a nice and easy way for 
Hyades users to describe these interfaces textually and shouldn't be the 
standard put forward. 
2. Standardization of agents interfaces for test components to interact 
with them. This is very important to formalize the communications of 
agents beyond the RAC transport layer. 
3. Provide a generic execution engine based on Web Services standards. 
This is a "nice to have". 

I think 1 and 2 definitely belong to the Hyades platform.  Unfortunately 
(1) needs to wait for Hyades and the UML 2.0 project to converge, so we 
should speak to this topic in light of UML 2.0 profile alignment post 
Hyades 3.0 (2) probably doesn't fit in the 3.0 schedule, but is very 
relevant. Finally (3) is a completely separate item, that should be 
considered as an example for now. 

I want to make sure that we (IBM) get involved in the detailed 
definition of what is proposed, before we bless it. At this stage, I 
think things are not well enough defined: The scope of the proposal is 
pretty wide, and I don't want people to go off on the basis of this 
document and mess up with the existing Hyades models, and/or 
positioning. So, to start with, I would like to see from Anthony (I 
guess) a detailed proposal describing the 3 topics I highlighted: 
testability interface, agents' interfaces, execution engine (behavior 
UI, WSDL and BPEL mappings to UML 2.0, runtime UI). 

Finally, I would like to get Mike to clarify that UML 2.0 remains the 
primary standard that Hyades/Eclipse supports, with no restrictions, 
WSDL and BPEL being specific to this generic execution engine 

Thank you, 
Serge 




Michael.Norman@xxxxxxxxxxxxx 
Sent by: hyades-dev-admin@xxxxxxxxxxx 

03/01/2004 01:49 PM 
Please respond to
hyades-dev


To
hyades-dev@xxxxxxxxxxx 
cc
Subject
[hyades-dev] New group

	




Following some discussions after the face to face about our plan post 
3.0, there have been some ongoing discussions around an additional 
choreography layer, and given these are only loosely related to the 
existing group structure the management group has decided to set up an 
additional group known as the Platform Group to address them.  It will 
be run by Antony Miguel antony.miguel@xxxxxxxxxxxxx, although because he 

isn't a committer I will represent it at the weekly committer call.

Attached is the current working document for the group  Antony will set 
up the weekly sessions via Webex.  Please come along and participate.

Regards,

Mike Norman,
Hyades Project Lead