[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]