W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2002

RE: Collected Requirements [comments/additions]

From: Sedukhin, Igor <Igor.Sedukhin@ca.com>
Date: Wed, 20 Feb 2002 17:46:11 -0500
Message-ID: <849C1D32E4C7924F854D8A0356C72A9E01C8AA10@usilms08.ca.com>
To: "Sadiq, Waqar" <waqar.sadiq@eds.com>, Jonathan Marsh <jmarsh@microsoft.com>, www-ws-desc@w3.org
Waqar,

In reply to your question, and as a possible addition to the use cases...

[Namespaces with data and interfaces]

A service can have an OO model like this
my.app.model.Address is a base class to represent 
data my.app.impl.Address inherits my.app.model.Address 
my.app.model.AddressBook is an interface my.app.impl.AddressBook is an implementation of my.app.model.AddressBook

It is possible to represent this model in WSDL and associated XML Schema by placing schema and interfaces in the proper XML namespaces. It has to be required that namespaces are not getting lost between service provider and the client. It should be part of WSDL compliance.

Here is a brief example:
<definitions
	xmlns:model="urn:my.app.model"
	xmlns:impl="urn:my.app.impl">
<types>
<schema targetNamespace="urn:my.app.model">...
<schema targetNamespace="urn:my.app.impl">...
</types>
<message targetNamespace="urn:my.app.model" ...
<message targetNamespace="urn:my.app.impl" ...
<portType targetNamespace="urn:my.app.model" ...
<portType targetNamespace="urn:my.app.impl" ...

[Events]

A WS provider can describe events generated by a service as follows

<message name="hasDataIn">
	<part name="container" type="data:Container"/>
</message>
<message name="hasDataOut">
	<part name="context" type="data:Context"/>
</message>
<portType>
	<operation...
	<event name="hasData1" mode="poll" interval="10">
		<input message="inerface:hasDataIn"/>
		<output message="inerface:hasDataOut"/>
	</event>
	<event name="hasData2" mode="push">
		<input message="inerface:hasDataIn"/>
		<output message="inerface:hasDataOut"/>
	</event>
</portType>

And this way WS client may subscribe to events like this

service.subscribe_hasData1(new data.Container(...),new myServiceListener()) service.subscribe_hasData2(new data.Container(...),new myServiceListener())

And implement a proper handler

class myServiceListener
{
	void hasData1(data.Context ctx) { ... }
	void hasData2(data.Context ctx) { ... }
}

The underlying WS framework would take care of the event by either polling (sending a SOAP request) with a specified interval or registering a SOAP listener (endpoint) with the target WS (according to the event definition in WSDL).

We should also describe the SOAP protocol sequence (registrtion/acknowledgement/notification) for the events in accordance with asynchronous SOAP messaging.

[Versioning]

A WS provider can describe versions of interfaces implemented by a service. Such as this

<definitions xmlns:interface-latest="urn:myService-latest"
	xmlns:interface-ver1="urn:myService-ver1" ... >
<binding targetNamespace="urn:myService-latest" version="2.0.0.0"> ...
<binding targetNamespace="urn:myService-ver1" version="1.0.0.0"> ...
<service name="myServiceService">
<port name="myService" binding="interface-latest:myServiceSoapBinding"> ...
<port name="myService" binding="interface-ver1:myServiceSoapBinding"> ...
</service>

WS client can bind to the necessary interface version. This way there is no ambiguity when WS proivider changes service interfaces and client has created a static proxy that uses previous version of interfaces.

WS provider can deprecate and remove interfaces as desired, and the client would know that. Client would send a SOAP request that would not be accepted (as namespaces do not match), as opposed to client trying to send a SOAP request that could be accepted, but improperly executed.

[Service Metadata]
TBD (will send later)

[References]
TBD (will send later)

[Sync/Async Operations]
TBD (will send later)

-- Igor Sedukhin .. (Igor.Sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



-----Original Message-----
From: Sadiq, Waqar [mailto:waqar.sadiq@eds.com] 
Sent: Monday, February 18, 2002 10:26 AM
To: Sedukhin, Igor; Jonathan Marsh; www-ws-desc@w3.org
Subject: RE: Collected Requirements [comments/additions]


Igor,

I think your requirements are quite interesting.  Would it be possible for you to articulate the usage of these capabilities in terms of a real-life usage.

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: Sedukhin, Igor [mailto:Igor.Sedukhin@ca.com] 
Sent: Thursday, February 14, 2002 12:09 PM
To: Jonathan Marsh; www-ws-desc@w3.org
Subject: RE: Collected Requirements [comments/additions]

I have the following comments/additions for the requirements document.

This exists/presumed by WSDL 1.1, but I didn't see it mentioned in the req:

[DR??] Must be able to accommodate namespace clusters with data types
(schemas) and interface definitions (message/port/binding). I.e. service may have several namespaces with types and several other namespaces with message/port definitions. That is pretty important for expressing proper OO model of a service. 
Very few framework implementations pay attention to this (in many cases namespaces are flattened out which results in name conflicts). I guess it is so because namespaces of various type definitions and message/port/binding definitions have never been emphasized as a requirement really.

I support, but would like to add to the following reqs:

[DR038, may be others too] Ability to define events is a must. WSDL should be very specific about events, defining a special type of a message or even a separate definition entity. Currently it is missing in WSDL 1.1.

[DR075/6, may be others too] Versioning is definitely a must. Version tag (a namespace URN, for instance) can be associated with a service, interface and data types. This way a client can bind to a *one* service that implements several versions of its interfaces which in turn may use different versions of data schemas. The procedure of selecting a version has to be defined as part of the standard.

[DR032] Extensible metadefinitions are the must. WSDL must be able to include *typed* metadata attributes for any definition element: message, part, port, operation, binding, service. The attributes may also be hierarchical (i.e. defined in another namespace).

I would like to add these new reqs:

[DR??] WSDL must be able to describe references to other services (remote) or other interfaces (ports, local to this WSDL doc) that can be used as parts in message definitions. Currently (as of WSDL 1.1) message parts refer to data types (described in one or the other schema). The part must also be able to  refer to a remote service (WSDL URL/Service/Port) or a local service/port qualified names. This has to be made clear as part of the standard for WS clients and service providers.

[DR??] WSDL must define operations that can be carried out synchronously (i.e. have a short expected reply cycle) and those messages that require asynchronous notification (i.e. have long expected reply cycle). Ability to differentiate such operations is a requirement of the service definition rather than application architecture. For the async operations, providing a reference to an event definition or status inquiry operation should be required.

-- Igor Sedukhin .. (Igor.Sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



-----Original Message-----
From: Jonathan Marsh [mailto:jmarsh@microsoft.com] 
Sent: Wednesday, February 13, 2002 12:10 PM
To: www-ws-desc@w3.org
Subject: Collected Requirements


Enclosed is a document that collects the requirements posted to this list, for the purposes of assigning numbers to each requirement.
Received on Wednesday, 20 February 2002 18:41:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:18 GMT