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]
