J2EE 1.4

[HS Thomas]

The networking giant is currently reworking its strategy on Java and its many variants such as J2EE (Enterprise Edition), J2SE (Standard Edition) and J2ME (Micro Edition). Fowler says Sun is looking forward to the February release of its J2EE version 1.4, which is expected to incorporate Java API for XML-Based RPC (JAX-RPC), SOAP with Attachments API for Java (SAAJ), Web Services for J2EE, J2EE Management Model, J2EE Deployment API, Java Management Extensions (JMX), J2EE Authorization Contract for Containers and Java API for XML Registries (JAXR).

Can anyone who is working in a standard J2EE environment ,say which of these will be immediately useful, please , in terms of developers crying out for particular features ?
Do any of these affect the way EJB's are written/ deployed? The two things I have heard about EJBs is that they "under-perform" and are "over-engineered".
The first has been rumoured to be attributable to badly written SQL . The second , probably as a direct result of the first, hence many EJBs that do simple things where one well-written EJB could suffice.
Any comments ?

[Rich Raposa]

JAX-RPC, SAAJ and JAXR are all APIs for developing Web Services, so these are useful for anyone who wants to use Web Services in their J2EE applications. (I suspect this is a large percentage of J2EE users.)
The deployment and management models are attempts to make the deployment and management of J2EE servers uniform across vendors. Useful? Sure, especially for your system admin.
None of the new technologies affect your existing EJBs. However, new capabilities have been added. A stateless session bean or message-driven bean can easily be made into a Web Service. Also, a timer feature has been added to the EJB portion of the spec, useful for scheduled tasks, etc.
Certainly nothing about the new J2EE spec will affect the under-performing, over-engineered EJB. That problem is typically a design issue.

[HS Thomas]

Thanks Rich,
That helps a lot.
The deployment and management models look like useful to get stuck into.
As far as EJB development it looks like there's nothing new in simplification other than good design.
Another question I have :
Can good EJB design be independent of whether you are using JDBC or JDOs. I suspect it ought to be. Any references(books or links) would help.
Actually I'm not sure if the alternatives are EJB vs JDO (there was some press about this at the start of last year) or
JDBC vs JDO (there seems to be some new press regarding this lately)
The other pre-conceptions I have are
1: EJB and RMI go hand-in-hand. RMI does not work between firewalls. So where exactly are they applicable ? Just within an Enterprise, within Virtual Private Networks ?
If you need to go beyond , convert it to a Web Service, use JNDI?
2: that EJBs are a "pain" to develop ? Since it looks as though nothing new has been added to lessen the pain where is the "gain"

[Ashik Uzzaman]

Actually I'm not sure if the alternatives are EJB vs JDO (there was some press about this at the start of last year) or JDBC vs JDO (there seems to be some new press regarding this lately)

Dear Thomas, I think its JDBC vs JDO.

[Rich Raposa]

When a client of a bean accesses the bean outside the container, then the method call likely uses RMI, so that is the relationship between EJBs and RMI.
If a client needs to access an EJB through a firewall, then you typically use another J2EE technology (part of the "Presentation Layer" of J2EE). If the client is using any type of GUI whatsoever, then use Servlets, JSP and so forth. If the there is no GUI involved, Web Services would be a good choice.
In terms of EJBs being a pain, I would say they are actually quite easy to develop. It's deploying them that tends to be a pain, but that's the beauty of EJBs. The code involves the business logic, and during deployment you get to pick your options for security, transactions, persistence, and so on. I think EJBs are a great design. Perhaps their learning curve is a little steep, but they're a heck of a lot easier to understand than CORBA.

[HS Thomas]

Thanks Rich and Ashik,
This helps a lot in gaining a perspective on these technologies.
Is there a resource library for this forum?
regards

[HS Thomas]

Excuse me for re-visiting this.
As I understand it, EJBs have database transactional support, and client connection support (presumably the packaging together is an attractive option) but client connections cannot penetrate firewalls.
Is it blocked because of the protocol RMI-IIOP or the default port that it runs on ?
Seems to be rather limiting!

What is the ONE convincing argument to move from a HTML,JSP,Servlet only platform to one that uses EJBs ?
Ease of development ?
i.e Why do people do it?

[Simon Brown]

Originally posted by Rich Raposa:
JAX-RPC, SAAJ and JAXR are all APIs for developing Web Services, so these are useful for anyone who wants to use Web Services in their J2EE applications. (I suspect this is a large percentage of J2EE users.)

I find this interesting - while it's a useful thing to have web services support in the platform, I still don't imagine that a large percentage of J2EE developers will be using it (yet).
J2EE 1.4 also brings JSP 2.0 (some very cool features including the expression language and new, simpler ways to build custom tags) and Servlets 2.4.
Simon

[Simon Brown]

Originally posted by HS Thomas:
Thanks Rich and Ashik,
This helps a lot in gaining a perspective on these technologies.
Is there a resource library for this forum?
regards

An FAQ was started but the bartender of this forum has been a little slack lately, what with the holiday season and writing some new stuff for Wrox. Let me dig it out and finish it off...
Cheers
Simon

[HS Thomas]

Thanks, Simon . Looking forward to the FAQ.

quoted by me:
Is it blocked because of the protocol RMI-IIOP or the default port that it runs on ?
Seems to be rather limiting!

I have since realized that RMI works with other protocols that have no problems , in itself, penetrating firewalls.

With all the features with EJB that are provided,what stops it being used where those features are especially needed i.e. connecting outside the Enterprise ?
Is it that :
1: No guarantees against security breaches provided ?
2: Management just are not ready for it ?
3: Performance is no longer an issue, but that info still needs to reach the trenches
4: A combination of all the above : No point in starting something till you have all the pieces of the jigsaw puzzle ?
That could be a long time away for some organisations.
[ January 24, 2003: Message edited by: HS Thomas ]
[ January 24, 2003: Message edited by: HS Thomas ]
[ January 24, 2003: Message edited by: HS Thomas ]