RE: Collected Requirements [comments/additions]

Waqar,

I'm continuing with more use cases (for the requirements I've sent earlier) which I haven't been able to complete yesterday.

[Service Metadata]

A WS provider can decorate various elements of the service description with custom attributes. These attributes may be application specific and would be described by the WS provider in an additional documentation. Such custom attributes may be defined in a specific schema. WS provider may include such extra information as owner e-mail, link to SLA, security and session requirements for a particular message, etc.

Here is an example of extended attribute definitions and inclusion.
<descriptions ... >
<extend xmlns:myExt="...">
<myExt:owner id="owner1" email="myadmin@mycorp.com/>
<myExt:sec id="sec1" signatureRequired="yes"/>
<myExt:sess id="sess1" cookie="MYCTX"/>
</extend>
<types>...
<message extend="sec1 sess1" ...
<portType...
<binding ...
<service extend="owner1" ...

A WS client can interrogate the metadata attributes as follows

NodeList ext = service.getExtend();

Similarly for message descriptions.

[References]

A WS provider can define operations that return and/or take as a parameter a reference to another WS interface.

The definition would look as follows
<definitions ... xmlns:ref="http://schemas.xmlssoap.org/wsdl/ref">
<message name="...">
	<part name="param" type="ref:ref">
</message>

A schema for http://schemas.xmlssoap.org/wsdl/ref is as follows
<schema targetNamespace="http://schemas.xmlssoap.org/wsdl/ref"
	xmlns:ref="http://schemas.xmlssoap.org/wsdl/ref">
	<complexType name="ref">
	<all>
		<element name="description" nillable="true" type="xsd:string"/>
		<element name="service" type="xsd:QName"/>
		<element name="port" nillable="true" type="xsd:string"/>
	</all>
	</complexType>
	<element name="ref" type="ref:ref"/>
</schema>

Then a WS client can use references to the interfaces as follows

MyExtSvc esvc = new MyExtSvc(service.myMethodReturnungRef(...))

The underlying WS framework would support instantiation of a service based on reference (like most already instantiate based on an endpoint URL).

I believe systinet does something similar, but unless it's mandated by the WSDL standard it is as good as private app-specific extension.

[Sync/Async Operations]

To negotiate proper communication sequence WS provider has to be able to describe if certain operations can be handled asynchronously, must be handled asynchronously or synchronously and what is the expected execution time. This would allow process orchestration system to properly adjust the flow and not run into unexpected blocking.

Here is an example of operation definitions.
<portType>
	<operation ... handling="sync async" replyTime="10000"/> <!-- up to the client -->
	<operation ... /> <!-- only sync -->
	<operation ... handling="async" replyTime="unknown"/> <!-- long running, human dependant -->
</portType>

WS client would then get to use operations properly. Similar to this.

AsyncContext ctx = service.start_myAsyncOp(...);
MyResult result = service.waitFor_myAsyncOp(ctx);

The underlying WS framework would then initiate proper SOAP messaging sequence with acknowledgement and notification phases. SOAP protocol must support asynchronous messaging.

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



-----Original Message-----
From: Sedukhin, Igor 
Sent: Wednesday, February 20, 2002 5:46 PM
To: Sadiq, Waqar; Jonathan Marsh; www-ws-desc@w3.org
Subject: RE: Collected Requirements [comments/additions]


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 Thursday, 21 February 2002 10:12:42 UTC