Re: [soa-rm] Opaqueness and Transactions

[Don Flinn <flinn@alum.mit.edu>]

Hmm - I suppose that during the discovery phase a requester look for a
service that spoke Java or some other language and do as you suggest.
But as you say, I also would not build such a service.  

However, that brings up another point - the use of rpc.  Although rpc
style is permitted in WSDL, I believe that rpc is inappropriate for a
SOA, since it leads to brittle API's which are opposite from what one
wants to accomplish with a SOA.  Mea Culpa, I'm delving too far into the
concrete and I don't suppose this is a matter for a reference model.  I
just had to get that off my chest.

Don

On Fri, 2005-04-22 at 09:22 -0700, Duane Nickull wrote:
> Don:
> 
> I would personally never build such a service, but it *can* be done.  
> The only thing I can think of is some type of service that accepts a 
> java class and returns a C# class (hmm - that could actually work)
> 
> I could easily declare this in a WSDL bit like so:
> 
> ...
> 
>    <binding name="JavaClassBinding" type="tns:JCE_PortType">
>       <soap:binding style="rpc" 
>          transport="http://schemas.xmlsoap.org/soap/http"/>
>       <operation name="javaClass">
>          <soap:operation soapAction="javaClass"/>
>          <input>
>             <!--the following refers to a schema that allows the raw class to be sent-->
>             <soap:body
>                encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
>                namespace="urn:examples:javaClassService"
>                use="encoded"/>
>          </input>
>          <output>
>             <soap:body
>                encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
>                namespace="urn:examples:cSharpReply"
>                use="encoded"/>
>          </output>
>       </operation>
>    </binding>
> ...
> 
> The SOAP Payload for the input could look like this:
> 
> <JavaClass>
> 
> <![CDATA[
> 
> 
> public class ParseDemo {
> 
> 
>     public static void main(String[] args) {
>         if (args.length != 1) {
>             System.out.println(
>               "Usage: java  <file.xml>");
>             System.exit(-1);
>           }
> 
>         try {
>             // get the root element object
>                Element rootElement = new 
> SAXBuilder().build(args[0]).getRootElement();
> 
> 
>             // just checking..
>             System.out.println("The root element is" + rootElement);
> 
> 
>             Element first = rootElement.getChild("FirstElement");
>             System.out.println( "Found first element: "  + first);
> 
> 
>             /* Unless you specifically know the structure of the 
> document (and therefore know
>              * what the document is) you cannot access the "Document 
> Header".
>              * There are no exceptions to this ... PERIOD!!!!
>              */
>             String documentHeader = 
> rootElement.getChild("DocumentHeader").getChildText("ThirdElement");
>             System.out.println("Document Header is: " + documentHeader);
>             System.out.println("It completely unnecessary because in 
> order to access the document header, you already have to know what the 
> document structure and syntax is.");
> 
>             Element third = 
> rootElement.getChild("DocumentHeader").getChild("ThirdElement");
> 
>             System.out.println("Found element: " + third);
> 
> 
> 
>           } catch (Exception e) {
>             System.err.println("Error encountered: " + e.getMessage());
>             System.exit(-1);
>           }
> 
>         System.exit(0);
>     }
> }
> ]]>
> </JavaClass>
> 
> I could alternatively send the java class as a binary attachment like this:
> 
> Content-Type: multipart/related; type=text/xml;
>     boundary="xXxXxXx";
>     start="<start-duane@www.foo.com>"
> 
> Here is the java class you requested.
> 
> --xXxXxXx
> Content-Type: text/xml; charset="UTF-8"
> Content-ID: <start-fred@www.foo.com>
> 
> <SOAP-ENV:Envelope>
>   <SOAP-ENV:Body>
>     <tns:JavaClass href="cid:duane@www.foo.com"/>
>   </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
> 
> --xXxXxXx
> Content-Type: application/java_class
> Content-Transfer-Encoding: 8bit
> Content-ID: <part1-duane@www.foo.com>
> 
> .....
> 
> --xXxXxXx--
> 
> 
> Duane
> 
> 
> Don Flinn wrote:
> 
> >Diane
> >
> >I disagree that a service could allow Java Classes as a parameter.  This
> >implies how the service is implemented.  Even if the service can
> >translate the Java Classes to some other model, it forces the service to
> >understand Java Classes.  
> >
> >Also, WS-BusinessActivity permits partial or "tentative" results to be
> >made available to the Coordination Service. There are times when partial
> >results are needed to synchronize services in a business activity.  IMO,
> >one of the major benefits of an SOA the ability to handle complex,
> >multi-service business activities.
> >
> >I realize that these examples are concrete, but I believe that we must
> >validate our model against the specific concrete situations.
> >
> >Don
> >  
> >
> ***********
> Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
> Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
> Adobe Enterprise Developer Resources  - http://www.adobe.com/enterprise/developer/main.html
> ***********
> 
> 
-- 
Don Flinn
President, Flint Security LLC
Tel: 781-856-7230
Fax: 781-631-7693
e-mail: flinn@alum.mit.edu
http://flintsecurity.com