RE: [wsdm] to singleton or not to singleton

[Heather Kreger <kreger@us.ibm.com>]

Igor,
I am more in line with Williams thinking on this one.

I am fine with our April interop being a singleton pattern, perhaps we should revist that for May.

If we are going to use WS-Addressing then we must always be prepared to send and receive
SOAP headers as specified by WS-Addressing. The default behavior has to be to assume there
are headers for reference properties because the client cannot know if there should be reference properties or not.

A client cannot create EPRs from WSDLs and be guaranteed that it will be able to address the Web service.
It must GET the EPR from a registry or from the service in the WSDL.
This EPR which is retrieved may or may not have reference properties. You cannot know.

I think it is a very bad idea to restrict appropriate usage of WS-Addressing in our specification. I think that MANY implementations
will have MANY manageable resources supplied through a single Web service endpoint. We need to support this and not
force them to generate MANY WSDLs just to comply with the singleton pattern unnaturally.

The discovery and aquisition of the EPR is something we will have to address in our 1.0 specification.

I believe that we can publish 0.5 such that it expects appropriate use of WS-Addressing without answering the broader
question of how EPRs, or WSDLs, are aquired. The answer may be that they are discovered and aquired the same way.

Heather Kreger
STSM, Web Services Lead Architect for SWG Emerging Technologies
Author of "Java and JMX: Building Manageable Systems"
kreger@us.ibm.com
919-543-3211 (t/l 441) cell:919-496-9572

To: "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>, <wsdm@lists.oasis-open.org>
cc:
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.


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_workgroup.php.