Re: Attributes Requirements to Support OGSI Service Data

Folks,

As per my action from June 16th call. Sorry for the premature posting
earlier this week. I hope this mail makes more sense. BTW: I won't be on the
call Monday (flying to GGF).


Attributes Requirements to Support OGSI Service Data
----------------------------------------------------

The perspective of this list of requirements can be described as an answer
to the following question,

   "What facilities must Attributes have in order to support
   (directly or indirectly) the abstract functions of OGSI Service Data?"


Highly Desirable: Whatever the state access mechanisms are, it would be
useful if they can be reused in other contexts, e.g. notification. The OGSI
Service Data model is reused for the notification framework. We can think of
"subscribe to SDE foo" as a push form of "find SDE foo", i.e. a pull model.

Required: We need predefined attributes. We need to be able to declare
certain attributes that can be relied on in any GS portType. There need not
be any defined attributes in the WSDL spec. The "ServiceDataNames" SDE
contains a list of all available SDEs. One could argue that this needed to
be provided as part of the WSL level attribute model. I don't believe this
is necessary. As long as we can declare ServiceDataNames in the WSDL and
allow it to be extendable, we can do what we need to do.

Required: We need to query across multiple attributes in one service. The
OGSI findByServiceDataNames query type to findServiceData gets multiple
values. I don't believe that this MUST be expressed in the WSDL (i.e. as
operations in WSDL). Our GridService portType can define this. The concern
here is one we have been discussing: "is the notion of access to declared
state domain specific or more general." I believe that is is quite general,
but GridServices can manage with an application domain specifi solution,
i.e. in the GS portType.

Required: Ability to restrict access on a per attribute basis. However, as
in the discussions on the call, OGSI puts this outside our scope at this
stage. It may mean that in time, we need to annotate SD with access
information (depending on how security is implemented). The issue of
visibility of this information is also an issue. Some services may not want
the client to know that they cannot access the information or even tat it
exists.

Required: We need the ability to restrict read vs. write access by the
client over the service interface. SD uses the modifiable attribute for
this.

Required: We need the ability to restrict read vs. write access based on the
structure of the value. In particular, we define four models: static - WSDL
defined and unchanging; constant - instance defined and unchanging;
extendable - can be added to only; and mutable - all changes are possible.
Examples on request.

Required: We need the ability to know a (partial) list of attributes at
design time. This is needed for the boot strapping process as well as
defining the architecture - "All Grid Services have these attributes."

Required: We ability to know type (some) of attributes ahead of time.
However, the dynamic nature of the grid envisions cases where a service
might have service data types that a client has never seen before. Tools to
interpret these dynamically are planned, but also service data forwarding
agents migh not need to understand the SD in order to perform their
functions.

Highly desirable: The service data model makes a distinction between a SDE
that is absent from one that is present but has the value nil. We have this
distinction at present, but there was much debate in this area and other
approaches to meeting the requirements might also be possible, e.g. clever
use on minOccurs.

Required: Input/output messages that manipulate attributes need to be
validated against WSDL. This is required, but can be defined in the OGSI
portTypes.

Highly desirable: If it turns out that W3C defines a standard mechanism the
access attributes, we would like to use these directly. In this case, we
would want flexible read and write access. For example, implicit get/set
operations based on attribute name would not be sufficient. We need multiple
attribute access and cross attribute query processing. We assume at the
present that the query format is domain specific.

Required: Some attributes may occur multiple times. E.g. the serviceDataName
SDE is a single service data name attribute that can occur multiple times
rather than a single multi-valued attribute.

Required: There is a need for handling opaque or abstract types. the
ExtensibilityType is a place to put data value that carry their type with
them (xsi:type or the like - but I don't fully understand this). By the way,
this is an area that has caused me some headaches on the implementation
side.

Required: Attributes can be inherited through WSDL 1.2 inheritance. Types
and values appearing in a parent portType will appear in the child. At
present static values are accumulated though the hierarchy. There are some
other issues that we resolved in this area in what might be called arbitrary
ways, such as conflicts between inheriting values and complying with
max/minOccurs. I believe we could adapt to changes in this space as long as
they are addressed clearly.

Required: Support metadata on attributes (creation date, type,
description...). OGSI has quite a rich framework that might be considered
application domain specific. That these attributes are listed as required by
all attributes or if the attributes are extensible really does not matter.
[There is a bit here that confuses me - attributes on attributes? Is this
really possible?]

Required: Attributes need to be of any schema type (simple or complex). Some
of our structures are quite complex.

There are two meta comments I would like to make:

1) A summary requirement is: we need to ensure that our GridService portType
can be built on top of the new WS state model. This minimal set of
requirements is probably quite small. We have the GridService portType on
which to put most of our mechanisms.

2) We believe that the content and facilities represented by the full
GridSrvice portType (and the rest of OGSI) are quite valuable and we would
like to see them receive wider exposure. The extent to which this task force
can promote these ideas within W3C may be somewhat limited. We realise this
and will not push you to overextend your remit.


-- 

Take care:

    Dr. David Snelling <d.snelling@fle.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)