Space: Apache Tuscany Docs 2.x
(http://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x)
Page: Serialization Deserialization of Endpoints and EndpointReferences
(http://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x/Serialization+Deserialization+of+Endpoints+and+EndpointReferences)
Edited by Raymond Feng:
---------------------------------------------------------------------
h1. Serialization Deserialization of Endpoints and EndpointReferences
h2. A sample scenario
!Endpoint and EndpointReference serialization.jpg!
Assuming we have two nodes (Node1, Node2) within an SCA domain. Node1 runs
component1 which is wired to component2 on Node2.
* Propagate the endpoint descriptions via the domain registry
** Serialize the endpoints of component2 at Node2
** Deserialize the endpoints at Node1
** Bind the endpoint reference of component1 to the remote endpoints of
component2
* Pass the ServiceReference from component1 to component2 via business methods
** Serialize the endpoint reference (for example, a reference to
component3) known to component1 at Node1
** Deserialize the endpoint reference at Node2
** Bind the endpoint reference to the context of Node2/Component2
h2. What information should be serialized?
h3. Endpoint serialization
What information is needed on the consumer side?
* The protocol-specific endpoint address
* The binding structural URI
* The binding type
* The intents and policySets
What information is not needed on the consumer side?
* The component implementation behind the endpoint
I'm not sure if the componentType of the owning component or interface
contracts are needed. Interface validation against a remote endpoint can be one
only if the interface contract for the endpoint is resolvable in the context of
the consuming component. But it can be too restrictive as it breaks the promise
of decoupling between the SCA reference and service.
The current code serializes the endpoint as a composite/component/service XML.
h2. How to resolve the deserialized information in the context of the consuming
component?
We keep the XML document from the Java serialization and load the XML into a
composite model to rebuild the endpoint in the context of the consuming
component. The currect scheme of XML serialization probably contains too much
information and some of them cannot be practically resolvable on the client
side. For example, the target component implementation or interface contracts.
Change your notification preferences:
http://cwiki.apache.org/confluence/users/viewnotifications.action
