OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsdm] to singleton or not to singleton


Title: Message
+1, I think you may safely say "manageability consumer" instead of "WSDL consumer". The latter was not defined anywhere.
 

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

 


From: Vambenepe, William N [mailto:vbp@hp.com]
Sent: Thursday, April 01, 2004 12:01 PM
To: Sedukhin, Igor S
Cc: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] to singleton or not to singleton

Igor and I discussed this and came up with the following proposed wording to add to section 3:
 
 
Either of the following WSRF-compliant patterns MAY be used by the WSDM compliant manageability providers
 
1) If one manageability endpoint corresponds to one and only one manageable resource, then a singleton WS-Resource implied pattern SHOULD be used. This means that the manageability endpoint doesn't expect to receive WS-Resource qualified EPRs in the message headers to indicate which resource is being managed.   WSDL consumer who does not have an EPR for a manageability endpoint MAY try to invoke manageability operations without including reference properties information. If this succeeds, the WSDL consumer knows that the manageability endpoint uses the singleton pattern.

2) If the manageability endpoint corresponds to zero or more manageable resources, then the WSRF Implied Resource Pattern MUST be followed. This means that the element(s) listed in the ReferenceProperties of a WS-Resource qualified EPR  must be included in the header of messages sent to such manageability endpoints. This specification does not currently define how to obtain the EPR. There may be an out-of-band agreement between provider and consumer on how to obtain EPRs or future versions of this specification would clarify this subject.
Regards,
 
William
 
-----Original Message-----
From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
Sent: Thursday, April 01, 2004 8:10 AM
To: Heather Kreger; Vambenepe, William N
Cc: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] to singleton or not to singleton

Heather,
 
The question was not about WS-Addressing. Proper use is expected by MUWS 0.5 and for the interop we make some technical simplifications. That is ok and was never an issue.
 
The problem was with requiring ReferenceProperties with something in it. I.e. not specifying explicitly that MUWS 0.5 uses singleton pattern and therefore ReferenceProperties are not needed. We're not making any better statements right now on how to provision EPRs, so why not make it explicit?
 

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

 


From: Heather Kreger [mailto:kreger@us.ibm.com]
Sent: Thursday, April 01, 2004 10:17 AM
To: Vambenepe, William N; Sedukhin, Igor S
Cc: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] to singleton or not to singleton

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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]