aspose file tools*
The moose likes Web Services and the fly likes XML-RPC Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "XML-RPC" Watch "XML-RPC" New topic
Author

XML-RPC

Bhushan Arora
Greenhorn

Joined: Feb 13, 2003
Posts: 15
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

Joined: Feb 21, 2002
Posts: 313
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,


Byron Estes<br />Sun Certified Enterprise Architect<br />Senior Consulant<br />Blackwell Consulting Services<br />Chicago, IL<br /><a href="http://www.bcsinc.com" target="_blank" rel="nofollow">www.bcsinc.com</a>
kundi kx
Greenhorn

Joined: Feb 03, 2003
Posts: 10
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

Joined: Feb 13, 2003
Posts: 15
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

Joined: Feb 21, 2002
Posts: 313
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

Joined: Feb 13, 2003
Posts: 15
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

Joined: Feb 21, 2002
Posts: 313
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

Joined: Feb 13, 2003
Posts: 15
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

Joined: Feb 21, 2002
Posts: 313
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

Joined: Feb 13, 2003
Posts: 15
Hi Byron
Really appreciate your suggestions.
Thanks
Bhushan
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: XML-RPC