RE: [wsdm] MUWS: New issue to consider?

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

Ok, so when one talks to a manageable resource's manageability endpoint SOAP messages will need to carry <muws-xs:ResourceID> in the header. And therefore, EPRs will need to contain that element in the reference properties (in addition to other junk). That seems reasonable to me, however it does restrict the implementations somewhat. For example, if I have that Axis thing that controls that one and only resource, then I don't need the ResourceId in SOAP messages. Also there may be times when ResourceId is so precious that you don't want unauthorized access to it, so you don't want an EPR to have it, but rarher will include some generated key which is only known to that one endpoint implementation.

 

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749 

 

---

From: fred carter [mailto:fred.carter@amberpoint.com]
Sent: Tuesday, November 16, 2004 9:19 PM
To: Sedukhin, Igor S
Cc: wsdm@lists.oasis-open.org
Subject: Re: [wsdm] MUWS: New issue to consider?

Sedukhin, Igor S wrote:

I would be fine with saying that an EPR is constructed by the "provider" which is close to the implementation and therefore knows where to put what. For example, if I'm a provider and I use say Axis and I don't want to mess around with reference properties and I have only one resource to worry about, then I will *advertize* an EPR which has just <wsa:Address> in it. Now, if I'm a .NET with WSE provider then I may be able to get the WSA dispatch for free and therefore I could advertize an EPR which includes <wsa:Address> and <wsa:ReferenceProperties> in it. So the choice is at the "provider".

OK, I think.

 

The client needs to only know of WSA and how to deal with it in either case. It does not need to know why the provider did it one way or the other.

true, but

 

What is it that we can say here except "use WSA"?

What we can do though is to say use only wsa:Address and wsa:ReferenceProperties for resource disambiguation.

So.  A "provider" returns an EPR with a bunch of junk in it.  Presumably, the EPR is returned wrapped in some element (<wsa:EndpointReference/>) that clearly identifies the parts?  If so, then the client can properly marshall/bind these into its SOAP:header message section. If not, then the issue is that the collected junk will have a <wsa:Address/> and/or <wsa:To/>, but may also have an <foomgr:goodness/> element.  The client can't know that this is a reference property -- reference properties have no identifying mark (when placed in a header).

Assuming this is reasonably correct, things are OK.  The question was more about whether we wanted to normalize on thie reference property name.  If, for example, we used <muws-xs:ResourceId/> as the known reference property (since it's already required as part if identity & will presumably identify the resource),  then things work out nicely for constructing EPR's, aiding in one's own "discovery", working with well-understood environments, and helping to foster interoperability.

It may be slightly over-spec'd, but I think it adds some clarity and linkage to the concepts...

/fred

-----Original Message-----
From: fred carter [mailto:fred.carter@amberpoint.com]
Sent: Tue 11/16/2004 8:45 PM
To: Sedukhin, Igor S
Cc: wsdm@lists.oasis-open.org
Subject: Re: [wsdm] MUWS: New issue to consider?

Sedukhin, Igor S wrote:

>Didn't we say in WSRF that you may use any of the embodiments you like
>
Well, insofar as I know, we did say that in WSRF.  However, WSDM has not
yet updated to the not-yet-released WSRF spec, so I think we (meaning
WSDM) are (is) still restricted to WS-Addressing (if that's what you're
asking).

That said, I guess my question was do we/should we (for, say,
interoperability) define how our EPR is constructed.  Or do we just rely
on the appropriate magic for obtaining one.  I know that's probably what
we say -- I'm just not terribly comfortable with it.

>
>
>-- Igor Sedukhin .. (igor.sedukhin@ca.com)
>-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749
>
>
>-----Original Message-----
>From: fred carter [mailto:fred.carter@amberpoint.com]
>Sent: Tuesday, November 16, 2004 4:23 PM
>To: wsdm@lists.oasis-open.org
>Subject: [wsdm] MUWS: New issue to consider?
>
>In reading the WS-Management spec the other day, one thing that sticks
>out as contextually different is that they describe a normative [I
>think] mapping to WS-Addressing.  That is, they make specific reference
>to where the analogous concept to identity fits into the WS-Address.
>
>Do we need to map this?  That is, to describe how to identify the
>resource in question in our WS-Address?  I think that this is currently
>missing, and I don't recall seeing it specifically addressed in WSRF
>(and it couldn't be, since they don't have an identity capability...).
>
>Seems like we could say that there must exist a ref prop that's the same
>as the property in the property sheet in the WS-A. This leaves open
>discovery, but that's a separate problem...
>
>Opinions?
>
>/fred
> 
>