[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] to singleton or not to singleton
-- Igor
Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza,
Islandia, NY 11788
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]