Re: Enterprise Application Integration

Thanks Anne for the detailed response. I am going to check out the
SOAP::Lite and other SOAP modules in ActiveState Perl distro.
Regards

---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 Anne Thomas Manes
> Sent: Saturday, September 21, 2002 9:54 AM
> To: SOAP@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [SOAP] 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.

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