288 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
9. Generate the TraderSPInterfaceProxy class by right-clicking the process
interface, TraderSystemProcess_TraderSPInterface_JMS.wsdl, and selecting
Enterprise Services
→ Generate Service Proxy.
10.Create a proxy object of type Client stub and select all operations that are
defined in the WSDL interface description.
9.3.3 Deploying BPEL processes
When WebSphere Studio Application Developer Integration Edition generates
deploy code, an EJB module including the BPEL process and a number of other
artifacts is created. The EJB module is added to an Enterprise Application
archive. To run and debug the BPEL process, you must install this Enterprise
Application archive on a WebSphere Business Integration Server Foundation
test server.
You can configure a test server in WebSphere Studio Application Developer
Integration Edition from the server perspective.
1. In the Server Configuration view, right-click and select New
→ Server and
Server Configuration.
2. Enter a name for the server and select Integration Test Environment as the
server type.
3. Add the Enterprise Application, including the BPEL process, to the server by
right-clicking the server and selecting Add and remove projects.
4. Deploy the applications to the server by selecting Publish.
To run the BPEL process in the test environment of WebSphere Studio
Application Developer Integration Edition, no specific configuration of the server
is required. If you deploy interruptible, long-running processes, select Create
tables and data sources before you start the server. For long-running
processes, entity beans are needed that require definition and setup of database
tables and the configuration of a DataSource. You can create process instances
using the business process Web client. Start the client by selecting Launch
Business Process Web Client.
If you wish to deploy and run the processes using a standalone WebSphere
Business Integration Server Foundation installation, configuration and setup of
the process engine is required.
9.4 Qualities of service for business processes
This section focuses on non-functional requirements. Non-functional
requirements such as security and high-availability have been described for the
Chapter 9. Integration into business processes 289
BPEL implementation from IBM in various white papers and Redbooks. The
following sections address two other important requirements: transaction support
and usability of technology and tools.
9.4.1 Transaction support
In 9.1.3, “Deploying and running business processes” on page 246, we introduce
the transactional support in the BPEL process engine of WebSphere Business
Integration Server Foundation. BPEL business processes are atomic
transactions if the process is short-running and non-interruptible. In this case,
service invocations are part of the global process transactions. If services
support transactions, for example EJB invocations and J2C-based services,
technical rollback using the XA protocol is performed in case of failures.
If BPEL processes are long-running and interruptible, the process consists of a
series of single transactions, typically including one service invocation. For
long-running processes there is no transactional context spanning the whole
business process. Instead, WebSphere Business Integration Server Foundation
introduces the notation of compensation to undo activities in case of failures.
Compensation requires that services functions can be undone. For instance, a
log record that was created in a database in the beginning of process execution
can be deleted later if service invocation of another function fails. An e-mail that
was sent to confirm a client’s order cannot be withdrawn and deleted in case
later in the process it is detected that the order item is out of stock. A possible
undo action would be to send another e-mail informing the customer that the item
is no longer available.
Compensations is initiated if faults occur in a business process. Faults are
indicated by an exception that is thrown by an activity or another business
process that are invoked in the process. Exceptions have to be specified in the
WSDL service description of the service or business process. To introduce
compensation in a BPEL process the following tasks have to be performed:
???? Add exceptions to the WSDL description of the operations that are used to
invoke the service or business process.
???? Add fault handlers for activities and business processes to catch or rethrow
exceptions.
???? Enable compensation for the business process by setting the Compensation
Sphere attribute to Required.
???? Select undo operations for activities that have to be invoked if compensation
is performed.
290 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
For our simple scenario, the business processes did not require compensation.
For the trader system process, however, we identified the need for defining a
transactional context that spans multiple service invocations. We extended the
design of the system process to include an activity that logs the sending of the
request message to the EIS component in a database. We implemented the log
service using an entity and session EJBs. Figure 9-33 shows the extended
system process.
Figure 9-33 Trader system process including logging of the EIS request message
Log and Send activities are tightly coupled because you only want to create the
log record if the message was successfully taken over by the MOM. On the other
hand, if the request cannot be recorded because of a database failure, the
message should not be sent, and the exception handling is needed.
WebSphere Business Integration Server Foundation allows the specification of
transactional behavior of activities in a long-running process. In the Server tab
Chapter 9. Integration into business processes 291
depicted in Figure 9-33 on page 290 the options are shown. The Transactional
behaviour field provides four choices:
???? Commit Before
Use this setting if your activity must be committed immediately after it has
completed. This activity tolerates being in a transaction with other activities
that precede it.
???? Commit After
Use this setting if the transactions that precede it must be fully committed
before it can begin. This activity tolerates being in a transaction with other
activities that follow it.
???? Participates
Use this setting if this activity does not require a commit to occur either before
or after it, and where it can coexist within a transaction where one or more
other activities are invoked.
???? Requires Own
Use this setting when this activity must be isolated within its own transaction.
By selecting these options for multiple activities correctly, blocks of activities can
be defined in a long-running BPEL process that share the transactional context.
If the service supports the XA protocol, for example EJBs interacting with a
relational database or sending messages via WebSphere MQ, technical rollback
of invocations is possible.
9.4.2 Usability of BPEL technology and tools
A BPEL-based business process is a series of business-related activities that are
invoked in a specific sequence to achieve a business goal. In BPEL, a process is
composed of partners, activities, elements, and variables.
???? The partners are the external users or services that interact with the process.
???? The activities are the individual business tasks within the process that
compose the larger business goal.
???? The elements supplement activities and assist them in accomplishing their
tasks. They are nested within the activities with which they interact.
???? The variables store the messages that are passed between these activities
and partners.
292 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
BPEL tool set
Using WebSphere Studio Application Developer Integration Edition, you can
assemble processes in a graphical tooling environment, called the BPEL process
editor, and deploy it to a separate run-time environment that executes it.
Process editor
The Process editor is a graphical programming environment that you use to
visually create and manipulate business processes. The BPEL-based Process
editor displays a visual representation of an instance of the Business Process
Execution Language. It builds upon the existing functionality of the language and
adds a number of useful extensions like Java snippets and Staff activities.
Using the Process editor is almost like creating a new Graphical User Interface
(GUI) panel using widgets from a pallet. When you create a GUI panel, you
typically drag-and-drop your widgets onto a panel, align them, set custom
properties for the GUI widgets, and add event handling.
With the Process editor, you select activities from a palette which you drop onto a
canvas. You can then set custom properties for the activities in the details area of
your Process editor and link your activities together using control links, if you
have a flow-based BPEL process. So, it would appear that creating a new
business process using the Process editor is almost like creating a new GUI
panel, using the Visual Editor for Java in WebSphere Studio Application
Developer.
Having a graphical view of a business processes will revolutionize the way you
build and interact with your business process. However, you must be aware that
there are a lot of artifacts and components generated by the Process editor,
especially when you generate deploy code.
In a multi-developer, multi-project type of environment you must consider how
you want to manage, control and maintain all of the components, projects and
artifacts being produced behind the scenes. For example, if you are working with
Rational Clear Case and you want to generate deploy code from a process that
is under the control of Clear Case, confirm that all of the relevant files have been
checked out of the repository or else the generation will fail.
The Process editor generates a lot of artifacts behind the scenes, and it also
depends on a other artifacts from other services or business processes in other
projects. Carefully consider how you want to approach, manage, and maintain
such a development environment between multiple developers or multiple
project teams.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.