RE: Semantics of WSDL vs. semantics of service

Jacek,

I know there's a plethora of functions that are provided by Web services,
and we have to consider data format issues, etc. as service providers. What
I stressed is that, the interface designed for requesters can be different
from that for the providers. When service requesters send a request to
service providers through the standardized interface
(doService(String):String), service providers will then differentiate which
data types are specified within the service description document.

For example, in a stock quote service, I send you the following elements in
the XML document,

  <s:element minOccurs="0" maxOccurs="1" name="CompanyName" type="s:string"
/> 
  <s:element minOccurs="0" maxOccurs="1" name="StockTicker" type="s:string"
/> 
  <s:element minOccurs="0" maxOccurs="1" name="StockQuote" type="s:string"
/> 
  <s:element minOccurs="0" maxOccurs="1" name="LastUpdated" type="s:string"
/> 
  <s:element minOccurs="0" maxOccurs="1" name="Change" type="s:string" /> 
  <s:element minOccurs="0" maxOccurs="1" name="OpenPrice" type="s:string" />

  <s:element minOccurs="0" maxOccurs="1" name="DayHighPrice" type="s:string"
/> 
  <s:element minOccurs="0" maxOccurs="1" name="DayLowPrice" type="s:string"
/> 
  <s:element minOccurs="0" maxOccurs="1" name="Volume" type="s:string" /> 
  <s:element minOccurs="0" maxOccurs="1" name="MarketCap" type="s:string" />

  <s:element minOccurs="0" maxOccurs="1" name="YearRange" type="s:string" />

  <s:element minOccurs="0" maxOccurs="1" name="ExDividendDate"
type="s:string" /> 
  <s:element minOccurs="0" maxOccurs="1" name="DividendYield"
type="s:string" /> 
  <s:element minOccurs="0" maxOccurs="1" name="DividendPerShare"
type="s:string" />

although, they are all in string data types, but once you process the
request, you understand which one is a string, which one is an integer or
double data type, which one is a date data type, in your programming. In
this case, you handle all such conversions on your server side. However, for
the service requesters, they just need to send you such a request document
without considering the data type issues.

As I demonstrated before, I can invoke both geocoding and data conversion
services through such a standardized interface. As a service provider, I
know which elements are string data types in the programming, and which ones
are double data types. The requesters do not need to care about such issues.
In that example, I showed that two different kind of functions in different
web services can be implemented by one interface. That's the same analogy in
comparing to the case of consuming electricity via standardized plug and
receptacle. In my dissertation research, I developed different kind of Web
services for geocoding, data conversion, data processing, spatial query and
analysis, integrated mapping, etc. ALL of them just have the same interface
(doService(String):String). 

Please describe any of your use cases, and let's see if such a request can
be sent through (doService(String):String) interface to the service
provider. As I told Carine before, the service description template is
pre-defined by service provider. Supposed you are a service provider and you
pre-define a service description template. If I send you such a request
following your pre-defined templage, can you handle such a request to
differentiate whatever data types embedded in such a document to match those
in your programming language? I wish you could try it first to see if it is
feasible to develop standardized plug and receptacle interfaces for all of
your services and functions.

Best wishes,

Xuan

 

-----Original Message-----
From: Jacek Kopecky
To: Shi, Xuan
Cc: 'Bijan Parsia '; 'Carine Bournez '; 'public-sws-ig@w3.org '; 'Battle,
Steven '
Sent: 3/20/06 11:47 AM
Subject: RE: Semantics of WSDL vs. semantics of service

Xuan, 

the problem is that Web Service interfaces are not so well standardized
as electrical plug interfaces, and that's because there's a plethora of
functions that are provided by Web services, as opposed to the one
function provided by the electricity company.

In particular, I don't expect that the interface of my stock quote
service should match the interface of your address lookup service. Even
if the operation is the same (doService(String):String), we will differ
on the data formats and on what we actually perform. WSDL describes the
data formats and WSDL-S tries to point to a description of what we
actually perform.

I'm afraid you have a simplified or idealistic view on what Web services
(should) look like.

Jacek

On Mon, 2006-03-20 at 09:56 -0500, Shi, Xuan wrote:
> It seems you all just ignore the title of this thread as "Semantics of
WSDL
> vs. semantics of service" and Bijan just could not answer my question
to him
> as why do I need to care about how many bindings he
> has for one operation? Or, why do I need to understand the semantics
of his
> WSDL document?
> 
> Given a simple example, we are all the consumers or service requesters
of
> certain electricity company. Do we need to care about the
infrastructure and
> the framework of the electricity company before we consume such
service? Do
> we need to care about how many bindings the electricity company has,
and,
> how they switch to any other bindings to maintain its operations to
support
> the service it provides? Definitely not!
> 
> As service providers, can we give more consideration for our service
> requesters? We can consume the electricity in the same interoperable
> appraoch because every plug and receptacle are all standardized. In
that
> way, the service requesters do not need to care about your complex
> infrastructure, framework, logics, etc. People access "Web" services
in the
> same situation.
> 
> So, please encapsulte all troubles into your server side development.
> Service requesters only need one standardized receptacle so that they
can
> use any interoperable plug to consume the service with little
question. They
> don't need to know how many bindings you have to maintain your single
> operation. We are service providers, not trouble makers.
> 
> -----Original Message-----
> From: Bijan Parsia
> To: Jacek Kopecky
> Cc: Carine Bournez; public-sws-ig@w3.org; Battle, Steven
> Sent: 3/20/06 8:09 AM
> Subject: Re: Semantics of WSDL vs. semantics of service
> 
> 
> On Mar 20, 2006, at 5:39 AM, Jacek Kopecky wrote:
> 
> > Hi Steve,
> >
> > while the charter does not directly support embedded semantic
> > annotations, I think the issue is still open and up for discussion
by
> > the WG.
> 
> I went back and looked and the Scope section is a bit broken (as 
> evidenced by Steve's quote):
> 
> """The Semantic Annotations for WSDL Working Group is chartered to 
> define one or more properties of WSDL 2.0 components to point to 
> additional semantics to concepts represented by those components, e.g.

> interface, operation, endpoint. Additionally, the Working Group may 
> define annotations to the schema structure to point to external 
> semantics.""""
> 
> "point to additional semantics to concepts" just doesn't parse. 
> Additional semantics *for* concepts represented?
> 
> I confess to hating the term "external semantics". C'mon.
> 
> > I for one see some use cases where embedding the annotations would
be
> > useful, and I can see at least two ways of embedding them: put a
whole
> > semantic description
> 
> I go back to a fight I had in SWSL. What's a *non* semantic
description?
> 
> >  document somewhere in the WSDL document (like we
> > put schemas in the <types> section) and then the annotations will
> point
> > into the document; or put the full annotations themselves on the
spot,
> > instead of referring to them.
> 
> How are the "semantics" to be realized? Via some sort of statement 
> (e.g., axioms in some formalism). So let's say I have a set of concept

> and property names, but no further axiomization. And I want to say of 
> some operation that is has at least one P relation to a C. Now since 
> there *is* no other axiom, this characterized the terms entirely (thus

> far). May I inline that? It seems like I should be able to. 
> Alternatively, I could require that I always coin a name for these 
> intermediate expressions (but why?).
> 
> (Note that originally I interpreted the discussion as requiring *all 
> parts* of the annotation to be outside the WSDL document, a la OWL-S. 
> There are reasonable reasons for doing this (including supporting
third 
> party and alternative annotations seamlessly. Technically, I guess
this 
> is not ruled out by the current charter since the concrete syntax of 
> the component properties could be or be required to be in a separate 
> document.
> 
> > While the second option can be seen as out of scope as defined in
the
> > charter, at least the first option should be available to us. 8-)
> 
> I find the Out of Scope more disturbing:
> 
> """discuss expression of Web services constraints and capabilities, 
> including precondition and effect."""
> 
> Why? And how can this be at all narrowed? I mean, from the scope, " 
> could have different meanings: calculation of tax on a product, 
> calculation of income tax, etc. " Aren't these expressions of 
> capabilities? (I recognize that constraints and capabilties are a term

> of art standing for "policy", but still.)
> 
> Cheers,
> Bijan.
> 
>

Received on Monday, 20 March 2006 17:44:41 UTC