Re: [regrep-comment] rim.xsd-Service et al.

[Farrukh Najmi <farrukh.najmi@sun.com>]

Paul Teasdale wrote:

>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)
>
Hi Paul,

First apologies ofr the delay in the resoponse.

The V2.1 schema does not support a serviceBinding attribute in 
SpecificationLink. This is a mistake in V2.1as you observe and will be 
fixed in V2.5. due out soon.

Until V2.5 the  above syntax is not supported. The only way currently to 
submit a SpecificationLink is to nest it within its parent 
ServiceBinding as you show in second form below.

>
> 
>
>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? 
>
Yes indeed. They are composed objects and their lifecycle is tied to 
lifecycle of their parents.

>
>E.g.:
>
>* If we remove a service from a registry, do we also have to specify in the ObjectRefList all child objects?  
>
No. It is implied because they are composed objects. Composed objects 
are deleted when their parents are deleted.

>
>* 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
>
The UpdateObjectsRequest does not allow partial updates. Thus above 
syntax will do just as you suggest above:

"

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. 
>
I agree with that having the second form may create confusion. We will 
consider your suggestion to remove it in a future release.

In summary, we will address the missing serviceBinding attribute in 
SpecificationLink immediately in 2.5 release. We will defer removing 
second form for a future release. Please let us know if this is a 
reasonable compromise.

Thanks for your valueable suggestions.

-- 
Farrukh