There are no silver bullets for the perils of architecting software
systems, at least not for e-commerce applications. J2EE won't address
all the design and architecture needs for you, but does this imply
that J2EE is not adequate for typical e-commerce application development?
In order to answer this question, let us consider the goals of J2EE. The
principal goal of J2EE is to specify a platform — one that can be
used to build distributed, object-oriented, enterprise applications. As we
discussed in the previous chapter, what J2EE provides is a component model,
and a core infrastructure. Its programming model includes Java servlets,
JSP pages, beans and tags to address web application development needs, and
EJBs to address distributed component development needs. The infrastructure
includes several APIs such as JTA, JNDI, JMS, JDBC and so on, which are
well integrated within the platform. The platform also provides the runtime
support through web and EJB containers for deploying and managing J2EE
applications.
Does J2EE specify any architecture for enterprise applications? Although
the term "architecture" is used to refer to "the structure" or "structural
views" of software, an architecture is (in simple terms) what tells you how
to structure or organize various programs (whether JSP pages, or EJBs or
other classes) of an application in order to implement the business use
cases and other facilities. Several proponents and adapters of J2EE imply
that J2EE does specify architecture for applications. However, that is not
the case. J2EE does not go beyond specifying the programming model, the
infrastructure, and the runtime. This leaves the application developer, as
always, to make the important decisions about architecture, based on their
specific business and technical requirements.
In this chapter, we shall address certain issues that affect the
architecture of an e-commerce application whether it's a stand-alone
application or one involving integration. Note that we will not try to
develop various architectures in this chapter; instead, our focus will be
on identifying certain styles applicable under different scenarios.
Depending on specific application needs, you might find that your
requirements can be addressed by one of the styles discussed in this
chapter, or you may construct your own by extending the styles suggested in
this chapter.
The following topics will be covered in this chapter:
- Component granularity
- Component interfaces
- Transactions in e-commerce applications
- Modes of connectivity
In this chapter, the phrase "distributed component" is used to mean an EJB
in J2EE, and a generic term "client application" to mean all types of
clients — from web clients (such as servlets and JSP pages), to
stand-alone GUI-driven clients, to external applications. Although it is
possible to use other relevant non-Java/non-J2EE technologies here, such
technologies are excluded from this particular discussion since you'll be
using Java and J2EE based technologies in the rest of this book.
Component Granularity
With component developers in the J2EE world, granularity is one of
first design questions. Granularity is how clients perceive components. In
the case of components representing data (such as entity beans),
granularity relates to whether clients see the data as large chunks or as
simple attributes. In the case of components representing business logic
(such as session beans), do clients see moderately complex business
processes, or simple operations? In both cases, if your answer points to
large data or complex logic, you can classify such a component to be
coarse-grained. If the client only sees small data or simple logic,
it is said to be fine-grained.
There are several questions related to granularity. Should you develop a
single bean for the entire order management system, or should you develop
it into four beans, or just a simple object for the order management? What
are the guidelines? Are there any tradeoffs? The answers to such questions
cannot be definitive. Perhaps, in some of the applications, these questions
may not matter at all. In certain other systems, the answers to such
questions may greatly affect the overall application complexity,
maintainability and performance. Nonetheless, it is important to consider
the question of granularity during the design time.
Abstraction
Unlike other distributed technologies such as CORBA, J2EE and EJBs provide
a very high-level of abstraction of the underlying distributed technology.
This is true for both clients and bean developers alike. The abstraction is
so strong that the difference between an object that can be referenced
locally and a distributed component (an EJB) is very marginal.
The aim of shielding the developers from the underlying distribution and other system-level issues
has been one of the goals of J2EE.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
