RE: [wsdm] to singleton or not to singleton

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

MOWS refers to MUWS, MUWS refers to WSArch. That, IMO, solves the "where do I find WSDLs" problem. There is sufficient information in WSArch, e.g. it says that URL to WSDL is fine. We're not alone on this.

MOWS does not need to make no statement about EPR. MOWS is based on MUWS and MUWS has to clarify this. Now, MUWS is using WSRP, but there is nothing in MUWS or WSRP that says how to get the EPR. We're alone on this. No one except people in this group knows what this is about and why it will or will not work right now. What is the point in publishing a spec that way?

I was not intending to make the discovery easier, I just wanted to make the spec sufficient for implementers OF THE SPEC ITSELF.

[
As you would expect, I have to contest this representation. The WSDL spec doesn't say how you find the WSDL description of a service. Does this mean that WSDL cannot be used in an interoperable manner?
]

WSDL also does not suggest to send any messages to retrieve or operate on WSDL. We have messages that have to be exchanged to retrieve WSDM properties. If I cannot properly form the messages that WSDM specs define, then that is the problem of the WSDM spec.

Finding manageability endpoint description is similar to the WSDL not specifying how to find WSDLs, however once I found such manageability endpoint description, finding EPR is not similar to the problem you're refering to.

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

-----Original Message-----
From: Vambenepe, William N [mailto:vbp@hp.com] 
Sent: Tuesday, March 30, 2004 9:36 PM
To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
Subject: RE: [wsdm] to singleton or not to singleton


Igor,

The problem you are pointing out is not specific to EPR and would not be solved by your proposed restriction to the singleton pattern. The question is "how do I find a handle to a manageable endpoint". Whether this handle is an EPR or a WSDL service element (in the case of the singleton pattern) is not the problem. This is a generic discovery problem with MUWS.

Now, as I wrote before, in the case of MOWS things are different because we have an operational WSDL for the resource. I can see how we would put some discovery optimization in MOWS to take advantage of this. But this has nothing to do with MUWS.

If I misunderstand you, please describe a MUWS (not MOWS) situation in which the singleton pattern makes discovery easier.

Now regarding:

> 3) Leave it as it is and publish a committee draft of a spec that 
> cannot be used in an interoperable manner.

As you would expect, I have to contest this representation. The WSDL spec doesn't say how you find the WSDL description of a service. Does this mean that WSDL cannot be used in an interoperable manner?

Regards,

William


> -----Original Message-----
> From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
> Sent: Tuesday, March 30, 2004 5:58 PM
> To: fred.carter@amberpoint.com; wsdm@lists.oasis-open.org
> Subject: RE: [wsdm] to singleton or not to singleton
> 
> 
>  Fred, yes I agree with you.
> 
> So to sum it up we have three choices now
> 
> 1) fix WSDM 0.5 spec and explain how to obtain EPRs before publishing 
> it as a committee draft. For that we may have to define some 
> operations or use WS-ServiceGroup or things like that. I don't want to 
> dive in details here.
> 
> 2) make a statement in the WSDM 0.5 spec that the valid silngeton 
> pattern of WSRF applies here. Then publish as a committee draft.
> 
> 3) Leave it as it is and publish a committee draft of a spec that 
> cannot be used in an interoperable manner.
> 
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> 
> -----Original Message-----
> From: Fred Carter [mailto:fred.carter@amberpoint.com]
> Sent: Tuesday, March 30, 2004 6:32 PM
> To: wsdm@lists.oasis-open.org
> Subject: Re: [wsdm] Groups -
> wd-wsdm-muws-0.5-20040329-with-tracking.zip uploaded
> 
> <FlameproofSuit state="on">
> 
> Folks,
> 
> I think that if we want to, we can all do a pretty good job of 
> sabotaging any chance of getting things to work.  If that's the goal, 
> so be it.
> 
> On the other hand, we can look at this as a chance to get something 
> working -- not complete, not totally perfect, but basically 
> functioning.
> 
> We know that for this interop, we will have one endpoint/provider 
> endpoint.  Thus, the singleton case applies.  Why complicate things?
> 
> "...the WS-R? standard says..." :: It's not a standard yet.  
> Nor, for that matter, is WS-Addressing, insofar as I know (but that's 
> a different problem), so I don't know what the required means for 
> operation necessarily is at present.  It may be that "our feedback" is 
> that the default cases for these should make things simpler, since 
> that's what exists in the world today. (<tongueSlightlyInCheek>If I 
> can define all current web services as compliant because they work 
> with the default case (no info),  "just look at my installed base."
> </tongueSlightlyInCheek>)
> 
> (Remember, too, that the standard as it's currently defined has 
> already undergone some change to make it work with tools, internally 
> consistent, etc.  Let us not believe too strongly in its state of 
> perfection...)
> 
> 
> Personally, I'd like to see something, however miniscule, working.  If 
> we can remove obstacles to getting basic interoperation between a 
> manager & a manageability provider, so much the better.  Once 
> something works, it's not hard to add new stuff til it breaks, and 
> mung until done.  The interop scenario about which we're talking is 
> "10 people in a room with a /community of laptops/."  If/when we stage 
> a more public thing, we can deal with how this will evolve, what is 
> the EPR format, how does real discovery work, what are the fault 
> definitions, etc.
> 
> 
> But that's just me...
> 
> /fred
> 
> </FlameproofSuit>
> 
> I'll now return you to your regularly scheduled entertainment...
> 
> --
> Fred Carter / AmberPoint, Inc.
> 
mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgrou
p.php.



To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgrou
p.php.