[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Opaqueness and Transactions
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 ***********
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]