Building SOA-Based Composite Applications Using NetBeans IDE 6
Composite applications aid businesses by stitching together various
componented business capabilities. In the current enterprise scenario,
empowering business users to react quickly to the rapidly changing business
environment is the top most priority. With the advent of composite applications
the 'reuse' paradigm has moved from the technical aspect to the business
aspect. You no longer re-use a service but re-use a business process. Now,
enterprises can define their own behaviors optimized for their businesses through
metadata and flows. This business process composition has become
increasingly important for constructing business logic.
The ability of composite applications to share components between them nullifies
the distinction between actual applications. Business users should be able to
move between the activities they need to do without any actual awareness that
they are moving from one domain to another.
The composite application design enables your company to combine multiple
heterogeneous technologies into a single application, bringing key application
capability within reach of your business user. Enterprises creating richer
composite applications by leveraging existing interoperable components increase
the development organization's ability to respond quickly and cost-effectively to
emerging business requirements. While there are many vendors offering various
graphical tools to create composite applications, this book will focus on
OpenESB and NetBeans IDE for designing and building composite applications.
This book introduces basic SOA concepts and shows how you can use
NetBeans and OpenESB tools to design and deploy a composite application.
After introducing the SOA concepts, you are introduced to various NetBeans
Editors and aids that you need to understand and work with to design a
composite application. The last part of the book deals with a full fl edged
incremental example on how you can build a complex composite application with
necessary screen shots accompanied by the source code available on the
website.
What This Book Covers
Chapter 1 introduces SOA and BPEL to the readers with simple examples and
gives an overview of the JBI components and runtime required to build
composite applications. This chapter also gives you an overview of the need for
SOA-based applications in companies by depicting an example of an imaginary
AirlinesAlliance system.
Chapter 2 shows you how you can quickly setup NetBeans IDE and other
runtime environments including OpenESB runtime and BPEL engine. There are
many software/tools mentioned in this chapter that you need to download and
configure to get started building composite applications using NetBeans.
Chapter 3 provides an overview of Java Business Integration (JBI) and the
Enterprise Service Bus (ESB). You will learn about JBI Service Engines and how
they are supported within the NetBeans IDE.
Chapter 4 introduces JBI Binding Components and how they provide protocol
independent communication between JBI components. You will also learn about
the support that the NetBeans IDE provides for Binding Components.
Chapter 5 introduces the NetBeans BPEL Designer that comes bundled with the
NetBeans IDE. You will also be introduced to the graphical tools/wizards and
palettes available for creating BPEL files.
Chapter 6 provides an overview of WSDL and how WSDL documents are
formed. You will learn about the use of WSDL in enterprise applications and the
WSDL editor within the NetBeans IDE.
Chapter 7 covers the XML schema designer and shows how it aids rapid
development and testing of XML schema documents.
Chapter 8 provides you an overview of the Intelligent Event Processor (IEP)
module and the IEP Service Engine that can be acquired from the OpenESB
software bundle. This chapter also shows the need for an event processing tool
through simple composite application examples.
Chapter 9 provides details of fault handling within a BPEL process and shows
how these can be managed within the NetBeans IDE by using graphical tools.
Chapter 10 shows you how you can build simple to complex composite
applications and BPEL processes using the NetBeans IDE. The examples in this
chapter are divided into several parts and the source code for all parts is
available in the code bundle.
Chapter 11 gives you the overall picture of the composite application and the
need for a composite application to deploy your BPEL processes. The composite
application support provided in NetBeans IDE comes with a visual editor for
adding and configuring WSDL ports and JBI modules.
Service Engines
In Chapter 1, we introduced the concept of SOA applications, and introduced
BPEL processes and JBI applications. To gain a greater understanding of these
concepts and to enable us to develop enterprise level SOA applications, we need to
understand JBI in further depth, and how JBI components can be linked together.
This chapter will introduce the JBI Service Engine and how it is supported within the
NetBeans Enterprise Pack.
In this chapter, we will discuss the following topics:
- Need for Java Business Integration (JBI)
- Enterprise Service Bus
- Normalized Message Router
- Introduction to Service Engines
- NetBeans Support for Service Engines
- BPEL Service Engine
- Java EE Service Engine
- SQL Service Engine
- IEP Service Engine
- XSLT Service Engine
Need for Java Business Integration (JBI)
To have a good understanding of Service Engines (a specific type of JBI component),
we need to first understand the reason for Java Business Integration.
In the business world, not all systems talk the same language. They use different
protocols and different forms of communications. Legacy systems in particular can
use proprietary protocols for external communication. The advent and acceptance of
XML has been greatly beneficial in allowing systems to be easily integrated, but XML
itself is not the complete solution.
When some systems were first developed, they were not envisioned to be able
to communicate with many other systems; they were developed with closed
interfaces using closed protocols. This, of course, is fine for the system developer,
but makes system integration very difficult. This closed and proprietary nature
of enterprise systems makes integration between enterprise applications very
difficult. To allow enterprise systems to effectively communicate between each other,
system integrators would use vendor-supplied APIs and data formats or agree on
common exchange mechanisms between their systems. This is fine for small short
term integration, but quickly becomes unproductive as the number of enterprise
applications to integrate gets larger. The following figure shows the problems with
traditional integration.
As we can see in the figure, each third party system that we want to integrate with
uses a different protocol. As a system integrator, we potentially have to learn new
technologies and new APIs for each system we wish to integrate with. If there are
only two or three systems to integrate with, this is not really too much of a problem.
However, the more systems we wish to integrate with, the more proprietary code we
have to learn and integration with other systems quickly becomes a large problem.
To try and overcome these problems, the Enterprise Application Integration (EAI)
server was introduced. This concept has an integration server acting as a central
hub. The EAI server traditionally has proprietary links to third party systems, so the
application integrator only has to learn one API (the EAI server vendors). With this
architecture however, there are still several drawbacks. The central hub can quickly
become a bottleneck, and because of the hub-and-spoke architecture, any problems
at the hub are rapidly manifested at all the clients.
Enterprise Service Bus
To help solve this problem, leading companies in the integration community
(led by Sun Microsystems) proposed the Java Business Integration Specification
Request (JSR 208) (Full details of the JSR can be found at http://jcp.org/en/jsr/
detail?id=208). JSR 208 proposed a standard framework for business integration
by providing a standard set of service provider interfaces (SPIs) to help alleviate the
problems experienced with Enterprise Application Integration.
The standard framework described in JSR 208 allows pluggable components to be
added into a standard architecture and provides a standard common mechanism for
each of these components to communicate with each other based upon WSDL. The
pluggable nature of the framework described by JSR 208 is depicted in the following
figure. It shows us the concept of an Enterprise Service Bus and introduces us to the
Service Engine (SE) component:
JSR 208 describes a service engine as a component, which provides business
logic and transformation services to other components, as well as consuming
such services. SEs can integrate Java-based applications (and other resources), or
applications with available Java APIs.
Service Engine is a component which provides (and consumes) business
logic and transformation services to other components. There are
various Service Engines available, such as the BPEL service engine
for orchestrating business processes, or the Java EE service engine for
consuming Java EE Web Services. We will discuss some of the more
common Service Engines later in this chapter.
The Normalized Message Router
As we can see from the previous figure, SE's don't communicate directly with each
other or with the clients, instead they communicate via the NMR. This is one of the
key concepts of JBI, in that it promotes loose coupling of services.
So, what is NMR and what is its purpose? NMR is responsible for taking messages
from clients and routing them to the appropriate Service Engines for processing.
(This is not strictly true as there is another standard JBI component called the Binding
Component responsible for receiving client messages. Binding Components are
discussed in Chapter 4. Again, this further enhances the support for loose coupling
within JBI, as Service Engines are decoupled from their transport infrastructure).
NMR is responsible for passing normalized (that is based upon WSDL) messages
between JBI components. Messages typically consist of a payload and a message
header which contains any other message data required for the Service Engine to
understand and process the message (for example, security information). Again, we
can see that this provides a loosely coupled model in which Service Engines have no
prior knowledge of other Service Engines. This therefore allows the JBI architecture
to be flexible, and allows different component vendors to develop standard
based components.
Normalized Message Router enables technology for allowing messages to
be passed between loosely coupled services such as Service Engines.
The figure below gives an overview of the message routing between a client
application and two service engines, in this case the EE and SQL service engines.
In this figure, a request is made from the client to the JBI Container. This request
is passed via NMR to the EE Service Engine. The EE Service Engine then makes
a request to the SQL Service Engine via NMR. The SQL Service Engine returns a
message to the EE Service Engine again via NMR. Finally, the message is routed back
to the client through NMR and JBI framework. The important concept here is that
NMR is a message routing hub not only between clients and service engines, but also
for intra-communication between different service engines.
The entire architecture we have discussed is typically referred to as an Enterprise
Service Bus.
Enterprise Service Bus (ESB) is a standard-based middleware architecture
that allows pluggable components to communicate with each other via a
messaging subsystem.
Now that we have a basic understanding of what a Service Engine is, how
communication is made between application clients and Service Engines, and
between Service Engines themselves, let's take a look at what support the NetBeans
IDE gives us for interacting with Service Engines. |
