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" <[email protected]>
Sent: Tuesday, December 08, 2009 10:15 AM
To: <[email protected]>
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
