responses. JSP pages are
text-based documents that execute as servlets but allow a more natural approach
to creating static content.
What is the container? - Containers are the interface between a component and the
low-level platform specific functionality that supports the component. Before a
Web, enterprise bean, or application client component can be executed, it must
be assembled into a J2EE application and deployed into its container.
What are container services? - A container is a runtime support of a system-level entity.
Containers provide components with services such as lifecycle management,
security, deployment, and threading.
What is the web container? - Servlet and JSP containers are collectively referred to as Web
containers. It manages the execution of JSP page and servlet components for
J2EE applications. Web components and their container run on the J2EE server.
What is Enterprise JavaBeans
(EJB) container? - It manages the execution of
enterprise beans for J2EE applications.
Enterprise beans and their container run on the J2EE server.
What is Applet container? - IManages the execution of applets. Consists of a Web browser and
Java Plugin running on the client together.
How do we package J2EE components? - J2EE components are packaged separately and bundled into a J2EE
application for deployment. Each component, its related files such as GIF and
HTML files or server-side utility classes, and a deployment descriptor are
assembled into a module and added to the J2EE application. A J2EE application
is composed of one or more enterprise bean,Web, or application client component
modules. The final enterprise solution can use one J2EE application or be made
up of two or more J2EE applications, depending on design requirements. A J2EE
application and each of its modules has its own deployment descriptor. A
deployment descriptor is an XML document with an .xml extension that describes
a component’s deployment settings.
What is a thin client? - A thin client is a lightweight interface to the application that
does not have such operations like query databases, execute complex business
rules, or connect to legacy applications.
What are types of J2EE
clients? - Following are the types of J2EE clients:
o Applets
o Application clients
o Java Web Start-enabled rich clients, powered by Java Web Start
technology.
o Wireless clients, based on Mobile Information Device Profile (MIDP)
technology.
What is deployment
descriptor? - A deployment descriptor is an
Extensible Markup Language (XML) text-based file with an .xml extension that
describes a component’s deployment settings. A J2EE application and each of its
modules has its own deployment descriptor. For example, an enterprise bean
module deployment descriptor declares transaction attributes and security
authorizations
for an enterprise bean. Because deployment descriptor information is
declarative, it can be changed without modifying the bean source code. At run
time, the J2EE server reads the deployment descriptor and acts upon the
component accordingly.
What is the EAR file? - An EAR file is a standard JAR file with an .ear extension, named
from Enterprise ARchive file. A J2EE application with all of its modules is
delivered in EAR file.
What is JTA and JTS? - JTA is the abbreviation for the Java Transaction API. JTS is the
abbreviation for the Jave Transaction Service. JTA provides a standard
interface and allows you to demarcate transactions in a manner that is
independent of the transaction manager implementation. The J2EE SDK implements
the transaction manager with JTS. But your code doesn’t call the JTS methods
directly. Instead, it invokes the JTA methods, which then call the lower-level
JTS routines. Therefore, JTA is a high level transaction interface that your
application uses to control transaction. and JTS is a low level transaction
interface and ejb uses behind the scenes (client code doesn’t directly interact
with JTS. It is based on object transaction service(OTS) which is part of
CORBA.
What is JAXP? - JAXP stands for Java API for XML. XML is a language for
representing and describing text-based data which can be read and handled by
any program or tool that uses XML APIs. It provides standard services to
determine the type of an arbitrary piece of data, encapsulate access to it,
discover the operations available on it, and create the appropriate JavaBeans
component to perform those operations.
What is J2EE Connector? - The J2EE Connector API is used by J2EE tools vendors and system
integrators to create resource adapters that support access to enterprise
information systems that can be plugged into any J2EE product. Each type of
database or EIS has a different resource adapter. Note: A resource adapter is a
software component that allows J2EE application components to access and
interact with the underlying resource manager. Because a resource adapter is
specific to its resource manager, there is typically a different resource
adapter for each type of database or enterprise information system.
What is JAAP? - The Java Authentication and Authorization Service (JAAS) provides
a way for a J2EE application to authenticate and authorize a specific user or
group of users to run it. It is a standard Pluggable Authentication Module
(PAM) framework that extends the Java 2 platform security architecture to
support user-based authorization.
What is Java Naming and
Directory Service? - The JNDI provides naming and
directory functionality. It provides applications with methods for performing
standard directory operations, such as associating attributes with objects and
searching for objects using their attributes. Using JNDI, a J2EE application
can store and retrieve any type of named Java object. Because JNDI is
independent of any specific implementations, applications can use JNDI to
access multiple naming and directory services, including existing naming and
directory services such as LDAP, NDS, DNS, and NIS.
What is Struts? - A Web page development framework. Struts combines Java Servlets,
Java Server Pages, custom tags, and message resources into a unified framework.
It is a cooperative, synergistic platform, suitable for development teams,
independent developers, and everyone between.
How is the MVC design
pattern used in Struts framework? - In the MVC
design pattern, application flow is mediated by a central Controller. The
Controller delegates requests to an appropriate handler. The handlers are tied
to a Model, and each handler acts as an adapter between the request and the
Model. The Model represents, or encapsulates, an application’s business logic
or state. Control is usually then forwarded back through the Controller to the
appropriate View. The forwarding can be determined by consulting a set of
mappings, usually loaded from a database or configuration file. This provides a
loose coupling between the View and Model, which can make an application
significantly easier to create and maintain. Controller: Servlet controller
which supplied by Struts itself; View: what you can see on the screen, a JSP
page and presentation components; Model: System state and a business logic
JavaBeans.
A great deal has transpired in the Java space
since we first attended Java One in 1998. The latest batch of Java 2 Platform
Enterprise Edition (J2EE) 1.4 compliant application servers is strong proof of
the technological advancements that have taken place during this time period.
These server-side offerings adhere to the J2EE three-tier model, while
providing a solid foundation for deploying both Web services and
service-oriented architectures (SOAs). Regarding Web services, there are
currently two main development paths that include J2EE and .NET for creating
and deploying these types of services.
Each has garnered the support of industry
leaders. For example, J2EE has gained strong support from the Java community
(e.g., BEA, IBM, Oracle, Sun, etc.) and .NET spearheads the Web services effort
for Microsoft. While development paths may differ, the aforementioned vendors
have been strong proponents of Web services and open-standards that include
WSDL, ebXML/UDDI and SOAP.
The J2EE Multitiered Model
J2EE multitiered applications are usually
considered to be three-tiered applications because they are distributed over
three locations (client machine, J2EE server and database server or legacy
systems at the back end). It is important to note that although a J2EE application
may consist of three tiers (client tier, business tier and EIS tier) or four
tiers (client tier, Web tier, business tier and EIS tier), J2EE multitiered
applications are generally considered to be three applications. Application
logic is divided into components according to function. Accordingly, the
various application components that make up a J2EE application are installed on
different machines depending on the tier in the multitiered J2EE environment to
which the application belongs. The following are the three tiers that comprise
the J2EE multitiered model.
Advertisement
Client Machine (Client Tier)
The J2EE client tier is divided into two main
categories that include Web-based clients and application clients.
Web-based
client (a.k.a
thin client) executes in a standard Web browser such as Microsoft Internet
Explorer (IE) and Mozilla Firefox. A Web-based client is comprised of two main
parts that include: 1) dynamic Web pages containing various types of markup
languages (e.g., HTML, XML, etc.) which are generated by Web components (JSPs
and servlets) on the Web tier and 2) a Web browser which renders the pages
received from the server. Web-based clients typically do not execute complex
business rules, query databases and/or connect to legacy systems. Normally,
heavyweight operations are offloaded to Enterprise Java Beans (EJBs) executing
on the J2EE server where they may leverage the reliability, security and speed
of J2EE-server-side technologies.
Biggest Advantage: Available
on a majority of client machines (e.g., laptops, PCs, Tablet, etc.).
Biggest Disadvantage: Limited to the capabilities of HTML, JavaScript
and other related Web-scripting languages.
Application
clients are
Java applications that run in a Java virtual machine (JVM), and provide a way
for users to handle tasks that require a richer user interface (UI) that can be
provided by markup languages. Application clients can directly access EJBs
running on the business tier. Alternatively, if required, an application client
may also open an HTTP connection to establish communication with a servlet
running in the Web tier.
Biggest Advantage: Richer user
interface.
Biggest Disadvantage: Must be installed on each client machine.
Web-based and application clients have their
own distinct benefits and drawbacks that must be taken into consideration
regarding the needs and requirements of the solution being deployed (e.g., CRM,
ECMS, ERP, etc.).
While these architectures are usually kept
distinct, there is another model that has not been much utilized, but which
presents some obvious advantages in a mix of these capabilities, both internal
to the enterprise and in its external-facing modalities. These are
application-specific runtimes that can be fairly limited additional extension
profiles to existing core markup mime typed plug-ins to augment UIs that travel
with the application from the Web tier to the Web-based client, where the
functionality is optionally added to the client's Web browser for the length of
runtime required by the application to take the processing load off the server
onto the client or that can be maintained as an addition to the browser's
plug-ins.
This model is characterized by specialized
viewers that have not found their way into markup standards for Web services as
yet, such as Macromedia Flash MX which has added forms management to its
feature set along with Adobe SVG Viewer for Lifecycle forms manager.
Heretofore, this model has been widely dropped in favor of server-based
processing, where the implementation of increased capacity is more predictable
and, therefore, more economically feasible than in the client.
However, consider the recent announcement of
an Outlook standalone subset available by subscription. This is an attempt by
Microsoft to see if such a modularization will fit its evolving
software-by-subscription service strategy. If Redmond is looking into this,
others will, too. Despite the fact that the aforementioned display technologies
are not now modularized to take advantage of this model, it seems likely that,
as seen in the Microsoft experiment cited above, the modularization of
software-by-subscription or in special-purpose, short-lived extensions that
travel with their application, modularization seems inevitable.
The monolithic single-vendor solution model
seems doomed in the face of open-source software based on open, public
standards. Open-source developers already have their offerings aligned with
this modularized model, by default largely since OSS does not lend itself to
monolithic, deliberately non-interoperable proprietary systems, and with its
availability and the advantages to the business world of eliminating
single-vendor locked-in dependence, this prediction of the demise of these
unwieldy, bloated leviathans certainly looks like the handwriting on the wall
in this arena. Regardless, there is currently an excess amount of processing
power going unused on the client side, and load-balancing considerations, as we
move into an era of greater processing asset utilization (grids) will
increasingly require moving the processing load onto the client, especially if
this capacity is kept to small and optionally short-lived profiles. Also, there
is a good chance that more modular architectures will find favor in a more
mix-and-match set of software functionalities as the post-Y2K IT environment
presents the necessity of adapting to a necessarily heterogeneous systems.
J2EE Server Machine (Web Tier and
Business Tier)
In basic terms, an application server is the
middleware that acts as the medium for a company's front-end applications
through its back-end business systems. It must be able to extract core data and
present it to a variety of clients (e.g., desktops, smart cards, Web browsers,
etc.). Application servers provide developers with the capability to build and
deploy Web application logic with data access through APIs. Leading cost-type
J2EE application server offerings include BEA WebLogic 8.1, IBM WebSphere V6,
Oracle Application Server 10g and Sun Java System Application Server. In
addition, there are a number of open-source J2EE application servers currently
available that include Apache Jakarta Tomcat, JBoss and Jonas. The following
are the core components and other key supporting server-side technologies that
comprise the J2EE server machine (Web tier and business tier).
Web Tier
J2EE Web components are either pages using
JSP technology (JSP pages) or servlets.
Advertisement
JSP: Java server pages
(JSP) are text-based documents that execute as servlets. A JSP page contains
two types of text that include:
·
Static Template Data: May be expressed in any
text-based format (e.g., HTML, WML, XML, etc.).
·
JSP Elements: Determine how a page constructs
dynamic content.
Servlets: Allow users to run
Java code on the server and send HTML pages to a browser. Java servlet
technology enables developers to define HTTP-specific servlet classes. As a
result, a servlet class extends the capabilities of servers, which host
applications that are accessed by way of a request-response programming model.
Business
Tier
Business code, which is logic that solves the
requirements or needs of a business entity (e.g., banking, brokerage,
insurance, etc.) is handled by Enterprise JavaBeans (EJB) running on the
business tier. EJB may be viewed server component architecture, which conform
to the Sun EJB component model. They can be used to create a business object
and related content may be sent using Java server pages (JSPs). Furthermore, an
EJB can receive data from a client program, process it (if required) and send
it to the EIS tier for storage or retrieve data from storage, process it (if
required), and send it back to the client program. There are three types on
EJBs that include session beans, entity beans and message-driven beans, and
brief descriptions of each follow:
·
Session Bean:A session
bean implements a conversation between a client and the server side. Session
beans execute a particular business task on behalf of a single client during a
single session.
·
Entity
Bean:An
entity bean represents a business object in a persistent storage mechanism.
Examples of business objects include customers, orders and products. In the
J2EE SDK, the persistent storage mechanism is a relational database. Typically,
each entity bean has an underlying table in a relational database, and each instance
of the bean corresponds to a row in that table.
·
Message
Driven Bean:A message-driven bean is an enterprise
bean that allows J2EE applications to process messages asynchronously. It acts
as a JMS message listener, which is similar to an event listener except that it
receives messages instead of events.
One of main benefits of entity beans is that
developers do not have to write SQL code or use the JDBC API directly to
perform database access operations because the EJB container handles this task.
Database Machine (EIS Tier)
Enterprise information systems (EIS) provide
the information infrastructure that is vital to the business processes of an
enterprise. The EIS tier handles software and includes enterprise
infrastructure systems such as ERP, mainframe transactions processing, database
systems and other related legacy systems. For example, J2EE application
components may require access to EIS for database connectivity. The database
plays a critical role in the storing and retrieving of information.
A database is a collection of data that is
organized so its contents may be accessed, managed and updated. The four main
types of databases include:
·
Distributed - Can be dispersed or
replicated among different points in a network.
·
Object Oriented - Is
congruent with data defined in object classes and subclasses.
·
Relational - A tabular design in
which data is defined so that it can be organized and accessed.
·
Object
Relational -
A combination of object and relational concepts where objects are mapped to
relational databases, often used to persist EJB.
At this time, relational databases are the
most prevalent type of offering. Leading relational database vendors include
IBM, Microsoft, Oracle and Sybase. These offerings support a wide range of
solutions that include business intelligence, collaboration, multimedia and
transactions processing. The database foundation for most businesses and
organizations deploying Web services and SOAs will most likely be based on a
two-tier architecture that is comprised of agency data marts and a central data
warehouse. This type database architecture provides four primary benefits that
include 1) high-speed access, 2) the ability to expand functionality both on
the data mart and/or
the central data warehouse levels without
reengineering the core architectural topology, 3) improved security, 4) a
360-degree perspective. The key components of the two-tier architecture are:
Data Mart. The data mart acts as
the information focal point regarding the activities of a specific entity
(e.g., local office, regional official, foreign office, etc.). It employs a
modular architecture that is comprised of individual data silos that are
directly coupled and synchronized with the entities software solutions (e.g.,
CRM, ECMS, ERP, etc.). A data silo methodology allows for faster access times
because a query is only performed against a specific section of the data mart
and does not have to search the entire data mart for the targeted information.
Security is greatly improved because data silos house only information on
specific types of solutions, so access can be implemented on a finer level of
granularity. The information held in the data mart, and or data marts may then
be sent to the central data warehouse on a scheduled basis chosen by the
business or organization.
The Central Data Warehouse. The central data
warehouse acts as the main repository and focal point for all data mart
information. Each data mart is directly coupled and synchronized with the
central data warehouse. The information housed in the central data warehouse
provides the authorized user with a 360-degree perspective of the entire
workings of the enterprise. For example, this holistic view enables the
business or organizations to better leverage business intelligence tools (BI) to
look for hidden trends and other previously unknown information within the
data.
The chosen database foundation should
leverage important open-standards such as extensible markup language (XML) for
internal as well as external applications; hence, the need to create the proper
infrastructure to support this essential technology. The ability to store and
retrieve XML documents in their native format will be of paramount importance
to businesses and organizations deploying Web services and SOAs.
Over the near term, the database landscape
and the J2EE architecture that supports and relies upon it are changing
rapidly. As the expanding parameters, which are blurring the differences, of
what constitutes a thick or thin, Web-based or application client, so also in
the realm of data; the only certain demand in the marketplace is for
flexibility, adaptability and quick responses.
ADVERTISEMENT
In a recent article, we wrote on the topic of integrated
development environments (IDE), we discovered that in the midst of a burgeoning
of application server choices there has been an unexpected development of a
relatively simplified set of platforms that are organized along lines so similar
as to be nearly identical. NetBeans looks like Eclipse without the XML
emphasis. This is also true of development environments for building OWL-based
ontological resources, such as Protégé and applications such as inference engines to
build semantically viable knowledge bases out of data collections. The fact is
that this makes increasing modularization almost inevitable.
The advent of object and object-relational
databases will only accelerate this process as business learns how to optimize
the functionalities used most, especially through SOA components, which are
likely to be housed in object or object-relational database repositories. The
essence of building a competitive advantage in the near term is going to be
building the most effective market-response systems, and the key to that will
lie in organizing, accessing data with a BI toolset that quickly transforms
data into useful information for timely or critical decision making.
Example
1: Application Client Directly Accessing EJBs Running on the Business Tier
Example 2: Application CLient Using an Open HTTP Connection to
Establish Communication with a Servlet Running in th Web Tier
J2EE Development Tools
An integrated development environment or IDE
is a programming environment developed to produce reasonably standard
applications within a specific programming language or platform such as C++,
Java, Java++, C#, etc., on Windows, Linux and Macintosh operating systems. It
enables developers to more easily and consistently create applications that are
meant to satisfy specific needs and or requirements. This is facilitated
because, as much as possible, IDEs organize application-specific coding into
modules or units automatically within an overall governing structure called a
"project" as opposed to requiring a programmer to organize the myriad
code files and resources, such as DLLs, and build programs manually. These
applications share a common structure, with their various resources and
directories organized into more or less standard patterns. They are considered
integrated because the source code components are packaged in one unit for
delivery to the end user. This means that the end user only needs to click on a
setup or installer icon to install the software. These end products can be
tailored for specific versions of hardware platforms and operating systems
meant to run these applications. IDEs have become far more sophisticated during
the last three years and provide rich functionality across many languages and
technologies.
Leading Java IDE offerings include: Borland
Software Platform for J2EE, IBM WebSphere Studio V5.1.2, Oracle JDeveloper 10g,
Sun Studio Enterprise and Sybase PowerBuilder 10. There is also the ubiquitous,
now open-sourced Eclipse 3.0 platform that IBM has converted to pure XML and
can output Java, and Sun's contribution to the open source community, the
NetBeans IDE, which, while not currently devoted to pure XML, can be used with
Eclipse to reverse engineer into XML.
The Challenges
High-end cost-type J2EE application servers
support a number of core enterprise requirements, which include superior
availability, reliability, scalability and security. In addition, they provide
a wide-range of features and functions that support the needs of large-scale
environments. Typically, high-end J2EE application servers from BEA, IBM,
Oracle, Sun and Sybase range in price from $10,000 to $20,000 per-processor.
Careful assessment is required because price is not the greatest differentiator
regarding these types of middleware offerings. J2EE certification and
open-standards support should be viewed as the two most important core
elements. These factors go a long way in determining the features and functions
provided by a specific application server. For example, the Java API for
XML-based RPC (JAX-RPC) released as part of Sun's of J2EE 1.4 is used to build
Web applications and Web services, incorporating XML-based RPC functionality
according to the simple object access protocol (SOAP) 1.1 specification. While
JAX-RPC is most often associated with building Web applications on the Java
platform, it may also be used for Web services interoperability across
heterogeneous platforms and languages. For that reason, JAX-RPC can be
considered a key technology for Web services integration. As a result, business
and organizations currently face two main challenges in developing and
deploying traditional and Web services application that include 1) application
server capabilities, 2) development tool capabilities. What follows are brief
summaries of these two main challenges.
Java 2 Platform, Enterprise
Edition (J2EE) Overview
|
|
Contents
The Enterprise Java BluePrints for the J2EE platform describe the J2EE
application model and best practices for using the J2EE platform. Building
on the J2SE platform, the J2EE application model provides a simplified
approach to developing highly scalable and highly available internet or
intranet based applications.
Thanks to the J2EE application model, maybe the most interesting thing
about J2EE applications is what they don't do. That is, various
complexities inherent in enterprise applications -- transaction management,
life-cycle management, resource pooling -- are built into the platform and
provided automatically to the components it supports. Component and
application developers are free to focus on specifics such as business
logic and user interfaces.
Another advantage of the J2EE platform is that the application model
encapsulates the layers of functionality in specific types of components.
Business logic is encapsulated in Enterprise JavaBeans (EJB) components.
Client interaction can be presented through plain HTML web pages, through
web pages powered by applets, Java Servlets, or JavaServer Pages
technology, or through stand-alone Java applications. Components
communicate transparently using various standards: HTML, XML, HTTP, SSL,
RMI, IIOP, and others.
Reusable J2EE components mean competitive choices for enterprise developers
and IT organizations. The J2EE platform enables them to assemble
applications from a combination of standard, commercially available
components and their own custom components. From general business
application components to vertical market solutions, a range of
standardized J2EE functionality is available off the shelf.
This means that an e-commerce site could be built using a combination of
off-the-shelf EJB components for shopping cart behaviors, modified EJB
components for specialized customer services, and completely customized
layouts using JavaServer Pages technology that bring a unique look and feel
to the site.
This approach means faster development time, better quality,
maintainability and portability, and Web services interoperability across a
range of enterprise platforms. The bottom line benefits are increased
programmer productivity, better strategic use of computing resources, and
greater return on an organization's technology investments.
Containers
and Connectors: Hiding Complexity, Enhancing Portability
The J2EE application model divides
enterprise applications into three fundamental parts: components,
containers, and connectors. Components are the key focus of application
developers, while system vendors implement containers and connectors to
conceal complexity and promote portability.
Containers intercede between clients and components, providing services
transparently to both, including transaction support and resource pooling.
Container mediation allows many component behaviors to be specified at
deployment time, rather than in program code.
Connectors sit beneath the J2EE platform, defining a portable service API
that communicates with existing enterprise vendor offerings. Connectors
promote flexibility by enabling a variety of implementations of specific
services. In particular, connectors implementing pluggable messaging
contracts enable bidirectional communication between J2EE components and
enterprise systems.
Flexible
User Interaction
The J2EE platform provides choices for
graphical user interfaces across a company's intranet or on the World Wide
Web. Clients can run on desktops, laptops, PDAs, cell phones, and other
devices. Pure client-side user interfaces can use standard HTML and Java
applets. Support for simple HTML means quicker prototypes, and support for
a broader range of clients. Additionally, the J2EE platform supports
automatic download of the Java Plug-in to add applet support where it's
lacking. The J2EE platform also supports stand-alone Java application
clients.
For server-side generation of dynamic content, the J2EE platform supports
two types of web component technologies: Java Servlets and JavaServer Pages
(JSP). Java Servlets enable developers to easily implement server-side
behaviors that take full advantage of the power of the rich Java API.
JavaServer Pages technology combines the ubiquity of HTML with the power of
server-side dynamic content generation. The JSP 2.0 specification supports
static templates, simplified access to Java objects, and easy
extensibility.
Enterprise
JavaBeans Component Model
Enterprise JavaBeans (EJB) technology
enables a simplified approach to multitier application development,
concealing application complexity and enabling the component developer to
focus on business logic.
EJB technology gives developers the ability to model the full range of
objects useful in the enterprise by defining several types of EJB
components: session beans, entity beans, message-driven beans. Session
beans represent behaviors associated with client sessions -- for example, a
user purchase transaction on an e-commerce site. Session beans can serve as
Web service endpoints. Entity beans represent collections of data -- such
as rows in a relational database -- and encapsulate operations on the data
they represent. Entity beans are intended to be persistent, surviving as
long as the data they're associated with remains viable. Message-driven
beans allow J2EE applications to process messages asynchronously. A
message-driven bean normally acts as a JMS message listener, which is
similar to an event listener except that it receives JMS messages instead
of events. The messages may be sent by any J2EE component--an application
client, another enterprise bean, or a Web component--or by a JMS
application or system that does not use J2EE technology.
Web
Services Interoperability
The Java 2 Platform, Enterprise Edition
version 1.4 is the most complete Web services platform ever. The platform
features Web services support through the new JAX-RPC 1.1 API, which
provides service endpoints based on servlets and enterprise beans. JAX-RPC
1.1 provides interoperability with Web services based on the WSDL and SOAP
protocols. The J2EE 1.4 platform also supports the Web Services for J2EE
specification, which defines deployment requirements for Web services and
utilizes the JAX-RPC programming model. In addition to numerous Web
services APIs, the J2EE 1.4 platform also features support for the WS-I
Basic Profile 1.0. This means that in addition to platform independence and
complete Web services support, the J2EE 1.4 platform offers platform Web
services interoperability.
Expediting
Development and Deployment
Based on these flexible component
configurations, the J2EE application model means quicker development,
easier customization and greater ability to deploy powerful enterprise
applications. And, because it's based on the Java programming language,
this model enables all J2EE applications to achieve all the benefits of
Java technology: scalability, portability, and programming ease.
J2EE Application Components
The J2EE Specification describes four types of
components that can be created by a developer. Each component is a modular
software unit that is deployed within the application server and interacts
with its host environment and other components through the J2EE APIs that
are available to it.
The APIs available to the components determine the
facilities that the components have access to.
Further description of the application components:
- Applet
component: These are client-side GUI components that are
hosted by an applet container, which is typically a web browser. They have
the ability to provide a feature-rich user interface to an enterprise
application.
- Application
client component: These are Java-based programs that
can execute within a supported JVM. They offer a user interface similar to
what exists on the native client while accessing J2EE Business Tier facilities.
- Web component:
These are components that have the ability to respond to HTTP requests.
They comprise servlets, JSP pages, filters, and web event listeners:
- Servlets:
These extend aweb server’s functionality to support the dynamic processing
of application logic. Servlets can be used in any request/response
programming models but are most often used with HTTP. In this method, they
utilize data embedded within HTTP requests for input and provide resulting
output using the HTTP response, making the processing facilities of the
J2EE Platform available to the information input on the source web page.
- JavaServer
Pages:
Similar to servlets, JSP pages provide dynamic web application capability
to the J2EE Platform. JSP pages achieve this goal through the introduction
of templating functionality. A JSP page begins with HTML elements that
remain static throughout the lifetime of the page; this forms the base
template. Dynamic elements are then added through the embedding of Java
code and/or special tags within the page. It should be noted that JSP pages
are indeed converted to servlets before execution, but the intricacies of
this process are managed by the web container.
- Filters:
These components provide the ability to intercept requests by clients for
resources on a server and also responses provided to these requests by the
web container with the goal of transforming the content of either the
request or response communication. Filters provide a reusable mechanism to
handle recurring tasks such as authentication, logging, etc., that are
applicable to items within the web container.
- Web
event listeners: These are components that are created
to perform a particular function when a specific event occurs within the
web container. These components provide developers with the flexibility to
respond in a certain way when different types of web application–related
events such as the creation or invalidation of a session occurs.
Enterprise
JavaBeans components: These are server-side components that
singularly or collectively encapsulate the application logic of an
enterprise application.
EJB
technology enables rapid
and simplified development of distributed, transactional, secure, and
portable applications based on Java technology. There are three types of
EJBs defined by the specification:
Session beans: A
session bean is a server-side extension of a client that exists to service
requests made by the client. As the name implies, it simulates an
interactive session between a client and the server-based component.
Session beans exist in two forms. There are stateful session beans, which
are said to maintain a “conversational state” with a client by virtue of
retaining instance variable data on multiple method invocations. Because of
this, they are wedded to a unique client throughout the instance existence.
Stateless session beans, on the other hand, exist to service requests from
multiple clients. They perform transient services for their clients,
fulfilling whatever request is made of them and returning to their original
initialized states.
Entity beans:
Entity beans are an encapsulated representation of business objects made
available with a persistence mechanism. They represent an object to
relational mapping of the data stored within these persistence layers,
thereby facilitating the modification of the underlying business objects
while preserving referential and data integrity constraints demanded by the
specific business process.
Message-driven
beans:
These are stateless, server-side components invoked by the EJB container on
the receipt of a message in an associated JMS Queue or Topic. This
component allows the EJB
container to provide support for asynchronous
message processing.
Web Services
Just-in-time integration
The
Web Services architecture describes the principles behind the next
generation of e-business architectures, presenting a logical evolution from
object-oriented systems to systems of services. Web Services systems
promote significant decoupling and dynamic binding of components: All
components in a system are services, in that they encapsulate behavior and
publish a messaging API to other collaborating components on the network.
Services are marshaled by applications using service discovery for dynamic
binding of collaborations. Web Services reflect a new service-oriented
architectural approach, based on the notion of building applications by
discovering and orchestrating network-available services, or just-in-time integration of
applications.
With
the Web Services approach, application design becomes the act of describing
the capabilities of network services to perform a function and describing
the orchestration of these collaborators. At runtime, application execution
is a matter of translating the collaborator requirements into input for a
discovery mechanism, locating a collaborator capable of providing the right
service and orchestrating message sends to collaborators to invoke their
services. These new applications, themselves, become services, thus
creating aggregated services available for discovery and collaboration.
What are Web Services?
Web
Services are self-contained, modular applications that can be described,
published, located, and invoked over a network, generally, the Web.
The
Web Services architecture is the logical evolution of object-oriented
analysis and design, and the logical evolution of components geared towards
the architecture, design, implementation, and deployment of e-business
solutions. Both approaches have been proven in dealing with the complexity
of large systems. As in object-oriented systems, some of the fundamental
concepts in Web Services are encapsulation, message passing, dynamic
binding, and service description and querying. Fundamental to Web Services,
then, is the notion that everything is a service, publishing an API for use
by other services on the network and encapsulating implementation details.
Web Services components
Several
essential activities need to happen in any service-oriented environment:
- A
Web service needs to be created, and its interfaces and invocation
methods must be defined.
- A
Web service needs to be published to one or more intranet or Internet
repositories for potential users to locate.
- A
Web service needs to be located to be invoked by potential users.
- A
Web service needs to be invoked to be of any benefit.
- A
Web service may need to be unpublished when it is no longer available
or needed.
A
Web Services architecture then requires three fundamental operations:
publish, find, and bind. Service providers publishservices to a
service broker. Service requesters find required services using a service
broker and bind to them. These ideas are shown in
the following figure.
The
mechanism of service description is one of the key elements in a Web
Services architecture. The full description of a service for our
architecture is found in two separate documents, a Network Accessible
Service Specification Language (NASSL) document and a Well-Defined Service
(WDS) document. NASSL is an XML-based Interface Definition Language (IDL)
for network-based services, and is used to specify the operational
information for a Web Service, such as service interface, implementation
details, access protocol, and contact endpoints. A WDS document is used to
specify the nonoperational information for a service, such as service
category, service description, and expiration date, as well as business
information about the service provider, such as company name, address, and
contact information. A WDS document is complementary to a corresponding
NASSL document. Together these two documents are used to specify a full
service description that allows service requesters to locate and invoke a
service.
All
collaborations in the Web Services architecture have the possibility of
being controlled by a configurable, negotiable set of environmental
prerequisites. An environmental prerequisite is any nonfunctional component or infrastructure
mechanism that must be made operational before a service can be invoked --
for example, the use of a particular communications mechanism (HTTPS, IBM
MQSeries), or the use of a particular third-party auditing or billing
service. These components (often, themselves, implemented as services) must
be put in place before the service can actually be invoked.
A
service may support multiple possible implementations for any environmental
prerequisite it specifies. For example, the service could offer a choice of
communications layer, choice of billing service, or other option. The
service requester can then negotiate or choose which implementation to use
to satisfy the environmental prerequisite. It is through environmental
prerequisites that collaborations can be as secure, reliable, and safe as
required by the two collaborators in a Web Services architecture.
Web Services benefits
Use
of the Web Services architecture provides the following benefits:
- Promotes
interoperability by minimizing the requirements for shared
understanding
XML-based interface definition language
(NASSL), an XML-based service description (WDS) and a protocol of
collaboration and negotiation are the only requirements for shared
understanding between a service provider and a service requester. By
limiting what is absolutely required for interoperability, collaborating
Web services can be truly platform and language independent. By limiting
what is absolutely required, Web Services can be implemented using a large
number of different underlying infrastructures.
- Enables
just-in-time integration
Collaborations in Web Services are bound
dynamically at runtime. A service requester describes the capabilities of
the service required and uses the service broker infrastructure to find an
appropriate service. Once a service with the required capabilities is
found, the information from the service's NASSL document is used to bind to
it.
Dynamic service discovery and invocation
(publish, find, bind) and message-oriented collaboration yield applications
with looser coupling, enabling just-in-time integration of new applications
and services. This in turn yields systems that are self-configuring, adaptive
and robust with fewer single points of failure.
- Reduces
complexity by encapsulation
All components in Web Services are
services. What is important is the type of behavior a service provides, not
how it is implemented. A WDS document is the mechanism to describe the
behavior encapsulated by a service.
Encapsulation is key to:
- Coping
with complexity. System complexity is reduced when application
designers do not have to worry about implementation details of the
services they are invoking.
- Flexibility
and scalability. Substitution of different implementation of the same
type of service, or multiple equivalent services, is possible at
runtime.
- Extensibility.
Behavior is encapsulated and extended by providing new services with
similar service descriptions.
- Enables
interoperability of legacy applications
By allowing legacy applications to be wrappered in NASSL and WDS documents, and
exposed as services, the Web Services architecture easily enables new
interoperability between these applications. In addition, security,
middleware and communications technologies can be wrappered to participate
in a Web service as environmental prerequisites. Directory technologies,
such as LDAP, can be wrappered to act as a service broker.
Through wrappering the underlying plumbing
(communications layer, for example), services insulate the application
programmer from the lower layers of the programming stack. This allows
services to enable virtual enterprises to link their heterogeneous systems
as required (through http-based communications) and/or to participate in
single, administrative domain situations, where other communications
mechanisms (for example, MQSeries) can provide a richer level of
functionality.
Examples of this can be found in merger
situations, where the resulting enterprise must integrate disparate IT
systems and business processes. A service-oriented architecture would
greatly facilitate a seamless integration between these systems. Another
example can be found in the combination of the travel industry with pervasive
computing, when largely mainframe-based travel applications can be exposed
as services through wrappering and made available for use by various
devices in a service-oriented environment. New services can be created and
dynamically published and discovered without disrupting the existing
environment.
|
|
|
|
|
|
|
|
|
