NotifyActionType.endPoint

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

Hi guys,

Being a little picky, I am looking at NotifyActionType, more precisely
the "endpoint" attribute.

Is the "endpoint" attribute of NotifyActionType a reference to a
ServiceType instance (or even better) to a ServicBinding instance?
Potential benefits in doing that compared to just a URI. 

Here is an except from rim.xsd :

<complexType name = "NotifyActionType" abstract="true">
		<annotation>
			<documentation xml:lang = "en">
Abstract Base type for all types of Notify Actions
			</documentation>
		</annotation>
		<complexContent>
			<extension base = "tns:ActionType">
				<attribute name = "notificationOption"
default="ObjectRefs">
					<simpleType>
						<restriction base =
"NCName">
							<enumeration
value = "ObjectRefs"/>
							<enumeration
value = "Objects"/>
						</restriction>
					</simpleType>
				</attribute>
        <attribute name = "endPoint" type = "anyURI" use="required"/>
			</extension>
		</complexContent>
	</complexType>  
 
--
Paul


-----Original Message-----
From: Farrukh Najmi [mailto:farrukh.najmi@sun.com] 
Sent: Monday, April 21, 2003 8:37 AM
To: Paul Teasdale
Cc: regrep-comment@lists.oasis-open.org
Subject: Re: [regrep-comment] rim.xsd-Service et al.

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