8/10/2019 j2ee1.pdf

1/9

Mastering J2EE Application Development Series

Step 1 of 12: Slicing and Dicing J2EE

Slicing and Dicing J2EEby Ted Neward

Understanding your application's needs up front goes a long way toward alleviating J2EE's

complexity

There was a time not too long ago when a Java developer could walk up to a

new enterprise Java development project and know ahead of time which tools

they would use. It was all so simple then: J2EE was new, the HTML browser was

the accepted norm for user interface, and complexity, at least supposedly, was a

thing of the past. Today, it's so... complicated.

"Developersface a

bewildering

array of

choices."

Developers face a bewildering array of choices, ranging

from the "lightweight containers" such as Spring, NanoContainer, or HiveMind,to "web frameworks" like WebWork, Tapestry, a JSF-based UI like Oracle's

new Application Development Framework (Oracle ADF), or Velocity. Add to

that selection a whole new array of J2EE specifications themselves or the new

emphasis on "Web services" and the corresponding new buzzword "Service-

Oriented Architecture" via JAXM, SAAJ, JAX-RPC, or JAX, (not to mention the

"WS-*" specifications, tools, and libraries), and it's an outright miracle that Java

developers can get anything done.

Ben Galbraith, a speaker with the No Fluff Just Stuff Software Symposium series, calls this

phenomenon the Java Framework Uncertainty Principle: "No sooner do you pick a framework, than a

new version of some other framework gets released, thus forcing you back into the analysis of

choosing a framework all over again." It doesn't take much to complicate the picture further, either:

Just include the core J2EE and J2SE classes in the mix. After all, wasn't it just yesterday when we

were told that EJB is the "core" of J2EE and that you'd be silly to consider an enterprise Java project

without it? Exactly how do generics change your J2EE coding experience? And who let all that Java

Management Extensions stuff in the door, by the way?

What happened? Why did an industry originally so clearly focused on creating a platform formed of

http://www.oracle.com/technology/pub/articles/masterj2ee/index.htmlhttp://www.oracle.com/index.html

8/10/2019 j2ee1.pdf

2/9

best-of-breed tools and libraries get so fragmented in such a short period of time? When do we

choose between traditional "J2EE" tools like EJB, as opposed to the new crop of "Web service" tools

like JAXRPC and WS-Security, and, more important, what can we do now to avoid Ben's Java

Framework Uncertainty Principle without losing sight of the vendor-neutral principles that Java

espoused in the first place?

Much of the problem lies in knowing which technology best addresses which needs, and the best

way to do that is to figure out what your application's needs are in the first place. Once that's done,

the appropriate technology choices become more cleanly defined and easily understood.

In this article, I'll take a broad-brush overview of the J2EE state-of-the-art, the surrounding

technologies around it, and some of the architectural challenges a Java developer faces today.

Where are We Trying to Go Today?

A lot of different kinds of Java-coded programs tend to get lumped under the term "enterprise Java,"

and it helps to perhaps distinguish them from other kinds of Java applications before we get too far

with this discussion. If we start from the traditional "3 layer" approach, where we separate outPresentation, Business Logic, and Data Access concerns into three coherent striations of design,

then we can identify essentially five kinds of "enterprise" Java applications: stovepipes, jewels,

aggregators, integrators, and enterprise apps.

"We can

identify

essentially

five kinds of"enterprise"

Java

applications:

stovepipes,

jewels,

aggregators,

integrators,

andenterprise

apps."

StovepipesA stovepipe application (also called a "silo") is probably the

easiest for developers to recognize, because it's one app we've all done over

and over again: it's the traditional "single database, single UI" application that

currently, in terms of sheer numbers, is the most popular kind of IT application

being built. It usually starts out with a desire by some department manager orsub-manager looking for some specific tool or application to gather,

manipulate, and display some kind of data that's not currently being gathered,

manipulated, and displayed, so a team (usually a size not larger than three or

four people, and often just one person) is formed to gather requirements, form

use cases, build the database, code the business logic, deploy it to the

machine chosen to act as the production server for this app, and keep an eye

on it from time to time.

The name, of course, derives from the picture you get when you draw the

three boxes representing the logical layers of the systemPresentation,Business Logic and Data Accesson a whiteboard, since they form a straight

vertical line, reminiscent of the old "stovepipe" that carried smoke from the

wood-burning stove to outside the room. (And, by the way, to those who

would use this term in a derogatory fashion, remember that many of the most

important systems you will ever use in your lifetimesuch as the ATM machine, the package locator

on major shipping company sites, and so onare stovepipe systems.

As amazing as it may seem, the J2EE software stack doesn't serve developers building the simple

stovepipe system well. When only one presentation layer is required, and only one resource is used

8/10/2019 j2ee1.pdf

3/9

to store and retrieve data, the complexity of the J2EE stack, particularly EJB, just seems to "get in

the way." It becomes more tempting to consider the lightweight frameworks, because they don't

focus as much on deployment descriptors, and there's no awkwardness regarding JNDI, JMS, or any

of that other stuff. It's just basic, request/response communication from the web browser, typically

built in something like Struts or similar MVC-style web framework, talking to business logic

centralized in a set of core Plain Old Java Objects, sometimes with both Presentation and Business

Logic layers (if not the database itself) running on a single machine. (You may wonder why the term

"database" doesn't show up here. The simple reason is that while most projects use a database (and

a relational one at that) to store data, frequently the data store is instead a legacy system,commercial software package, or "broker" technology, a laa CICS mainframe, SAP, or BizTalk.

Using the more generic term "resource" helps reinforce the idea that the back-end implementation is

really irrelevant at this level of discussion.)

Stovepipes also have the advantage that they tend to "stand alone"there are no other players

involved. There's little need to conform to any established standard for security, reliability, or

management, since whatever this application defines will be the standard (at least, for this

application, and that's all that matters at this scope). Developers frequently take advantage of this

fact to build infrastructure that's "just good enough" for this application, thus eliminating the

accusation most frequently leveled at enterprise Java applications: that they're too complex to useand maintain.

Despite the desire to label it as such, the stovepipe application scenario isn't quite what J2EE was

designed to addresscertainly a J2EE-based application can build this kind application (and there

are thousands out there that stand as testament to that fact), the truth of the matter is, it's somewhat

like using grenades to go fishing. A J2EE-based application enforces a certain separation of layers,

and sometimes this is just overkill to the problem at hand, as in the traditional "10-user" stovepipe

system. The problem, of course, is that the 10-user stovepipe system has this annoying tendency to

morph into one of the other four versions, and this when things start to get hairy. Like the philosopher

who said "no man is an island," we can fairly easily and accurately say, "no system is an island", aswell. At least, not for long. (Of course, if the system fails to accomplish its desired aim, then it

typically doesn't get integrated with anything else and probably won't stay long in production, but we'll

assume that's not a desired aim.)

JewelsNo, not in the sense that this is the pride and joy of the IT environment or the "best" of the

five, the jewel style of application is one in which multiple presentation layers kick in (thus its name--a

"jewel" has lots of facets through which one can look). Note, however, that a given presentation layer

may not be something for users to look at at all; one layer that companies are frequently found

discussing these days is a Web-service-based front end to their application, which isn't intended for

human consumption whatsoever. Despite this fact, the Web service still represents a presentation

layer, since it's fundamentally doing the same thing: taking input for and providing output from the

core Business Logic layer underneath it.

Jewel applications present some interesting twists to the traditional programming model, because

suddenly certain assumptions that used to be in place can't be anymore. For example, when

considering a Web service front-end, it's suddenly necessary to define types in some kind of

platform- and language-neutral fashion (XML Schema is the current tool of choice here), and ideally

the Once-and-Only-Once rule--also known as the Don't Repeat Yourself principle--would allow us to

8/10/2019 j2ee1.pdf

4/9

build this directly from the same types the HTML-based Presentation layer uses to talk to the

Business Logic layer. This is where some of the JAX* specifications come to play--the Java API for

XML Binding, for example, helps to define a standard way of doing object-to-XML-and-back-again

transformations in a fairly opaque way, and the Java API for XML RPC (JAX-RPC) defines a way of

building interoperable request-response remote communication layers using WSDL, SOAP and XML.

While nothing stops a developer from using the JAX* specifications from their favorite lightweight

container, the J2EE 1.4 Specification directly incorporates JAXRPC and JAXB into its overall

technology suite, making it possible to expose an EJB stateless session bean as a WSL 1.1/SOAP

1.1 RPC/encoded Web service. (Note that according to the WS-Interoperability Basic Profile

specification, RPC/encoded services are officially deprecated in favor of document/literal ones; this

difference is widely expected to be fixed in the next round of JAX* and J2EE specifications, and

concrete implementations should be hitting the street about the same time that developers actually

figure out the difference between RPC/encoded and document/literal services.) What's more,

commercial application server vendors are taking great pains to ensure their offerings are not only

fully compatible with the J2EE standards, but with the Web service standards as well. This is clearly

an area where "compatible-yet-competitive" describes best the vendors' motivations (including those

of J2EE's principal competitor, from that little-known software company in the Pacific Northwest).

By the way, when looking to build a Web service Presentation facet, it bears pointing out that it's

tempting to expose the Model objects of the system directly as XML types, using JAXB or Oracle's

XML Developer's Kit, and essentially code-generate the entire Web service front end as a large

WSDL document. While this may seem like a good validation of one's Business Logic layer at

firstafter all, if there really aren't any business rules in the Presentation layer, then it shouldn't be a

hardship to take this approachlimitations in the Web services technology stack quickly make this

prospect difficult.

Consider, for example, the relationship of reference-based objects to XML: How should we best

represent a java.util.Date reference whose value is null in XML? Particularly when in .NET a Date

isn't a reference-based object at all, but a "value type,"meaning that it acts much like an int does in

Java? Things get particularly sticky when trying to represent complex cyclic graphs of objects in

XML, which is one reason why RPC/encoded was deprecated in the first place. This is all part of the

ongoing work behind the WS-* suite, but even if a team were to decide to "go their own way" and

build their own XML-over-HTTP system, they're going to face the same core problem. There's some

effort underway to try and incorporate object-XML mappings into core offerings, such as Oracle

Toplink, but as of yet they're still in their initial stages.

Meanwhile, we can't ignore the new trend in Presentation layer approachesthat of the "smart" or"rich" clientdesigned to fill in that very large hole in traditional browser-based applications, "greater

responsiveness." HTML, for all its goodness, has some fundamental flaws, two of which quickly

come to mind:

Least-common-denominator perspective.HTML was originally intended to defer

presentation decisions as late as possible, so very few elements in standard HTML actually

offer up guarantees about how the rendering will look on any given system. Attempts to give

page-builders greater control, like CSS, have met with mixed success, particularly across

different browsers.

8/10/2019 j2ee1.pdf

5/9

Presentation code as well as content must be sent.Because the browser has no inherent

knowledge of the application, the complete set of both presentation code and content must be

sent in every network round-trip to the server. This approach has two negative impacts, one

being lower bandwidth (higher consumption per client means fewer clients for the same

hardware) and the other being compromised availability (if the server or any of the

intervending topology goes down, no more application).

Toward this end, enterprise applications vendors are thinking strongly about putting Presentation

layer code onto the end-user's machine, thus eliminating part or all of two of HTML's principal

disadvantages. This creates some interesting deployment implications, however, so many shops are

looking to do both a thin-client and a rich-client Presentation layer simultaneouslythe rich-client for

use inside the company's firewall, and the thin-client for use outside of it (proving once again that you

can never be too rich or too thin). This approach raises the ugly specter of having to deal with two

separate frameworks, however, and at the very least we'd like to have some unified way of shuffling

data from the user's fingertips and into the back-end repository, and it would be nice if this could

somehow be standardized for both "rich" and "thin" clientshence JSR 227, a common data-binding

framework.

"We'd like

to have

some

unified way

of shuffling

data from

the user'sfingertips

and into the

back-end

repository;

hence JSR

227."

AggregatorsJust as a system can offer multiple "entry points," if you will, a

system can also build on top of multiple back-ends, bringing together data from

different resources and presenting it in some coherent and meaningful manner.

(Hence the term "aggregator," since the data presented and manipulated is an

aggregate of multiple resources/databases.) And, about 30 seconds after

starting to create use cases for manipulating and storing this aggregated data,

it becomes clearly apparent that some kind of atomicity is necessary to keep

the two databases in sync with the modifications being pushed on them. This isthe very space that the Java Transaction API was created to cover (and the X/

A specifications before that), and the intersection of transactional processing

and Business Logic is what EJB was created to deal with.

It's more than just transactions, however. Multiple resources covers more than

just two different databasessometimes a system needs a higher reliability

than a single database machine can provide. After all, a single machine

anywhere in the system represents a single point of failure, and frequently, all

"hot-swapping" failover scenarios aside, we just need to take the database down to perform some

scheduled maintenance on itwhich can include new schema changes to accommodate a coderollout, by the way. The Java Naming and Directory Interface (JNDI) serves as a single API for all

"lookup" operations, providing a layer of indirection from the actual underlying physical database

machine, meaning that if you don't cache JNDI lookup results, an administrator can change a JNDI

entry to point from one machine to a different one, and the J2EE application will simply follow suit,

thus creating a seamless and transparent "switch" to a new database that wouldn't be possible

without that layer of indirection "baked in."

Integrators When the need arises to connect two separately maintained collections of Business

Logic, an integrator system comes into play, and it becomes necessary to start thinking about

8/10/2019 j2ee1.pdf

6/9

interoperability in ways that a stovepipe system never needs. For example, if it's necessary to do

traditional request-response service, how will the request and response be carried out? Frequently,

developers immediately reach for the WS-* set of services, but as mentioned above, sometimes the

WS-* specs are too much (and too under-baked in current implementations) to reliably serve the

integration/interoperability need. Again, the J2EE Specification covers this base, by requiring every

EJB container to be CORBA call-compliant, meaning that any CORBA client can interact with the

Business Logic encapsulated in an EJB container.

Not all integration occurs in a request-response fashion, however. In order to avoid the bottlenecks

implicit in the synchronous nature of RPC and request-response communications, many systems

choose to integrate with one another using a messaging-based approach, which is the province of

the Java Messaging Service specification (and associated implementations, such as Oracle's

Advanced Queueing), and/or the Java API for XML Messaging (JAXM) and its associated SOAP API

for Attachments in Java (SAAJ), for doing "messaging with angle brackets."

The database itself serves as an integration layer as well, though not in the same sense as the

traditional RPC or message-driven system. In many cases, integration and interoperability is just a

matter of getting data from program "A" to program "B," and the database (along with otherresources) frequently serves as a useful-and well-understood lingua francafor different

platforms, most notably J2EE and .NET. While it doesn't address all interoperability needs, for many

systems this approach is just "good enough"which carries its own share of benefits, particularly

when Business Logic is embedded into the database (via a stored procedure). Furthermore there's

no need for .NET to figure out how to call Java code residing in an EJB server, or Java to figure out

how to call .NET code residing in a COM+ ServicedComponent, or how to share a single distributed

transaction ID between them, and so on. Particularly in view of the fact that Oracle has made it easy

to write stored procedures by letting you write them in Java instead of PL/SQL.

Enterprise apps Finally, we get to the "true" enterprise application, which turns out to be anamalgamation of multiple facets of all three layers: Presentation, Logic, and Data Access. The

traditional enterprise system is one which needs to present data from multiple resources in a variety

of formats using a collection of business rules stretched across multiple applications, languages, or

platforms. This space is the one in which we find the greatest complexity, and it's here that J2EE

really shines. Once here, the apparent "over-complexity" of the J2EE Specification and its associated

technologies becomes more appropriate, because with complexity comes power (and flexibility).

Portals, for example, frequently fall into this category, as they have a tendency to have need for

multiplicity at all three layersPresentation, in that the portal is often bringing

together different web applications from all across the company (or departments, or different

companies, maybe even different mob families), Business Logic, in that sometimes a given "portlet"

will want or need to call functionality exposed by a different portlet's back-end, and Data Access, in

that most portlets have their own database (or set of databases, just to make things more interesting)

against which they need to interact, but more interestingly, often a given user's session needs to

track in-progress information even as the user moves back and forth between the various portlets. In

a lot of ways, the portal and its associated portlets is the epitome of the enterprise application.

8/10/2019 j2ee1.pdf

7/9

"In a lot of

ways, the

portal and

its

associated

portlets is

the epitomeof the

enterprise

application."

Where Does That Leave Us?

This sort of categorization is nice enough in itself, and certainly keeps

technology philosophers occupied for a little while longer, but what, precisely,

does that have to do with building enterprise Java applications today?

First and foremost, it's important for enterprise Java developers to figure out,

as quickly as possible, which of the above five kinds of applications they'rebeing asked to build. If it's a traditional stovepipe system, the choice of

technology isn't as crucial as it will be for any of the other four. When the Web

services question comes up, recognize it as another Presentation layer

(meaning now you're looking at a jewel app) and not simply as an extension of

your Model objects used between the Struts code and the Business Logic. In

fact, in a lot of ways, the Model-View-Controller pattern is part of the Presentation layer itself, and

isn't something that stretches into the Business Logic layer, since doing an effective "different"

Presentation layer will typically require that we make different choices about how we interact with the

back-end, such as (in the case of Web service) leaving the "object-oriented" nature of the system

behind.

When the question of multiple database or other back-ends come up, think about failure atomicity

and the need for distributed transactions to achieve that atomicity, and the failover implications of

having a good hot-swappable layer of indirection for accessing resources. When integration between

existing systems becomes an issue, remember that there are more options than just Web services

(although the Web service approach is quickly becoming viable and more assumed to be the norm),

and keep in mind messaging-driven systems as well as the possibility of putting Business Logic into

the database itself to make it more accessible to other platforms needing to integrate with the

system.

Remember that J2EE is only a means to an end, and that to be dogmatic about any technology is

usually to miss the point of the technology as a whole. Don't look to use EJB on stovepipe systems,

for example, since EJB's principal focus is on transactional processing (and, in particular two-phase

commit transactional processing, which is expensive but necessary to obtain atomicity across two or

more resources as part of the same transaction), but don't neglect its use when the aggregator

application rears its head at you. Don't try to code everything as a session bean when the

asynchronous nature of JMS (and message-driven beans, when transactional processing is required)

better serves the purpose. And so on.

Second, make sure to always keep in mind precisely what the application's performance and

scalability goals are (see my book Effective Enterprise Java). While this is always important for any

application written in any language, it's even more so in the enterprise Java space, precisely because

of the wide array of technology choices of available to the enterprise Java developer. Does your

system need to deliver sub-second responses on every user action? This goal will be hard for a

browser-based application to meet, particularly across a WAN, since it often takes about a second for

the HTML browser to process an even moderately-complicated HTML page; perhaps a better

approach would be to consider a "rich client" front-end, delivered via JavaWebStart, so as to keep

8/10/2019 j2ee1.pdf

8/9

Next Steps

Bookmark: The Mastering

J2EE Application Development

Series: Join top J2EE experts

over the next 12 weeks as they

present techniques to help you

develop, debug, and deployJ2EE applications and web

services quickly and easily.

Oracle JDeveloper 10g

Reviewer's Guide: Learn how

to use Oracle JDeveloper 10g

to develop J2EE applications

with this step-by-step guided

tour.

Get started with Oracle

JDeveloper 10g: Use the

resources on this link to get

started with Oracle JDeveloper

10g.

Jump Start your J2EE

deployment with OC4J 10g(J2EE 1.4 compatible): Get up

to speed with the new

capabilities available in the

OC4J 10g Developer Preview

Oracle TopLink: Learn how

Toplink provides a highly

flexible and productive

mechanism for storing Java

objects and Enterprise JavaBeans (EJBs) in relational

database tables

Downloads

Oracle JDeveloper 10g

Oracle Containers for

J2EE

the amount of data traveling across the wire as small as

possible, and the response time once that data is received as

short as possible (thus avoiding the need to parse the

presentation elements).

Need to reach a forecasted 10 million users all across the

Internet? The user interface definitely needs to change,

thenJava's lack of ubiquity on the average consumer's PC

makes WebStart impractical in such situations, and perhaps an

applet or traditional HTML becomes more appropriate.

However, scaling to this number of users means that

developers need to pay careful attention to the response time

per each request at high loads, and perhaps built the user

interface differently to avoid making frequent round-trips back

to the server. And so on.

Third, keep in mind that the Java developer's toolset is

constantly evolving, and much of the work over the last half-

decade has been in the direction of the J2EE space, looking

for ways to make it simpler and easier to define J2EE

components. This area is one where a large commercial

vendor has an advantage over an open-source project, in that

the vendor can create a complete end-to-end development

experience around their commercial offerings, where an open-

source project has a tendency only to scratch the itch as far as

the development team's experience is concerned, and then

stop. Witness some of the new features coming in Oracle ADF

compared with trying to build a JSF application in Eclipse, for

example. Or look at defining a Web service in JDeveloperagainst writing the .wsdd files in Axis. The tools are getting

better, and we can only expect this trend to continue, because

it's in the vendors' best interests to keep it up.

"The tools

are getting

better, and

we can onlyexpect this

trend to

continue,

because it's

in the

vendors'

best

Last, but not least, keep an eye on this

space for future articles in this series,

which will cover topics ranging from

modeling and design to the art ofdebugging to optimizing/profiling your

code (which will be much easier now that

you've defined those performance and

scalability goals).

Most important, relax. Life's too short.

Conclusion

http://www.oracle.com/technology/pub/articles/masterj2ee/index.htmlhttp://www.oracle.com/technology/pub/articles/masterj2ee/index.htmlhttp://www.oracle.com/technology/pub/articles/masterj2ee/index.htmlhttp://www.oracle.com/technology/products/jdev/collateral/papers/10g/reviewer/reviewerguide.htmlhttp://www.oracle.com/technology/products/jdev/collateral/papers/10g/reviewer/reviewerguide.htmlhttp://www.oracle.com/technology/products/jdev/collateral/papers/10g/reviewer/reviewerguide.htmlhttp://www.oracle.com/technology/products/jdev/collateral/newtojdev.htmlhttp://www.oracle.com/technology/products/jdev/collateral/newtojdev.htmlhttp://www.oracle.com/technology/products/jdev/collateral/newtojdev.htmlhttp://www.oracle.com/technology/tech/java/oc4j/1003/how_to.htmlhttp://www.oracle.com/technology/tech/java/oc4j/1003/how_to.htmlhttp://www.oracle.com/technology/tech/java/oc4j/1003/how_to.htmlhttp://www.oracle.com/technology/tech/java/oc4j/1003/how_to.htmlhttp://www.oracle.com/technology/products/ias/toplink/index.htmlhttp://www.oracle.com/go/?&Src=1952635&Act=33http://www.oracle.com/go/?&Src=1952635&Act=33http://www.oracle.com/technology/tech/java/oc4j/1003/content_preview.htmlhttp://www.oracle.com/technology/tech/java/oc4j/1003/content_preview.htmlhttp://www.oracle.com/technology/tech/java/oc4j/1003/content_preview.htmlhttp://www.oracle.com/technology/tech/java/oc4j/1003/content_preview.htmlhttp://www.oracle.com/go/?&Src=1952635&Act=33http://www.oracle.com/technology/products/ias/toplink/index.htmlhttp://www.oracle.com/technology/tech/java/oc4j/1003/how_to.htmlhttp://www.oracle.com/technology/tech/java/oc4j/1003/how_to.htmlhttp://www.oracle.com/technology/tech/java/oc4j/1003/how_to.htmlhttp://www.oracle.com/technology/products/jdev/collateral/newtojdev.htmlhttp://www.oracle.com/technology/products/jdev/collateral/newtojdev.htmlhttp://www.oracle.com/technology/products/jdev/collateral/papers/10g/reviewer/reviewerguide.htmlhttp://www.oracle.com/technology/products/jdev/collateral/papers/10g/reviewer/reviewerguide.htmlhttp://www.oracle.com/technology/pub/articles/masterj2ee/index.htmlhttp://www.oracle.com/technology/pub/articles/masterj2ee/index.htmlhttp://www.oracle.com/technology/pub/articles/masterj2ee/index.html

8/10/2019 j2ee1.pdf

9/9

Oracle TopLink

Oracle BPEL Process

Manager

Java Object Cache

Oracle Workflow for

Java

Oracle Application

Server Portal

interests to

keep it up."While the enterprise Java world cansometimes seem like a bewildering forest

of specifications, implementations, de

facto standards and frameworks that seem to follow flavor-of-

the-month favoritism, take a deep breath and realize that for

any of the five types of applications, any of the available Java/

J2EE technologies can be made to work (and work well).

Ted Neward[ted@neward.net] is a consultant, mentor,

speaker, author and all-around geek who specializes in enterprise Java/J2EE, Web service and .NET

systems, with particular focus on interoperability between J2EE and .NET.

Copyright 2005, Oracle. All Rights Reserved.

http://www.oracle.com/technology/products/ias/toplink/preview/10.1.3dp3/index.htmlhttp://www.oracle.com/technology/products/ias/bpel/index.htmlhttp://www.oracle.com/technology/products/ias/bpel/index.htmlhttp://www.oracle.com/technology/products/ias/joc/index.htmlhttp://www.oracle.com/technology/products/ias/workflow/index.htmlhttp://www.oracle.com/technology/products/ias/workflow/index.htmlhttp://www.oracle.com/technology/products/ias/portal/index.htmlhttp://www.oracle.com/technology/products/ias/portal/index.htmlmailto:ted@neward.netmailto:ted@neward.nethttp://www.oracle.com/technology/products/ias/portal/index.htmlhttp://www.oracle.com/technology/products/ias/portal/index.htmlhttp://www.oracle.com/technology/products/ias/workflow/index.htmlhttp://www.oracle.com/technology/products/ias/workflow/index.htmlhttp://www.oracle.com/technology/products/ias/joc/index.htmlhttp://www.oracle.com/technology/products/ias/bpel/index.htmlhttp://www.oracle.com/technology/products/ias/bpel/index.htmlhttp://www.oracle.com/technology/products/ias/toplink/preview/10.1.3dp3/index.html