Skip to main content

[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


Back to the top