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 <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your
mobile. http://www.msn.txt4content.com/
---------------------------------------------------------------------
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]
