http://www.javabeat.net/2011/04/oracle-weblogic-10-3-2-campaign/ http://www.javabeat.net/2011/04/oracle-weblogic-10-3-2-campaign/#comments Sun, 17 Apr 2011 00:01:58 +0000 krishnas http://www.javabeat.net/?p=657 Connect to us ( @twitter | @facebook )

Introduction This post is to present the steps for creating a Campaign in Weblogic Portal that illustrates some vague points about it. The campaign target is to show an advertisement in a placeholder, within some interval (start & end dates), with some goals to be reached before the end date of the campaign. Campaign Goals [...]

]]> Connect to us ( @twitter | @facebook )

Introduction

This post is to present the steps for creating a Campaign in Weblogic Portal that illustrates some vague points about it.

The campaign target is to show an advertisement in a placeholder, within some interval (start & end dates), with some goals to be reached before the end date of the campaign.

Campaign Goals

Campaign goals are set against content clicks or impressions (views) count. This count can be calculated based on the clicks/views of the specific content that is displayed in the campaign, or if the content is viewed/clicked outside the campaign. Also, the count is checked for each content count or the summation of the contents’ count in the goal.

Example Scenario

For example, a campaign is to show some advertisements on the ads area of the portal, on IPhone should display 5 different contents. Each content is displayed in its place based on the queries defined in the placeholders in the portal, content selectors or Content Presenter Portlet. The goal of the campaign is to reach 1,000,000 clicks on the 5 contents/ads. So, the goal is to check on the summation of the 5 content paths added to the campaign goal.

Campaign Target

The campaign should target females only. So in the data sync project, we create a gender property in the default profile, GroupSpace profile, and make it restricted multi-value property, with two values (male or female). Then, define a user segment that filters the users based on the gender profile property to equal “female”.

Campaign Content Action

We can now add a new scenario to the campaign, and drag the segment condition on it, then assign it to be the “females” segment. Now, we need to define the action. Here we create two actions to be performed. First, we need to place a specific content on a placeholder (suppose that the place holder by default shows the logo of the company). We drag the “place content” action, and assign a query to this action that retrieve the content to be placed and then select the place holder, that to be replaced its content with the content retrieved.

Campaign Calling Method Action

Second, we need to call a static method in a Class. When I tried this, I created a class in the Web project and I was getting an exception that the class is not found. I didn’t read carefully that I need to make this class “application-scoped” class by creating a Library Project (JAR) and add it to the EAR project, to expose all the classes in this library to the portal project. Then, we drag the “call static method” action on the campaign, then enter both the method name & the type of the class.

The campaign works fine, but there is something bothered me. When I made the campaign has a goal of X clicks on a content, I didn’t notice that the count is not resting when I redeploy, the count persisted in the database. But I needed someway to monitor how many clicks so far on the content and debug if the campaign goal is reached successfully or not.

Database Tables

I used PointBase console and looked around the tables in the “weblogic” scheme, till I found the table named “AD_COUNT”. It contains the column “AD_ID” which represents the path of the ad, a column that represents the Portal Application, a column for the view count, and another for the clicks count. Also, I found that the whole content in the WLP Repository goes in the table CM_NODE & CM_PROPERTY. The funny thing about PointBase console that it interprets the binary column and display the content image inside it. Check figure 1

Figure 1 Shows the image appears in the PointBase database console as it interpreted its binary content

Conclusion

Weblogic Portal Campaigns is a powerful feature that lets you provide personalized content on the portal, with predefined goals, targeting specific segment(s) of users. It enables the portal to be dynamic to adapt with market changes by changing the parameters of the campaigns in run-time, choosing which content to be displayed to which segment till the campaign goal is reached or the campaign due date comes. It integrates with Weblogic Virtual Content repository.

A feature it lacks is enabling the campaign to end based on goals other than content views/clicks only, like checking against an inventory of the limited product items(which may require calling some back-end method or web service) to flag the campaign as ended. Also the documentation lacks many details about features found in the development IDE (Eclipse packed with OEPE) which make it hard to exploit all the features of Weblogic Portal Campaigns.

email

print

]]> http://www.javabeat.net/2011/04/oracle-weblogic-10-3-2-campaign/feed/ 0

1

  <Host appBase="www/appBase" name="www.myhostname.com"/>

1
2
3
4
5
6

<?xml version="1.0" encoding="UTF-8"?>
<Context
    path="/"
    docBase="www/deploy/mywebapp.war"
    reloadable="true" antiJARLocking="true">
</Context>

1
2
3
4
5
6
7

// Assuming you are in a Servlet extending HttpServlet
                    // This will look for a file called "/more/cowbell.properties" relative
                    // to your servlet Root Context
                   InputStream is = getServletContext().getResourceAsStream("/more/cowbell.properties");
                   Properties  p  = new Properties();
                   p.load(is);
                 is.close();

1

<Connector port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" tomcatAuthentication="false" />

1
2

MyPrincipal p = request.getUserPrincipal();
String emailAddress = p.getEmailAddress();

1
2

Principal p = request.getUserPrincipal();
String emailAddress = p.getClass().getMethod("getEmailAddress", null).invoke(p, null);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public interface MyPrincipalInterface extends java.security.Principal {
  public String getEmailAddress();
}
 
public class MyPrincipal implements MyPrincipalInterface {
...
  public String getEmailAddress() {
    return emailAddress;
  }
}
 
public class MyServlet implements Servlet {
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    MyPrincipalInterface p = (MyPrincipalInterface)request.getUserPrincipal();
    String emailAddress = p.getEmailAddress();
...
}

1
2
3
4
5

<welcome-file-list>
        <welcome-file>index.html</welcome-file>
        <welcome-file>index.htm</welcome-file>
        <welcome-file>index.jsp</welcome-file>
    </welcome-file-list>

1
2
3
4
5
6
7
8
9
10

<html>
 
<head>
<meta http-equiv="refresh" content="0;URL=http://mydomain.com/some/path/to/servlet/homepage/">
</head>
 
<body>
</body>
 
</html>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<servlet>
        <servlet-name>ssi</servlet-name>
        <servlet-class>
          org.apache.catalina.ssi.SSIServlet
        </servlet-class>
        <init-param>
          <param-name>buffered</param-name>
          <param-value>1</param-value>
        </init-param>
        <init-param>
          <param-name>debug</param-name>
          <param-value>0</param-value>
        </init-param>
        <init-param>
          <param-name>expires</param-name>
          <param-value>666</param-value>
        </init-param>
        <init-param>
          <param-name>isVirtualWebappRelative</param-name>
          <param-value>0</param-value>
        </init-param>
        <load-on-startup>4</load-on-startup>
    </servlet>

1
2
3
4
5
6
7
8
9
10
11
12

<?xml version="1.0" encoding="UTF-8"?>
 
<Context>
 
  <Resource name="jdbc/WallyDB" auth="Container"
            type="javax.sql.DataSource" username="wally" password="wally"
            driverClassName="com.microsoft.sqlserver.jdbc.SQLServerDriver"
            url="jdbc:sqlserver://localhost;DatabaseName=mytest;SelectMethod=cursor;"
            maxActive="8"
            />
 
</Context>

1
2
3
4
5

InitialContext ic = new InitialContext();
  DataSource ds = (DataSource) ic.lookup("java:comp/env/jdbc/WallyDB");
  Connection c = ds.getConnection();
  ...
  c.close();

@facebook )

Tomcat 6.0 Developer’s Guide

Current books on Tomcat are primarily focused on the application deployer
or administrator. As a result, they invariably focus on the issues related to
managing a Tomcat installation, configuring the runtime environment, and on
deploying web applications.

On the other hand, while books on servlet programming are targeted at Java web
developers, they often provide a container-agnostic view of the servlet specification.
Tomcat is often a bit player in these books and has very few speaking lines.

This book fills the void between these two approaches.

It will take you on a guided tour of a living implementation of an industrial-strength
servlet container.

Along the way, you will learn how various elements of the Servlet 2.5 specification as
well as how the HTTP RFCs are implemented.

By the end of your journey, you will have acquired specialist grade skills in a range of
technologies that contribute to the arena of Java server-side development.

This book intended to provide Tomcat administrators, deployers, and developers an
introduction into the internal workings of the Tomcat servlet container.

At the same time, it provides Java web programmers with a deep appreciation of the
Servlet APiby exploring its reference implementation—the Tomcat container.

While this book provides you with the conceptual background of all that is necessary to
take your skills to the next level, it assumes that the reader has a general understanding of
the Java programming language and Java web programming.

What This Book Covers

Chapter 1—Introduction to Tomcat introduces you to the Tomcat container and provides
you with the tools necessary to begin to take it apart. The key objective of this chapter is
to allow you to make a current source distribution of Tomcat active in a development
environment (Eclipse Galileo) so that you can trace the path that a request takes through
the container’s code.

Chapter 2—Servlet APiOverview provides the prerequisite information necessary to
navigate the remainder of the book. It describes the Java Enterprise Edition Platform, the
HTTP protocol, and the Servlet API, and serves as a refresher for those who are already
familiar with Java EE web development.

Chapter 3—Servlet Container Overview introduces the reader to the Tomcat container.
This is the 10,000 foot overview of the container that provides a backdrop to the chapters
that follow. All the components of Tomcat are described with just enough detail, so as
not to overwhelm the reader with too much information, too early in the process.

Chapter 4—Starting up Tomcat takes a closer look at the startup process for Tomcat. This
is also where you will be first introduced to the Apache Digester project—a key
component that we will revisit in later chapters. The chapter ends with an example that
demonstrates how a web application can be deployed to a dissected Tomcat container
living within an Integrated Development Environment.

Chapter 5—The Server and Service Components discusses the Server component and
investigates one of its key services—an implementation of the Java Naming and
Directory Interface (JNDI) API. We are also introduced to the Lifecycle interface
that almost every component within Tomcat implements in order to participate in a
standardized event based listener mechanism. To show JNDiin action, our example
considers connecting to a MySQL database to retrieve data.

Chapter 6—The Connector Component introduces our first Tomcat luminary, the Coyote
Connector. We take a closer look at the standard Java I/O implementation of an HTTP
connector. In this chapter, we get a closer look at socket programming, advanced
elements of the HTTP protocol, and the internals of the request processing mechanism.

Chapter 7—The Engine Component describes the first request processing ‘Container’
within Tomcat and gives us an inkling of things to come. We are also introduced to the
Pipeline and its Valves, which are the standard request processing mechanism for
Tomcat components.

Chapter 8—The Host Component discusses the Tomcat implementation of a Virtual Host.
This is the key component responsible for the deployment of web application contexts, as
well as for the error page mechanism.

Chapter 9—The Context Component is at the central core of this book. You get an upclose-
and-personal look at how a Context is configured, how it accesses its resources,
and how it implements its class loading magic.

Chapter 10—The Wrapper Component takes us to the workhorse of the Tomcat
component hierarchy. This component wraps an actual servlet, and as a result is close
to a web developer’s heart. In addition to reviewing the mapping rules dictated by the
Servlet API, we also look at the implementation of servlet filters and the request
dispatcher mechanism.

Chapter 11—The Session Component discusses how sessions are implemented in Tomcat
to enable stateful behavior over the stateless HTTP protocol. In addition to looking at
some core concepts, such as Java serialization and entropy gathering for random number
generation, we look at the standard memory based session implementation, as well as an
implementation that uses files to persist sessions.

Servlet Container Overview

In the last chapter, we noted that the Java Enterprise Edition can be considered to be
nothing more than a set of specifications, or interfaces, for which service providers
are required to provide implementations.

While it is the actual implementation that does all the work, these specifications
ensure that each implementation can assume that all its other collaborating
pieces work as described by their interfaces. In theory, this allows complex
software platforms (such as application servers) to be assembled from
constituent implementations, each of which is sourced from a different vendor.

In practice, it is highly unlikely that you will interface an EJB container from
WebSphere and a JMS implementation from WebLogic, with the Tomcat servlet
container from the Apache foundation, but it is at least theoretically possible.

Note that the term ‘interface’, as it is used here, also encompasses abstract classes.
The specification’s APimight provide a template implementation whose operations
are defined in terms of some basic set of primitives that are kept abstract for the
service provider to implement. For instance, in Chapter 2, we noted that the servlet
hierarchy is made up of the Servlet interface, and the GenericServlet and
HttpServlet abstract classes within the javax.servlet package.

A service provider is required to make available concrete implementations of
these interfaces and abstract classes. For example, the HttpSession interface
is implemented by Tomcat in the form of org.apache.catalina.session.
StandardSession.

Let’s return to the image of the Tomcat container that we saw in Chapter 1.

As was stated in Chapter 1, the objective of this book is to cover the primary request
processing components that are present in this image. Advanced topics, such as
clustering and security, are shown as shaded in this image and are not covered.

In this image, the ‘+’ symbol after the Service, Host, Context, and Wrapper
instances indicate that there can be one or more of these elements. For instance, a
Service may have a single Engine, but an Engine can contain one or more Hosts.
In addition, the whirling circle represents a pool of request processor threads.

In this chapter, we will fl y over the architecture of Tomcat from a 10,000-foot
perspective taking in the sights as we go.

Component taxonomy

Tomcat’s architecture follows the construction of a Matrushka doll from Russia. In
other words, it is all about containment where one entity contains another, and that
entity in turn contains yet another.

In Tomcat, a ‘container’ is a generic term that refers to any component that can
contain another, such as a Server, Service, Engine, Host, or Context.

Of these, the Server and Service components are special containers, designated as
Top Level Elements as they represent aspects of the running Tomcat instance. All
the other Tomcat components are subordinate to these top level elements.

The Engine, Host, and Context components are officially termed Containers, and
refer to components that process incoming requests and generate an appropriate
outgoing response.

Nested Components can be thought of as sub-elements that can be nested inside
either Top Level Elements or other Containers to configure how they function.
Examples of n ested components include the Valve, which represents a reusable unit
of work; the Pipeline, which represents a chain of Valves strung together; and a
Realm which helps set up container-managed security for a particular container.

Other nested components include the Loader which is used to enforce the
specification’s guidelines for servlet class loading; th e Manager that supports session
management for each web application; the R esources component that represents the
web application’s static resources and a mechanism to access these resources; and
the Listener th at allows you to insert custom processing at important points in a
container’s life cycle, such as when a component is being started or stopped.

	Not all nested components can be nested within every container.

A final major component, which falls into its own category, is the Connector. It
represents the connection end point that an external client (such as a web browser)
can use to connect to the Tomcat container.

Before we go on to examine these components, let’s take a quick look at how they are
organized structurally.

Note that this diagram only shows the key properties of each container.

When Tomcat is started, the Java Virtual Machine (JVM) instance in which it
runs will contain a singleton Server top level element, which represents the entire
Tomcat server. A Server will usually containjust one Service object, which is a
structural element that combines one or more Connectors (for example, an HTTP
and an HTTPS connector) that funnel incoming requests through to a single
Catalina servlet Engine.

The Engine represents the core request processing code within Tomcat and supports
the definition of multiple Virtual Hosts within it. A virtual host allows a single
running Tomcat engine to make it seem to the outside world that there are multiple
separate domains (for example, www.my-site.com and www.your-site.com) being
hosted on a single machine.

Each virtual host can, in turn, support multiple web applications known as
Contexts that are deployed to it. A context is represented using the web application
format specified by the servlet specification, either as a single compressed WAR
(Web Application Archive) file or as an uncompressed directory. In addition, a
context is configured using a web.xml file, as defined by the servlet specification.

A context can, in turn, contain multiple servlets that are deployed into it, each of
which is wrapped in a Wrapper component.

The Server, Service, Connector, Engine, Host, and Context elements that
will be present in a particular running Tomcat instance are configured using the
server.xml configuration file.

	Things are a bit more complicated than this. However, we’ll defer the

	complexity until later chapters when we deal with each component in a

	lot more detail.

Architectural benefits

This architecture has a couple of useful features. It not only makes it easy to manage
component life cycles (each component manages the life cycle notifications for its
children), but also to dynamically assemble a running Tomcat server instance that
is based on the information that has been read from configuration files at startup.
In particular, the server.xml file is parsed at startup, and its contents are used to
instantiate and configure the defined elements, which are then assembled into a
running Tomcat instance.

	The server.xml file is read only once, and edits to it will not be picked

	up until Tomcat is restarted.

This architecture also eases the configuration burden by allowing child containers
to inherit the configuration of their parent containers. For instance, a Realm defines
a data store that can be used for authentication and authorization of users who
are attempting to access protected resources within a web application. For ease of
configuration, a realm that is defined for an engine applies to all its children hosts
and contexts. At the same time, a particular child, such as a given context, may
override its inherited realm by specifying its own realm to be used in place of its
parent’s realm.

]]> http://www.javabeat.net/2010/06/tomcat-6-0-servlet-container-overview/feed/ 0 http://www.javabeat.net/2010/02/developing-applications-with-jboss-and-hibernate/ http://www.javabeat.net/2010/02/developing-applications-with-jboss-and-hibernate/#comments Sun, 14 Feb 2010 00:18:55 +0000 krishnas http://www.javabeat.net/?p=1948 Connect to us (

	<i>Hibernation is a state of regulated hypothermia undergone by some animals to
	conserve energy during the winter</i>. – Wikipedia

	<hibernate-configuration>
		<session-factory>
			<property name="connection.username">user</property>
			<property name="connection.password">password</property>
			<property name="connection.url">
				jdbc:mysql://localhost/database
			</property>
			<property name="connection.driver_class">
				com.mysql.jdbc.Driver
			</property>
			<property name="dialect">
				org.hibernate.dialect.MySQLDialect
			</property>
			<mapping resource="com/sample/MyClass.hbm.xml"/>
		</session-factory>
	</hibernate-configuration>

	CREATE schema hibernate;
	GRANT ALL PRIVILEGES ON hibernate.* TO 'jboss'@'localhost' WITH GRANT
	OPTION;
	CREATE TABLE `hibernate`.`department` (
		`department_id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
		`department_name` VARCHAR(45) NOT NULL,
		PRIMARY KEY (`department_id`)
	)
	ENGINE = InnoDB;
	CREATE TABLE `hibernate`.`employee` (
		`employee_id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
		`employee_name` VARCHAR(45) NOT NULL,
		`employee_salary` INTEGER UNSIGNED NOT NULL,
		`employee_department_id` INTEGER UNSIGNED NOT NULL,
		PRIMARY KEY (`employee_id`),
		CONSTRAINT `FK_employee_1` FOREIGN KEY `FK_employee_1` (`employee_
	department_id`)
		REFERENCES `department` (`department_id`)
		ON DELETE CASCADE
		ON UPDATE CASCADE
	)
	ENGINE = InnoDB;

A new Eclipse project

Now start Eclipse. You don’t have a specific project for Hibernate applications, so a utility project (that simply packs the classes in an archive) will be enough. You can reach this option from the menu by going to New | Other | Java EE | Utility Project.

Now, we are going to unleash the full potential of Hibernate tools. Select from the menu New | Other | Hibernate | Hibernate Configuration File. The Hibernate configuration contains all of the details for wiring your application to the database. You will be asked for the name and the parent folder of the configuration file. Accept the default hibernate.cfg.xml at the root of your project.

One important selection is the Type option that lets you choose between the Core hibernate configuration (Java classes backed by mapping files), Annotations, or even JPA annotations. We will leave the selected Core option.

Before clicking Finish, select MySQL (InnoDB) as Database dialect in the Options tab. No other changes are required.

Reversing your schema into Java classes

The next move will be reversing our database schema into Java classes and mapping files. This powerful feature is available from the menu: File | New | Hibernate |Hibernate Reverse Engineering file. You can place this file in a convenient location for your project and choose a name for it. The default name proposed is hibernate.reveng.xml, which looks rather the tile of another fiction movie from G. Lucas.

	<hibernate-reverse-engineering>
		<table-filter match-catalog="hibernate" match-name="department"/>
		<table-filter match-catalog="hibernate" match-name="employee"/>
	</hibernate-reverse-engineering>

If you are smart at noticing variations, you might have discovered a new icon in your toolbar. This is your gateway to the reverse engineering process. (Notice: this icon is visible only in the Hibernate Perspective, you will not be able to find it anywhere else.)

Just below, you will find the checkbox Reverse engineer from JDBC Connection. If enabled, the tools will reverse engineer the available database using the connection information in the selected Hibernate Console configuration. Check this option and enter the package name for the generated classes, which will be com.packtpub. hibernate. Leave the other text fields to the defaults and move to the tab Exporters.

In the upper area of the dialog, you will notice an interesting checkbox named Generate EJB 3 annotations. We will return to this useful option later. At the moment, what we need is just to check the Domain code and Hibernate XML Mappings options, which will generate the Java POJOs and mapping files respectively.

It took a bit of time to complete all of these steps; however, now your Java classes and configuration files are handy and waiting to be packaged.

Adding Hibernate configuration to your project

The advantage of embedding the Hibernate application in JBoss AS is that you can expose Hibernate SessionFactory through a JN DI tree and modify its configuration at runtime.

This is indeed a great configuration advantage; before the new release of JBoss AS, you had to delegate to an MBean the creation of the Hibernate SessionFactory and its exposure through JNDI.

For example, if you wanted to configure a SessionFactory at the naming context hibernate/SessionFactory, you would have to package your Hibernate application with a file named xxx-service.xml in the META-INF folder. Here’s a sample of it:

	<server>
		<mbean code="org.jboss.hibernate.jmx.Hibernate"
			name="jboss.har:service=Hibernate">
			<attribute name="DatasourceName">java:/ MySqlDS</attribute>
			<attribute name="Dialect">
				org.hibernate.dialect.MySQLDialect
			</attribute>
			<attribute name="SessionFactoryName">
				java:/hibernate/SessionFactory
			</attribute>
			<attribute name="CacheProviderClass">
				org.hibernate.cache.HashtableCacheProvider
			</attribute>
		</mbean>
	</server>

This configur ation is still valid for pre 5.0 releases of JBoss AS. With the introduction of the new Virtual Deployment Framework (VDF), you now have to provide your SessionFactory configuration using the Hibernate XML schema. For example, if you want to link your SessionFactory to your MySQL database, you have to add the following service-hibernate.xml. (Be aware, the suffix is -hibernate.xml and not –service.xml.)

	<hibernate-configuration xmlns="urn:jboss:hibernate-deployer:1.0">
		<session-factory name="java:/hibernate/SessionFactory"
			bean="jboss.test.har:service=Hibernate,
			testcase=TimersUnitTestCase">
			<property name="datasourceName">java:/MySqlDS</property>
			<property name="dialect">
				org.hibernate.dialect.MySQLDialect
			</property>
			<depends>jboss:service=Naming</depends>
			<depends>jboss:service=TransactionManager</depends>
		</session-factory>
	</hibernate-configuration>

The preceding configuration file needs to be stored in the META-INF folder of your Hibernate archive (HAR) file. The structure of the updated project from the Package Explorer is as shown in the following snapshot:

Adding a web client to your project

There are seve ral ways to test our Hibernate application. The simplest of all is adding a web application, which is packaged in an Enterprise application along with the Hibernate application. Create a new dynamic web project named HibernateWeb.

The first step, before adding servlets and JSPs is linking the HibernateProject libraries to your web application, otherwise, you will not be able to reference the Hibernate POJOs. Right-click on your project and select Properties. Reach the Java Build Path option and select the tab Projects. From there add HibernateProject.

In the following snippet, you can see the core section of the servlet. Here, we will not detail the Controller logic, which is straightforward if you have some rudiments of the MVC pattern; rather we want to highlight the most interesting part of it, which is how to query and persist Hibernate objects.

	public class HibernateServlet extends HttpServlet {
		private SessionFactory getSessionFactory() {
			return (SessionFactory)getServletContext().
			getAttribute("sessionFactory");
		}
		public void init() { [1]
			if (getSessionFactory() != null) {
				return;
			}
			InitialContext ctx;
			try {
				ctx = new InitialContext();
				<b>factory = (SessionFactory)ctx.
					lookup("java:/hibernate/SessionFactory");
				getServletContext().setAttribute("sessionFactory", factory);</b>
			}
			catch (NamingException e) {
				e.printStackTrace();
			}
		}
		private String saveEmployee(HttpServletRequest request) {
			Session hsession=null;
			String name=request.getParameter("name");
			String salary=request.getParameter("salary");
			String departmentId=request.getParameter("departmentId");
			try {
				hsession = getSessionFactory().openSession();
				hsession.beginTransaction();
				<b>Query query = hsession.createQuery("from Department d where
					d.departmentId = :departmentId"); [2]</b>
				query.setInteger("departmentId", new Integer(departmentId));
				Department dep = (Department) query.uniqueResult();
				Employee emp = new Employee();
				emp.setDepartment(dep);
				emp.setEmployeeName(name);
				emp.setEmployeeSalary(Integer.parseInt(salary));
				<b>hsession.save(emp); [3]</b>
				hsession.getTransaction().commit();
			}
			catch (Exception e) {
				// TODO Auto-generated catch block e.printStackTrace();
				hsession.getTransaction().rollback();
			}
			finally {
				if (hsession.isOpen())
				hsession.close();
			}
			return employeeList(request);
		}
		private String employeeList(HttpServletRequest request) {
			Session hsession=null;
			Department dep;
			try {
				hsession = getSessionFactory().openSession();
				<b>Query query = hsession.createQuery("select p from Employee p
					join fetch p.department c"); [4]</b>
				List <Employee>list = query.list();
				request.setAttribute("employee", list);
			}
			catch (Exception e) {
				e.printStackTrace();
			}
			finally {
				if (hsession.isOpen())
				hsession.close();
			}
			return "/listEmployees.jsp";
		}
		private String saveDepartment(HttpServletRequest request) {
			String depName=request.getParameter("depName");
			Session hsession=null;
			Department dep;
			try {
				hsession = getSessionFactory().openSession();
				hsession.beginTransaction();
				dep = new Department();
				dep.setDepartmentName(depName);
				<b>hsession.save(dep); [5]</b>
				hsession.getTransaction().commit();
			}
			catch (Exception e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
				hsession.getTransaction().rollback();
			}
			finally {
				if (hsession.isOpen())
				hsession.close();
			}
			return employeeList(request);
		}
	}

As you can see from the preceding code, we recover the SessionFactory from the JNDI tree in the init() [1] method of the servlet. Instances of SessionFactory are thread-safe and typically shared throughout an application, so we store it in the ServletContext and share it among all servlet instances.

The SessionFactory is subsequently used to start a Hibernate session, which is not thread-safe and should only be used for a single transaction or unit of work in an application.

In order to store our Employee, in the saveEmployee method, we first retrieve the corresponding Department from our schema [2], and finally the Employee is saved [3] and the transaction is committed.

The list of employees is fetched by the employeeList method. Notice we are using a join fetch statement to retrieve all the employees [4], which will be routed to the listEmployees.jsp view. Why? The answer is that with the default fetch mode (Lazy), once the Hibernate session is closed, the client will not be able to navigate through the department field of the Employee. The common solution to this issue is switching to the EAGER fetch mode that reads the related fields (in our case department) in memory, as soon as we query the Employee table.

You have more than one option to achieve this. One possible solution, if you don’t want to change the default fetch mode for the Employee table, is to build an ad hoc query that forces Hibernate to read also those fields that are in relation with the Employee table.

	"select p from Employee p join fetch p.department c"

If you prefer to use the XML class files to configure the fetch mode, you can also change the lazy=”true” attribute in the employee-department relationship.

The last method, saveDepartment [5] takes care to persist a new Department in the corresponding table. We complete our excursus on the web tier with the listEmployees.jsp that is used to display a tabular view of the employees:

	<b><%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %></b>
	<html>
		<script language="JavaScript">
			function doSubmit(url) {
				document.module.action = url;
				document.module.submit();
			}
		</script>
		<body>
			<table border="1">
				<tr>
					<th>Name</th>
					<th>Salary</th> <TH>department</th>
				</tr>
				<b><c:forEach items="${employee}" var="emp">
					<tr>
						<td> <c:out value="${emp.employeeName}"/> </td>
						<td> <c:out value="${emp.employeeSalary}"/></td>
						<td> <c:out value="${emp.department.departmentName}"/></td>
					</tr>
				</c:forEach></b>
			</table>
			<form name="module" method="POST">
				<input type="button" value ="New Employee"
					onClick="doSubmit('actionServlet?op=newEmployee')">
				<input type="button" value ="New Department"
					onClick="doSubmit('actionServlet?op=newDepartment')">
			</form>
		</body>
	</html>

This page uses JSP 2.0 Expression Language (EL) to iterate through the list of employees, as highlighted in the last code snippet. We have also highlighted the taglib directive, at the beginning of the page. This directive will be used to resolve the JSTL core set of libraries that ships with JBoss AS in the server/xxx/deploy/ jbossweb.sar/jstl.jar library. (Eclipse does not contain references to this library when you create a web project; you have to add jstl.jar to your build path, otherwise Eclipse will mark it as an error. However, that’s only a visual annoyance because the JBoss web container has got everything it needs to run JSTL.)

The complete web application is available on the Packtpub website (http://www.packtpub.com) and includes two additional JSPs for entering the employee (newEmployee.jsp) and department (newDepartment.jsp) data, plus one placeholder index.jsp that merely forwards to the HibernateServlet.

Packaging and deploying the application

Your enterprise application is complete. We need to package it in an EAR archive so that the web application will be able to interact with the Hibernate POJOs. Create a new Enterprise Application project from the Java EE folder. You will be prompted to select the projects that will be included as modules. Select both the HibernateProject and the web application HibernateWeb.

As HAR archives are not Java EE standard components, you have to declare it in a JBoss AS-specific configuration file named jboss-app.xml that sits in the META-INF folder of our EAR.

	<!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 1.5//EN"
		"http://www.jboss.org/j2ee/dtd/jboss-app_5_0.dtd">
		<jboss-app>
			<module>
				<har>HibernateApplication.har</har>
			</module>
		</jboss-app>

While this approach is still advisable if you want to grant backward compatibility to your applications, with release 5.0 of the Application Server you now have a handy quicker solution. As the new VFS of JBoss AS is able to detect the nature of your application by scanning deployment descriptors, it’s enough to pack your Hibernate application in a plain Java ARchive (JAR). JBoss AS will discover the .hbm.xml mapping files and look for the corresponding Java classes. If successful, the package will be deployed as a Hibernate application straightaway.

The corollary of this theorem is that you can leave out, as well, the JBoss AS configuration file jboss-app.xml, which is not necessary any more. The only update required is to your application.xml, where your Hibernate application is declared as a Java module in order to make it available to other enterprise modules.

	<application>
		<module>
			<web>
				<web-uri>HibernateWeb.war</web-uri>
				<context-root>HibernateWeb</context-root>
			</web>
		</module>
		<b><module>
			<java>HibernateProject.jar</java>
		</module></b>
	</application>

This is how your Enterprise ARchive should look like before deploying it:

16:46:18,949 INFO [HbmBinder] Mapping class: com.packtpub.hibernate.

Employee ->employee

16:46:19,261 INFO [HbmBinder] Mapping class: com.packtpub.hibernate.

Department -> department

16:46:19,277 INFO [HbmBinder] Mapping collection: com.packtpub.hibernate.

Department.employees -> employee

In order to test your application, simply recall your JSP default page, using the HibernateWeb context. In our example:

http://localhost:8080/HibernateWeb/

Using the wizard to generate EJB 3

Hibernate tool capabilities are not limited to Hibernate programming. By using the reverse engineering option, you can also generate EJB 3.0 classes in a matter of seconds. Recall the Reverse Engineering Configuration:

Hibernate and EJB: Friends or opponents?

In Chapter 4, we introduced the EJB programming model, so at this stage, you might wonder when it’s more appropriate to use EJB from your projects and when it’s better to stay on the Hibernate framework.

The premise of this debate is that EJB and Hibernate are not fully comparable because they are semantically different. EJBs live in a container, which provides services, such as transactions, concurrent access control, security, instance pooling,and others. On the other hand, Hibernate is classified as an object-relational mapping tool and it is independent from a server container.

So, if comparing EJB and Hibernate is technically a mistake, you can actually compare the Java Persistence API and Hibernate, which are, in some ways, two antagonist technologies. The most important factor, which is in favor of JPA, is that it is a standard. Using industry-standard components allows the business comparatively more fl exibility when it’s necessary to change its business model, to reorchestrate itself, and to collaborate dynamically.

Technically speaking, it is also important to stress that an EJB-centric approach is the appropriate implementation technology for two types of applications:

• Applications that use distributed transactions initiated by remote clients

• Applications that are heavily message-oriented and need message-driven beans

On the other hand, Hibernate framework has reached a vast community of developers and it offers the benefit of peacefully coexisting in various deployment environments, from application servers to standalone applications.

At the end of the day, the choice between the two technologies might be to preserve your well-tested applications backed by Hibernate Persistence and to definitely consider switching to JPA when you are designing a new project from the ground up. What about using them together instead?

Using Hibernate with EJB

A plausible scenario is that some time ago, you designed the persistence layer of your application with Hibernate. Now you need to expose some functionalities of your application through RMI or Web Services.

The good news is that persistent classes that are mapped using Hibernate *.hbm. xml files are supported by JBoss AS EJB 3 implementation. The EJB 3 deployer will search the archive for any .hbm.xml files and add them to the definition of the underlying Hibernate SessionFactory. Let’s see how you can leverage Hibernate objects from the EJB environment.

Injecting key Hibernate objects

If you have been through the Hibernate web application carefully, you might advocate that it is not a pure MVC application, as we are accessing the persistence layer from within the servlet.

This approach can be useful for a learner who wants an easy-to-catch example of Hibernate. However, you can create a clean separation of roles between the controller and the model tier, also by introducing an EJB as intermediary.

From inside your Hibernate project, add another Stateless Session Bean named com.packtpub.hibernate.HibernateDAOBean implementing a local interface com.packtpub.hibernate.HibernateDAOLocal.

Following is a code snippet of the bean implementing the saveEmployee method:

	@Stateless
	@LocalBinding(jndiBinding="HibernateDAO/local")
	public class HibernateDAOBean implements HibernateDAO {
		<b>@PersistenceUnit(unitName="hibernateUnit") [1]
			SessionFactory factory;</b>
		public void saveEmployee(String name,String salary,String
			departmentId) {
			Session hsession=null;
			try {
				hsession = factory.openSession();
				Query query = hsession.createQuery("from Department d where
				d.departmentId = :departmentId");
				query.setInteger("departmentId", new Integer(departmentId));
				Department dep = (Department) query.uniqueResult();
				Employee emp = new Employee();
				emp.setDepartment(dep);
				emp.setEmployeeName(name);
				emp.setEmployeeSalary(Integer.parseInt(salary));
				hsession.save(emp);
			}
			catch (Exception e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
				throw new EJBException(e.getMessage());
			}
			finally {
				if (hsession.isOpen())
				hsession.close();
			}
		}

The most interesting point in this example is that you have injected the Hibernate SessionFactory in your bean by means of the persistence unit named hibernateUnit. Therefore, you have to equip your application with a JPA persistence.xml file:

	<?xml version="1.0" encoding="UTF-8"?>
		<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/
			persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
			xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://
			java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
			<b><persistence-unit name="hibernateUnit" transaction-type="JTA"></b>
				<provider>org.hibernate.ejb.HibernatePersistence</provider>
				<jta-data-source>java:/MySqlDS</jta-data-source>
				<properties>
					<property name="hibernate.dialect"
						value="org.hibernate.dialect.MySQLDialect"/>
				</properties>
			</persistence-unit>
		</persistence>

We leave as exercise to the reader to complete the EJB with all other methods. On the web tier, you will do a clear cut of all the persistence stuff, just taking care to invoke the EJB with the parameters collected from the request. Look how simple and effective your servlet method saveEmployee has become:

	<b>@EJB(mappedName = "HibernateDAO/local")
	HibernateDAO hibernateDAO;</b>
		private String saveEmployee(HttpServletRequest request) {
			Session hsession=null;
			String name=request.getParameter("name");
			String salary=request.getParameter("salary");
			String departmentId=request.getParameter("departmentId");
			try {
				hibernateDAO.saveEmployee(name,salary,departmentId);
			}
			catch (Exception e) {
				e.printStackTrace();
			}
			return employeeList(request);
		}

A snapshot of the complete Hibernate EJB-driven project follows here:

Summary

Hibernate is a fl exible framework that can be used in any Java application environment. In our excursus, we have showed how to develop a sample application that is geared toward a managed environment. In the last two sections of the chapter, we have compared the Hibernate framework with the JPA persistence standard, showing how the two technologies can be coupled in a single application.

In the next chapter, we will learn JBoss AS JMX infrastructure, which was the backbone of earlier releases of JBoss. Even if it’s not the main kernel component anymore, the JMX API is still the glue around many JBoss AS services.

package jms;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.Session;
import org.springframework.jms.core.JmsTemplate;
import org.springframework.jms.core.MessageCreator;
public class InvoiceQueueSender {
	private JmsTemplate jmsTemplate;
	public void setJmsTemplate(JmsTemplate jmsTemplate) {
		this.jmsTemplate = jmsTemplate;
	}

	public void sendMesage() {
		MessageCreator messageCreator=new MessageCreator() {
		public Message createMessage(Session session) throws
		JMSException {
		return session.createTextMessage("I am 
                               sending Invoice message");}
		};

		jmsTemplate.send("jms/testQueue", messageCreator);
	}
}

package jms;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.TextMessage;

public class InvoiceMDB implements MessageListener {
	public void onMessage(Message message) {
	 try {
	   System.out.println(((TextMessage) message).getText());
	   System.out.println("Hello");
	 } catch (JMSException ex) {
	   throw new RuntimeException(ex);
	 }
	}
}

	
<bean id="jndiTemplate" class="org.springframework
       .jndi.JndiTemplate">
<property name="environment">
 <props>
   <prop key="java.naming.factory.initial">
           weblogic.jndi.WLInitialContextFactory</prop>
   <prop key="java.naming.provider.url">t3://localhost:7001</prop>
 </props>
</property>
</bean>

<bean id="queueConnectionFactory" 
      class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiTemplate">
 <ref bean="jndiTemplate" />
</property>
<property name="jndiName">
 <value>jms/connectionFactory</value>
</property>
</bean>

<bean id="jmsDestinationResolver" 
       class="org.springframework.jms.support.destination
       .JndiDestinationResolver">
<property name="jndiTemplate">
 <ref bean="jndiTemplate" />
</property>
<property name="cache">
 <value>true</value>
</property>
</bean>

	
<bean id="invoiceQueueTemplate" class="org.springframework.jms
        .core.JmsTemplate">
<property name="connectionFactory">
 <ref bean="queueConnectionFactory" />
</property>
<property name="destinationResolver">
 <ref bean="jmsDestinationResolver" />
</property>
</bean>

<bean id="invoiceQueue" class="org.springframework
            .jndi.JndiObjectFactoryBean">
 <property name="jndiTemplate">
   <ref bean="jndiTemplate" />
 </property>
 <property name="jndiName">
   <value>jms/testQueue</value>
 </property>
</bean>

<bean id="invoiceListener" class="jms.InvoiceMDB" />

<bean id="Invoicelistener" class="org.springframework.jms
           .listener.DefaultMessageListenerContainer">
    <property name="concurrentConsumers" value="5" />
    <property name="connectionFactory" ref="queueConnectionFactory" />
    <property name="destination" ref="invoiceQueue" />
    <property name="messageListener" ref="invoiceListener" />
</bean>

<bean id="jmsInvoiceSender" class="jms.InvoiceQueueSender">
<property name="jmsTemplate">
<ref bean="invoiceQueueTemplate" />

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>

<bean id="invoiceListener" class="jms.InvoiceMDB" />

<bean id="jndiTemplate" class="org.springframework.jndi.JndiTemplate">
<property name="environment">
 <props>
   <prop key="java.naming.factory.initial">weblogic.jndi
                   .WLInitialContextFactory</prop>
   <prop key="java.naming.provider.url">t3://localhost:7001</prop>
 </props>
</property>
</bean>

<bean id="queueConnectionFactory" class="org.springframework.
             jndi.JndiObjectFactoryBean">
<property name="jndiTemplate">
 <ref bean="jndiTemplate" />
</property>
<property name="jndiName">
 <value>jms/connectionFactory</value>
</property>
</bean>

<bean id="jmsDestinationResolver" class="org.springframework
            .jms.support.destination.JndiDestinationResolver">
<property name="jndiTemplate">
 <ref bean="jndiTemplate" />
</property>
<property name="cache">
 <value>true</value>
</property>
</bean>

<bean id="invoiceQueueTemplate" class="org.springframework
             .jms.core.JmsTemplate">
<property name="connectionFactory">
 <ref bean="queueConnectionFactory" />
</property>
<property name="destinationResolver">
 <ref bean="jmsDestinationResolver" />
</property>
</bean>

<bean id="jmsInvoiceSender" class="jms.InvoiceQueueSender">
<property name="jmsTemplate">
 <ref bean="invoiceQueueTemplate" />
</property>

</bean>

<bean id="invoiceQueue" class="org.springframework.jndi
        .JndiObjectFactoryBean">
 <property name="jndiTemplate">
   <ref bean="jndiTemplate" />
 </property>
 <property name="jndiName">
   <value>jms/testQueue</value>
 </property>
</bean>
<bean id="Invoicelistener" class="org.springframework.jms
               .listener.DefaultMessageListenerContainer">
    <property name="concurrentConsumers" value="5" />
    <property name="connectionFactory" ref="queueConnectionFactory" />
    <property name="destination" ref="invoiceQueue" />
    <property name="messageListener" ref="invoiceListener" />
  </bean>
</beans>

package jms;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.springframework.web.context.WebApplicationContext;
import org.springframework.web.context.support.WebApplicationContextUtils;

public class InvoiceSenderServlet extends javax.servlet.http.HttpServlet
		implements javax.servlet.Servlet {
   protected void service(HttpServletRequest request,
          HttpServletResponse response) throws ServletException, IOException {
	     WebApplicationContext ctx = WebApplicationContextUtils
		.getRequiredWebApplicationContext(this.getServletContext());

		InvoiceQueueSender sender = (InvoiceQueueSender) ctx
				.getBean("jmsInvoiceSender");
		sender.sendMesage();
	}
}

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="2.4" 
  xmlns="http://java.sun.com/xml/ns/j2ee" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 

http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

	<display-name>
	SpringJMS</display-name>
	<servlet>
		<description>
		</description>
		<display-name>
		InvoiceSenderServlet</display-name>
		<servlet-name>InvoiceSenderServlet</servlet-name>
		<servlet-class>
		jms.InvoiceSenderServlet</servlet-class>
	</servlet>
	<servlet-mapping>
		<servlet-name>InvoiceSenderServlet</servlet-name>
		<url-pattern>/InvoiceSenderServlet</url-pattern>
	</servlet-mapping>
	<welcome-file-list>
		<welcome-file>index.html</welcome-file>
		</welcome-file-list>

	<listener>
	<listener-class>org.springframework.web.context.
                  ContextLoaderListener</listener-class>
	</listener>
</web-app>

Processes are classifi ed by duration as follows:

• Short-running: The process runs comparatively quickly, for not more than a few seconds. Most short-running processes run in single burst (as in process (a) in the fi gure), but some have intermediate events with fast arrival times—as in (b), where the intermediate event, a response to an asynchronous system call, arrives in about two seconds—and thus run in multiple bursts. TIBCO‘s BusinessWorks and the BPEL compiler described later in the chapter are optimized to run both single-burst and multiple-burst short-running processes. BEA’s Weblogic Integration can run single-burst, short-running processes with limited overhead, but, as discussed further next, treats cases like (b) as long-running.
• Long-running: The process has multiple bursts, and the waiting times of its intermediate events are longer than the process engine itself is expected to run before its next restart! In process (d), for example, the engine is restarted for maintenance while the process waits two days for a human action. The process survives the restart because its state is persisted. At the end of its fi rst burst (that is, after the Assign Work step), the engine writes the state to a database, recording the fact that the process is now waiting on an event for a human action. When the engine comes back up, it fetches the state from the database to remember where it left off. Most BPEL processes are longrunning. In Weblogic Integration, stateful processes can run for arbitrarily long durations.
• Mid-running: T he process has multiple bursts, but the waiting times of its intermediate events last no more than a few minutes, and do not need to be persisted. Stakeholders accept the risk that if the process engine goes down, in-fl ight processes are lost. Chordiant’s Foundation Server uses mid-running processes to orchestrate the interaction between agent and customer when the customer dials into a call center. The call is modeled as a conversation, somewhat like a sequence of questions and answers. A burst, in this design, processes the previous answer (for example, the Process Answer activity in (c)) and prepares the next question (Prepare Question). Intermediate events
  (Get Answer) wait for the customer to answer. State is held in memory.

Stateful and Stateless Processes in BEA’s Weblogic Integration

I n Weblogic Integration, single-burst processes are stateless, but multiple-burst processes, even short-running ones, are stateful. Even if the wait between bursts is very small (one or two seconds perhaps), Weblogic Integration nonetheless persists process state to a database. The distinction is subtle, but Weblogic Integration provides visual clues to help us detect the difference. In the next fi gure, the process on the left is stateless. The process on the right is the same as that on the left except for the addition of an event step called Control Receive; the step, in effect, puts the process in a wait state until it receives a specifi c event. When this step is added, Weblogic Integration changes the appearance of its start step—Start—from a circle with a thin border to one with a thick border, indicating that the process has changed from being stateless to stateful.

Those who designed Weblogic Integration thought process state so important that they worked into their notation whether a process is stateful or stateless. We now study one of the most critical pieces of any process engine: how it keeps state.

How to Keep Long-Running State

In this section, we study the data models for long-running process state in two commercial process integration platforms: Oracle‘s BPEL Process Manager and BEA’s Weblogic Integration. We also develop our own model, a generalization of the Oracle and BEA approaches, which enables us to achieve the effect of a long-running SOA process from a group of short-running processes. We put this model to practical use later in this chapter, in the email money transfer example.

SOA process state models contain information about the following:

• Process metadata, including the types of processes currently deployed, their versions, and how their activities are assembled.
• Process instances, including status, start time and end time, and the position of the instance in a call graph (that is, parent/child relationships). Some models also track the status of individual activities.
• Pending events, and how to correlate them with process instances.

State in Oracle‘s BPEL Process Manager

The following figure shows the core tables in the Oracle BPEL model (version 10.1.2).

In this model process, metadata is held in two tables: Process_Default and Process_Revision. The former lists all deployed BPEL processes and their current revision numbers; the process_id field is not a technical key but the name of the process specified by the developer. The latter lists all of the revisions; for a given process, each revision has a distinct GUID, given by the field process_guid.

The seemingly-misnamed table Cube_Instance—actually, cube is synonymous with process in the internals of the product—has information about current and completed process instances. The instance has a unique key, given by cikey. From process_guid we can deduce, by joining with Process_Revision, the process type and revision of the instance. Other important information includes the instance creation date, its parent instance, and its current state. Possible states are active, aborted, stale, and completed, although the state fi eld uses numeric codes for these values.

The Work_Item table tracks the status of instance activities. Cikey indicates the instance to which the activity belongs. Within an instance the activity is identified by the combination of node_id, scope_id, and count_id. The fi rst two of these indicate the position of the activity in the process graph and the scope level to which it belongs; the label column is a friendlier alternative to these, assuming that the developer applied a useful label to the activity. Count_id is required in case the activity executes more than once. Work_Item has its own state fi eld (again numeric), which indicates whether the activity is completed or pending, was cancelled, or encountered an exception.

Dlv _Subscription records pending events and correlates them with instances. Conv_id is a conversation identifi er known to both the BPEL process and its partner service. To trigger the event, the partner service passes this identifi er as part of its message. The process matches it to a subscriber_id, which uniquely identifies the activity that is waiting on the event. Thus, when the event arrives, the process knows exactly from which point to continue. (Technically, subscriber_id is a delimited string, which encodes as part of its structure the values of cikey, node_id, scope_id, and count_id that point to a unique Work_Item record.) The partner also specifi es an operation name, which specifi es which type of event it is fi ring. If the process is waiting on several events in the same conversation (as part of an event pick, also known as a deferred choice), operation_name determines which path to follow. The combination of operation_name and conv_id points to a unique activity (that is, to a unique subscriber_id).

State in BEA’s Weblogic Integration

The following fi gure shows three important tables in the Weblogic Integration model:

WLI_Process_Def has metadata about types of deployed processes and their activities. The table has one row for each activity. Process_type is the human-readable name of a process. Activity_id is the numeric identifi er of an activity in the process, although user_node_name, the descriptive name provided by the developer is more intuitive.

Process instance information is held in WLI_Process_Instance_Info. Each instance has a unique numeric identifi er, given by process_instance. Process_type specifi es the process defi nition on which the instance is based. Process_status specifi es, in a numeric code, whether the instance is active, pending, or aborted. The table also tracks process start and end times, as well as time in excess of the SLA (sla_exceed_time). Through Weblogic Integration’s administration console, the administrator can confi gure an SLA on process cycle time.

In Weblogic Integration a process instance can receive intermediate events by several means. One of the most important of these is by listening for messages published by Weblogic Integration’s message broker system. The table WLI_Message_Broker_Dynamic keeps track of specifi c events waiting on broker messages. The column subscriber_instance is the process instance identifi er; it matches the process_instance value in WLI_Process_Instance_Info. Rule_name is, in effect, a pointer to the event in that instance. Filter_value is an XQuery expression that checks the content of the message to determine whether to accept the event. When a message arrives, the broker checks for any subscription events, and triggers those whose fi ltertest passes.

Our Own State Model

Our own model, shown in the next fi gure, follows a design approach similar to that of the Oracle and BEA models.

To begin, the model features a single metadata table, called ProcessStarter, which enumerates the types of processes deployed (processType) and specifi es for each the type of event that can start it (triggeringEventType). The table’s main purpose is to route start events: when an external event arrives, if ProcessStarter can map it to a process, then a new instance of that process is created from the event.

Several tables track the state of process instances. The Process table assigns a unique identifi er to each instance (procID), indicates its type (processType), locates it in a conversation (convID), and records its start time, end time, and status (pending, completed, or aborted). The ProcessVariable table persists process variables, ensuring that instance-specifi c data survives system restarts. A variable is identified by a name (name) that is unique within its level of scope (scope) in a process instance (procID). The ProcessAudit table keeps a chronological list of important occurrences in a process instance. It is tied to a specifi c instance (procID), and has both a timestamp and a text entry. The entry can optionally be associated with a specifi c process activity (activityID). Implementations can extend the model by providing a custom state table (such as the hypothetical MyAppState in the diagram) that associates application-specifi c fi elds (myState, in this example) with an instance.

Final ly, the PendingEvent table assists in correlating intermediate events. An event is identifi ed by the combination of its process instance (procID), its activity node in the process (activityID), and if it is part of a deferred choice, the identity of that choice (choiceActivityID). (If the event is not part of a choice, choiceActivityID is zero or null.) There are two types of events: timed events and events triggered by a message. If the event is a timed event, timeToFire specifi es the date and time (somewhere in the future) when the event should fi re. If the event is message-based, triggeringEventType indicates the type of message that triggers it. When the event is created, the Boolean fi eld isDone is set to false. When the event fi res, isDone is switched to true. If the event is part of a choice, isDone is set to true for all events in the choice, thereby ensuring that only one event is chosen.

The model assumes that all messages carry the following fi elds:

• Event Type
• Recipient Process Type
• Conversation ID

When a message arrives, the following logic determines how to route it:

• If there is an instance of the process in the conversation (that is, if there are rows in Process where processType and convID match the values from the message), check whether it has a pending event of the given event type (that is, check for rows in PendingEvent where procID matches the value from Process, isDone is false, and triggeringEventType matches the event type). If it does, fire the event. Otherwise, discard the event.
• If there is no instance of the process in the conversation, check whether the process can be started by this type of event. (That is, check for rows in ProcessStarter where processType and triggeringEventType match those from the message.) If so, instantiate the process. Otherwise, discard the event.

We put this model to use in the next section. Refer to the discussion of correlation in Chapter 4 for more details on this approach, especially the use of optimistic locking to prevent two simultaneous events from firing.

Combining Short-Running Processes with State in TIBCO‘s BusinessWorks

The next discussion covers the TIBCO implementation of the email transfer process.

Our Use Case—Sending Money by Email

With this model in place, we build a process that spans several days as a set of short-running processes, none of which lasts more than a few seconds. The use case we consider is email money transfer, introduced in our discussion of choreography in Chapter 4. In a transfer there are four main parties: the sender, the sender’s bank, the recipient, and the recipient’s bank. We build the process for the sender’s bank.

The following figure depicts the required fl ow of events:

When the bank receives the request to send funds from the sender (Sender’s Request), it validates the request (Validate Request), and rejects it if discovers a problem (Send Reject to Sender). If the request is valid, the bank informs the sender of its acceptance (Send Accept to Sender), notifi es the recipient by email (Send Email To Recipient), and sets aside funds from the sender’s account (Allocate Funds). The fi rst burst is complete, but several possible paths can follow:

1. There is a time limit on the transfer, and if it expires the transfer is aborted.
2. The sender may cancel the transfer.
3. The sender’s bank may reject the recipient’s bank’s request to move the funds into the recipient’s account. The recipient may try again later.
4. The sender’s bank may accept the recipient’s bank’s request to move the funds into the recipient’s account.

The control flow to support this logic is a deferred choice inside a loop. The loop runs for as long as the variable loopExit is false. The process initializes the value to false (Set loopExit=false) immediately before entering the loop. Paths 1, 2, and 4 set it to true (Set loopExit=true) when they complete, signaling that there is no further work to do and the loop need not make another iteration. Path 3 leaves the loopExit fl ag alone, keeping it as false, thus allowing another iteration (and another chance to complete the transfer). Each iteration is a burst.

There are three events in the deferred choice, one for expiry (path 1), one for cancellation (path 2), and one for the recipient’s bank transfer request (paths 3 and 4). The logic for cancellation and expiry (headed by the events Sender’s Cancellation and Expired respectively) is identical: the process sends a cancellation email to the recipient (Send Email Recipient), informs the sender that the transfer is aborted (Send Abort to Sender), and restores the funds to the sender’s account (Restore Funds). In the transfer request path (starting with the event Recipient Bank’s Transfer Request), the sender bank validates the transfer (Validate Transfer) and sends the outcome to the recipient’s bank (Send Reject to Recipient Bank or Send Accept to Recipient Bank). If validation passes, the process also notifi es the sender that the transfer is complete (Send Completion to Sender) and commits the funds it had earlier allocated (Commit Funds).

The sender’s bank’s process is long-running, typically spanning several days from start to fi nish. To build it using a short-running process engine, such as TIBCO‘s BusinessWorks, we need to break it into smaller processes: one to handle the sender’s request to send funds, one to handle the recipient’s bank’s request to complete the transfer, one to handle the sender’s cancellation, one to handle expiry, and one to manage the overall event routing. In dividing the process into pieces, we lose the loop and deferred choice, but we add housekeeping responsibility to each piece.

The Router Process

The next figure shows the BusinessWorks process to handle the overall routing.

When it receives an inbound message on a JMS queue in GetEvent, the router process checks the event type to determine to which BusinessWorks process to route the event. There are three event types:

• Request: Sent by the account holder (known as the sender). Because this request starts the process, it must not contain a conversation identifi er. If it does, the route process immediately logs the event as an error and discards it (Log Illegal Input). Otherwise, it queries the ProcessStarter table, in the step Check Starter Enabled, to verify that the email transfer process may be started by this type of event. (It checks that there is a record in the table that matches the given event type and process type.) If this check passes, the route process creates a unique conversation identifi er (Set Conv ID) and calls the request process to handle the event (Call Request Process).
• Transfer: Sent by the recipient bank. The route process checks that the message has a conversation identifi er. If it does, it calls the transfer process (Call Transfer Process) to handle the event. Otherwise, it logs the event and discards it (Log Illegal Input).
• Cancel: S ent by the sender or internally by the timer process (discussed further next). The route process checks that the message has a conversation identifi er. If it does, it calls the cancellation process (Call Cancel Process) to handle the event. Otherwise, it logs the event and discards it (Log Illegal Input).

The Request Process

The next figure shows the BusinessWorks process to handle the sender’s request to send funds:

The process begins by creating a unique process identifi er (Set Proc ID) and then validates the request (Validate Request). If the request is invalid, the process sends a rejection to the sender (Send Reject to Sender) and writes three records to the database:

1. A record in the Process table (using Add Process Record Aborted) that sets the status of the instance to ABORTED. The process identifi er is the one created in Set Proc ID.
2. A log of the validation failure (using Add Audit Invalid Req) in the ProcessAudit table.
3. A copy of the inbound message in the ProcessVariable table, using Add Variable Request. The earlier step RequestAsString converts the message from XML to string form.

Thus, there is a record that the instance was aborted, an explanation in the audit trail why it failed, and a copy of its message data.

The happy path, in which the request passes validation, contains three steps that we described earlier: Send Email Recipient, Send Accept to Sender, and Allocate Funds. It also creates the following records in the database:

• A record in the Process table (using Add Process Record Pending) about the instance, with a status of PENDING and the identifier created in Set Proc ID.
• An indication that the validation passed (using Add Audit Valid Request) in the ProcessAudit table.
• A copy of the inbound message (using Add Variable Request 2) in the ProcessVariable table.
• Three PendingEvent records, for transfer, expiry, and cancel respectively (using the steps Add Transfer Event, Add Expiry Event, Add Cancel Event). The records share a common choiceActivityID, and for each the isDone fi eld is set to false.
• A record in the custom table EXState (using Add EXState), which extends the Process table with information specifi c to email transfers. The next figure shows the EXState table and its relationship to Process. The table adds one fi eld to the mix, numRejects, which is initialized here to zero and is incremented each time the sender’s bank rejects the recipient’s bank’s transfer request.

When the happy path completes, the PendingEvents table has, among its contents, three records similar to the following:

According to this information, process instance 123 has three pending events, whose activityIDs are Cancel, Expiry, and Transfer respectively. These events are set in a single deferred choice, whose choiceActivityID is 1. None of these events has occurred, indicated by isDone being false. The Cancel and Transfer events are triggered by the inbound events types EX.Cancel and EX.Transfer respectively. The Expiry event does not have a triggering event type, but has a timeToFire confi gured for December 13, 2008; Expiry is a timed event.

When one of these events arrives, it is processed only if the isDone fi eld is false; otherwise it is discarded. When it is processed, the isDone fl ag is set to true for all three events. Marking all three true in effect marks the whole deferred choice as complete, and prevents a second event from occurring.

The Transfer Process

The process that handles the recipient’s bank’s request for transfer is shown in the following figure.

The process begins immediately by querying the PendingEvent table to check that its event is still pending (FindEvent). If it has already been marked as completed, the process rejects the request (Send Reject to Recipient Bank Event Not Found) and quits. Assuming the event is permitted, the process marks the choice as completed (Remove Event) and validates the request (Validate). If validation passes, the process, as already discussed, sends an acceptance to the recipient’s bank (Send Accept Recipient Bank) and a completion notifi cation to the sender (Send Completion Sender), commits the funds (Commit Funds), and then performs the following table updates:

• In the Process table, it sets the instance status to COMPLETED (using Close Process).
• It adds an entry to the ProcessAudit table (using Add Audit), indicating that the transfer succeeded.
• It saves the transfer request message to the ProcessVariable table. If a previous version of the message is already there, the process overwrites it (Update Variable); otherwise, it inserts a new message (Insert Variable).

If validation fails, the process sends a rejection message to the recipient bank (Send Reject Recipient Bank) and makes four table updates:

1. It restores the deferred choice (using Restore Event), setting isDone to false for each of the three events (Restore Event).
2. It increments the numRejects fi eld in the EXState table (Add Reject).
3. It adds an entry to the ProcessAudit table (using Add Audit), indicating that the transfer failed.
4. It saves the transfer request message to the ProcessVariable table, using the same logic as above.

The successful validation path effectively terminates the larger process by removing all of its pending events. The failed validation path effectively loops back in the larger process to an earlier point, giving each of the events another chance to fire.

The Cancellation Process

The process to handle cancellation, shown in the next fi gure, starts out much the same way.

The process fi rst checks that the event is still pending (Find Event), and if so, disables the deferred choice (Remove Event). The process then notifi es the sender and the recipient of the cancellation (Send Recipient Email and Send Abort to Sender), restores the funds (Restore Funds), and update the tables as follows:

• It marks the status of the instance as ABORTED (Close Process).
• It adds an audit entry indicating cancellation (Add Audit).
• It saves the cancellation event to the ProcessVariable table (Save Variable).

The Expiration Process

The process to handle expired transfers, shown in the next fi gure, is somewhat different.

The expiration process is not designed to handle the expiry of a single transfer. Rather, it scans the PendingEvents table for all expired transfers (Get Expired Transfers), and fi res a cancellation event for each of them. The outer box labeled For Each Expired is a for loop that, for each record returned by the query, constructs a cancellation message (Create Cancellation Message) and launches a cancellation process (Launch Cancellation Process) to handle the message. It launches the process by sending a message on the JMS queue to which the routing process listens. The routing process, when it receives the event, routes it to the cancellation process. Thus, it is the cancellation process that will disable the deferred choice and abort the instance, not the timer process.

		The timer process runs on a predefi ned schedule. The Poller step
		defines how often it runs (every fi fteen minutes, for example). The timer
		process is not designed to run at the very moment a particular transfer
		expires. BusinessWorks manages the schedule internally; the schedule is
		not configured in our process state model.</code>

A Note on Implementation

TIBCO‘s BusinessWorks is designed for performance, and admittedly our processes make database updates rather liberally. (The request process has seven updates in the happy path!) More effi cient alternatives are to fl atten the data model (so that there are fewer tables to update) or build stored procedures to bundle updates (resulting in less IO to the database server).

Another option is use TIBCO‘s proprietary checkpoint mechanism to serialize process state to the disk. The checkpoint feature is clumsy but is often an effi cient way to achieve the effect of long-running state in an engine that is designed for short-running processes. As a proprietary capability, it does not work as part of a generalized state model, which is why we did not demonstrate it here.

Fast Short-Running BPEL

We conclude with a discussion of compiled BPEL.

Uses of Short-Running Processes

Having developed an approach to keep SOA processes running for an arbitrarily long time, we now turn our attention to short-running processes and ask: how can we make them run as fast as possible? The two most common uses of a short-running process are:

1. To implement a synchronous web service operation. The process begins with an input message, runs through a quick burst of logic to process it, sends back the output message, and completes. The client application blocks for the duration, as diagram (a) in the next fi gure shows. If the process moves too slowly, the client will complain about the response time.
2. To perform complex routing for the ESB. As David Chapelle discusses in his book Enterprise Service Bus (O’Reilly, 2004) , a good ESB can natively perform basic content-based- and itinerary-based-routing, but it needs orchestration processes to handle more complex routing patterns. In diagram (b) in the figure, when the ESB receives a message, it passes it to an orchestration process that proceeds to perform in eight steps a series of transformation and invocation maneuvers that could never be achieved with the basic branching capabilities of the ESB. Again, speed is critical. The ESB prefers to get rid of messages as soon as it gets them. When it delegates work to an orchestration process, it expects that process to move quickly and lightly.

Architecture for Short-Running Processes

In considering a design to optimize the performance of these two cases, we assume that our stack, like the model stack we discussed in Chapters 1 and 3, has both an ESB and a process integration layer. All messages in and out of the stack go through the ESB. The ESB, when it receives an inbound message, routes it to the process integration engine for processing. The process integration engine, in turn, routes all outbound messages through the ESB. Further, we assume that the ESB uses message queues to converse with the process integration layer. Client applications, on the other hand, typically use web services to converse with the ESB.

The following fi gure shows how we might enhance this architecture for faster short-running processes. (The implementation we consider is a Java-based BPEL process engine.)

When a client application or partner process calls through the ESB, the ESB routes the event, based on the event’s type, either to the general process integration engine or to an engine optimized for short-running processes. To route to the general engine, the ESB places the message on the Normal PI In Queue. That engine is drawn as a cloud; we are not concerned in this discussion with its inner workings. To route to the optimized engine, the ESB either queues the message on SR In Queue or, to reduce latency, directly calls the short-running engine’s main class, ProcessManager. (Direct calls are suitable for the orchestration routing case described in the previous figure; there, processes run as an extension of the ESB, so it makes sense for the ESB to invoke them straightaway.) A set of execution threads pulls messages from SR In Queue and invokes ProcessManager to inject these inbound events to the processes themselves. The role of ProcessManager is to keep the state of, and to execute, short-running processes. Each process is represented in compiled form as a Java class (for example, ProcessA or ProcessB) that inherits from a base class called CompiledProcess. Compiled classes are generated by a tool called BPELCompiler, which creates Java code that represents the fl ow of control specifi ed in the BPEL XML representation of the process. ProcessManager runs processes by creating and calling the methods of instances of CompiledProcess-derived classes. It also uses TimeManager to manage timed events. Processes, whether running on the general engine or on the optimized engine, send messages to partners by placing messages on the outbound queue Out Queue, which the ESB picks up and routes to the relevant partner.

A general process engine is built to handle processes of all durations, long and short alike, and, with a mandate this extensive, does not handle the special case of time-critical short-running processes very effectively. There are three optimizations we require, and we build these into the short-running engine:

1. Process state is held in memory. Process state is never persisted, even for processes with intermediate events. Completed process instances are cleaned out of memory immediately, so as to reduce the memory required.
2. Processes are compiled, not interpreted. That is, the process defi nition is coded in Java class form, rather than as an XML document. Compilation speeds the execution time of a burst.
3. The process may defi ne timed events of a very short duration, to the order of milliseconds. Furthermore, the engine generates a fault when the process exceeds its SLA. The process may catch the fault or let it bubble up to the calling application.

The architecture we sketched in this section, as we discover presently, is designed to meet these requirements.

Example of a Very Fast Process

The next figure shows a short-running process with multiple bursts that benefits from these optimizations.

When the process starts, it initializes its variables (InitVars) and asynchronously invokes a partner process called the Producer (Call Producer Asynx). It then enters into a loop (FetchLoop) that, on each iteration, waits for one of the two events from the Producer: result or noMore. If it gets the result event, it, in parallel, invokes two handler services (Call Handler A and Call Handler B), and loops back. If it gets the noMore event, the process sets the loop’s continuation fl ag to false (Set Loop Stop). The loop exits, and the process completes. While it waits for the producer events, the process also sets a timed event (too long) that fi res if neither event arrives in suffi cient time. If the timer expires, the process sends an exception message to the producer (Send Exception Msg Producer Async), and loops back.

The timing characteristics are shown in parentheses. The producer, on average, sends a result or noMore event in 80 milliseconds. The handlers that the process invokes to handle a result event average 50 milliseconds and 70 milliseconds, but because they run in parallel, their elapsed time is the greater of these two times, or 70 milliseconds. Thus, an iteration of the loop with a result event averages roughly 150 milliseconds. An iteration with a noMore event averages just 80 milliseconds, because the activity Set Loop Stop runs nearly instantaneously. The cycle time of an instance with one result iteration and one noMore iteration is just 220 milliseconds. The too long timed event has a duration of 200 milliseconds, which in itself is rather a small interval, but is a huge chunk of time compared to the normal cycle time. The cycle time of an instance whose three intermediate events are result, too long, and noMore is 420 milliseconds on average. Times this fast cannot be achieved on a general-purpose engine.

Running the Very Fast Process on the Optimized Engine

The se quence diagram in the following fi gure illustrates how this process runs on the short-running engine:

The process starts when client application sends a message intended to trigger the process’ start event. The Pro cessManager receives this event (either as a direct call or indirectly via an execution thread that monitors the shortrunning inbound queue) in its routeMessageEvent() method. It then checks with the process class—shown as Process in the fi gure, a subclass of the CompiledProcess class we discuss presently—whether it supports the given start event type (hasStartEvent()), and if so, injects the event into the process (onStartEvent()). The process, as part of its logic, performs the activities InitVars and CallProducerAsync and enters the fi rst iteration of the while loop, in which it records in its data structures that it is now waiting for three pending events (Set Pending Events). Because one of these events is a timed event, it also registers that event with the TimeManager (addEvent()).The fi rst burst is complete.

In the second burst, the producer process responds with a result event (result: routeMessageEvent()). The ProcessManager checks whether the process instance is waiting for that event (hasPendingEvent()) and injects it (onIntermediateEvent()). The process invokes the two handlers (that is, it invokes CallHandler on HandlerA and HandlerB), completing the fi rst iteration of the loop. It now loops back, resets the pending events (Set Pending Events), and registers a new timed event (addEvent()). The second burst is complete.

Assuming the producer does not respond in suffi cient time, the timer expires, and the TimeManager which checks for expired events on its own thread notifi es the Process Manager (routeTimedEvent()). ProcessManager gives the event to the process (calling hasPendingEvent() to confi rm that the process is waiting for it and onIntermediateEvent() to inject it), and the process in turn performs the SendExceptionMsg activity, completing the second iteration of the loop. The next iteration starts, and the process resets its pending events. The third burst is complete, and we leave it there.

Managing Inbound Events and Timeouts

The sta te information needed to tie all of this together is held in memory.

ProcessManager maintains a data structure called instanceList that, much like the Process table just described, keeps a list of process instances indexed by the combination of conversation identifi er and process type. The list contains references to CompiledProcess-derived objects. The logic for routeMessageEvent(), in pseudo code, is the following:

	Does instanceList have instance for specified process type and conv
									ID?
	If no
	   Instantiate this instance
	   Create a unique PID
	   Add instance of instanceList
	   Call process.hasStartEvent() to check if proc supports
	   start event of specified type
	   If no, return error
	   Else
	      Call process.onStartEvent()
	   End If
	Else
	   Call process.hasPendingEvent() to check if proc supports
							intermediate
	   Event of specified type
	   If no, return error
	   Else
	      Call process.onIntermediateEvent()
	   End Id
	End If</code>

TimeManager keeps a list of timed events, each tied to a particular wait node in a process instance. TimerManager’s thread periodically sweeps through the list, finding events that have expired. It calls ProcessManager’s routeTimedEvent() method to inject the event to the instance. Three types of timed events are supported:

• wait activity
• onAlarm activity
• SLA on the instance

The first two event types simply wake up the process. If the process previously entered a wait activity, for example, the timed event causes it to complete. The third generates a fault. If the process has a handler for this fault, control moves immediately to the handler. Otherwise, the instance is immediately aborted.

Compiled Form

The Com piledProcess class (the base class for compiled BPEL processes) keeps track of variables, current pending events, and permitted start events, holding in memory the same sort of data that is defi ned for the tables ProcessVariable, PendingEvent, and ProcessStarter. Here is an excerpt of the code:

	public abstract class CompiledProcess {
	   List pendingEvents = new ArrayList();
	   Map variables = new HashMap();
	   String pid;
	   String convID;
	   public abstract <b><i>BPEL</i></b>Graph getGraph();
	   public boolean hasStartEvent(….) {
	      check graph to see if specified event is allowed
	   }
	   public boolean hasPendingEvent(….) {
	      check pendingEvents list to see if specified event is allowed
	   }
	   public void onStartEvent(…){
	      walk();
	   }
	   public void onIntermediateEvent(…) {
	      remove event from pending events
	      walk();
	   }
	   void walk() {
		From the node containing the current event, navigate forward in
		the graph until the process completes or we hit another
		intermediate event.
		When we hit an intermediate event,add it to the pendingEvents
									list.
		For timed events, register them with TimerManager too.
		Update process variables as needed.
	   }
	}
</code>

Notice that the class is marked abstract, and that its method getGraph() is not implemented. In our design, each BPEL process is run through a special compiler utility that generates a Java class extending CompiledProcess. The utility, called BPELCompiler, is a Java program that takes as input the XML source code for the BPEL process. It parses the XML and outputs a Java source fi le that is later compiled and loaded into the address space of the process engine. At runtime, the BPEL process runs at the speed of compiled Java. We thus save the performance-stultifying effect of runtime XML parsing and serialization that affl icts many process engines.

Here is a snippet of the Java source of the class for our sample short-running process:

	public class SRProcess extends CompiledProcess {
	static <b><i>BPEL</i></b>Graph graph = null;
	   static {
		graph = new <b><i>BPEL</i></b>Graph();
		graph.initGraph();
		graph.addSequence();
		graph.addArc(1,3);
		graph.addArc(4,2);
		graph.addReceive(&quot;client&quot;,&quot;client:SRProcess&quot;,&quot;initiate&quot;,true,
		   &quot;inputVariable&quot;);
		graph.addArc(3,5);
		graph.addAssign(rules6);
		graph.addArc(5,6);
		graph.addInvoke(&quot;Producer&quot;,&quot;ns1:SRProducer&quot;,&quot;initiate&quot;,
		   false,&quot;producer&quot;,null);
		graph.addArc(6,7);
		graph.addWhile(&quot;bpws:getVariableData(‘keepGoing')=true()&quot;);
		graph.addArc(7,8);
		graph.addPick(false);
		graph.addArc(8,10);
		graph.addArc(11,9);
		graph.addOnMessage(&quot;Producer&quot;,&quot;ns1:SRProducerCallback&quot;,
		   &quot;onResult&quot;,10,&quot;result&quot;);
	   	...
	   }
	   @Override
	   public <b><i>BPEL</i></b>Graph getGraph() {
	      return graph;
	   }
	}
</code>

The class does nothing except build a graph representing its process defi nition. It begins by declaring a class-scoped member variable called graph (static BPELGraph graph = null;). In the static intializer code that follows (beginning with static {), it instantiates this attribute (graph=new BPELGraph();) and proceeds to construct it as a set of nodes (for example, graph.addSequence(), graph. addReceive(), graph.addAssign(), graph.addInvoke(), graph.addWhile(), graph.addPick(), and others not shown) and arcs (graph.addArc()). The class also overrides the getGraph() method that is left abstract in the base class. This method simply returns a reference to the graph variable.

And that’s all there is to the generated class. It inherits the most important methods from the base class. Its job is to fi ll in the one missing ingredient: the actual process defi nition. Signifi cantly, it creates this defi nition (that is, the graph) at class scope, so that there is only one copy of it in the process engine, not one copy per process instance. This saves a lot of memory.

The structure of the graph is similar to that of the XML-defined process in the source—which is not surprising given that this code is generated from a parse of the XML. The next fi gure depicts the graph constructed in the compiled process.

Here is a snippet of the corresponding BPEL source, predictably similar to the graph:

	<process>
	   <sequence>
	      <receive>
	      <assign name=&quot;InitVars&quot; />
	      <invoke name=&quot;Call Producer Async&quot; />
	      <while>
		<pick>
		   <onMessage name=&quot;result&quot;>
		      <flow>
			<invoke name=&quot;Call Handler A&quot; />
			<invoke name=&quot;Call Handler B&quot; />
		      </flow>
		   </onMessage>
	           <onMessage name=&quot;noMore&quot;>
			<assign name=&quot;Set Loop Stop&quot; />
		   </onMessage>
		   <onAlarm name=&quot;Too Long&quot;>
			<invoke name=&quot;Send Exception Msg&quot; />
		   </onMessage>
	        </pick>
	      </while>
	   </sequence>
	</process>
</code>

The surest way to learn the functionality of compiled processes and the short-running engine is to play with the accompanying compiler demo. See About the Examples for a download link.

Compiled Code—What Not To Do

A n alternative to the graph implementation is to represent the process as a single block of code, as follows:

	InitVars();
	   CallProducerAsync();
	   While (loopContinue)
	      WaitNextEvent()
	      If (event is result)
		Fork (CallHandlerA)
		Fork (CallHandlerB)
		Join the forks
	      Else if (event is noMore)
		Set loopContinue = false
	      Else if (event is too slow)
		SendExceptionMsg();
	      End If
	   End While
</code>

Though simple, this code hampers performance, because the intermediate event in WaitNextEvent() ties up an execution thread while it waits. That’s one less thread for the process engine to work with, which might be needed elsewhere. The graph implementation might be a little harder to code—that code is generated by a tool anyway—but it uses resources more effi ciently. Performance is the point, after all.

About the Examples

The source code for this chapter is available for download in the code bundle. Refer to the README fi le for information on how to set up and run the examples.

The example of email funds transfer, which demonstrates how to build a long-running process out of several short-running processes, uses TIBCO‘s BusinessWorks 5.6 and Enterprise Message Service 4.4, as well as an RDBMS. TIBCO products can be downloaded from http://download.tibco.com. You must have an account to access this site. Once in, there are several installation programs to download; refer to our README fi le for the complete list.

The BPEL compiler is a set of Java programs. To run them, you require JDK 1.4 or higher. If you wish to compile the source code or run the programs from Eclipse, you need Eclipse 3.0 or later.

Summary

SOA processes have both active and passive activities. Active activities include calls to systems and services, data manipulations and transformations, and scripts or inline code snippets. Passive activities are events. When performing active activities, the process is actively performing work, tying up the process engine. Events put the process into an idle wait state.

An event can occur at the beginning of the process or in the middle. Every SOA process starts with an event. An event in the middle is called an intermediate event, and not every SOA process has one. The segment of a process between two events is called a burst; in a burst, the process performs active activities.

Processes are classifi ed by duration as short-running, long-running, or mid-running.

Short-running processes span no more than a few seconds. Many short-running processes are a single burst, but some have intermediate events, which break the process into multiple bursts. Languages that support short-running processes include TIBCO‘s BusinessWorks and BEA’s Weblogic Integration.

Long-running processes run longer—often days, weeks, months, or years— than the uptime of the process engine on which they run. Most of the time is spent waiting on intermediate events; the bursts themselves are quick. The engine persists the state of such processes to a database to survive a restart. Languages that support long-running processes include BPEL and Weblogic Integration.

Mid-running processes run for about the duration of a phone call in a call center. In call center usage, processes are structured as question-and-answer conversations between agent and customer. Bursts process the previous answer and prepare the next question; intermediate events wait for the customer’s next answer. The engine keeps process state in memory. If the engine goes down, in-fl ight instances are lost. Chordiant’s Foundation Server is an example of this sort of implementation.

Process data models include process metadata (information about the types of processes currently deployed), instance data (the status of live instances of processes), and pending events (and how to correlate them with instances). We studied the data models in Oracle’s BPEL Process Manager and BEA’s Weblogic Integration, and developed our own model that generalizes these. We used this model to build a use case that requires a long-running process (email funds transfer) from several short-running processes in TIBCO‘s BusinessWorks.

We concluded by designing a process engine optimized for short-running processes. The design is able to run short-running processes faster than a typical process engine because process state is held in memory (never persisted), processes are compiled rather than interpreted, and the process may define timed events of a very short duration. Further, the engine generates a fault when the process exceeds its SLA; the process may catch the fault or let it bubble up to the caller.

java weblogic.j2eeclient.Main applicationclient.jar t3://localhost:7001

javax/transaction/TransactionSynchronizationRegistry and weblogic/
        transaction/TransactionSynchronizationRegistry.