Re: [2.x] What information should be serialized with EndpointReference/Endpoint and how to resolve them on the consumer side?

[Luciano Resende <lu...@gmail.com>]

On Mon, Dec 7, 2009 at 1:54 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> I have been trying to find out what information should be serialized with an
> Endpoint or EndpointReference and how they can be resolved (or rebuilt) by
> the consuming component. The current code serializes an EP or EPR as
> composite/component/reference|service/binding. I have put together a wiki
> page at [1] to illustrate the use cases and explain how an EP/EPR should be
> exchanged. Let's use it to discuss and fix the issues we have run into.
>
> [1]
> http://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x/Serialization+Deserialization+of+Endpoints+and+EndpointReferences
>


>From the wiki page, it seems that we are currently serializing more
info then needed (The current code serializes the endpoint as a
composite/component/service/binding XML). I can see couple options to
optimize this :

- optimize the cloned composite/endpoint/service/binding by removing
reference to unnecessary information
- create a EP/EPR schema which would hold only the necessary
information that needs to be submitted remotely

IMO, the second options seems to allow for better
flexibility/optimizations and if people agree I could try improving
the code to perform this.

Thoughts ?


-- 
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: [2.x] What information should be serialized with EndpointReference/Endpoint and how to resolve them on the consumer side?

[Raymond Feng <en...@gmail.com>]

The scenarios you listed look good. You added the matching perspective to 
what I had for the serialization/deserialization.

Case 1: No serialization/deserialization is involved. The matching is based 
on the local endpoints.

Case 2: Remote endpoint descriptions are received from the registry which 
can be p2p or centralized. It only provides the following information:

* The protocol-specific endpoint address (to connect to the target endpoint)
* The binding structural URI (to identify the endpoint in the domain 
hierarchy to resolve @target)
* The binding type (to know the binding protocol)
* The intents and policySets (to match the policy configurations)

Deployment-time matching is limited since the node doesn't have knowledge of 
the artifacts (interfaces in particular) from the target endpoint.

Case 3: A domain manager that serves as:
*  A repository for contributions that can be used to validate domain-level 
wirings at deployment time
*  A a registry to provide endpoint descriptions and policy definitions at 
runtime

Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Tuesday, December 08, 2009 10:15 AM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] What information should be serialized with 
EndpointReference/Endpoint and how to resolve them on the consumer side?

> I think we have to take a view on this. Standing back what scenarios
> are we trying to support?
>
> 1/ a single node that matches EPRs within a composite
> 2/ a distributed set of nodes that are started independently, have no
> central point of control and no ability to match domain level EPRs
> other than via the distributed registry
> 3/ a distributed set of nodes that are started with reference to a
> distributed registry populated by a domain manager
>
> In 1 the node has all of the contributions/assets it needs to validate
> all wires and ensure that EPRs match EPs before the application is
> started
>
> In 2 each node can only validate local wires fully before the app is
> started. For EPRs to services running in other nodes we want to
> minimize the amount of information used for matching and hence the
> amount of information that has to be represented in the registry. I
> think the minimum set is as follows (taken from the wiki page)
>  The protocol-specific endpoint address
>  The binding structural URI
>  The binding type
>  The intents and policySets
>
> I've missed out interface contracts here because even if we do name
> the contract in the registry we won't have the assets local to the EPR
> to complete the matching process. We could choose some intermediate
> format for the interface contract and pass that but it's extra
> complication. The flip side of this is that we may wire remote
> references and then find that there is some interface matching issue
> at runtime.
>
> In 3, as in 1, the full set of matching can be performed before the
> registry is populated because the domain manager has access to all of
> the assets. interface matching errors can therefore be reported before
> the nodes are started.
>
> So can we live with leaving detection of interface miss-matches until
> runtime in scenario 2? I think I probably could in the first instance
> but it leaves me a little uneasy that there is an inconsistency.
>
> A subsidiary question related to policy sets. We will provide policy
> specific matching code which will need to be present in the EPR node
> in order for the match to take place. However we would have to assume
> that any resources to which a policy set refers may not be available
> for matching based on the point made above. I.e. we can match the XML
> but not any referenced resources.
>
> Simon 

Re: [2.x] What information should be serialized with EndpointReference/Endpoint and how to resolve them on the consumer side?

[Simon Laws <si...@googlemail.com>]

I think we have to take a view on this. Standing back what scenarios
are we trying to support?

1/ a single node that matches EPRs within a composite
2/ a distributed set of nodes that are started independently, have no
central point of control and no ability to match domain level EPRs
other than via the distributed registry
3/ a distributed set of nodes that are started with reference to a
distributed registry populated by a domain manager

In 1 the node has all of the contributions/assets it needs to validate
all wires and ensure that EPRs match EPs before the application is
started

In 2 each node can only validate local wires fully before the app is
started. For EPRs to services running in other nodes we want to
minimize the amount of information used for matching and hence the
amount of information that has to be represented in the registry. I
think the minimum set is as follows (taken from the wiki page)
  The protocol-specific endpoint address
  The binding structural URI
  The binding type
  The intents and policySets

I've missed out interface contracts here because even if we do name
the contract in the registry we won't have the assets local to the EPR
to complete the matching process. We could choose some intermediate
format for the interface contract and pass that but it's extra
complication. The flip side of this is that we may wire remote
references and then find that there is some interface matching issue
at runtime.

In 3, as in 1, the full set of matching can be performed before the
registry is populated because the domain manager has access to all of
the assets. interface matching errors can therefore be reported before
the nodes are started.

So can we live with leaving detection of interface miss-matches until
runtime in scenario 2? I think I probably could in the first instance
but it leaves me a little uneasy that there is an inconsistency.

A subsidiary question related to policy sets. We will provide policy
specific matching code which will need to be present in the EPR node
in order for the match to take place. However we would have to assume
that any resources to which a policy set refers may not be available
for matching based on the point made above. I.e. we can match the XML
but not any referenced resources.

Simon