OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [soa-rm] Opaqueness and Transactions


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" 
      <operation name="javaClass">
         <soap:operation soapAction="javaClass"/>
            <!--the following refers to a schema that allows the raw class to be sent-->

The SOAP Payload for the input could look like this:



public class ParseDemo {

    public static void main(String[] args) {
        if (args.length != 1) {
              "Usage: java  <file.xml>");

        try {
            // get the root element object
               Element rootElement = new 

            // 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 
             * There are no exceptions to this ... PERIOD!!!!
            String documentHeader = 
            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 = 

            System.out.println("Found element: " + third);

          } catch (Exception e) {
            System.err.println("Error encountered: " + e.getMessage());


I could alternatively send the java class as a binary attachment like this:

Content-Type: multipart/related; type=text/xml;

Here is the java class you requested.

Content-Type: text/xml; charset="UTF-8"
Content-ID: <start-fred@www.foo.com>

    <tns:JavaClass href="cid:duane@www.foo.com"/>

Content-Type: application/java_class
Content-Transfer-Encoding: 8bit
Content-ID: <part1-duane@www.foo.com>




Don Flinn wrote:

>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.
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]