Re: Enterprise Application Integration

Ranga,

One of the primary advantages of using SOAP is that the SOAP runtime
performs the non-XML to XML conversions for you. Since you have your own XML
data transformation technology, you'd only be using SOAP (or XML-RPC for
that matter) as an envelope. This approach requires your application to work
with the SOAP runtime using a low-level API. You use the API to construct
the SOAP envelope and then add your XML data to the SOAP body, then use the
API to make the connection and send the data. On the server side, the SOAP
runtime can dispatch the appropriate method for you, but again you would
need to work with a low-level API, because your asking the SOAP server not
to do the language translations for you.

If you intend to send the message over HTTP, then you might find it easier
simply to send your XML message (the XML that Any2XML outputs) directly over
HTTP. In this situation, the only real advantage that SOAP or XML-RPC
provides is that it provides a mechanism that indicates what you want the
service to do with the data you're sending (i.e., you can specify a method
name).

Are you looking for an RPC mechanism or just a transport mechanism?

XML-RPC only supports the RPC-style of communication. The structure of an
XML-RPC message has this form:
  <methodCall>
    <methodName>method.name</methodName>
    <params>
      <param>
         <value><struct>output from Any2XML goes here</struct></value>
      </param>
    </params>
  </methodCall>

SOAP supports both RPC-style and document-style messages. The structure of a
SOAP-RPC message has this form:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/";>
    <env:Header/>
    <env:Body env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
        <m:&methodName xmlns:m="wsdlURL">
            <m:&input>output from Any2XML goes here</m:&input>
        </m:&methodName>
    </env:Body>
</env:Envelope>

A document-style SOAP message would look like this:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/";>
    <env:Header/>
    <env:Body
        <m:&input xmlns:m="wsdlURL">
            output from Any2XML goes here
        </m:&input>
    </env:Body>
</env:Envelope>

Notice that the document-style SOAP message doesn't indicate a method name.
If you want to provide information on what to do with this message, you can
specify it in the SOAPAction HTTP header. You can also specify anything you
like in the SOAP Header element, such as transaction ids, message sequence
numbers, session ids, etc.

Another valuable feature that SOAP offers is that the message can be
transported using many different protocols (although the specific protocols
supported depends on the SOAP implementation used). Taking a quick glance at
www.soaplite.com, I see that SOAP::Lite supports HTTP, HTTPS, SMTP, POP3,
Jabber, and MQSeries. So if your client wants reliable delivery or
asynchronous communication for certain messages, you can send those messages
over MQSeries. The others can be sent over HTTP. (SOAP supports both
synchronous and asynchronous communications.)

Hope this helps with your decision-making process.

Best regards,
Anne

> Date:    Fri, 20 Sep 2002 11:35:55 -0400
> From:    Ranga Nathan <ranga.nathan@xxxxxxxxxxx>
> Subject: Re: Enterprise Application Integration
>
> Thanks for that response Sean!
> The integration involves conversion of non-XML data to XML (using
> Any2XML) and marshall into some uniform layout (thinking SOAP objects
> here) and decode, convert from XML to whatever at the other end, in
> order to connect the end points. I am assuming SOAP is synchronous like
> XML::RPC, otherwise we could use a database (PostgreSQL) or if the
> customer wants to spend $$$ then MQ Series / Tibco etc.
>
> Thanks again for the input.
>
> ---Closing information gaps-----
> Ranga Nathan, Reliance Technololgy
> >>Live demo at http://any2xml.com/docs/timesheet_demo.shtml<<
> >>Get free COBOLExplorer at http://goreliance.com/download-products <<
>
> > -----Original Message-----
> > From: Discussion of implementing SOAP applications today
> > [mailto:SOAP@xxxxxxxxxxxxxxxxxxx] On Behalf Of Sean Meisner
> > Sent: Thursday, September 19, 2002 1:09 PM
> > To: SOAP@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [SOAP] Enterprise Application Integration
> >
> >
> > Hi,
> >
> > By reading this I am not sure if what you want to do is a
> > customized integration for a customer, or to provide a
> > generic integration interface to go along with your toolkit.
> >
> > If you are going to provide a generic integration interface
> > with your software, I would say use SOAP::Lite, for the very
> > reasons you suggested.  Wider application and standards
> > compliance.  From what I have seen and done, I don't think
> > SOAP::Lite is substantially harder to use than XML::RPC.
> >
> > However if you are doing a custom project then I would
> > suggest you need to base your decision on what technologies
> > the applications you wish to integrate already use.  Do they
> > have SOAP or XML::RPC interfaces?  If not, and if all you
> > need to do is exchange XML documents, I would seriously be
> > inclined to simply use email or standard CGI on a web server
> > to pass the documents around.  Or a message system like
> > MQSeries or Tibco.  This would probably be somewhat faster to
> > implement.  If all you want to do is pass some XML data
> > around, SOAP could be overkill.
> >
> > Again, it all depends on the nature of your project.
> >
> > Cheers,
> >
> > Sean
> >
> >
> > > -----Original Message-----
> > > From: Ranga Nathan [mailto:ranga.nathan@xxxxxxxxxxx]
> > > Sent: Tuesday, September 17, 2002 2:11 PM
> > > To: SOAP@xxxxxxxxxxxxxxxxxxx
> > > Subject: [SOAP] Enterprise Application Integration
> > >
> > >
> > > I am proposing an integration project using our software
> > Any2XML (free
> > > download at http://goreliance.com/devel) which is also
> > available as an
> > > ActiveX dll. While this will work as an agent between disparate
> > > applications, I still need a transport mechanism to deliver the
> > > messages. As we do almost all our work in Perl, I am not sure if I
> > > should stick with XML::RPC or SOAP::Lite. It appears that
> > XML::RPC is
> > > certainly quicker to implement and less complex but SOAP holds a
> > > bigger promise of wider application and standards
> > compliance. But SOAP
> > > is not 'Lite' anymore with the way the big companies are
> > pushing it.We
> > > are working with tight budgets and need to complete
> > projects quickly
> > > in order to see some money.
> > >
> > > I am trying to learn from others' experience before I committ to
> > > anything. Thanks for your input
> > >
> > > ---Closing information gaps-----
> > > Ranga Nathan, Reliance Technololgy
> > > >>Live demo at http://any2xml.com/docs/timesheet_demo.shtml<<
> > > >>Get free COBOLExplorer at
> > http://goreliance.com/download-products <<
> > >
> > > You can read
> > messages from the SOAP archive, unsubscribe from SOAP, or
> > > subscribe to other DevelopMentor lists at
> > http://discuss.develop.com.
> > >
> >
> > You can read messages from the
> > SOAP archive, unsubscribe from SOAP, or subscribe to other
> > DevelopMentor lists at http://discuss.develop.com.
> >
>
> You can read messages from the SOAP archive, unsubscribe from
> SOAP, or subscribe to other
> DevelopMentor lists at http://discuss.develop.com.
>
> ------------------------------
>
> Date:    Fri, 20 Sep 2002 10:13:08 -0700
> From:    Soumen Sarkar <SoumenS@xxxxxxxxx>
> Subject: Re: Enterprise Application Integration
>
> I do not understand, why you would go for SOAP RPC. No need!
> Do the following:
>
> 1. Convert any data to XML using Any2XML
> 2. Transfer the XML document as an attachment. Why take pain converting
>    the XML document to SOAP RPC format!
> 3. Receive the XML attahment doc.
> 4. Convert to any from XML using An2XML.
>
> Why are you thinking of "SOAP Objects"? Why extra encoding and decoding --
> just
> transfer the XML doc as it is.
>
> On a philosophical note:
>
> Every software architecture decision point needs to backed by use case. So
> if you
> are thinking of "SOAP Objects" as an software architectural
> decision point,
> where is your use case?
>
> Substantiate your need to use SOAP by use case.
>
> Soumen Sarkar.
>
> -----Original Message-----
> From: Ranga Nathan [mailto:ranga.nathan@xxxxxxxxxxx]
> Sent: Friday, September 20, 2002 8:36 AM
> To: SOAP@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [SOAP] Enterprise Application Integration
>
>
> Thanks for that response Sean!
> The integration involves conversion of non-XML data to XML (using
> Any2XML) and marshall into some uniform layout (thinking SOAP objects
> here) and decode, convert from XML to whatever at the other end, in
> order to connect the end points. I am assuming SOAP is synchronous like
> XML::RPC, otherwise we could use a database (PostgreSQL) or if the
> customer wants to spend $$$ then MQ Series / Tibco etc.
>
> Thanks again for the input.
>
> ---Closing information gaps-----
> Ranga Nathan, Reliance Technololgy
> >>Live demo at http://any2xml.com/docs/timesheet_demo.shtml<<
> >>Get free COBOLExplorer at http://goreliance.com/download-products <<
>
> > -----Original Message-----
> > From: Discussion of implementing SOAP applications today
> > [mailto:SOAP@xxxxxxxxxxxxxxxxxxx] On Behalf Of Sean Meisner
> > Sent: Thursday, September 19, 2002 1:09 PM
> > To: SOAP@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [SOAP] Enterprise Application Integration
> >
> >
> > Hi,
> >
> > By reading this I am not sure if what you want to do is a
> > customized integration for a customer, or to provide a
> > generic integration interface to go along with your toolkit.
> >
> > If you are going to provide a generic integration interface
> > with your software, I would say use SOAP::Lite, for the very
> > reasons you suggested.  Wider application and standards
> > compliance.  From what I have seen and done, I don't think
> > SOAP::Lite is substantially harder to use than XML::RPC.
> >
> > However if you are doing a custom project then I would
> > suggest you need to base your decision on what technologies
> > the applications you wish to integrate already use.  Do they
> > have SOAP or XML::RPC interfaces?  If not, and if all you
> > need to do is exchange XML documents, I would seriously be
> > inclined to simply use email or standard CGI on a web server
> > to pass the documents around.  Or a message system like
> > MQSeries or Tibco.  This would probably be somewhat faster to
> > implement.  If all you want to do is pass some XML data
> > around, SOAP could be overkill.
> >
> > Again, it all depends on the nature of your project.
> >
> > Cheers,
> >
> > Sean
> >
> >
> > > -----Original Message-----
> > > From: Ranga Nathan [mailto:ranga.nathan@xxxxxxxxxxx]
> > > Sent: Tuesday, September 17, 2002 2:11 PM
> > > To: SOAP@xxxxxxxxxxxxxxxxxxx
> > > Subject: [SOAP] Enterprise Application Integration
> > >
> > >
> > > I am proposing an integration project using our software
> > Any2XML (free
> > > download at http://goreliance.com/devel) which is also
> > available as an
> > > ActiveX dll. While this will work as an agent between disparate
> > > applications, I still need a transport mechanism to deliver the
> > > messages. As we do almost all our work in Perl, I am not sure if I
> > > should stick with XML::RPC or SOAP::Lite. It appears that
> > XML::RPC is
> > > certainly quicker to implement and less complex but SOAP holds a
> > > bigger promise of wider application and standards
> > compliance. But SOAP
> > > is not 'Lite' anymore with the way the big companies are
> > pushing it.We
> > > are working with tight budgets and need to complete
> > projects quickly
> > > in order to see some money.
> > >
> > > I am trying to learn from others' experience before I committ to
> > > anything. Thanks for your input
> > >
> > > ---Closing information gaps-----
> > > Ranga Nathan, Reliance Technololgy
> > > >>Live demo at http://any2xml.com/docs/timesheet_demo.shtml<<
> > > >>Get free COBOLExplorer at
> > http://goreliance.com/download-products <<
> > >
> > > You can read
> > messages from the SOAP archive, unsubscribe from SOAP, or
> > > subscribe to other DevelopMentor lists at
> > http://discuss.develop.com.
> > >
> >
> > You can read messages from the
> > SOAP archive, unsubscribe from SOAP, or subscribe to other
> > DevelopMentor lists at http://discuss.develop.com.
> >
>
> You can read messages from the SOAP archive, unsubscribe from SOAP, or
> subscribe to other
> DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the SOAP archive, unsubscribe from
> SOAP, or subscribe to other
> DevelopMentor lists at http://discuss.develop.com.
>
> ------------------------------
>
> End of SOAP Digest - 19 Sep 2002 to 20 Sep 2002 (#2002-193)
> ***********************************************************
>

You can read messages from the SOAP archive, unsubscribe from SOAP, or 
subscribe to other
DevelopMentor lists at http://discuss.develop.com.