[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [alf-dev] ALF Vocabularies - Problem with Document Literal for Event declaration
|
More on RPC
Literal
As you can see from
the example SOAP messages
I gave below there is
really not much difference at runtime. The SOAP messages just have an extra
layer.
The only disadvantage is positioning and
communication; possible confusion
caused by telling people to use Document Literal for services and RPC
literal for events. While this seems at first somewhat unsatisfactory
it doesn't seem like it should be that problematic since both forms are WS-I
compliant.
The only other solutions I can think of are:
1. Message hacking by the the Event manager to
force all event messages to be given to service flows with a base element of "EventNotice".
2. Special conventions whereby the tool declares its events
one way (eg: with a message that uses a "MyEventNotice" element) but
sends it as "EventNotice"
Both of these have the problem that the declaration
provided by the tool is misleading and this makes it hard to deal with in a
design tool. 1. has the additional
problem that the event manager would need to be a non standard service and
accept any SOAP message for its EventNotice operation.
A variant of 1 might
address the design tool problem:
1a. Message hacking by
the the Event manager to force event messages sent to generic service flows to
be have a base element of "EventNotice".
but it would still have the non standard web service
issue and it is means the event manager has to engaging in behavior it
really shouldn't (ie transforming message formats) making ALF message
routing very specific to the ALF runtime.
If we wish to remain standard so that standard tools
can consume our definitions without the need to extra processing to fix them up
then these solutions are unacceptable or at least a last
resort.
I still have to
confirm that RPC literal does indeed solve the problem. I will let you
know. If it does it seems to offer the cleanest most standard and most
straight forward way to address it.
Tim
PS:
Attached is some example WSDL that illustrates the declaration differences
between document literal and rpc literal. It is similar to the WSDL I used
to generate the service proxies that resulted in the messages below but I have
re-organized id and annotated to explain the problem.
From: alf-dev-bounces@xxxxxxxxxxx
[mailto:alf-dev-bounces@xxxxxxxxxxx] On Behalf Of Tim
Buss
Sent: Wednesday, January 10, 2007 9:54 AM
To: ALF
Developer Mailing List
Subject: [alf-dev] ALF Vocabularies - Problem
with Document Literal for Event declaration
ALF has previously
recommended using "Document Literal" or more "Document Literal Wrapped"
WSDL for the web services implemented for use with ALF.
While this is still the
recommendation it has some problems for events.
Document Literal that is WS-I compliant
requires the use or an element to link
the WSDL message to its data definition. Event declaration as so
far proposed relies on XSD type derivation by restriction. The problem is
that the same element name cannot
have the a different type in the same namespace. You end up with something like this as the SOAP
message. Notice the element
"MyEventNotice". This should really be "EventNotice". This
means the service flow would have to be written for the specific
event and cannot be generic. So far I have
not found a way to get around that when using a derived type.
<?xml version="1.0" encoding="UTF-8"
?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:q0="http://www.eclipse.org/alf/schema/EventBase/M7"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<q0:MyEventNotice
version="1.0">
<q0:Base
Version="1.0">
<q0:EventId
/>
<q0:Timestamp>2001-10-26T21:32:52</q0:Timestamp>
<q0:EventType>My
Product Event Type
A</q0:EventType>
<q0:ObjectType>MyObjectType1Name</q0:ObjectType>
<q0:ObjectId
/>
<q0:Source>
<q0:Product>My
Product
Name</q0:Product>
<q0:ProductVersion>
My
Product
Version
</q0:ProductVersion>
<q0:ProductInstance
/>
</q0:Source>
<q0:User>
<q0:CommonName
/>
<q0:LoginID
/>
<q0:Credentials
/>
</q0:User>
</q0:Base>
</q0:MyEventNotice>
</soapenv:Body>
</soapenv:Envelope>
It seems
that RPC Literal may work. This is WS-I compliant and
doesn't require much to be changed. To make it work like
somewhat like document literal so there is a single parameter called EventNotice
we need another layer hence the two "EventNotice" elements in the example
below. The first is the RPC operation and the second is the single
parameter it takes. Since the
parameter can be defined within a type rather than an element, the XML always has EventNotice as its
base element even if it is a derived type.
<?xml version="1.0" encoding="UTF-8"
?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:q0="http://www.eclipse.org/alf/schema/EventBase/M7"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<q0:EventNotice>
<parameters>
<q0:EventNotice
version="1.0">
<q0:Base
Version="1.0">
<q0:EventId>123</q0:EventId>
<q0:Timestamp>2001-10-26T21:32:52</q0:Timestamp>
<q0:EventType>
My
Product Event Type
A
</q0:EventType>
<q0:ObjectType>MyObjectType1Name</q0:ObjectType>
<q0:ObjectId
/>
<q0:Source>
<q0:Product>My
Product
Name</q0:Product>
<q0:ProductVersion>
My
Product
Version
</q0:ProductVersion>
<q0:ProductInstance
/>
</q0:Source>
<q0:User>
<q0:CommonName
/>
<q0:LoginID
/>
<q0:Credentials
/>
</q0:User>
</q0:Base>
</q0:EventNotice>
</parameters>
</q0:EventNotice>
</soapenv:Body>
</soapenv:Envelope>
I
think this should allows us to declare events in a way that is
interchangeable with the base defintion. Need to do some more checking to
see if it hangs together. An issue is that it is not the generally
recommended option (eg WTP does not suppport
it as a bottom up target although it will generate frameworks and proxies fromt
eh WSDL) and is not the
option ALF recommends for services.
Tim
**********************************************************************
This email and any files
transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply e-mail and destroy all copies of the original
message.
Attachment:
DerivedEventExample.wsdl
Description: DerivedEventExample.wsdl