You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jim Marino <jm...@myromatours.com> on 2007/02/25 21:32:30 UTC
Marshalling WireDefinitions for federated deployment
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Marshalling WireDefinitions for federated deployment
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 25, 2007, at 5:29 PM, Jeremy Boynes wrote:
> For all of these:
> <cns:component
> <bns:reference and service
> <ins:interceptorName
>
> the element is an extension-specific, unique, versioned identifier
> for the component implementation type, binding, or interceptor
> builder. Meeraj's unmarshalling framework is able to dispatch the
> to the appropriate unmarshaller in order to read the element in
> builder-specific manner. The content of that is completely under
> the control of the marshaller/unmarshaller for that extension so
> there is no need for xml extension hooks.
>
> This data is not intended for use by end-users so we can be very
> precise with the XML definitions (read really ugly XML, lots of
> namespaces etc.). We need that in order to maintain portability
> between different implementation and different versions of the same
> implementation.
>
> Hope that makes sense.
Yep, Didn't pick up on the namespaces. I think that should work for us.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Marshalling WireDefinitions for federated deployment
Posted by Jeremy Boynes <jb...@apache.org>.
For all of these:
<cns:component
<bns:reference and service
<ins:interceptorName
the element is an extension-specific, unique, versioned identifier
for the component implementation type, binding, or interceptor
builder. Meeraj's unmarshalling framework is able to dispatch the to
the appropriate unmarshaller in order to read the element in builder-
specific manner. The content of that is completely under the control
of the marshaller/unmarshaller for that extension so there is no need
for xml extension hooks.
This data is not intended for use by end-users so we can be very
precise with the XML definitions (read really ugly XML, lots of
namespaces etc.). We need that in order to maintain portability
between different implementation and different versions of the same
implementation.
Hope that makes sense.
--
Jeremy
On Feb 25, 2007, at 3:00 PM, Jim Marino wrote:
>
> On Feb 25, 2007, at 2:18 PM, Jeremy Boynes wrote:
>
>> 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>
>> ...
>>
> I'm cool with the format above provided we allow for extensibility
> info in the interceptor (I think it needs to be more than a name).
> Having the param types as elements rather than attributes is better
> as is the separation of forward and callback ops. Also, you are
> right, we don't need binding type.
>
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Marshalling WireDefinitions for federated deployment
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 25, 2007, at 2:18 PM, Jeremy Boynes wrote:
> 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>
> ...
>
I'm cool with the format above provided we allow for extensibility
info in the interceptor (I think it needs to be more than a name).
Having the param types as elements rather than attributes is better
as is the separation of forward and callback ops. Also, you are
right, we don't need binding type.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Marshalling WireDefinitions for federated deployment
Posted by Jeremy Boynes <jb...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Marshalling WireDefinitions for federated deployment
Posted by Jim Marino <jm...@myromatours.com>.
On Feb 25, 2007, at 1:07 PM, Meeraj Kunnumpurath wrote:
> Jim,
>
> As it is now, the marshaller framework only deals with marshalling
> and unmarshalling physical change sets (PhysicalChangeSet class in
> SPI). A physical change set is composed of zero or more physical
> component definitions (sub types of PhysicalComponentDefinition in
> SPI) and zero or more wide definitions (PhysicalWireDefinition in
> SPI). Physical wire definition currently has source and target
> URIs, binding type and zero or more interceptor definitions
> (PhysicalInterceptorDefinition in SPI). The interceptor definition
> currently has only the qname of the builder defined against them.
>
> The creation of the wires themselves from the wire definitions, I
> assume is done by the connector. However, as I gather from your
> note, the connector may need additional metadata on top of the
> source and target URIs, binding types and the interceptor builders
> to create the wires. This includes metadata for individual
> operations, extesibility elements for the wires themselves and
> extensibility elements for the interceptors. I have two questions
> on this,
>
> 1. Do we currently have classes that represent operations in our
> model? Operation in SPI looks to me as having more information than
> we need. Is it worth defining PhysicalOperationDefinition in the
> SPI physical model?
Yes, I think it has more than we need and it is problematic in that
it defines things such as databinding types which are specific to the
implementation and not the service contract. I was proposing to move
that information to ComponentType and BindingDefinition and having it
serialized as extensibility elements under interceptorDefinition.
Other information such as allowsPassByReference would not need to be
serialized as there will be an interceptorDefinition for it.
> 2. What kind of information is expected in the extsnsibility
> elements for wire and intereceptor definitions?
I think information related to what the implementation expects from
the container. The one that comes to mind is databinding type
information
> Also what does extensibility information entail to? Is it enough to
> have some generic mechanism for attaching extension information
> within PhysicalWireDefinition and PhysicalInterceptorDefinition
> classes or is it worth having specific sub-types for different
> types of extensions.
I prefer strongly typed when possible through subtypes. I've seen
that having generic extensibility collections promotes doing
problematic things like tunneling information through multiple layers
without an easy way to trace it.
>
> I should be up late tonight, if you could pls respond tonight I can
> continue hacking the marshaller framework.
:-) I'll take a look at the PCD as well.
Jim
> Also, it would be great to know your thoughts (and others as well)
> on marshalling physical component definitions. Currently, we have
> one sub-type for PCD, which is Java PCD that uses instance factory
> byte code. PCDs are mainly used by the new physical component
> builders.
>
> Thanks
> Meeraj
>
>> From: Jim Marino <jm...@myromatours.com>
>> Reply-To: tuscany-dev@ws.apache.org
>> To: tuscany-dev@ws.apache.org
>> Subject: Marshalling WireDefinitions for federated deployment
>> Date: Sun, 25 Feb 2007 12:32:30 -0800
>>
>> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
> _________________________________________________________________
> Get Hotmail, News, Sport and Entertainment from MSN on your
> mobile. http://www.msn.txt4content.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
RE: Marshalling WireDefinitions for federated deployment
Posted by Meeraj Kunnumpurath <m....@hotmail.co.uk>.
Jim,
As it is now, the marshaller framework only deals with marshalling and
unmarshalling physical change sets (PhysicalChangeSet class in SPI). A
physical change set is composed of zero or more physical component
definitions (sub types of PhysicalComponentDefinition in SPI) and zero or
more wide definitions (PhysicalWireDefinition in SPI). Physical wire
definition currently has source and target URIs, binding type and zero or
more interceptor definitions (PhysicalInterceptorDefinition in SPI). The
interceptor definition currently has only the qname of the builder defined
against them.
The creation of the wires themselves from the wire definitions, I assume is
done by the connector. However, as I gather from your note, the connector
may need additional metadata on top of the source and target URIs, binding
types and the interceptor builders to create the wires. This includes
metadata for individual operations, extesibility elements for the wires
themselves and extensibility elements for the interceptors. I have two
questions on this,
1. Do we currently have classes that represent operations in our model?
Operation in SPI looks to me as having more information than we need. Is it
worth defining PhysicalOperationDefinition in the SPI physical model?
2. What kind of information is expected in the extsnsibility elements for
wire and intereceptor definitions? Also what does extensibility information
entail to? Is it enough to have some generic mechanism for attaching
extension information within PhysicalWireDefinition and
PhysicalInterceptorDefinition classes or is it worth having specific
sub-types for different types of extensions.
I should be up late tonight, if you could pls respond tonight I can continue
hacking the marshaller framework. Also, it would be great to know your
thoughts (and others as well) on marshalling physical component definitions.
Currently, we have one sub-type for PCD, which is Java PCD that uses
instance factory byte code. PCDs are mainly used by the new physical
component builders.
Thanks
Meeraj
>From: Jim Marino <jm...@myromatours.com>
>Reply-To: tuscany-dev@ws.apache.org
>To: tuscany-dev@ws.apache.org
>Subject: Marshalling WireDefinitions for federated deployment
>Date: Sun, 25 Feb 2007 12:32:30 -0800
>
>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: tuscany-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.
http://www.msn.txt4content.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org