rim.xsd-Service et al.

["Paul Teasdale" <pteasdale@betweenmarkets.com>]

Looking at rim.xsd, Service, ServiceBinding and SpecificationLink. 

Focusing on parent/child relationships and the life cycle management of ServiceBinding and SpecificationLink.

I assume we can now submit Service, ServiceBinding and SpecificationLink as follows

** First form ** 

<SubmitObjectsRequest>

          <RegistryObjectList>

                      <Service id="serviceId"/>

                      <ServiceBinding id="serviceBindingId-1" service="serviceId"/>

                      <ServiceBinding id="serviceBindingId-2" service="serviceId"/>

                      <SpecificationLink id="specLink" serviceBinding="serviceBindingId-1" specificationObject="urn:uuid:EO"/>

                      <ObjectRef id="urn:uuid:EO"/>

           </RegistryObjectList>

</SubmitObjectsRequest>

(Note: I assume that rim.xsd unintentionally omits the SpecificationLink's serviceBinding objectRef attribute)

 

Which is equivalent to:

** Second Form **

<SubmitObjectsRequest>

          <RegistryObjectList>

                      <Service id="serviceId">

                                   <ServiceBinding id="serviceBindingId-1" >

                                         <SpecificationLink id="specLink"  specificationObject="urn:uuid:EO"/>

                                  </ServiceBinding>

                                   <ServiceBinding id="serviceBindingId-2" />

                       </Service>

                      <ObjectRef id="urn:uuid:EO"/>

           </RegistryObjectList>

</SubmitObjectsRequest>

I certainly can appreciate the second form when returning a Service entry from within the context of a query, but it is confusing when we start thinking about other life cycle management functions suchs as update, remove, etc...  Especially if we think in terms of cascading deletes, updates etc... Are child ServiceBinding and SpecificationLink dependant on their respective parent LifeCycle? 

E.g.:

* If we remove a service from a registry, do we also have to specify in the ObjectRefList all child objects?  

* Updating, If we do:

<UpdateObjectsRequest>

          <RegistryObjectList>

                      <Service id="serviceId" >

                                   <ServiceBinding id="serviceBindingId-1" name="new binding name" />

                       </Service>

           </RegistryObjectList>

</UpdateObjectsRequest>

This "wrongly" lets me believe that we are : renaming serviceBinding-1, removing SpecificiationLinkId and removing serviceBindingId-2

While without ambiguity, the following (first form) clears everything:

<UpdateObjectsRequest>

          <RegistryObjectList>

                      <ObjectRef id="serviceId" />

                        <ServiceBinding id="serviceBindingId" name="new binding name"  service="serviceId"/>

           </RegistryObjectList>

</UpdateObjectsRequest>

So...can't we just drop the second form? If not, then best practices should suggest that the defining form is the first. 

Thanks,

Paul.