Bala,
Have you considered content based routing. If your xml docs are arriving in
a queue, maybe you could use a MDB as a listener to pick up these xmldocs as
textmesages asynchronously,and then process and delegate accordingly based
on certain tags kept in memory, rather than keeping tags in database. Just a
thought if your architecture is event driven.
Regards,
Raj Chanian
LogicaCMG
-----Original Message-----
From: Bayarsaikhan VOLODYA (YAZ-ArGe) [mailto:bayar@(protected)]
Sent: 15 September 2004 16:18
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: XML messaging
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)
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)
