RE: [hyades-dev] New group

[Joseph P Toomey <jptoomey@xxxxxxxxxx>]

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