This past year the J2EE 1.4 specification enjoyed increased adoption by the
industry, with most major application server vendors having released their
J2EE 1.4 products and more and more enterprises upgrading their application
servers and production applications to comply with it.
Apart from merely upgrading, there's a natural desire to leverage the primary
focus of J2EE 1.4 - its support for service oriented architectures and Web
services - and make it benefit the business by exposing the business logic of
J2EE applications in a way that makes them portably accessible from the
various heterogeneous environments that are around today.
Here at Compuware (the company I work for) we chose to make the ability to
generate J2EE 1.4 applications one of the top requirements of the upcoming
version of our OptimalJ product, an MDA-based development product that
enables you to... (more)
In my earlier article "Moving to SOA in J2EE 1.4" published in the February
issue of JDJ I introduced you to the new object distribution model based on
Web Services that became available to Enterprise Java applications with the
advent of Java EE 1.4. In this article I want to look at the security
features available in Java EE SOA.
Here you'll get thehands-on knowledge of Web Services security in Java EE
that we acquired when adding security support to OptimalJ-generated SOA
applications. It's based on the J2EE 1.4 specification itself as well as on
what is actually supported and... (more)
One of the things that kept me and my team busy over the past couple of years
was starting to support J2EE 1.4 in OptimalJ - a goal that we accomplished
with the release of OptimalJ 4.2. Now that this job is complete, it's
interesting to look back and ponder the experience and learn from it.
As OptimalJ is a vendor-neutral modeling tool that generates J2EE
applications, we tend to avoid application server-specific features that are
not mandated by J2EE. Typically our first take is to implement our
code-generation modules by the letter of the spec and then ensure we fill in
the n... (more)