[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Opaqueness and Transactions
Don,
An extension of the point I was making is that the RM has to allow for brittle as well as flexible interfaces. The SOA must be neutral as to implementation but must be able to account for it in some manner.
Wes
-----Original Message-----
From: Don Flinn [mailto:flinn@alum.mit.edu]
Sent: April 22, 2005 1:10 PM
To: Duane Nickull
Cc: McGregor, Wesley; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Opaqueness and Transactions
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]