thanks Chris.
i am looking around the ways how to do it. JAXB is one solution for me. however JAXB doesn't give me dynamism. Maybe i have another XML document i have to handle. In this case, i have to first convert XML documents to get xsd and compile it to get Java classes and make updates to my program again. I dont want all these steps every time when there is new XML document arise. Do i want much :) ?
anyway, i have decided to do it my own method, holding XML tags in DB and creating dynamic XML blah blah. it seems little bit complex, but after deployment it gives me dynamism.
I am still open to new ideas, guys!
Thanks again.
Bayarsaikhan VOLODYA
-----Original Message-----
From: Chris Rowse [mailto:crowse@(protected)]
Sent: Wednesday, September 15, 2004 12:02 PM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: XML messaging
Hi Bayarsaikhan
Perhaps you want to look at JAXB (Part of JWS pack)
You can use it to marshall and unmarshall all your XML
directly off the XSD into an object tree.
The documents will be separated i.e. you get a class back based on the
XML you received, and by extension or delegation you can do whatever you
require. I use a factory to wrap this returned object in a standard
interface for all received messages. My application code doesnt need to
know what specific class came back, the factory handles that.
You might also want (or need) to look at a SAX parser to generate
events for you.
I've used JAXB in a http client that http:POSTs java objects as XML,
then waits for the response and creates the correct java object trees
for me based on the response xml.
I use overridden action(), toString() etc methods in the interface to
create behaviour based on the class returned.
I'm sure there are neater and better ways of doing this, but I now have
independance over changes to the XML schema since JAXB compiles the
external schema for me. The XML schema is out of my control.
The only flaws I can see in JAXB are
a) It creates concrete classes. I would prefer interfaces.
b) AS a result it does not map easily to EJB CMP2. I would love to be
able for instance to ....
1) Create an XSM schema
2) Use JAXB to create marshallers, unmarshallers, interfaces to
these XML objects
3) Use XDoclet to create EJB CMP2 for these interface objects
I now would have a system that transparently stores my XML as it
arrives! (and gives me EJB).
Chris
On Wed, 2004-09-15 at 10:13, Bayarsaikhan VOLODYA (YAZ-ArGe) wrote:
> i think, it is not for me.
> my problem is how to seperate these XML documents. should i create objects for each XML document and apply mapping between them? or is there any way to create dynamic objects using XML?
> thanks,
>
> -----Original Message-----
> From: Chanian, Raj [mailto:Raj.Chanian@(protected)]
> Sent: Tuesday, September 14, 2004 6:15 PM
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: Re: XML messaging
>
>
> Use CorrelationIdentifier messaging pattern
>
> Regards,
>
> Raj Chanian
> LogicaCMG
>
> -----Original Message-----
> From: Bayarsaikhan VOLODYA (YAZ-ArGe) [mailto:bayar@(protected)]
> Sent: 14 September 2004 15:54
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: XML messaging
>
>
> Hi all, i hope you all are doing well.
>
> There is an challenging project.
> Maybe some of you know about FlexCube. I have to talk to FlexCube using XML
> messaging.
> There are so many XML documents i send to FlexCube to make some kind of
> transaction or blah blah, and result is also in XML format.
> How do i seperate incoming XML? How do i know which kind of transaction is
> that XML.
> How do i manage so many XML documents? Should i convert all of them into
> Java Objects (will be static)? Is there any way to process all these XML in
> similar manner? In future, when there maybe new kind of transaction, i dont
> want to play with my code again. So is there any dynamic way to handle all
> that XML messages? sorry, i know there is so many questions. but i will
> appreciate any feedback, advice from you.
>
> Bayarsaikhan VOLODYA
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com
> J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> listserv@(protected)
>
> This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com
> J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com
> J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
