+1
I'll add that ODs apply to PCDs as well as interceptors may be
required between the component implementation and the binding's
transport.
--
Jeremy
On Feb 26, 2007, at 4:23 AM, Meeraj Kunnumpurath wrote:
Hi,
Just wanted to confirm a few things before I hack on ..
1. The unit of transmission between the master and slave is always
going
to be a PCS.
2. The PCS will contain collections of PWDs and PCDs
3. I am assuming we will use different namespaces for different
types of
PCDs (Java PCD for example) and have corersponding strong-typed
sub-classes for PCD.
4. A PCD will have a collection of RD (Reference Definitions) and SD
(Srevice Definiions), which will again use namespaces and concrete
sub-types for supporting extensions.
5. WDs will contains a set of Ods (Operation Definitions), which
will in
turn contain a set of Ids (Interceptor Definitions). Ids will use
namespaces and concrete sub-types for supporting extensions.
6. PhysicalChangeSet, PhysicalWireDefinition and OperationDefinition
will be generic, whereas PhysicalComponentDefinition,
ReferenceDefinition, ServiceDefinition and InterceptorDefinition will
support extensions using namespaces and strong typed sub-classes
for the
extensions.
Ta
Meeraj
-----Original Message-----
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: Monday, February 26, 2007 1:30 AM
To: [email protected]
Subject: Re: Marshalling WireDefinitions for federated deployment
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message has been checked for all email viruses by MessageLabs.
*****************************************************
You can find us at www.voca.com
*****************************************************
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.
Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX
This message has been checked for all email viruses by MessageLabs.
---------------------------------------------------------------------
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]
