RE: DR032 [was Requirements]

Speaking for Intel and on Pallavi Malu's behalf, we agree.  Once the QoS
attributes are determined (by whom?) we should be able to query for them.
My apologies, in advance, Pallavi is currently out-of-touch and unable to
contribute this comment herself.
Joel Munter
Intel Corporation

-----Original Message-----
From: Sandeep Kumar [mailto:sandkuma@cisco.com]
Sent: Thursday, February 14, 2002 10:41 AM
To: www-ws-desc@w3.org
Subject: RE: DR032 [was Requirements]


I agree with Waqar that queriable attributes such as the ones that are based
QoS
would be very relevant and useful.

Cheers,

Sandeep Kumar
Cisco Systems
sandeep.kumar@cisco.com

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
Behalf Of Sadiq, Waqar
Sent: Thursday, February 14, 2002 6:49 AM
To: Jeffrey Schlimmer; www-ws-desc@w3.org
Subject: RE: DR032 [was Requirements]


Jeffrey,

Actually I was not necessarily thinking in terms of SOAP but a more general
problem of reflecting some properties, which are not really business level
operations, but are relevant to the entire service (various Qos parameters).
They could ofcourse be business level properties.  So version was just an
example but their could be others also.

I can actually imagine two uses cases for these.  First, in my thinking the
description language is also a service schema.  So if later on, the business
registries start supporting queries on service schemas, one could possibly
perform queries on these service level attributes to select the appropriate
service.  This probably would require the publisher to provide values of
these queryable attributes.  Second use case is where a client application
infrastructure queries the service at runtime inorder to obtain various
parameters that it might need to configure itself properly.

Basically, I was looking for a generalized mechanism which is able to show
these service-level attributes/properties and at the same time keeping them
separate from the business operations (the service business contract).

Thanks,


_______________________________________________
Waqar Sadiq

EDS EIT EASI - Enterprise Consultant
MS: H3-4C-22
5400 Legacy Drive
Plano, Texas 75024

phone: +01-972-797-8408 (8-837)
e-mail: waqar.sadiq@eds.com
fax: +01-972-605-4071
_______________________________________________



-----Original Message-----
From: Jeffrey Schlimmer [mailto:jeffsch@windows.microsoft.com]
Sent: Wednesday, February 13, 2002 5:32 PM
To: www-ws-desc@w3.org
Subject: DR032 [was Requirements]

Waqar, interesting... Of course we could expose version through an
element / attribute in the spec's namespace, but that doesn't seem like
the right solution for the other examples you give.

Are you thinking of the general problem of composing an
application-defined SOAP Body with SOAP Headers defined by the
underlying plumbing or service policy? Maybe the former could be defined
with a port type, and the latter composed in separately through another
mechanism.

--Jeff

-----Original Message-----
From: Sadiq, Waqar [mailto:waqar.sadiq@eds.com]
Sent: Monday, February 11, 2002 6:32 AM
To: www-ws-desc@w3.org
Subject: Requirements



Here is another requirement:

[DR032] In a lot of cases, it is important for the server to expose some
service wide properties/attributes.  These properties/attributes have
the service-level scope and could be used to describe either some Qos
parameters or some application specific characteristics.  As an example,
a service may want to expose an attribute which describes the version
number of the service.  Hence, a web service description language should
be able to model service level attributes/properties.

Thanks,

_______________________________________________
Waqar Sadiq

EDS EIT EASI - Enterprise Consultant
MS: H3-4C-22
5400 Legacy Drive
Plano, Texas 75024

phone: +01-972-797-8408 (8-837)
e-mail: waqar.sadiq@eds.com
fax: +01-972-605-4071
_______________________________________________

Received on Friday, 15 February 2002 17:47:33 UTC