File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

XML-RPC

 
Bhushan Arora
Greenhorn
Posts: 15
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How can J2EE application interact with an application which takes XML-RPC style request but its response is in a different format(still XML) than XML-RPC style response - Is there a strategy other than creating URLConnection and XML parsing programatically
[ February 15, 2003: Message edited by: Bhushan Arora ]
 
Byron Estes
Ranch Hand
Posts: 313
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bhushan Arora,
I'm not sure I understand the question. The whole idea of the RPC based webservice is to conform to the request/response format because through conformance we get ease or implementation and increased interoperability.
If you want to provide the response in some other format, you're realling looking at message/document oriented webservices where the payload of the soap envelope can be anything you want.
That being said, I believe that even with RPC you could provide an attachment to the soap message that could contain an xml document. However, the recipient would still need to know it's there, retrieve it and then progamatically access/manipulate it which requires them to have some knowledge about what they are receiving so they know how to use it.
Regards,
 
kundi kx
Greenhorn
Posts: 10
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think your question is close to mine. So if anyone could answer yours, I would get a lot of tips also.
Basically I am looking for set rules, guidelines, or existing lib for writing XML/SOAP parser, which might deal with non-standard SOAP with attachments also.
Sorry that it's not a reply
 
Bhushan Arora
Greenhorn
Posts: 15
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Byron
Definitely you are correct in accessing that it's not a practical case scenario.The question makes it mandatory that one side uses XML-RPC style request format not even SOAP style rpc request format and response is a xml file(not xml-rpc standard reponse format),we can't touch this side and other side has the responsibility to talk to it. So i was thinking of URLconnections and sending xml files as i/p stream and retriving as o/p stream and then parsing it as both formats are known to both the sides.
Even one other intersting situations -
How could a J2EE application interact with a web application in PERL if it is not permitted to modify/enhance Perl web application. Is it a good solution to hit the database of perl application directly if available locally.
Your thoughts would be highly appreciated and i am certain that you are gonna clear your exam with flying colors.BTW 100% is really too good!
Thanks
Bhushan
 
Byron Estes
Ranch Hand
Posts: 313
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bhushan,
Thanks for your kind remarks.
On the perl/db issue...
I think it could be valid to bypass the perl program is some situations, but you need to look at the purpose of the perl application. If it's intent is to act as an accessor/guardian of the data to ensure that the data is either extracted or manipulated according to a set of business rules designed to protect the data (...above and beyond the normal data type, referential integrity and trigger constraints imposed by the dbms), then I'd try to find a way to use the accessor. If it's simple the only application that currently is attached to the database and you're trying to re-use it, I'd just "hit it" with JDBC.
Regards,
 
Bhushan Arora
Greenhorn
Posts: 15
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Byron
Would using the accessor means making pertinent http calls from our middle tier(ie remote method in stateless ejb could act as interface to perl program) ,getting the html response from perl program as a stream,,clubbing it together with our display logic and simply putting it out as response to client hit.
Cheers
Bhushan
 
Byron Estes
Ranch Hand
Posts: 313
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is certainly a posibility, but it could be a fairly inefficient and brittle solution. Inefficient, because of all the string parsing and brittle because if the output changes it will probably break the parsing routine. Again, it all depends upon the role the perl program already plays and it's importance. I still might look at replacing the perl program as an RPC webservice.
 
Bhushan Arora
Greenhorn
Posts: 15
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Byron
Again the problem is that can't touch/modify Perl application.So what would be probably your take considering a lot of bussiness logic in perl application.
further considering all scenarios for the case 1(XML-RPC) too,again what would be your advice for the same.
Thanks
Bhushan
 
Byron Estes
Ranch Hand
Posts: 313
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The URL connection is really the only choice you have. You might want to look at one of the XML binding mechanisms (i.e. JAXB, Castor etc.) to make the parsing more generic. This could at least make any maintenance to it a little less troublesome.
 
Bhushan Arora
Greenhorn
Posts: 15
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Byron
Really appreciate your suggestions.
Thanks
Bhushan
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic