On Fri, Jan 16, 2009 at 7:48 AM, Simon Laws <[email protected]>wrote:
> > > On Thu, Jan 15, 2009 at 10:17 PM, Raymond Feng <[email protected]>wrote: > >> One more thought: >> >> Binding extensions probably need to help create the endpoint and resolve >> the endpoint references. Different bindings may even have their >> implementation of the Endpoint/EndpointReference model. For those bindings >> that support local wiring (for example, binding.sca), the endpoint reference >> can be resolved to a local endpoint which contains information about the >> component/service/binding. >> >> Thanks, >> Raymond >> >> *From:* Simon Laws <[email protected]> >> *Sent:* Thursday, January 15, 2009 6:31 AM >> *To:* [email protected] >> *Subject:* Re: [2.x] [DISCUSS] Endpoints >> >> HI Raymond >> >> Comments in line... >> >> Simon >> >> On Tue, Jan 13, 2009 at 5:45 PM, Raymond Feng <[email protected]>wrote: >> >>> Nice proposal. I agree with you on most of the points with a few >>> comments: >>> >>> Let's first fix the model. The SCA spec uses <binding.???> element for >>> two purposes: >>> a) Describes a concrete transmission protocol >>> b) Provides an address for the endpoint >>> When we initially defined the in-memory representation of the metadata, >>> the XML syntax misled us. Now we realize we should an explicit Endpoint >>> model as the WSDL [1] spec does. >>> >>> An SCA service has an interface. Each service can be configured with >>> multiple bindings and each binding binds the interface to a concrete >>> transmission protocol (and message format). The service is made available at >>> a set of endpoints. Each endpoint will have a binding, an address (URI) and >>> the interface. >>> >>> service --> interface (1..1) >>> service --> endpoint (1..n) >>> endpoint --> binding >>> --> address >>> --> interface >>> >>> An SCA reference also has an interface. Each reference will have zero or >>> more references to the endpoints (the binding, address and interface). I >>> prefer to model them as EndPointReference which can be resolved to an >>> Endpoint (or proxy). >>> reference --> interface (1..1) >>> reference --> endpoint references (1..n) >>> endpoint reference --> binding >>> --> address >>> --> interface >>> >> >> Ok. I see where you're going with EndpointReference. Works for me. I think >> we will probably still need some link from the endpoint reference back into >> the component/reference that owns it in order that the lookup part can work. >> But lets model it in a bit more detail and see how it looks. Be good to get >> some interaction diagrams going so we understand. >> >> I have yet another wiki page. Started off with just a simple diagram. >> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Endpoints. >> >> >>> >>> EndpointReference can be mapped into CallableReference and >>> ServiceReference defined by the SCA java spec. It can be used to create >>> proxies to an SCA service. The EndpointReference can be passed implicitly by >>> the runtime or explicitly as part of the business methods. >>> >>> EndpointReference can be serialized into different binding protocols and >>> later on be deserialized. For web service binding, it should be mapped to >>> the WSA EndpointReference. >>> >>> The EndpointReference can be potentially used as the client entry point >>> to the SCA composite. The client can create an endpoint reference with the >>> information about the binding, address, interface and policies and then a >>> service proxy can be created out of that. >>> >>> >> snip.... >> > > Certainly the resolution of an endpoint reference can be binding specific > so I agree with you here. > > Simon > Just bringing this thread to the top again as Endpoints are coming up in the current policy thread. We can carry on expanding http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Endpoints. Not much there yet but am starting to add things. Simon
