[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stp-dev] Intermediate Hybrid Model Discussion

Hi Adrian, Andrea,

Good to hear that you think this is possible.
I am wondering how one would attach metadata to the endpoint, like policy information. I guess one way to do this would be to attach it as a property to the Service Binding, but then we would have to make sure that there is only one endpoint per Binding, This would be fine with me, but is this how you are thinking too?
Also to attach a property to the ServiceBinding it would need to have a containment relation to the Property entity which currently isn't there.


Cheers,

David

Adrian Mos wrote:
Hi David,

So I gave this some thought together with Andrea and I think we can go about putting the endpoint information even without resorting to using the Steps, in a rather straight-forward manner. With some inspiration from the SCA assembly model, I think the endpoints can be defined as properties of the services associated with a particular binding.

In the particular case of the current intermediate model version, this would involve the following:
- Bindings would define a PropertyDefinition instance called "Endpoint"
- Services would have a Property instance for each endpoint and this would be linked to the property definition linked to the particular binding.


Eg. to expose a service via HTTP and JMS, you'd first have 2 bindings defined. The HTTP binding will have an "HTTPEndpoint" instance of the PropertyDefinition and the same goes for the other binding. The Service that you want to expose via 2 endpoints that correspond to these 2 bindings would actually have two Property instances, with the corresponding URI's. For the endpoint to be exposed via HTTP, its Property instance would be linked to the PropertyDefinition instance ("HTTPEndpoint") associated to the HTTP binding. Similarly for the other one. In this way, you can even define multiple endpoints for a service that use the same binding, by having multiple Property instances that are associated to the same PropertyDefinition instance.

I admit that using this mechanism renders the endpoints "second-class citizens" as they do not appear explicitly. However, I believe that they are somewhat implicit in SCA and JBI anyway, and in fact the current approach taken by the intermediate model resembles SCA pretty closely in the definition of services and bindings with the associated endpoints.

What do you think, is this something that would work for you?
Cheers,
Adrian.

On Sep 5, 2007, at 4:09 PM, Andrea Zoppello wrote:

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



_______________________________________________ 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