[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Transmitting XML between different applications

  • To: xml-dev@l...
  • Subject: Transmitting XML between different applications
  • From: Mukul Gandhi <mukul_gandhi@y...>
  • Date: Fri, 18 Feb 2005 03:31:34 -0800 (PST)
  • Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=uHAc27pjvMXcxpG4RIAhFRodFHlb+Kfqryo0gtRA9Me4rf1D2JOm9S4gR5YfEDPA2GLDzycwje796c2nmHjjtdG9M+LGtvAUsx9DV6V+YDcA1zsM9Lp5qAWc5h3HPdvjJipJo9H0lm7twGCkDz6tHD/YU66RJC9IDzT86yu9UVE= ;
  • In-reply-to: <f5bacq22m08.fsf@e...>

transmitting xml
Hello,
I have a requirement to pass XML between 2 different
applications. The 2 applications are running on
different machines, and are Java based. The sender
application will generate XML to be sent, and would
send the XML to the receiving application. 

I want to know the possible approaches for this.

The following two approaches are coming to my mind.
1) Create a DOM object at the sending application, and
send this DOM object to the recieving application. I
have some doubt with this approach.. I think, that
with this approach, if XML parser being used at both
applications is same, it won't be a problem. But lets
say, if "Java XML parser" used by 2 applications is
different (but both conform to DOM specification),
will this approach work(for e.g., the sending
application is using Xerces, while receiving
application is using Oracle implementation)? 

Lets say, if I create a DOM object at the sending
application using Xerces, like this -

Document doc= new DocumentImpl();
Element root = doc.createElement("person");  
Element item = doc.createElement("name");      
etc..
Here Document is an interface (defined in package
org.w3c.dom) , while DocumentImpl is a concrete
class(defined in package org.apache.xerces.dom).

And I send the "doc" object to the recieving
application. If the receiving application is using an 
"Oracle Java XML parser", will it be able to parse the
recieved DOM object?

2) Encode XML as string at the sending application,
and send this XML string to the receiving appliction.

I want to compare the above approaches from
feasibility and performance point of view. I also want
to know other approaches..

As a secondary requirement, I want to make the XML
transmission reliable(i.e. guranteed and 1 time
delivery). I belive, I can use messaging softwares for
this (like WebSphere MQ and others). What are the best
practices for reliable transmission? Should I pass DOM
object, String.. etc.?

Later, it might be possible that 2 participating
applications may run on different technologies (like
J2EE and .NET). What are the possible XML
transmission(i.e. creation, transmission and finally
consuming) techniques in this scenario? 

Regards,
Mukul


		
__________________________________ 
Do you Yahoo!? 
The all-new My Yahoo! - Get yours free! 
http://my.yahoo.com 
 


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.