RE: [hyades-dev] New group

[Michael.Norman@xxxxxxxxxxxxx]

Joe
 
I love the  sound of people chiming in. 
 
 I tried to get back to you last night but it appears to have bounced.  
Anyway here's the gist of my response.
 
The "Platform" name can be changed, but I think it's not far off correct 
and I'd rather we had a discussion of what we are building and what its 
implications are before we change it.  let's talk on Monday at the 
regular calls about it and/or wait until some more flames appear on the 
mailing list.
 
It's important not to devalue this layer.  It is optional but it is also 
extremely valuable.  It provides a generic way of defining a behaviour 
in the "clean" Hyades model world and executing it in the "dirty" Hyades 
agent and SUT world. The universality of the BPEL language means that it 
can provide equivalent functionality to any special-purpose execution 
engine (subject to the "edge" constraints imposed WSDL).  There is 
nothing inherently non-performant about its implementation. There's no 
parsing going on until you hit the end-point, and only then if you're 
going via a textual binding such as SOAP, it's simply pushing references 
around and re-casting them.  
 
On the specific points Serge raised.  I have no immediate answers but we 
have places in Hyades to address them.  Point 1) is with the Test Model 
group. Point 2) is with the Data Collection group and Point 3) is with 
the group currently known as Platform.
 
Mike
 
 
 
 -----Original Message-----
From: jptoomey [mailto:jptoomey@xxxxxxxxxx]
Sent: Wednesday, March 03, 2004 9:03 PM
To: hyades-dev
Subject: RE: [hyades-dev] New group




I just wanted to chime in here and agree with the concerns raised by 
Serge, and also with most of the clarifications offered by Mike.   

In the interest of eliminating much future confusion (and at the risk of 
debating terminology), I request that we not call this new optional 
layer "The Platform Layer", as most people would reasonably infer that 
the platform layer for most any construct is anything but optional.  
Beyond that, I'm in agreement with the clarifications about UML2, model 
compliance and interchange formats, and I think that Serge's first "list 
of three" are pretty well addressed by this.  I assume that Mike will 
update the document in light of this. 

Beyond the first "list of three", Serge had another list of actions in 
his e-mail which I don't believe has yet been fully addressed.  I think 
we should discuss these issues as soon as possible, as they clearly will 
have an impact on the {hopefully soon to be renamed} Platform Layer. 

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

Thanks, 
--Joe 

Joe Toomey 
Advisory Software Engineer
Rational Software
IBM Software Group 


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

03/02/2004 09:32 AM 

Please respond to
hyades-dev@xxxxxxxxxxx


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

	




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





_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev

ForwardSourceID:NT00011C5A