EJB development doesn't have to be hard. This article will show you how easy it is to create an EJB-based application visually and test it on a server using WebSphere Studio V5.1.2 and its UML Visualizer. By creating a simple library application, you'll learn how to use the UML Visualizer to create, modify, deploy, and test of a set of EJBs.
- Posted by: Frank Charles
- Posted on: October 14 2004 19:25 EDT
Read: EJB development made easy using the UML Visualizer in WebSphere Studio
- RE: EJB development made easy using the UML Visualizer by shay shmeltzer on October 15 2004 12:39 EDT
- EJB development made easy using the UML Visualizer by Konstantin Ignatyev on October 18 2004 10:56 EDT
- EJB development made easy using the UML Visualizer by Arik Kfir on October 22 2004 16:45 EDT
What's new about this?
JDeveloper, for example, had EJB modeling for ages now.
You want something new?
How about the drag and drop binding from EJB to JSP fields using JSR-227?
And since we are posting tutorials here, here goes another one that will take you even further by showing you how to build JSP interfaces to your EJB (Visually of course):
I'm gonna play a little with JDev's ability in the next few min, but AFAIK JDev does this by using a proprietry framework called ADF, am I correct?
I wish there would be a standard (perhaps there is one in the works) that standardizes the entire J2EE data flow between tiers. Something that defines how the data should be returned from the EJB tier, processed, if needed, for presentation, and then updated (again, using some session facade that accepts a common form of the data).
Today, it's everyone to himself/herself - *we* define the interface of the session beans (which is basically good) but then we need to do it all over again in every application - the data-to-presentation and vice versa, that is.
I often tinked with the idea of having our session beans return RowSets consistently, so that we could automate our presentation tiers more effectively.
Again, everything is possible, but everything is also proprietry or application-specific.
Just a couple of cents of my head ;-)
Actually, what JDeveloper is doing to enable binding of EJBs to UI's is the base for JSR-227 http://www.jcp.org/en/jsr/detail?id=227
Which tries to solve the exact problem you describe.
JSR 227 aims to define a standard way to bind to data sources (be them EJBs, POJOs, Web services or....), realizing that there is a common set of functions that you preform on these data sources.
I think it must be possible to return DOM for UI or register UI builder as SAX handler for performance, there are many standards and tools for XML, probably performance is a problem, but it must be possible to transform data to HTML stream without parsing.
EJB development doesn't have to be hard.It is not that hard since invention of XDoclet.
But even EJB development 'not hard' it does not mean that EJB-s should be used everywhere.
XDoclet made things simpler, true, but I think I'd wait till EJB 3.0/3.1 before diving into it. So far I've managed to get along fine with servlets, JSPs, struts, spring/hivemind etc just fine.