Hi all:
Here is a proposal for a improved EJX GUI. Using EJX I've
found it is very .xml oriented. You have to edit two or
three .xml files to get your application deployable in
jBoss2. I want to present a better (in my opinion)
alternative.
PROPOSAL
-----------------------------------------------------------
Make an improved EJX GUI. One that can make your .xml files
"behind the scenes" while you concentrate on the components
that make your application and how they relate to each
other.
DESCRIPTION
-----------------------------------------------------------
I've found the NOMENCLATURE of jBoss2 code very clear. This
has inspired me :-) this proposal. I like the names
Application, Container... etc.
(1) The user will work with these concepts to construct the
application. User is not the correct word, the applica-
tion assembler is a better one. I see EJX as an appli-
cation assembler tool. In fig.1 are the basic concepts
the assembler will see.
Fig. 1 -> http://perso.wanadoo.es/dwillis/fig1.gif
EJX should be able to read jBoss config files to
show the esternal resources (like datasources, mail
sessions, jms services, etc).
I think the best way to show this information is
graphically (I learn to program 16 years ago on a Mac,
I am very graphical oriented :-) This way we could
show relationships between components with a simple
line connecting two items. We could see quickly
components with unresolved references (ie, an ejb
with an ejb-reference not connected to any other bean,
or an ejb with a resource reference not connected to
any external resource). EJX could analyze these
references and see if they are satisfied, and show
a list of conflicts. Going far, far (far away from
this galaxy :-) EJX could, using the new verification
classes in jBoss2, verify the complete application
to see if it is EJB 1.1 compliant (EJB 2.0 compliant
in the future).
IN-DEPTH
-----------------------------------------------------------
Here are the steps the app. assembler will do to create or
modify an application.
(1) New/Open application
Fig. 2 -> http://perso.wanadoo.es/dwillis/fig2.gif
(2) This would be show to the app. assembler
Fig. 3 -> http://perso.wanadoo.es/dwillis/fig3.gif
(3) Clicking in the Application area would show the common
properties/actions of the Application.
(4) Clicking in the "Web containers" area would show the
common properties/actiosn of web containers.
- Web containers administration (I don't know if there
any, hehehe). Ability to add/modify/remove configu-
rations.
(5) Clicking in "EJB Containers" area would show...
- EJB containers administration. Ability to add/modi-
fy/remove container configurations.
- EJB persistence managers administration config?
- Other common EJB configurations.
(6) Clicking in a particular container would show the
specific properties of this container.
(7) Every item (application area, web containers area,
a particular container, external resource) should
have a pop-up menu to do the same things that can
be done through the properties page.
RELATIONSHIPS
-----------------------------------------------------------
Using this graphical interface only to display in a fancy
way an application and its components would be useless. I
think that it offers a lot more than just displaying
beatiful colored rectangles ;-)
Here is an idea to construct an application just drawing
lines from component to component.
(1) Every container would have handles to show references
to external components.
(2) The application assembler will create these handles
(ie. ejb-references, resource references, etc) and
then selecting the "line tool" will connect this
handle to another component. EJX will ask the nece-
ssary information to complete the request.
Fig. 4 -> http://perso.wanadoo.es/dwillis/fig4.gif
This way if we see a handle not connected to any
component, we know there is an unresolved reference.
EJX will check these situations to show the app.
assembler a list containing all the conflicts found.
PLUGIN ARCHITECTURE
-----------------------------------------------------------
I like a lot the plugin architecture of EJX. These plugins
show a properties page when an item is selected. How does
EJX will know when to show the correct plugin? Well, I
see it's a matter of SCOPE.
For example, an ejb container configuration plugin has to
be shown when we select "EJB Containers". This is the
scope of the plugin.
This scope could declared in a xml file associated with
the plugin or something similar.
THAT'S ALL FOLKS
-----------------------------------------------------------
Here are some ideas to improve EJX. I think some are
valuables. If this mail has made someone begin to think
about more possibilities... well, "mision cumplida" (I
can't translate this, sorry ;-)
kind regards
Pedro Mota
-----------------------------------------------------------
P.S. The most dificult part doing this new EJX I see is in
the routing of lines (is there any CAD/CAE developer
here? :-)
_______________________________________________________
�Tienes cuentas de e-mail GRATIS en Excite Espa�a!
A tu disposici�n en http://correo.excite.es
