From 200a40b332420f94992eb39a6d0ea1cf1490ffc4 Mon Sep 17 00:00:00 2001 From: coreyg Date: Fri, 21 Nov 2014 09:30:19 +0000 Subject: Adding tuscany's website to their svn repo for svnpubsub git-svn-id: http://svn.us.apache.org/repos/asf/tuscany@1640879 13f79535-47bb-0310-9956-ffa450edef68 --- ...zation-of-endpoints-and-endpointreferences.html | 278 +++++++++++++++++++++ 1 file changed, 278 insertions(+) create mode 100644 site/trunk/site-publish/documentation-2x/serialization-deserialization-of-endpoints-and-endpointreferences.html (limited to 'site/trunk/site-publish/documentation-2x/serialization-deserialization-of-endpoints-and-endpointreferences.html') diff --git a/site/trunk/site-publish/documentation-2x/serialization-deserialization-of-endpoints-and-endpointreferences.html b/site/trunk/site-publish/documentation-2x/serialization-deserialization-of-endpoints-and-endpointreferences.html new file mode 100644 index 0000000000..090601fd0d --- /dev/null +++ b/site/trunk/site-publish/documentation-2x/serialization-deserialization-of-endpoints-and-endpointreferences.html @@ -0,0 +1,278 @@ + + + + + + + + + + + + + + + Serialization Deserialization of Endpoints and EndpointReferences : Apache Tuscany + + + + + + + + + + + +
+ Home > Apache Tuscany Docs 2.x > Index > Development Guides > SCA Java Runtime Overview > Serialization Deserialization of Endpoints and EndpointReferences + +
+ + + + + + +
+
+ + + + + + + + +
+  Apache Tuscany Docs 2.x > Index > Development Guides > SCA Java Runtime Overview > Serialization Deserialization of Endpoints and EndpointReferences + + Tuscany Home | User List | Dev List | Issue Tracker   +
+ + + + + + +
+
Table of Contents
+
+ + +
+ 		+ +
+
+ + +
Apache Tuscany Docs 2.x
+
Serialization Deserialization of Endpoints and EndpointReferences
+ +
+ + + + Edit Page +   + + + Browse Space +   + + + Add Page +   + + + Add News + +
+
+ +
+
+

Serialization Deserialization of Endpoints and EndpointReferences

+

A sample scenario

+

+ +

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
      • +
    +
    • +
+ + +
+
+public class Component1Impl {
+  @Reference
+  ServiceReference<Component3> component3;
+
+  @Reference 
+  Component2 component2;
+
+  public String op1(...) {
+    // Pass a ServiceReference of component3 to component2
+    component2.op2(component3, ...);
+  }
+}
+
+
+ +
+
+public class Component2Impl {
+
+  public String op2(ServiceReference<Component3> component3Ref, ...) {
+    ...
+    // Call component3 using the service reference
+    Component3 component3 = component3Ref.getService();
+    component3.op3(...);
+  }
+}
+
+
+ +

What information should be serialized?

+ +

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/binding XML.

+ +
+
+<composite name="..." targetNamespace>
+  <component name="..." uri="...">
+    <implementation.bpel process="..."/> <!-- This should be removed -->
+    <service name="..." requires="..." policySets="...">
+      <interface.wsdl interface="..."/> <!-- Is the interface needed? -->
+      <binding.ws uri="..."  requires="..." policySets="..."/>
+    </service>
+  </component>
+</composite>
+
+
+ + +

How to resolve the deserialized endpoint 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.

+ +

+ +

EndpointReference serialization

+

What information is needed on the consumer side?

+
    +
  • The binding structural URI
    • +
  • The binding type
    • +
  • The intents and policySets
    • +
  • The resolved target endpoint (including the endpoint address and/or structural URI)
    • +
+ + +

What information is not needed on the consumer side?

+
    +
  • The component implementation behind the endpoint reference
    • +
+ + +

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 reference as a composite/component/reference/binding XML.

+
+
+<composite name="endpointReference" targetNamespace="...">
+  <component name="..." uri="...">
+    <implementation.java class="..."/> <!-- This should be removed -->
+    <reference name="..." requires="..." policySets="..." target="..."> <!-- reference/@target and binding.ws/@uri are exclusive -->
+      <interface.java interface="..."/> <!-- Is the interface needed? -->
+      <binding.ws uri="..."  requires="..." policySets="..."/>
+    </reference>
+  </component>
+</composite>
+
+
+ +

How to resolve the deserialized endpoint reference 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.

+ +

+
+ +
+
+
+ + + + + + + +
+    + Delicious + Bookmark this on Delicious +    + Digg! + Digg this + +    + + Privacy Policy  -   + Copyright © 2003-2010, The Apache Software Foundation, Licensed under ASL 2.0.   +
+ + + \ No newline at end of file -- cgit v1.2.3