[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Service group Use Cases
Folks,
Susan Malaika sent us a mail a while back in response to an action item
on embodiments. However, the mail seems relevant to the current
discussion on Service groups. So I repost it, with my answers to the
questions/use cases she raises.
> From: "Susan Malaika" <malaika@us.ibm.com>
> Date: 17 December 2004 10:21:15 GMT
> To: <dais-wg@gridforum.org>, <wsrf@lists.oasis-open.org>
> Subject: [dais-wg] WSRF Embodiments and DAIS
>
>
>
>
>
>
>
>
> The Oasis WSRF group asked the GGF DAIS working group to consider the
> WSRF
> "WSDL 1.1 Binding Element Embodiment". An item was posted to the DAIS
> mailing list entitled "DAIS mapping and WSRF embodiments" on 23
> November
> 2004. There has been discussion among the DAIS community on the use of
> the
> WSRF embodiments. Some of the DAIS community involved in the
> discussions
> are the implementers of the first open source version of DAIS known as
> OGSA-DAI; they are the first users of DAIS; they are active in
> promoting
> DAIS among data grid communities around the world. These are some
> interim
> conclusions:
>
> 1. Multiple kinds of DAIS Users
> It is still not clear if DAIS should mandate WSRF because some of the
> participants in the DAIS group rely on non-WSRF middleware. DAIS could
> go
> some way towards satisfying WSRF and non-WSRF users by placing the
> resource
> identifier in the DAIS messages (so a single DAIS message format could
> be
> used by both WSRF and non-WSRF DAIS users).
> A note on resource properties:
>
> Resource properties requests cannot include resource identifiers in
> the
> message body. The resource identifier must be placed in the header.
I believe that there is a minor misunderstanding here that has been
cleared up, I think. In the RAP, the resource disambiguator must be in
the header, but this does not preclude it's inclusion in the body as
well. For example, assume that the wsa:Address field in the EPR fully
disambiguates the resource "doit". Then a operation on doit could look
like this:
doit.makeItGo (your_address, other_junk);
The disambiguator appears in both the header (to point to the resource
doit) and as the value of the your_address parameter.
Some might consider this redundancy of information bad design, but is
it certainly legal.
>
> A suggestion for the WSRF group :
>
> It would be helpful to know if specifying a resource identifier in
> the
> DAIS messages as well as in the header is acceptable to the WSRF
> folk.
No problem here, see above.
> 2. Multiple resources in a single request (see below for use cases)
> Currently, each DAIS service request accesses a single resource, and
> the
> resource being accessed determines the underlying resources that
> should be
> accessed too, e.g., the exposed single resource can perform resource
> name
> mappings . In this case, the WS-Resource concept may (or may not) be
> used
> to represent the exposed resources in DAIS. (depending on whether DAIS
> adopts WSRF)
> In some proposed extensions and applications of DAIS, multiple
> resources of
> different types are accessed through a single service request. It is
> required that the multiple resources be visible to the client. The
> WS-Resource concept could be used to represent a collection of
> resources.
> An identifier to represent the collection could be placed in the
> header,
> while the individual resource identifiers in the collection could
> appear in
> the message content.
> A note on resource properties:
>
> Resource properties requests could result in properties for all the
> resources in the collection being examined. (see below for
> alternatives
> for representing the resource properties documents)
>
> A suggestion for the WSRF group :
>
> It would be helpful to know if representing a collection of
> resources as
> a WS-Resource is a recommended use of WSRF.
Yes. This is an ideal use case for the Service Group. It doesn't fit
exactly, but pretty close. Roughly, ...
doit-all = ServiceGroupFactory (list-of-resources);
success = doit-all.sync();
Or in the redundant information approach, one eliminate the factory and
have a static service with a multiple resource argument.
success = Static-doit-all.sync(list-of-resources);
or keep the factory and just duplicate the information
doit-all = ServiceGroupFactory (list-of-resources);
success = doit-all.sync(list-of-resources);
The first option, I think is most elegant and would be the WSRF
recommendation.
> 3. WSRF "WSDL 1.1 Binding Element Embodiment"
> If DAIS does adopt WSRF then the "WSDL 1.1 Binding Element Embodiment"
> is
> helpful because it permits a client supplied resource identifier to
> appear in the message header (in other words the resource identifier
> is
> not opaque to the client). However note that there are client side
> prerequisites for the "WSDL 1.1 Binding Element Embodiment", e.g., the
> client software would have to know to place the resource identifiers
> in the
> right place in the header
> A suggestion for the WSRF group :
>
> It would be helpful to know if there are any tools that support
> embodiment "WSDL 1.1 Binding Element Embodiment"
The only tools I know about are those that any WSDL tooling supports.
For example, if the WSDL service element states that an X509 cert must
be provided, then the tooling should automatically force the client to
provide it. I don't know what tooling actually provides this support.
The important point is that nothing in the use of this embodiment is
special wrt its usage in the WS-Resource access pattern. If your
tooling for WSs supports this capability it will work. WSRF makes no
additional requirements on tooling.
> .................................................................
>
> Use Cases
> .........
> Here are some use cases for multiple resources in a single request:
>
> U1. In an interaction with a DAIS service, many resources may be
> created to
> represent the results of requests. There may come a time when several
> of
> these resources can safely be removed. In such a setting, the options
> are
> to:
> U1.1. Invoke something like "remove() => EPR representing resource"
> for
> each of the resources.
> U1.2 Invoke something like "remove([EPR representing resource-1,
> ...,EPR
> representing resource-n]) => EPR representing service" once.
>
> How would option U1.2 be modeled through WSRF?
As usual, there are some design choices.
Option 1: Simple WS.
Basically this is exactly like your description above. You know of a
service (not necessarily a WS-Resource) that somehow has told you that
it "knows" about all the resources you want to remove. Then just as you
describe above:
remove([EPR-1, EPR-2, ... EPR-n])
Option 2: Model with a Service Group.
Extend Service Group with the ability to invoke operations on each on
its members, in this case, remove().
So assuming that the service group 'sg' exists and is populated, we
have solved the problem in option 1 of how you know about which
resources the service knows about - the RPs of the service group tell
you. Then invoke remove on the service group and the service group will
perform remove on all the resources in it. You can of course build more
complex functions, such as a query on some property of all the members
to decide which ones to remove.
> U2. In an interaction with a DAIS service, it may be necessary to
> aggregate
> multiple results sets and return the combined result set via ftp. In
> such
> a setting, the options are to:
> U2.1 Invoke something like "ftp (..) => EPR for resource1" for
> each of
> the resources and then aggregate the results on the client
> U2.2 Invoke something like :
> - "aggregate ([EPR representing resource-1, ...,EPR
> representing
> resource-n]) => EPR representing service"
> - "ftp (..) => EPR representing aggregated resource"
> (the result aggregation would be done at the server.)
>
>
> How would option U2.2 be modeled through WSRF?
> (BTW it is possible that a combined aggregate and ftp operation
> would be
> desirable)
Basically the same two approaches as above apply. The service group has
the advantage that you could also add members to the service group over
time and then perform the aggregate_&_ftp operation.
> U3. In an interaction with a DAIS service, it may be necessary to
> issue a
> query over multiple databases and files. In such a setting, the
> options
> are to:
> U3.1 Invoke something like "query (..) => EPR for resource1" for
> each
> of the resources, returning each query result to the client, and
> then
> aggregate the results on the client
> (the result aggregation process could be very complex.)
> U3.2 Invoke something like "copy (..) => EPR for resource1" for
> each of
> the resources and then issue the queries locally on the client
> (this means having a query engine on the client.)
> U3.3 Invoke something like "query([EPR representing resource-1,
> ...,EPR
> representing resource-n]) => EPR representing service" once
> (the query result aggregation would be done at the server.)
>
> How would option U3.3 be modeled through WSRF?
As before both options are possible.
> Alternatives for modeling resource properties documents for U1.2,
> U2.2,
> U3.3
> .......................................................................
> ......
> <ResourceNames>
> <ResourceName>resource1</>
> <ResourceName>resourceX</>
> </>
>
> Or as complex as
>
> <Resources>
> <Resource>
> <ResourceName>resource1</>
> <ResourceType>RDB</>
> <ResourceSchema>....</>
> </>
> <Resource>
> ...
> </>
> </>
>
> A suggestion for the WSRF group :
> It would be helpful to know which modeling approach is preferred
When using the service group approach, the service group provides the
data structure for you. It is basically:
<!-- ========== Resource Properties for ServiceGroupEntry ========= -->
<xsd:element name="ServiceGroupEntryRP">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="wssg:ServiceGroupEPR"
minOccurs="1" maxOccurs="1"/>
<xsd:element ref="wssg:MemberEPR"
minOccurs="1" maxOccurs="1"/>
<xsd:element ref="wssg:Content"
minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
There is one such ServiceGroupEntryRP for each member of the SG. Each
entry points to both the SG to which the member belongs and to the
member. It also contains some interesting information about the member.
this may be (but it is not mandated) a sub set of the RP's on the
member resource. Note that service group members need not be
WS-Resources. As long as you can point at it with an EPR, it can be a
member of a service group.
BTW: Service Group is the current hot topic in WSRF.
--
Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
Fujitsu Laboratories of Europe
Hayes Park Central
Hayes End Road
Hayes, Middlesex UB4 8FE
+44-208-606-4649 (Office)
+44-208-606-4539 (Fax)
+44-7768-807526 (Mobile)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]