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
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.
[1] http://www.w3.org/TR/wsdl20/#Endpoint
Thanks,
Raymond
From: Simon Laws
Sent: Tuesday, January 13, 2009 6:51 AM
To: tuscany-dev
Subject: [2.x] [DISCUSS] Endpoints
With reference to this previous mail that included discussion on endpoints [1]
and the other endpoint discussions it in turn references [2][3][4]. We got the
RRB piece done in 1.x but the endpoint piece was held over to 2.x. Now's the
time?
>From all these posts here are some suggested changes. The motivation here is
>to;
- clearly express the idea that the combination of a reference or service with
a binding implies a single endpoint that can take part in wiring
- rationalize the two endpoint and wire structures we have in 1.x
- include pluggable support for late binding for those who want to do this kind
of thing
- if possible tidy the $promoted representation and resolve to new endpoints
rather than new services.
Structural changes
- combine endpoint and endpoint reference into a single endpoint structure
- remove endpoint wire so we are left with a single wire representation
- allow runtime services to hold a list of active endpoints
- allow runtime references to hold a list of target endpoints
- add endpoint providers in place of the endpoint resolver
- we could look at allowing endpoints to serialize themselves so bindings can
use this for callback support. I know Raymond mentioned this previously so I
hope he'll add more details.
Procedural changes
- Reference
-- create reference endpoints based on the either targets, bindings or autowire
-- don't re-write the reference binding list in memory
-- change the activator so that endpoints are used to drive wire creation
rather than bindings.
-- create a runtime wire in a similar way as now but allow a wire to be created
with no binding parts for unresolved endpoints.
-- provide an endpoint resolution hook point in the providers for people who
want to do resolution at runtime
- Service
-- create an endpoint to represent and active binding for the service. Allows
promotion to add new endpoints without changing the service binding list
-- wire creation similar to now but driven by endpoints and not bindings
Roundtripping
Using endpoints allows us to maintain the binding lists as is. However we need
to be able to support the domain re-writing of bindings we have currently.
Reference targets give rise to endpoints and resolved endpoints relate to a
configured bindings. It is not valid to have both configured bindings and
targets so we convert targets to configured bindings in the domain and write
them out to the SCDL that's passed to a node.
If we allow for unresolved targets we have a problem of how to represent them
in SCDL in this domain re-writing case. There is no SCDL structure that
represent and endpoint. We need somthing like a tuscany:binding.unresolved that
can hold the endpoint information which can then be reconstituted by the node
for use at runtime.
Thoughts?
Simon
[1] http://www.mail-archive.com/[email protected]/msg02902.html
[2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion
[3] http://marc.info/?l=tuscany-dev&m=121318046912690&w=2
[4] http://issues.apache.org/jira/browse/TUSCANY-2382
