Discussions

This pattern allows the client to absorb data from mutiple sources of data (tables, other XML documents etc.) and delinks the front end GUI from the middle tier.

Where can it be used (sample):
1: for report generation, after extracting data from multiple sources.
2: workflow queries

How it works:

Entity EJBs model the Database (DB here onwards), so that the DB is abstracted by the EJBs. This is a known pattern documented on this site and elsewhere.

These entity beans are next wrapped in session beans. This is also a known pattern documented on this site and elsewhere. These session beans perform the query on the entity EJBs and format the result of the finders from the entity EJBs into XML documents.

These XML documents are passed back to the servlet (or session EJB client) which called the session EJB. The servlet can then parse this XML document and display the data whichever way it wants via XSL or can pass the data to other servlets for processing.

Each table can be represented by a XML Schema so that the client can parse it. This XMLSchema can be got from the actual table schema by mapping the table schema.

This helps the display servlet to merge data from multiple sources and give a unified view.

The display servlet can then pass this back as a HTML document or even a SOAP response. The EJBs act as XML data sources effectively forming a database to XML bridge.

Step by Step:
a) The database is mirrored by Entity EJBs (CMP or BMP).
b) The entity beans are covered with a session EJB facade.
c) The clients call methods on the session EJBs to query data.
d) The session EJBs, after getting the results from the entity EJBs, format the query result into a XML document and return the XML document back to the client.
e) This calls for each table to have a XML Schema giving what type of data it contains, so that the client knows how to parse it.
f) This allows the client to get XML data from various sources (tables) and display it via XSL as whatever format it wants.
g) The client can be a servlet or JSP or any EJB client.
h) This allows multiple datasources to be combined into a single view and enables the EJBs to give a XML based interface. You can even use SOAP to pass this XML data to various other types of clients.

How XML data is passed back to the Servlet...in the form of hashtable or vectore or ?????

also, is it possible for you to provide a sample XML code that parase the XML document and display all the elements as data.....I have done it for one specific node...but wondering what would be the trick to gel all the elements node ..from xml..and store them in java string...so we can use it whatway way we want...

1) as a Stream
2) as a StringBuffer
3) as a XML DOM Object
4) (cumbersome, might be required for very large amounts) as a filename (file being generated by the bean and read by the servlet, find some way to delete the files at regular intervals).

Even i am facing the same kind of problem.....One possible solution is to return data in the form of ResultSet object....but i came across Marshalling Exception and NotSerializable Exception.Could anyone give a better solution please....?

hi,
I am another guy here looking out for some code fragments for XML data generation from EJBs. This is the core part of my module for which my hunt has already started any help in this regard would be thanked a lot.

I had just one question . how is it better than passing serialized objects.
As a java client can access an EJB which generates XML. So the presentation can be independent of the data (Model -view) in both cases i.e in case data is passed as XML or serialized java Objects.

Also If you could pls send some snippets of code which create XML and also which parse XML .
I can be reached at pankajgrover at yahoo dot com

I had come across systems in which the data is already in XML format. So to integrate other applications with these XML systems, it would be easier if the EJBs gave out their data in the form of XML. Also, in some cases one half of the systems had say some reports generated in XML and other reports coming in some form out of a database. So to merge these 2 it would be better if all were in XML. Hence I thought about this pattern.

As for storing XML as serialised objects (CLOBs)in the DB,
1: Your beans would be BMP since weblogic does not support CMP for CLOBs.
2: Your data since it is stored as a serialized string now would have no relation to any other table. I mean that your table relationships are lost. Here in this pattern, the data gets stored back into the fields it belongs to. Your table data is totally independent of the XML document.
3: but yes, if you are doing some processing on the XML data and you want the preocessed results to be stored, especially if the processing is resource intensive, then you might as well store the result as a serialized string.

The case I had mentioned has nothing to do with storing XML data as a serialized strings (although that could be done). I extract data from the DB using normal EJBs i.e the data is stored as normal SQL datatypes like varchar or number. These EJBs then convert the data to an XML format and passes it to a servlet or some other program for further processing. This helps to get multiple data from various sources and merge them into a single XML document. The EJbs effectively act as a XML to Database bridge. The EJBs can also parse the XML document and break it up into java primitive types and store the data back in the required tables. The SQL schema for these tables correspond to the XML Schema for these documents (like a one to one mapping betweem the table columns and the XML tags). This thing would work for simple XML docs but i thnk it can be made to work for complex XML docs, since the work for getting data and parsing is handled by session beans with some parsing logic.
Admitted, it would be easier to store the XML data as a CLOB in the DB, but then the relational aspect is lost. In my case, the data is stored as normal data types. The Entity beans map the tables. The session beans manipulate the data to XML form and back from XML form to normal data.

I will write some sample code and put it here in the next few days,
cheers,
Anil

I think I have been misunderstood . what I was referring to was pros and cons of passing XML between ejb's and java clients like servlets with passing serialised objects from the ejb to the servlets like java beans which could be acessed by JSP's as well with relative ease.

I ma interested in knowing what relative benefits does the XML provide in passing the data to the client layer.

I can understand if it is going to de different clients like a servlet and a MFC GUI.
If it has to be only a java client, I fail to understand any relative merits of this approach.

This pattern was meant as a means to give out and put in XML data via EJBs into a database. This decouples the EJBs from the presentation layer totally.
1: You could have a servlet which would take this XML data and via XSL convert it to HTML or WML maybe.
2:Or you could even write a servlet which consolidates all the XML from various EJBs and merges them into a single document. (one of such applications being reporting tools).
3: Or you could write a servlet which takes this XML data from the EJBs, and formats back a SOAP response and sends it back to a SOAP client.

The point being that since your EJBs give out XML, you can do whatever you want with thier output, whether to do more processing or just display. You can always create JavaBeans from these XML documents and use them if you want to. It is a design issue which you will have to decide.

dear friend,
i have a very basic question. i want to know where exactly
XML comes to picture in a real world web based project.
like
1. client side or server side
2. like if in client side can we design UI forms
with all the elements like list boxes, tables as
we do in html. if we can do that can we completely
eliminate HTML in our applications

Hi Kiran,
The XML part comes both in the server side as well as in the server side.
Client Side:
When you are using the XML in Client Side you can get the input and process in XML format itself using tools like XSQL
Servlet which you can get from ORACLE site(www.technet.oracle.com).

Server side:
You can query a database get the contents in XML form and process the same thru a the same XSQLSERVLET or ordinary SERVLET or JSP and you can make your screen to view in XML form itself.As you have mentioned in your message in this way we can eliminate the usage of HTML effectively.

If you do the process like this then you can see the time taken for processing the data is considerably reduced.

I think that the real benefit of using xml with EJBs is on the process side, particulary in the way session EJBs exchange data and informations.
Exchanging XML documents is more "abstractive" than exchanging serialized Objects or calling each others public remote methods.
Actually the only problem with XML is the lack of a good and simple querry language, it is possible to map an xml document against a DB table and then use SQL but it's not very realistic because the XML shema can be complex and can evolve frequentely.

U talked about mapping entity beans to represent the database and having session beans to communicate with the entity beans.

In my view to think about the architecture it is a clear one.But if we consider about performance I don't think it'll give a fast response system when we imagine a big system take an example financial systems.There we've to map hundreds of tables with entity beans and if we talk with them using session beans see the roundtrips and load on the server.It'll affect the performance.

What I think would be the best is we can cut entity from the architecture and we can use XML methods to parse data directly from the database.

Feel free to share your experience with the design architecture u proposed with a huge system if u felt it enhanced the performance.

I dont want this to sound like an advertisement, but my company uses cerebellum software [www.cerebellumsoft.com], which is used to create data access components that can be used in a variety of methods. Heterogeneous queries can be graphically created, and included inside entity beans that can in turn be used in jsp pages. it makes this whole process a LOT easier. then again its not free... It seriously cuts down development time though.

I'm glad this topic was brought up, as I use it in two of the projects I'm working on. We use XML as a serialization mechanism between the client (an applet) and the server, with a servlet being the router, or controller. Why, as Pankaj asked? Well, for one, we could only use HTTPS, not IIOP, RMI, etc. and we spent a lot of time investigating the use of just 'plain' serialization, but found this to be somewhat problematic in that it is very rigid. What if the server through an exception, and you are expecting your object graph to come back? In our case we have no way of catching it, because of HTTP. So, we are using XML as an RPC mechanism as well, serializing both the message (method calls) and the data back and forth. The actual GUI doesn't know about XML as it is deserialized back into objects for it's use, as in the Details Object pattern.

Also, as mentioned before, you could apply XSL for HTML clients using something like Apache's Cocoon, use it as an app-to-app communication (B2B), etc. At the moment it has also served us well as a temp storage medium until we finalize the DB schema.

Our first major question that came up was that of performance, which we expected to take a big hit on. Suprisingly, it was really no slower than standard serialization on a large object graph; maybe a few milliseconds at most.

On peristence, I probably wouldn't store XML directly in the db, but mapping to it won't be a major chore either. I'm not a big fan of CMP anyway...

Just thought I'd add my 2 cents as passing data as XML seems to be a trendy choice. There are actually 4 proven methods for passing data from the EJB business tier back to the servlet Presentation layer for processing that I'm aware of. These are:

1) Use an array of strings
2) Use an array of structs ( Java classes with public fields - standard C technique )
3) Use a Java bean
4) Use XML

I think the pattern that started this discussion is good but it's not complete. IMHO, the final step, after the data is passed from Entity EJB to the Stateless Session EJB, is to pass the data back to the servlet for display. The Servlet acts as the display controller in the classic MVC pattern.

Now, does it really make sense to serialize the data coming back from the EJB tier as an XML string when it's always passsed to the servlet for rendering anyway? What I'm getting at is that passing a bean over RMI for Java EJB to Java servlet communication within a firewall makes a lot more sense to me in terms of performance. When the bean gets to the servlet, the servlet can then decide to transform it into XML, WML, HTML or anything else.

An interesting notion is to use sun's new WebRowSet for just this purpose. WebRowSet is a beanified jdbc resultset that was created to pass data from an EJB to a servlet. This is not an original Sun idea. It's a pretty good copy of the Microsoft RecordSet COM object. Anyway, the servlet can then choose to call toXML() on this bean and the data will be converted automatically to XML. Presto, you don't get the performance hit of converting to XML and back unless you need to send data thru a firewall across the Internet via HTTP.

Your perfectly right, but here are some Applications for this patterns (haven't checked this ones for performance or stability, just for ease of use: <br>

- EntityBeans always have more than one view: Most prominent example is a view inside a web application and the corresponding administration client: Having an XML-Representation of an EntityBean will serve as a good Starting-Point for Generating for example a Swing GUI to administrate the Bean. (Is this compatible with the Pattern?! Even a Swing-GUI always interacts with a Session Bean wich extracts the XML from the EntityBean or puts it back.)<br>

- this is essentially just another way of marshalling/unmarshalling an EntityBean, and this can be done automatically (e.g. castor.exolab.org) which makes the Pattern even more useful.<br>

- Essentially this is just a rephrasing of the well-known Transport-Object, or am I wrong?

The only time I probably would NOT use any kind of to/fromXML is if you know that you:

- are never going to communicate app to app or B2B
- never need to communicate over HTTP (such as in an applet or WML)
- are never going to use XSL vs. JSP for presentation (which has a strong following)

It doesn't always make sense to go from EJB to XML to HTML (via JSP), when you can go from EJB to JSP, but then again sometimes it does. It really depends on the end use of the application and it's growth potential.

- XML is a kind of view of the model and the model shouldn't be responsible for generating views
- The Entity Bean will have to be changed everytime the DTD is amended
- The Entity will have to not only produce a valid XML document but also XML fragments as one might want to build an XML view from several Entities. This means that the Entity must know about all the different DTD's it might form a fragment of.

My feeling that the proper place for generation of XML from Entity beans is in stateless session beans whose sole function is to build XML views of the underlying data in Entity beans. This allows the greatest flexibility in putting different XML documents with different DTDs/Schemas together of the underlting model without cluttering the model.

I agree entirely with your assertion that it doesn't always make sense to go from beans - xml - xml+xsl = xhtml, xhtml + css + jsp. Much better to go directly from bean to presentation when thats all the app does (no B2B for instance).

I like the idea of a stateless session bean doing the generation of XML as opposed to the Entity bean itself. In my own framework I do something similiar; I have a utility class that generates the XML for our business objects, and reinstantiates objects from XML as well (we are using XML for RPC/marshalling over HTTPS).

I used this pattern in my previous project. it worked nicely. I consider XML is the objects property like draw() method of shapes. When control asks the entities to draw each entity like line and circle draws itself.

This is how I used this pattern before in a content based email system
- I have entity beans for Channel, content and product. Channel is entertainers - Title, author etc. Content is about Tom Hanks and products are Apollo 13, xxx and yyy
- When I need to display only product session bean x calls product entity bean and toXML() and hands of this XML to XSL
- When I was building full email, my yy session bean calls channel bean, content bean and all the realted products beans to get individual XML and builds the total XML for the email
- I use same entity beans to producr preview screens for content generation people

I have one argument against your belief. You said "XML is a kind of View", but I say "XML is a kind model, XSL is the kind of view". The controller (a stateless session bean) has a responsibility to build the XSL (ie, the controller class has a immplemented method getXSL) and this method collects the XML (sole data) from the entity bean and applies the proper XSL (according to viewing needs - admin view, compact view, detailed view, edit view etc) to the XML.

I think, XML must me considered as a more meaningful representation of the data inside the entity bean. Hence, it should be entity bean's responsibility to generate XML and give it (stream or file or some other representation) to the controller class when requested.

We are using a form of this pattern in a production application (3000 users). Our beans are really pretty dumb--stateful session beans that are really a poor man's version of entity beans wrapping concepts resident in legacy systems. Communication to and from legacy systems is in XML form.

Being able to convert an object to and from XML is a great idea. For an example, see my BeanMapper at www.jdom.org, or any of the countless other Bean<->XML serializers.
<p>
However, you should not allow an object to serialize itself with a toXml() method (or fromXml()). This limits the object to having one and only one possible XML representation, when as we all know, there are an infinite number of mappings to choose from.
<p>
Instead, use a separate serializer object (like BeanMapper). That maintains object separation (often mistakenly called MVC).
<p>
Cheers -<br>
&nbsp;- Alex

I just want to add that one can use the Adapter pattern
to do this. For example have a XmlCarAdpater wich takes
a Car object in it's constructor and have a method toXML()
to get the XML string presentation of the Car object.

Note: In one of the projects I am working on, I use
composite objects, like CarPark containg a list of cars, etc
This lends itself to using the Composite pattern in which
you specify composite objects as branches having one or more
leaves. Each such object then, wrapped in an adapter would
know how to represent itself (acording to the adpater rule).
Thus, the whole tree (or composite component) will know how
to represent itself when wrapped in an adapter.

This leads to a solution where your composite object doesn't
know anything about how to represent itself, rather the
Adapater defines rules of that. Also adpater uses the
Composite pattern to allow for complex, composite objects to
be represented.

I also agree with Alex. An entity may have several XML representation.
In our project, for example, we have to represent Entities which have aggregated entities in them. Whether the client has to receive the aggregated entities along with the parent depends on the exact use case.

As for the adapter pattern, how would that be better than a Translator class?, e.g.

Great topic!! Here are some performance and maintenance considerations for large applications. Our project, a large eCommerce portal, has ~100 entity beans and just as many session beans.

I have seen finders and iteraters become too slow for creating large numbers of XML messages. We also have to deal with dereferencing OIDs and looking up reference codes on large data sets.

Our data is maintained by session and entity EJBs ( using Lazy References and DataBeans as we call them ) and supports inbound and outbound XML. We took a different Java approach for outbound XML since large numbers of XML messages can be requested. Our approach includes JDBC, Oracle views, HashMaps, a text Formatting class, and external element tag files with matching java classes.

We perform queries against the views which perform complete translation of all reference codes and conversion to element column names. The HashMaps are produced from JDBC result sets and store references to data by element name. The tag files and Formatters are referenced by reflection and loaded on demand. This is quite fast against large result sets and is also easy to test. Our next goal is to move this into Oracle 8i for even more speed.

On the maintenance side it is much faster to engineer, test, and roundtrip debug given the large number of beans that we are already supporting.

Plz elaborate this scheme little in more detail to extract data in xml from ejb. example could be report generation for vendor in B2B kind of application.
Bye,
Ajit wadekar.
Email: ajitwadekar@yahoo.com

I've been looking at this kind of mechanism for a current project I'm running for a 30-person class at a major financial institution to do fixed income holdings...

The tradeoffs I've come up with is pretty similar to the ones I've seen stated here: do you explicitly generate the XML inside the entity bean with a toXML() method? Or do you write a visitor of some sort to allow the "XML Hub/Broker", so to speak, to traverse the beans' get/set methods to get the data and turn it into XML.

By and large my major concern is performance with the visitor approach. It's obviously cleaner from the beans' perspective, because then they really don't have any XML knowledge, but if a business entity has hundreds of fields (not uncommon with securities that have hundreds of derived economic indicators), this becomes a bottleneck with RMI/IIOP, even over the local loopback. If the servlet engine (which runs the XML hub) is on the same server as the EJB's, and you have short-circuted RMI stubs that perform in-process call routing, then I suppose you lose that network trip overhead. I believe BEA Weblogic does this sort of short-circuiting, but I need to confirm...

My other concerns are how we can format the DTD. I'm thinking we can use or possibly mildly extend an existing DTD for hierachial data, such as XML-DATA from Microsoft.. this allows for a pretty generic Object oriented data representation, but it doesn't really provide me any way to map "process", or "actions" in my XML. What I want to be able to do is to map queries and result collections, but also to map business transactions in my XML. Right now I think the best way to accomplish this would be to provide an ID for the bean (session typically) that has the business transaction on it, and the transaction name, and just to use Java reflection, i.e.:

Another concern I have is that I'm not sure I want to have the complexity of scanning my beans for fields through get/set methods. I had to do this once for a business object framework that allowed me to arbitrarily update methods based on key/value spec in HTML, and it was somewhat complex (ask Floyd, he knows... :) Anyway, what I'm thinking is that perhaps I should have an XML file that acts as a "data dictionary", or sort of an app-specific deployment descriptor, that lists the fields of my entity beans.

My XML hub then, completely un-knowing about any hard-coded bean names or method calls, would just map the XML messages to the info in the data dictionary, and call the appropriate methods.

This could also lead a wilder implication in that I could roll my own object/relational mapper to do schema changes to my BMP entity beans fairly simply by just adding a field+getters+setters to the bean and updating the stored procs for my ejbCreate/Remove/Store/Load/Finders... (yes I know I should probably PURCHASE an OR mapping tool, but if I can teach one team of students how to build a scaled-down, simplified OR mapper, they'd get a world of experience..)

1. Talking about how to generate XML from EJB gets complicated quickly, not least because these two approaches overlap at the model layer. Why not simply ask the database to generate the XML directly (see comments by S.Varadarajanarayanan)? Most databases are supporting this anyway. What value does the entity bean offer if it simply gets in the way of efficient processing (see Rob Murtha's comments re: iterators)? Also, when using the db to generate the XML directly, the data is stored as the DB likes it (not as a CLOB), preserving the relations. This avoids the problem Channing Walton mentioned: the entity bean must change each time the DTD is amended. If there is no entity bean, but only DTD and XML, then obviously this goes away. This is an example of "Adding Lightness" to the design, making it simpler, by removing the EJB Entity.

2. re: Why generate XML? - with all the hype surrounding XML, perhaps we sometimes forget to answer this question. To me, it's quite clear that for interop (either via JMS, or some other external connector) XML will be quite important in server-side java systems.

2. Sun's WebRowSets - this is an interesting idea, but when applied with EJB entity beans, really it is a patch, a band-aid approach to delivering sets of data from entity beans. [see Stu Charlton's comments re: short-circuiting RMI]. Much more preferable will be JDO (still in JSR) or perhaps WebRowSets with JDBC directly against the db (again, avoiding the entity bean completely).

3. Some of us perhaps are thinking XML is useful only in the View of MVC, hence the questions "why generate XML in the EJB?" But XML holds value in integrated distributed systems primarily in representing the Model (see S.Varadarajanarayanan). Which is why it makes sense to generate it in a layer as close to the storage as possible. XML can also be useful at the view layer, but that is not the point here.

----

re: xml in java, use xerces, which is available at xml.apache.org. This was previously IBM's xml4j, but is now open-source.

We went ahead with the visitor approach to XML generation... here's our results (our first iteration is completed and demoed on October 6th):

A servlet is tightly coupled to a session bean "XML Hub". This enables each XML request to contain N number of method calls that are brought in as one transaction through the parseXML(String s) method on this session bean.

We use a 500 kilobyte StringBuffer in this bean that represents the cache for the generated XML. This object is nullified on ejbPassivate and re-created on ejbActivate. This allows for fast XML generation from the resultsets, with few redundant String creatiosn.

Row-level data reads & updates occur through a coarse-accessor method on a fine-grained generic entity bean, driven by our own schema-management data dictionary. The combination of XML and a dictionary-driven bean allow for near-transparent field-lengthening and field additions.

Set based data reads and updates occur through stored procs that are encapsulated in session beans.

Performance is promising, though we have not come up with hard numbers yet. Relatively little CPU overhead is apparent in using XML (we're using SAX). Network overhead is obviously going to be higher than raw rowsets, but it has not impacted us yet. We are using a data-windowing strategy to limit the maximum amount of data sent for a details-query and will optimize this further by "window shading" various groups of columns.

So far, I'm fairly pleased. In one iteration, we'll have developed a basic inventory system with ad hoc querying, easy schema chagnes, fixed-file format import, and scalability/fail-over support in 3 1/2 weeks... all with junior developers, some of whom learned Java only 2 months ago.

Obviously, it's not perfect, nor is it a full product, but it shows that even though the J2EE is complex, it provides a lot of time-to-market value.

We're using a variation on this theme for putting a web front end on multiple legacy systems. The theory is that we're not creating yet another <xyz> (insert your own domain) information system. We're creating a web front end. So why build entity beans that have to be modified whenever business rules change?

The presentation layer consists of a servlet that uses session beans to implement a "request handler" architecture. Request handlers in turn communicate with entity beans that exist mainly for caching purposes. The entity beans communicate with an integration layer that manages communication with legacy systems (mainframe, COBOL, etc.) through message queueing over some relatively slow links.

Responses from the integration layer all the way back to the presentation layer are in XML. The entity beans have no real knowledge of the entities they represent. They just know primary keys, sort keys, etc. Everything else is maintained by the beans in XML format, and isn't really accessed by anything but the XSLT stylesheets that format the XML into HTML.

This allows us to isolate changes to a great degree. Presentation of information is handled entirely by XSLT. We'll be implementing a business rule engine to manage validation for updates. So changes to front-end logic are managed without having to modify any code...

It's still early in the project, and we had some initial problems with the complexity of XSLT, but our initial prototypes look very promising.

The code for this pattern is very easy to write yourself and I feel that you should. I wrote the stuff with sample code from the weblogic examples plus some stuff from the xerces examples. The more complex part of generating a report from the database tables is part of a product and I would be violating copyrights if I made it open.

After a long time I had a chance to read all the comments/ideas posted on this site. I have had a few more experiences to add since the day I posted the pattern. Most of you will know them, but anyway here goes:
1: In any project, get the data model perfectly.
2: Decide on the queries you are going to perform. How many queries/how many updates/how many concurrent users?
3: Decide to go either the EJB way or the direct Servlet JDBC way depending on the complexity and marketing strategy of the product. I have seen products do EJB and XML jsut because they could be marketed as cutting-edge, not for any performance or other real world issues!
4: Finally how will data be passed in the system - as XML or as serialised objects? This depends on your project. If it is a reporting system, it would be easier in XML. If it is a system to just lookup data and pass it to JSPs for a view you would be better off with Javabeans.

Coming to the pattern:
A lot of good experiences with this pattern have been posted here. The visitor approach by Stu Charlton looks good.

The other appliction of this pattern which I found interesting was by Stefan Frank (XML representation of an EntityBean will serve as a good Starting-Point for generating for example a Swing GUI to administrate the Bean.) (How come I never thought of that!)

I had come across this pattern when my team was grappling with the problem of making user customisable reports from a system which already had EJBs. For creating reports XML/XSL is the easiest way to go. The data was anyway present as EJBs and also we could integrate our system with other providers of XML data to generate unified reports.

Finally some clarifications:
I had initially stated that we could map each table with an XMLSchema which in hindsight should have been that XMLSchema is used to map the resultant data which is generated by the session EJBean.

I&#8217;m not sure where this idea originally came from but I&#8217;d like to throw it out here and see what you think.

A servlet accepts an XML description of a session bean from the client. The servlet parses the XML description and uses reflection to call the corresponding EJB. The method called must accept and return a XML Document object. The servlet then outputs the returned Document object to the client where it is combined with XSL for presentation.

Here&#8217;s an example of what the session bean description could look like:

Doesn't representing elements of the model in XML make it harder to manipulate? This may be alright if the data is read-only, except that it still doesn't provide as many options for scaling up the servers as when the XML representation is deferred to a View. I will try to illustrate...

Consider a system with the following characteristics:

1. Business logic is implemented in an object Model that uses entity and session EJBs.

2. Entity beans deal only in Java data types. They may persist directly to a RDB (SQL data types) or talk to some other legacy system.

3. Controller is a servlet. Requests may come in XML format (SOAP?); they are parsed and the requested service is invoked.

4. Services are also servlets. They make calls to the session beans (and possibly entity beans) and make the results available to the View through data beans.

5. The View consists of JSP documents that are XML with custom JSP tags. Note that if the DTD or schema changes, no programming changes are required; just get someone who knows XML to modify the View documents.

6. Possibly wrap the service servlet and the XML/JSP in a filter that then applies XSLT, resulting in a transformed XML (or HTML) document.

Also I am looking for some good comparison or advantages of session beans over servlets where in this system the persistence is not handled by the session beans or entity beans (entity beans are not going to be used) and it is handled by a bunch of networking services which uses JDBC.

If you happen to come across any such document can you point me out to that.

Another aproach would be to use a helper class (instantiate by the Entity EJB) to convert the EJB Data into XML and XML into DATA.

On the client side, like so many pointed out, instead of a servelet or a XSL translator, one could use a pesistent adapter class (coupled to the Bean), to convert the XML received form the Entity EJB (using the helper class) into inside data, which can be accessed by the cliente (by getValueA, getValueB, etc) . (the client do not call or refere to the EJB itself, the adapter is the one who does).

The client could use the adapter to update the bean as well. Just calling a adapter method that update its inside data, send this data as XML to the Entity EJB. The entity bean, using the helper class already instantiated, convert the XML into DATA and stores it.

Note: you cold change the that inside the adapter and do not update the bean by creating to diferent methods: one to change and one to update.

I think that having a toXML method is nice because you can present a OO interface to the Entity Bean. Locking the EB to a specific DTD of course is a Bad Thing. The visitor pattern over RMI would also be slower, so couldn't all of the above be solve thusly:

XMLGenerator is Serializable so when it's passed to the Entity Bean the entity bean will have a local copy of it, so conversly when the entity bean passes itself to the XMLGenerator the XMLGenerator will have a local reference of the Entity Bean, therefore method calls will be a fast as you can get.

The XMLGenerator could use Reflection to determine the EB's getters or a specific XMLGenerator for an EB could make direct calls.

I'm not a EJB guru, nor even a neophyte, but I'm assuming that you can still use inheritance in the implementation of an EJB, so all this code can be placed into a base, including code for caching of XMLGenerators.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.