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 <[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]
