[no subject]

ServiceGroup:

=B7     A Web service that is a collection of other Web services or
WS-Resources and the information that pertains to them. The purpose of =
the
group is application domain specific. The means by which the membership=
 in
the ServiceGroup is formed may be through ServiceGroupRegistration, or
through other means not defined by this specification.



"Sedukhin, Igor S" <Igor.Sedukhin@ca.com> wrote on 05/21/2004 12:05:55 =
PM:

> Tom,
>
> Due to [A ServiceGroup is a WS-Resource, following the implied
> resource pattern] as defined in http://www.oasis-open.
>
org/apps/org/workgroup/wsrf/download.php/6580/WS-ServiceGroup.March%203=
1.f.doc

> , one would need to obtain an EPR to talk to a ServiceGroup. So that
> does not solve a problem of obtaining initial EPRs just yet.
>
> Either WSDM or WSRF has to clarify
>    1) that a ServiceGroup can be used in a singleton pattern
>    2) describe a normative way to determine whether a singleton
> pattern can be used to communicate to a ServiceGroup [or WS-Resourse
> in general, for that matter]
>
> I think it is reasonable to allow a management interface and a query
> collection interface to be implemented by the same endpoint in an
> intention to provide EPRs for the resources managed by a given Web
> service endpoint.
>

+1 to reasonable to "allow".  I just want to make sure we do not "requi=
re"
that to be true.

>
>
> I think it is perfectly reasonable to be able to locate WS-Resource
> qualified endpoint references.
> I also think it is perfectly reasonable to standardize an interface
> for querying/retrieving a collection or related WS-Resources.  (BTW,
> there is one of these already WS-ServiceGroup ;-) )
>
> I think it is unreasonable (perhaps even outright wrong) to require
> that the management endpoint interface and the interface for
> querying/retrieving a collection MUST be implemented by the same
endpoint.
>
>
>
> Fred Carter <fred.carter@amberpoint.com> wrote on 05/20/2004 06:38:22=
 PM:
>
> > <ScenarioPart>
> >
> > My scenario, unless I mentioned another to which I wasn't paying
> > attention during the call, is as follows.
> >
> >     Manager is started.  It is given either a WSDL file (which
> > corresponds to an endpoint for a manageability endpoint) or a URL
> > (which corresponds to said endpoint -- assumed to have some known
> capabilities).
>
> More precisely you mean that a manager is "given" a service element
> and port, somehow.
>
> >
> >     Manager wants to use said endpoint to do its manager applicatio=
n
> > thing.  To do so, it needs to find the resources available.
> >
> >     Now what?
> >
> > that's it.  I think this is the fundamental part of the so-called
> > "WSDL->EPR" requirements.
> >
> > </ScenarioPart>
> >
> > <FredsCommentary>
> >
> > Responses to anticipated issues:
> >
> >     Well, why not start with EPR's.
> >         1) Cause we didn't.
> >         2) Cause many web service applications follow the above
> > pattern
>
> Today
>
> >     Use [insert name] registry here.
> >         1) Small site, I don't have one.
> >         2) My first implementation will be the simplest one.  Later=
, I
> > will add complexity with more moving parts, etc.
>
> It is fine if you "want" to implement an interface that provides
> query and retrieval on the same endpoint as the management
> interfaces.  That is clearly an implementation choice; requiring ALL
> implementations to make that same choice is overly constraining.
>
> >
> >     Why should we do this?  Why isn't this left unspecified?
>
> Not asking for the interfaces to be left unspecified but rather
> requesting that we give the implementers latitude in where and how
> they implement that interface.
>
> >         1) Our intent, insofar as I can tell, is to provide a
> > specification which is usable as is.  We have made a number of
> > decisions and taken directions based on the capability of extant to=
ols
> > and software stacks, to ensure that the specification is adoptable.=

> > If the we rely on a implementation specific stuff to start up,
> > especially for the simplest case (a small number of resources, one
> > container, no uddi, etc.), I think we have an adoption problem.
>
> But you are relying on implementation stuff.  You are suggesting (I
> think) that EVERY implementation MUST provide this interface.  If we
> create hardened requirements for collocation of interfaces in an
> implementation we introduce a fragility in the standard that will
> eventually cause us grief/pain perhaps even thwarting adoption.
>
> >         2) We can certainly argue that there are should be some oth=
er
> > [heretofore nonexistent] specification in which the belongs.  And t=
hat
> > may even be true.  But we want folks to adopt & implement now, so
> > basing our work on more things that might come real soon now seems
> > fraught with peril.
>
> Lots of questions here.  What do you think the product adoption
> cycle of a standard is?  As always wrt dependencies on other work;
> however, reinventing, over-sepcifying, or ignoring other work are
> equally fraught with peril.
>
> >         3) One /could/ make whatever a solution might be (say, the
> > ListEPRs operation, for purposes of argument) optional so that "tin=
y
> > manageability provider endpoints" (or dynamic ones) could function
> > without fear, but I think we should provide the definition nonethel=
ess.
>
> +1 to this.  Normatively describe the interface and make it optional.=

>
> > At a higher level, I think that any system wherein access to said
> > resources is provided by other access providers (e.g. WSRF-based
> > things
> > :-) ) must have a means by which one can determine which resources =
are
> > accessed via what access provider (modulo permissions, etc.).  This=
 is
> > a bootstrap issue.  It may be that there are options (e.g. use some=

> > registry), but then one must be able to find said registry. (Perhap=
s
> > we define some appropriate fault or property that directs the calle=
r
> > to said registry when necessary.)  Consequently, I tend to think th=
at
> > this is a general problem for WSRF.
>
> Some aspect of this may be WSRF.  However, I think you will find
> that WSRF TC will not standardize service implementations.  They MAY
> standardize a fault mechanism (which is an interesting idea).
>
> >
> > [It may be appropriate higher up in the chain (it may be some of th=
e
> > defined mechanism behind ...Addressing), but since WS-Addressing is=

> > agnostic on what the properties are used for, it may not be
> > appropriate there.]
> >
> > </FredsCommentary>
>
> <snip/>


T o m=A0=A0 M a g u i r e

STSM, On Demand Architecture
Poughkeepsie, NY=A0 12601

internet: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 tmaguire@us.ibm=
.com
phone:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 845.=
433.9401 (t/l 293-9401)=