I'm little confused by this one. AIUI we have two configurations in
the physical world:
1) two co-located components connected by a wire
the PCS would contain two PCDs and a PWD for the connection
2) a component connected to the network via a binding
the PCD would contain a PCD with binding configuration for the
remote service/reference
These could actually be mixed (a PCD may have one service/reference
bound to the network and another wired to a different co-located
component).
With that in mind, I don't see why we would have 'bindingType' on a
PWD. In the optimal case, the controller would have reduced that to:
<wire source="foo#ref" target="bar#srv"/>
In the non-optimal case, we would need to define interceptor chains
for each of the source/callback operations, something like:
<wire source="foo#ref" target="bar#srv">
<interface>
<operation name="method1">*
<paramType type="type1"/> <!-- deals with overloading
<ins:interceptorName ...>* <!-- unique QName for each
interceptor type
<callback>
<operation name="cb1">*
<ins:interceptorName ...>*
For the second configuration above, we would just specify binding
configuration in the PCD for each physically bound service/reference.
Something like:
<cns:component name="foo">
...
<bns:reference name="ref">* <!-- unique QName for
reference binding
... binding config elements ...
<interface>
<operation name="method1">*
<paramType type="type1"/> <!-- do we need to deal with
overloading?
<ins:interceptorName ...>* <!-- outbound interceptors
<callback>
<operation name="method1">*
<paramType type="type1"/>
<ins:interceptorName ...>* <!-- inbound interceptors
<bns:service name="srv">* <!-- unique QName for service
binding
... binding config elements ...
<interface>
...
<callback>
...
--
Jeremy
On Feb 25, 2007, at 12:32 PM, Jim Marino wrote:
We need to settle on a marshalling format for WireDefinitions as
they are propagated from the Controller/Master to a slave where
they will be constituted as Wires. Meeraj has been doing work on
the Marshallers and I started to implement part of the
ConnectorImpl.connect(PhysicalWireDefinition definition) method
which will do the actual Wire creation and attach steps. The issue
is we need additional metadata about each invocation chain in the
wire to be created. We will also need to be able to pass
extensibility elements as part of an InterceptorDefinition for
InterceptorBuilders to use. I think we need the following operation
metadata:
- whether it is a forward or callback operation
- operation name and param types, the return type, and exception
types.
We also need the an extensible metadata about the wire. For (at
least) service contracts defined using Java, we need the FQN of the
forward and callback services.
We have a couple of options for serializing this across. Since we
need to support operation overloading, it may be easiest to do
something similar to the following:
<wireDefinition sourceUri="" targetUri="" bindingType="">
<metadata>
<!-- extensibility elements -->
</metadata >
<operation name="" types="" exceptions="">
<interceptorDefinition builder="">
<!-- extensibility elements -->
</interceptorDefinition>
</operation>
</wireDefinition>
On the master, we also have the issue related to implementation-
specific meta-data, e.g. data binding type information and
@AllowsPassByReference. I don't think we should pollute
ServiceContract or Operation with that metadata since they may be
reused across implementations, which will wreak havoc with the
contribution subsystem. For components, perhaps we need to add this
information to the ComponentType (we could subclass where
extensible elements only apply to specific implementation types)?
For references and services, perhaps we add this information to
BindingDefinition?
Thoughts?
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
