W3C home > Mailing lists > Public > public-ws-desc-state@w3.org > June 2003

RE: Some requirements

From: VAMBENEPE,WILLIAM (HP-Cupertino,ex1) <vbp@hp.com>
Date: Thu, 12 Jun 2003 17:26:21 -0400
Message-ID: <68157FD469848D45B9CBC2833AD5528002159457@xsun02.ptp.hp.com>
To: "'Steve Graham'" <sggraham@us.ibm.com>, David Snelling <d.snelling@fle.fujitsu.com>
Cc: Jim Webber <jim.webber@arjuna.com>, Paul Watson <Paul.Watson@newcastle.ac.uk>, public-ws-desc-state@w3c.org, Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>, Steve Tuecke <tuecke@mcs.anl.gov>


Thanks for the good comments. I appreciate the information on which of this
requirements are covered by ServiceData and how they are covered. At the
same time, at this point I think the discussion should be "what are the good
requirements for attribute support in WSDL 1.2" not "what are the
requirements that ServiceData supports"...

My comments inlined below, inside <wv></wv>... 

Looking forward to Monday's discussion.

William

> >> <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>

<wv>So at the minimum this means that we should make sure to allow WS-Policy
elements added to attribute description elements. What about going beyond?
Should this task force recommend a way to specify policies (not just
security policies) on attributes? Or should the task force stay away from
this and users of WSDL 1.2 will figure on their own how to do this (OGSI and
OGSA security will pick one way, maybe based on WS-Policy, some other groups
will pick other ways that might or might not be based on WS-Policy, etc...).
Seems to me that the same policy-description requirement applies to WSDL
operations. So it might not make sense to consider it specifically for
attributes. On the other hand, I would very much like to see WSDL 1.2
provide guidance on this instead of leaving it hanging (and done in
non-interoperable ways).</wv>

> >> 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.

<wv>This is what I meant.</wv>

> 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.

<wv>Yes, I like this feature in ServiceData. The requirement I offered is
more basic though</wv>

> >> 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.

<wv>You are right, just like for the discussion on policy that we sparked by
the first requirement this is something for which attributes and operations
are very similar.</wv>

> 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.

<wv>At least we need to make sure we describe attributes in a way that makes
it easy to attach security (or more general policy) statements to them.</wv>

> >> 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?

<wv>I don't have a strong opinion on this.</wv>

> 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>

<wv>What about allowing a WSDL author to attach any metadata element s/he
wants (in addition to those pre-defined) to an attribute and allowing this
metadata to be of a complex type.</wv>

> >> 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>
Received on Thursday, 12 June 2003 17:26:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:54 UTC