[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [stp-dev] Intermediate Hybrid Model Discussion
|
Hi David,
I'm Andrea zoppello, from engineering.
I'm working with Adrian moss on the definition stp intermediate model.
If your service could be exposed with more than one protocol, you could
use the "ServiceBinding" to do this.
In this way you could mantain the reusable nature of the service, and
bound a service to a particular binding only
when you define the Steps in process.
When you bind a Step to a particular Service and ServiceBinding, is like
to say for example "in my process i want to use my service
within the HTTP channel ( the service binding )"
The Service Binding associated to your step defines the property
required for particular protocol and othe technological details.
the values of this will be property values of the step.
Andrea Zoppello
David Bosschaert ha scritto:
Hi Adrian,
I thought a little bit more about this and was wondering about Service
*Endpoints* and how they would be represented in your model. As far as
I understand in your current meta model a Service is really a logical
entity, correct?
So I might want to expose that Service in a number of ways, maybe
using SOAP/HTTP, maybe using CORBA or some other wire protocol. That
would produce a number of endpoints that make that service available
over the wire in a number of ways. Those endpoints themselves may also
need extra metadata, such as policy information.
I think trying to shoehorn all the endpoint-related information in the
properties is not going to work out too well. One approach could be to
add an Endpoint (any other name is fine too) as a contained 0..*
entity that is owned by the Service entity. This Endpoint entity would
also have properties such like the Service entity does.
Or is this already possibly in todays design?
Thanks,
David
David Bosschaert wrote:
Thanks Adrian, this should work.
One thing we might do at some point is publish a list of well known
property names so that everyone uses the same property for the same
kind of information. So e.g. the WSDL might be stored in a property
called 'Interface' etc.
Cheers,
David
Adrian Mos wrote:
Hi David,
Thanks for the suggestions, they are both very useful. I think that
in the new version of the model (that I just announced on the
mailing list) the contract can be defined using properties, by
creating a particular property definition (if it's an informal
document this might work). Same for the 'metadata' map you
mentioned. If the contract is a service definition, then perhaps our
Service component would suffice as well, if we agree that for each
contract, there is a service element (there is some conceptual
overloading here, I know). For instance, in SCA, a service may have
only one interface, so we'd not run into trouble with the current
model.
Let me know if you think that we lack expressivity with the Service
and property elements, perhaps with an example.
Thanks,
Adrian.
On Aug 28, 2007, at 2:26 PM, David Bosschaert wrote:
Hi Adrian,
Thanks for posting that. This is certainly very useful.
Just a few additional ideas here:
On the meta model, it might be useful to have a Service Contract
associated with the Service, as all types of Services typically
have some sort of a contract or other - I know certain
editors/technologies may not deal with the interface directly, but
its normally there somehow. This could be WSDL, a Java interface,
XML Schema or even a worddoc describing how it's used.
Also, it might be good to add a 'metadata' map to the Service where
arbitrary key-value pairs can be registered. This could be used by
editors to enhance the metamodel with optional extra metadata that
the transformations could use to make the migration from one model
to another smoother / less lossy.
Just my 2c,
David
Adrian Mos wrote:
Hi David, all,
I have created a page that illustrates a sample scenario involving
the meta-model at
http://wiki.eclipse.org/Sample_scenario_involving_the_intermediate_meta-model
It is rather rudimentary and does not cover the entire set of
entities of the meta-model but I believes it captures the
essential functionality (i.e. moving between editors that deal
with different SOA concerns).
I imagine some things might need further clarification, I will
update the page appropriately as questions arise.
best regards,
Adrian.
On Aug 24, 2007, at 5:43 PM, David Bosschaert wrote:
Hi Adrian,
Do you think you can provide the example as discussed well in
time to consider it with the proposal. It would greatly help my
understanding of the proposed model.
Thanks!
David
Adrian Mos wrote:
Forgot to attach the link referred to in the text...
[1] http://wiki.eclipse.org/MinutesAug23
On Aug 24, 2007, at 5:21 PM, Adrian Mos wrote:
Hi Guys,
To follow-up to Adrian Skehill's email, we had an interesting
discussion [1] regarding the proposed intermediate model to be
used in STP (by editors that want to benefit from facilitated
state transfer). We would like to speed up the conceptual phase
of this model and start its implementation so I am proposing
the date of Friday 31st as the last day to make any changes to
it. This would allow us to move forward quickly and not hold
back developments on components where this will be used such as
the Service Creation component. So please come forward with any
suggestions and additions to it until next Friday.
best regards,
Adrian.
---------------
*Adrian Mos*
ObjectWeb Project
SOA Technical Lead
adrian.mos@xxxxxxxx <mailto:adrian.mos@xxxxxxxx>
+33 4 76 61 54 02
*INRIA Rhone-Alpes*
655 avenue de l'Europe - Montbonnot
38 334 Saint Ismier Cedex France
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx <mailto:stp-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/stp-dev
------------------------------------------------------------------------
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx <mailto:stp-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/stp-dev
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx <mailto:stp-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/stp-dev
------------------------------------------------------------------------
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
