Re: Some requirements

Hi all:
Some comments on David's comments
<sgg></sgg>

++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
++++++++



                                                                                                                                              
                      David Snelling                                                                                                          
                      <d.snelling@fle.fujitsu.        To:       Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>,                      
                      com>                             <public-ws-desc-state@w3c.org>                                                         
                      Sent by:                        cc:       Jim Webber <jim.webber@arjuna.com>, Paul Watson                               
                      public-ws-desc-state-req         <Paul.Watson@newcastle.ac.uk>, Steve Tuecke <tuecke@mcs.anl.gov>                       
                      uest@w3.org                     Subject:  Re: Some requirements                                                         
                                                                                                                                              
                                                                                                                                              
                      06/12/2003 10:01 AM                                                                                                     
                                                                                                                                              
                                                                                                                                              




Folks,

I'll try to answer these questions from the OGSI ServiceData perspective.
Steve Graham can either back me up or argue. I have tried to only state
facts, and not say anything about how I might argue the point.


On 12/6/03 8:22, "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
wrote:

>
> All,
>
> Few comments/questions...
>>
>> <requirements>
>>
>> User should be able to know what their permissions are on attributes
>> before
>> trying
>>
>
> Isn't permission (part of a security/policy infrastructure) orthogonal
> to specifying an interface?

For ServiceData (SD), access authorization is completely outside the OGSI
scope. Although I can see that it would be nice to know if you could access
a particular bit of SD.
<sgg>I agree that security is not sufficiently described in OGSI
ServiceData and that we do need a solution
for this. We in OGSI WG should work with the OGSA Security WG to determine
how to do this.  I suspect
that we could use some form of WS-Policy decoration on the serviceData
declarations to suggest WS-Policy
related to Access to serviceData/attributes.</sgg>

>
>> Query across attributes (in one service): what query language?

This is expected in SD, probably with Xpath/Xquery, provide queries across
all SD. According to the current spec, a service can advertise what query
processing it supports, but only "by name" access is specified.
<sgg>+1</sgg>

>> Ability to know (partial?) list of attributes at design time

Yes. The service publishes a list of some of the SD elements (SDEs)
available to the client. The service may also add more SDEs dynamically.
Clearly, these would only be useful to clients that recognized the type and
understood the semantics.
<sgg>If the user understands the set of porttype(s) implemented by the
service, then introspecting
on the portType(s) will tell the user which serviceData are supported by
the service.  Of course, with
dynamic service data, there may be additional serviceData than just those
declared in the portType.</sgg>

>> Ability to know type of attributes ahead of time
>>
> Since attributes are going to be part of an interface, wouldn't be a
> requirement that ALL are known at design time? If attributes can be
> added/removed at runtime, the interface changes. Type-safety becomes a
> runtime issue. Personally, I like implementation-time type safety.

All declared SDEs are typed in the WSDL. Only the dynamically added ones
could show up without the client being able to know the type before hand.

Enforcing this on the Service Data model would be a restriction of the
current specification.
<sgg>given that SDEs (even dynamic ones) are identified by QName, the user
would need to find the
GWSDL that declares that namespace and introspect to find the type of the
declared SDE.
Of course, finding where the source WSDL file is, can be tricky, it is one
of the odd things about XML.
XSI:schemaLocation doesn't seem to be very useful.</sgg>


>> Input/output messages that manipulate attributes can be validated
>> against WSDL

These are defined in the GridService portType that all Grid services
extend.
This has made it easy for OGSI. We were going to have a default set of
operations anyway, so there was nothing to overcome in this area. See Stece
G's slides for a summary of the operations we used.

>> Support for static attributes
>>
>
> What does static mean? Does it mean that you can specify the value of an
> attribute within the WSDL that will always be the same? If so, then
> ignore this.

OGSI SD supports the above as mutibility = 'static' SD also has the concept
of mutibility = 'constant' where the value is set once and for all at
service instantiation time.

>> Ability to restrict access on a per attribute basis.
>>
>
> Again, I think this is part of a security/policy infrastructure. It's
> similar to permitting/restricting access to a web service operation.

Yes. As far as OGSI is concerned, this is outside the scope of the spec. A
implementation could provide this facility, but we didn't define any
mechanism for exposing this information to the client.


>> Ability to restrict read vs. write access

This we did do: modifiable = 'true' | 'false'

>> Attributes can be inherited through WSDL 1.2 inheritance

Yes, this is true of OGSI of both declared types and values where they are
provided.

>> Support metadata on attributes (creation date, type, description...)
>>
>
> Should "type" be part of the metadata or a first-class characteristic of
> the attribute?

The SD attribute/element set is (extracted from whole schema is):

<element ref="annotation" minOccurs="0"/>
<attribute name="name" type="NCName"/>
<attribute name="type" type="QName"/>
<attributeGroup ref="occurs"/>
<attribute name="nillable" type="boolean" use="optional" default="false"/>

<attribute name="mutability" default="extendable">
              <enumeration value="static"/>
              <enumeration value="constant"/>
              <enumeration value="extendable"/>
              <enumeration value="mutable"/>

<attribute name="modifiable" type="boolean" default="false"/>

<anyAttribute namespace="##other" processContents="lax"/>

<complexType name="ServiceDataValuesType">
    <sequence>
      <any namespace="##any" minOccurs="0" maxOccurs="unbounded" />
    </sequence>
</complexType>

There are also lifetime attributes associated with service data

    <attributeGroup name="LifeTimePropertiesGroup">
      <attribute ref="ogsi:goodFrom" use="optional"/>
      <attribute ref="ogsi:goodUntil" use="optional"/>
      <attribute ref="ogsi:availableUntil" use="optional"/>
    </attributeGroup>


>
>> Allow bulk retrieval of several attributes in one operation

Yes. The find by SD names is a plural construct. Also, when an extesnion
for
Xpath/Xquery is added, this would also support multiple/bulk replies.

>>
>> Attributes can be of any schema type (simple or complex)

Yes, the type of SD is unrestricted.

>>
>> </requirements>
>>

I hope this helps.


--

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)





#### InterScan_Disclaimer.txt has been removed from this note on June 12,
2003 by Steve Graham

Received on Thursday, 12 June 2003 16:49:33 UTC