Java Development News:

Enterprise Java Beans for building Business Process Management Applications

By Setrag Khoshafian and Partha Nageswaran

01 May 2006 | TheServerSide.com

1. Introduction

Business Process Management Suites have come a long way. The amalgamation of human workflow, enterprise application integration, business to business integration, business rules management, and process monitoring has resulted in the emergence of holistic end-toend Business Process Management Suites. The following figure illustrates the components of Business Process Management Suites.


Click for screen shot

Figure 1: BPM Suites

BPM Suites are being deployed on highly distributed platforms, and for mission critical applications. It is not uncommon to see Fortune 2000 companies deploy robust, distributed, and clustered application servers to host BPM Suite engines that in turn host BPM applications. We shall see application servers, more specifically component containers, provide transactional, security, reliability, and performance advantages to the hosted BPM Suite applications. More specifically, in addition to the BPM Engine executing within the component container tier, BPM Suite applications could themselves be published as components. In the coming sections we will elaborate and expand upon EJB component support for the BPM Suite. Section 2 discusses the various service layers of BPM Suites in the context of J2EE application servers. Section 3 goes deeper into component container support for BPM Suites, especially EJB components. The BPM engine itself executes as a collection of session and message driven beans. Furthermore, you can dynamically generate EJBs, especially typed signature-based EJBs, from your application flows or business rules. Utilizing component containers for this dual purpose (core engine as well as generated business logic component EJBs) empowers the BPM Suite with all the quality of service, transactional, and performance advantages of component container architectures.

2. BPM and Component Architectures

This section will explain how a BPMS leverages component architectures. We must first provide an overview of multi-tier component architectures.

Distributed applications have increasingly leveraged component technologies, such as J2EE and EJBs, over the last few years to benefit from container provided qualities of service. Recall that Components differ from Objects in that Components may only execute within a Container since they require runtime qualities of services, as specified in deployment descriptor (XML) files or annotations. Containers or frameworks, which host these components at runtime, use these descriptors or annotations to provide the stipulated runtime qualities of service prior to invoking the logic coded in the components. This powerful feature enables the decoupling of code to enable qualities of service (cross-cutting functionality), such as security (e.g., authentication) and Transaction API calls, from business logic code.


Click for screen shot

Figure 2: Generic Multi-tier Architecture

Figure 2 depicts a generic Multi-tier Architecture that illustrates how browser based clients may access business logic component EJBs by sending HTTP requests to a Servlet, which then communicates via RMI/IIOP with the EJB. JSPs are leveraged to generate the output HTML in this scenario. Alternatively, thick clients could access EJBs directly by sending RMI/IIOP requests. The EJB Object "intercepts" the calls to the EJBs and based on the configured qualities of services (such as transactions, security, etc.), enables those services prior to calling the Business Logic method on the EJB. The DAO (Data Access Object) is the logic component that enables persisting and retrieving business data.

As an illustration of this, consider a Business Logic method that requires transactions to be invoked prior to the logic being executed. One way to achieve this is to programmatically invoke transactions as follows:

...public class InsuranceApp ... { 
public void applyForInsurance (...) { 
// Start a transaction by accessing the UserTransaction object 
// from JNDI in a J2EE environment 
Properties env = new Properties(); 
env.setProperty("java.naming.factory.initial", "..."); 
env.setProperty("java.naming.provider.url", "..."); 
InitialContext ctx = new InitialContext(env); 
UserTransaction ut = (UserTransaction) 
PortableRemoteObject.narrow("usertransaction", 
UserTransaction.class); 
// Note that "usertransaction" is assumed to be the name of the 
// stub bound into JNDI 
ut.begin(); 
try { 
// Business Logic implementation goes here 
ut.commit(); 
}
catch(...){ 
// handle exception 
ut.rollback(); 
}f
inally { 
// check and ensure that the transaction is 
// is committed or rolledback 
} 
} 
}

In this case, the cross-cutting functionality that enables transactions is coded along with the core functionality (business logic). This approach has limitations - consider a scenario where this functionality is to be "aggregated" into other functionality. When this method is invoked by the composing logic, the composing logic had better not have started its own transactions since J2EE does not support nested transactions. Note that at a minimum, such code should be introduced as an Aspect, by leveraging Aspect Oriented Programming (AOP), since AOP is geared towards weaving cross-cutting functionality, such as transaction support, at compile or runtime.

An alternative approach is to leverage Component technology and move the cross-cutting functionality into a deployment descriptor XML file as opposed to embedding it as code within the core functionality. Yet another alternative involves placing the cross-cutting functionality as annotations along with the core functionality. In these scenarios, the transaction-attribute for this cross-cutting functionality may be set to "RequiresNew," in which case the EJB container does the following:

  • If the caller of this functionality has NOT started a transaction, the EJB Container sets up a transaction
  • If the caller of this functionality has already started a transaction, then the in-coming transaction is suspended, a new transaction is spawned in which context the business logic functionality executes and commits (or rolls back), and then the original transaction is resumed.

Instead of the transaction attribute being "RequiresNew", "Required" could be used in which case the EJB Container does the following:

  • If the caller of this functionality has NOT started a transaction, the EJB Container sets up a new transaction.
  • If the caller of this functionality has already started a transaction, then the functionality executes in the context of the calling transaction.

This powerful ability to descriptively achieve the desired transaction behavior without writing code (and the ability to modify it easily when the behavior is to change) is a compelling reason why Component technology such as EJBs are leveraged extensively in Enterprise applications.

BPM applications typically compose functionality based on process flow definitions and rules. Some processes may be invoked stand-alone in certain circumstance, thus requiring their own transactions. The same processes may be composed by higher level processes which may have spawned transactions. Here, the powerful declarative quality of service provided by an EJB container may be leveraged to achieve the desired transaction behavior in either case. This is a compelling reason for BPM applications to leverage component technologies such as EJBs.

Aside from J2EE, there are several other emerging component enabling frameworks, such as Spring. While the lighter weight frameworks such as Spring are increasingly leveraged in the enterprise, the mature EJB technology (particularly Session EJBs) continue to be used extensively. It is to be noted that the discussions below could have referred to any component technology, not just EJBs.

Also most IDEs for Java developers support EJBs natively. Therefore, while the EJB technology has its own set of issues (including complex programming model, potential performance overheads when not used appropriately, etc.), it is very much here to stay and relevant in the enterprise as evidenced by the number of applications that continue to leverage this technology.

As discussed above, distributed applications that use EJBs wisely and appropriately may benefit from several (declarative or programmatic) qualities of services that the EJB container provides. These qualities of services include distributed transactions, role-based authentication, and life cycle management. Conversely, applications that use EJBs inappropriately may end up with increased complexity and possibly significantly reduced performance.

In fact, only two types of EJBs are prevalent in most enterprise implementations where performance is a factor - Stateless Session EJBs and to some extent, Message Driven Beans (MDBs). These EJBs are leveraged to implement Business Logic components. The other types of EJBs including Stateful Session EJBs and Entity EJBs are NOT leveraged as much for various reasons including:

  • Potential Performance Degradations:
    • Entity EJBs by default waste a database "Select" operation when loading state from a persistent store to memory with the context of a transaction.
  • Activation and Passivation:
    • Stateful session beans, when not configured appropriately, may incur activation and passivation overheads when being flushed in and out of memory.

Stateless Session EJBs on the other hand are poolable and reusable across multiple client invocations. These EJB are typically used as facades - they act as a single point of entry to business functionality where transaction context may be established and security context validated.

Where a request may be processed asynchronously, Session Facades are replaced with Asynchronous Facades (implemented as Message Driven Beans) that listen on JMS destinations. Clients may invoke methods on the Session Facade or write JMS messages to the JMS destinations where MDBs are listening.

As noted earlier, in cases where the overhead of a container for enabling runtime qualities of services is unacceptable, applications could leverage lighter weight frameworks such as Spring.

2.1 Example

Let us consider an insurance application processing scenario, a typical BPM application. In this application, users may call insurance brokers and apply for auto insurance over the phone. The insurance brokers may leverage a thick client application to process the insurance application (which may include invoking tasks such as getting quotes and checking the age group of the applicant, etc.). As with many Business Process Management applications, some of these tasks invoked in this application may require manual intervention while other may not. BPM applications such as this may have rules configured, which determine which task may be invoked during runtime.

Note that we are considering a thick client only for illustration purposes. The client of the BPM application could be local or remote EJBs that is composing the BPM application functionality into its own functionality.


Click for screen shot

Figure 3: Process Flow

Figure 3 above illustrates the Policy Eligibility flow. There will be several business rules associated with this process. For example the determination of the age group is a decision rule that will drive the decisioning to spawn the appropriate sub-process depending on the risk associated with the age group. Here is the definition of the decision rule that decides the risk level, depending upon gender and age:


Click for screen shot

Figure 4: Decision Rule for Age Group

Note that the rule uses the same object model as the process and there are no separate integration or invocation issues. All rules execute in the same JVM as the business process execution in a cohesive BPM suite engine. We should point out here that the BPM suite generates Java as target code. So the flow as well as business rules, user interfaces, and integration components are generated from the higher-level graphical forms. Additionally the BPMS stores and manages the processes and rules in its application repository. The BPMS allows you to specialize (version, inheritance, situational selection) your repository so that you apply the best flow or the best process for a given specialized situation.

A non-optimal implementation of such an application may implement the process flow as well as the rules as code. This is non-optimal because any changes to either the rules or the process would involve modifications to the Java code (whether implemented in plain old Java objects (POJOs) or EJBs, etc.), thus constraining the ability to dynamically reconfigure the BPM application.

A more optimal solution is to leverage a BPM suite to define the process flows and associated rules separately from the Java code. Now with EJB support you can also leverage all the aforementioned component architecture advantages for your BPMS engine and applications.

More specifically, component architecture advantages are leveraged for BPM Suites through two fundamental and complementary mechanisms: The BPM Suite engine itself executing in the component tier and the ability to expose the flows or business rules defined in the BPM suite as EJBs, with either generic or signature based interfaces. In the following section we expand upon BPM and EJB Containers, and illustrate the advantages of executing the BPMS engine within EJB containers as well as exposing flows or rules as signature based EJB components.

2.2 BPM and EJB Containers

The BPM Suite capabilities and functionalities are executed in the context of J2EE applications. In fact when it comes to BPM engines and J2EE application servers you have three options:

  • Execute the engine and BPM services entirely as POJOs in the Web container tier.
  • Execute the engine and BPM services entirely in the EJB container tier, involving session, message driven, and entity beans (Figure 5)
  • Mixed execution model involving Web container and EJB container tiers (Figure 6)


Click for screen shot

Figure 5: Engine and BPM Services in the EJB Container


Click for screen shot

Figure 6: BPMS Engine in EJB Container

Note that in the case of the BPM services executing with an EJB Container entirely or in the case of the BPM services executing across the Web and the EJB Container, the BPM services may leverage a lot of the infrastructural functionality provided by these containers. The threading infrastructure provided by application servers may be leveraged by the BPMS, thus making it unnecessary for the BPMS to implement its own threading model. The BPMS may also leverage JTA/JTS for transactions and JAAS for authentication and authorization, infrastructures that are provided by these containers. In addition, it may leverage connection pools and data sources that are configured in the application server.

BPMS may also leverage JCA support provided by the Application Server to access legacy systems in a transactional and secure manner. Another important side-effect of running the BPM services within these containers is that the BPM services themselves may be managed by leveraging JMX, support for which typically exists in Application Servers.

A JMX based administration console may be provided by the BPMS that communicate with MBeans, also provided by the BPMS, to monitor BPM Services as well as executing process flows and rules. The MBeans, which are deployed in the Application Server where the BPMS is deployed, may monitor any aspect of the BPMS and BPM Applications. For instance, a MBean may be provided to monitor the performance of a process flow, while another MBean may be provided that can be leveraged to dynamically reconfigure a process flow to leverage a different database Connection Pool at runtime. Figure 7 provides a general illustration of this benefit.


Click for screen shot

Figure 7: MBeans and BPMS, Process Flow and Rules EJBs

Let us consider the insurance application discussed above. Insurance brokers may leverage thick clients to trigger the Insurance application process flow. In addition, they may access other applications from the same Thick client, such as checking on the driving history (which may have been saved into databases) of a potential client. A dashboard GUI displayed by the thick client could allow the Insurance brokers to invoke the appropriate application activities and pass the appropriate parameters.

In order to check the driving history of a potential client, the thick client may invoke methods on remote business logic components such as Session EJBs which then consults databases (using Hibernate DAOs, plain JDBC DAOs or Entity EJBs, etc.) and returns the driving history of a client.

Similarly, to trigger the insurance application process flow, the thick client could either invoke the generic EJB with a standardize interface that is available from the BPM Suite or invoke a process flow or rules specific signature based EJB, which is generated by the BPM system at process flow or rules definition time. It is important to note that applications may sometime trigger only specific rules that are part of a BPM application instead of the entire flow.

Independent of whether the generic EJB is used or the signature based EJB is leveraged, once a service request has been received in the BPM suite, there is no difference in how the request is processed. The fundamental difference lies in the way clients interact with the generic or signature specific EJB.

Furthermore, since the BPM Suite is a tightly integrated and cohesive system that runs within an EJB Container itself, irrespective of whether generic or signature based EJB is called by a client, the internal calls (between flows and rules that make up a BPM application) are highly efficient and optimized.

Both the generic EJB and the signature based EJB approaches have their benefits. Note that in both cases the EJBs delegate the requests to POJO request handlers which implement the process flow rules. It should be noted that the flow and rules being represented as EJBs that are generated (generic or signature based), offer several opportunities for reuse across:

  • Local clients running in the same JVM
  • Remote Clients running in a different JVM (including other EJBs)
  • Thick GUI clients running as part of different JVM

The ability to invoke the flows or rules from remote or local clients is absolutely essential in a BPM application environment where flows and rules are constantly composed to create more complex applications. A BPM application running externally (possibly as an EJB in another EJB Container) may want to compose a flow or rule that is deployed in a different JVM. A thick client based application may want to compose flow or rules deployed in a different JVM. A web browser based administration application may require the use of a flow or rules, which it can trigger via Servlets in the same JVM as the EJBs. If the flow or rules were implemented as just POJOs then the first two scenarios are not generally feasible.

The Generic EJB

In the case of the generic EJB, the delegation model (where the EJB delegates the calls to a POJO that implements the process flow/rules) allows for new flows/rules to be implemented as POJOs and "plugged in" to the runtime and invoked by the generic EJB using Java Reflection.

Insurance brokers may invoke these functionalities by passing the appropriate activity name and parameters in the thick client dashboard. No additional client side bindings have to be made available since the only bindings necessary are those of the generic EJB.

The parameters passed in as part of the call determine which process/rules are invoked. As long as the Brokers are aware of the name and input parameters required to invoke the new process flows/rules, they may invoke them by specifying those parameters in the dashboard. The thick client application could then invoke the generic EJB and pass those parameters.

A drawback of this approach is that the generic EJB will have to be invoked whether the client is invoking the entire BPM Application (flow) or specific rules within the BPM Application.

Another drawback of this approach is that client side validation and type checking of the input parameters is not feasible. All of the validation, type checking and type coercion have to be performed on the server side. However, since the generic EJB delegates the request to the appropriate POJO that implements the flow/rules using Java Reflection, all necessary validation code may be generated into the POJO. This inability to perform client side validation requires the EJB or the delegated POJO to perform additional validation and exception handling.

Finally, the EJB can only send back to clients unchecked or generic exceptions (since the EJB can't know in advance what exceptions may be generated by a POJO that represents a new set of rules). While unchecked exceptions are preferred over checked exceptions (to reduce the number of catch clauses that need to be coded), in the case of a Thick GUI client, for example, checked exceptions offer additional insights that may be leveraged to generate specific messages to be displayed to the clients, without having to introspect the exception message or nested exception.

While a business delegate may be coded/generated and used to invoke the generic EJB, the business delegate cannot perform service specific optimizations, such as caching of service specific resources.

Signature Based EJB:

The BPM Application illustrated in Figure 3 may signature based EJBs (one for the entire flow and one for the rule - "which age group"). The generated code includes local and remote interfaces, localhome and home interface and the bean implementation class. Shown below, is the generated EJB for the entire insurance application process flow:

Generated Local Home

package InsuranceFlow; 
import javax.ejb.*; 
public interface Auto_Policy_PersonalLocalHome extends EJBLocalHome 
{ 
// Session property types 
public static final String USERNAME = "UserName"; 
public static final String PASSWORD = "Password"; 
public static final String REMOTELOGHOST = "RemoteLogHost"; 
public static final String REMOTELOGPORT = "RemoteLogPort"; 
Auto_Policy_PersonalLocal create(java.util.HashMap 
aSessionProperties) 
throws CreateException;

Auto_Policy_PersonalLocal create() 
throws CreateException; 
} 

Generated Local Interface

package InsuranceFlow; 

import java.util.*; 
import javax.ejb.*; 

public interface Auto_Policy_PersonalLocal extends EJBLocalObject 
{ 
public String startAutoPolicyEligibility(String pyLabel) throws 
Exception; 

} 

Generated Bean Implementation Class


package InsuranceFlow; 

public class Auto_Policy_PersonalBean implements SessionBean 
{ 
private PRServiceClient client = null; 

public Auto_Policy_PersonalBean()
{
}


public void ejbCreate(java.util.HashMap aSessionProperties) 
throws CreateException 

{ 
String classURI = "InsuranceFlow.Auto_Policy_Personal.*"; 
client = PRServiceClientFactory.getClient( 

PRServiceClient.EJB_COMPONENT); 
try{ 

client.initStateful(classURI, aSessionProperties); 
} 
catch(Exception ex){ 

throw new CreateException( 
"Failed to create PRServiceClient client, " + 
ex.toString()); 

}
}


public void ejbCreate() 
throws CreateException 

{ 
String classURI = "InsuranceFlow.Auto_Policy_Personal.*"; 
client = PRServiceClientFactory.getClient( 

PRServiceClient.EJB_COMPONENT); 
try{ 
client.initStateful(classURI, null); 


}
catch(Exception ex){


throw new CreateException( 
"Failed to create PRServiceClient client, " + 
ex.toString()); 

} 
} 

public void ejbRemove() 
{ 
try{ 

client.release();
}
catch(Exception ex){


throw new EJBException( 
"Failed to remove PRServiceClient client, " + 
ex.toString()); 

} 
} 

public void ejbActivate() 
{ 
} 

public void ejbPassivate() 
{ 
} 

public void setSessionContext(SessionContext sc) 
{ 
} 

public String startAutoPolicyEligibility(String arg1) throws 

Exception { 
String methodURI = "startAutoPolicyEligibility"; 
ArrayList reqParams = new ArrayList(1); 
reqParams.add(arg1); 
ArrayList resList = null; 
// Invoke the EJB Service method 
try 
{ 

resList = (ArrayList)client.invoke( 

methodURI, null, reqParams);
}
catch(Exception ex)
{


throw new Exception( 
"PRServiceClient invoke method failed: " + 
ex.toString()); 

} 

// Get returned value 

Object returnParam = resList.get(0); 

String retval = (String)returnParam; 

 
return retval; 
} 
}

Note that in the bean implementation class, in the ejbCreate method we obtain a reference to the POJO to delegate the request to, by leveraging a Factory pattern. The POJO contains the actual implementation of the flow (in this case) or rules. In the startAutoPolicyEligibility method, the request is delegated to the POJO, via Java Reflection.

Similar to the above generated EJB (for the entire application flow), signature based EJBs may also be generated for the "which age group" rule.

In the case of the signature based EJB, when a client needs to invoke the entire BPM or just invoke specific rules within the BPM application (flow), the client may invoke the signature based EJB associated with the flow or the signature based EJB associated with the specific rule. This has significant benefits - clients can leverage an interface that is a meaningful and precise representation of the flow or the rules to be invoked.

BPM Suites may also generate business delegates corresponding to the signature based EJB that may be made available to the client applications. While insurance brokers will still have to specify the name of a flow or rules and associated parameters, the thick client may now translate that information into calls that dynamically load and invoke the business delegates. These delegates may perform action specific parameter validation including type checking, prior to forwarding the call to the corresponding EJBs. The delegates may also expect checked exceptions which can then be translated into specific messages for display to the clients. On the server side, the signature based EJB may delegate the call to the appropriate POJO that implements the flow or rules.

There are other significant advantages to leveraging the generated business delegates that correspond to signature based EJBs. These delegates hide the details of the service implementation from the Client application, thus decoupling clients from server-side implementation details. More importantly, these service specific delegates may also perform caching of resources necessary for the service calls, thus optimizing on performance.

Service specific business delegates may also implement service specific failure recovery code. A server side exception may result in the business delegate attempting a retry of the service invocation (based on the exception), thus preventing the client from having to know how to handle and recover from certain service exceptions.

In addition to the above advantages, signature based EJBs may leverage Dependency Injection[1] to be associated with the POJOs that they need to delegate to. For instance an EJB that is generated to represent the insurance BPM application could have the POJO implementation class injected using Dependency Injection. The benefit here is that association between the signature based EJB and the corresponding POJO implementation class is configurable as opposed to being coded into the components. Contrast this with the case of the generic EJB, where EJB has to instantiate (via Java Reflection) or implement Dependency Pull[2] code to fetch the associated POJO, as opposed to leveraging the preferred Dependency Injection.

3. Conclusions

BPM Suites provide the option of generating EJBs, while themselves executing within the context of an EJB Container in a cohesive optimal manner. The deployment of business process management system within the EJB container provides several advantages:

BPMS can leverage EJB Container provided qualities of services to effectively manage processes. BPMS may delegate to containers to leverage fundamental capabilities such as threading and more advanced capabilities such as instance management, transaction support and security support, instead of having to themselves implement such infrastructural functionalities. Similarly, BPMS may leverage Connection Pools that are supported by Application servers and may leverage the JCA support within an Application Server to access legacy systems. In addition, management of the BPMS itself may be standardized by leveraging JMX support available within the Application Server. MBeans may be leveraged to monitor and manage the BPMS itself, BPM Applications, as well as the EJBs that represent the process flows and/or rules.

In addition to the engine itself executing at the EJB tier, BPM Suites can also generate EJBs from existing processes or business rules. The generated EJBs may either be generic EJBs or signature based EJBs. Since EJBs (particularly Session EJBs) continue to be leveraged extensively and have a noticeable role in enterprise applications as the preferred business logic components, BPMS generated EJBs fit well within the context of standardized Enterprise Architectures. Leveraging EJBs, be it generic or signature based, allows for Process flows or rules to be composed into larger BPM Applications with the right transactional as well as security semantics. However, using signature based EJBs can generally be more advantageous than using the generic EJBs, for reasons summarized below.

  • The Type system of the environment can be fully leveraged - any type mismatches between clients and the called EJB automatically results in compile time or runtime marshalling errors.
  • Clients can decouple themselves from technologies leveraged by BPMS to implement process flows and rules by using Business Delegates (these may also be generated by the BPMS which generates the process flow/rules EJBs). Such Business Delegates can perform target specific caching of resources when accessing signature based EJBs, something that is not easily possible when accessing generic EJBs.
  • Signature based EJBs make it easy for clients (business delegate based client or other clients) to perform client side validation prior to marshalling the request to the EJB. In essence, more robust validation (including client side validation) of input data may be achieved.
  • Signature based EJBs may leverage Dependency Injection to have all Dependency Injected (DI). Since the process flow/rules EJBs are generated such that they delegate calls to a POJO implementation class, the required POJO itself can be injected into the EJB using DI. For generic EJBs this is not feasible as the generic EJB, based on parameters in the call, has to identify the target POJO, instantiate it if necessary and then delegate the call.
  • Service specific error and exception handling can be performed, in the case of signature based EJBs. Each method on a signature based EJB may declare to throw specific application exceptions that the caller (business delegate) may catch and handle appropriately. In the case of generic EJBs, exceptions thrown have to be generic and the caller is responsible for identifying the type of exception and the appropriate exception handling behavior dynamically.

In summary, BPMS have evolved significantly in recent years, to where they can reside and function within an EJB Container and thus leverage the benefits of the EJB Container. In addition, BPMS have evolved to where they can generate either generic EJBs or signature specific EJBs that represent process flows and/or rules. This feature enables ease of integration (locally or remotely) of process flow/rules into applications that need to compose such functionality. It is generally more advantageous to leverage signature based EJBs generated by BPMS, compared to generic EJBs.

Notes

[1] Dependency Injection is a mechanism whereby Components or objects which have references to other objects may have these references initialized by a container or framework, based on configuration files, as opposed to coding the initialization of the references.

[2] Dependency Pull is a mechanism whereby Components or objects which have references to other objects may have these references initialized by calling factories that can instantiate objects necessary to initialize the references.

About the Authors

Partha Nageswaran, a former Advisory Engineer at IBM, currently owns an Enterprise technology consulting and training company. He specializes in providing architectural consulting and instructional services for large corporate clients in technologies including J2EE, Web Services and SOA. He has over 13 years of significant experience having worked on large and small enterprise applications leveraging CORBA, J2EE and Web Services technologies. Nageswaran has three patents in the area of distributed computing and holds three MS degrees in Physics, Mathematics and Computer Science. He can be reached at partha@twresources.com.

Setrag Khoshafian is one of the earliest pioneers and recognized experts in Business Process Management. Currently he is Vice President of BPM Technology at Pegasystems, Inc. He is the strategic BPM technology direction and thought leader at Pega. He has been a senior executive for the past 15 years. He designed and led the implementation of the earliest Web centric distributed (CORBA) BPM system. In addition to BPM he has done extensive research and implementation in advanced Database Management Systems. He also led the architecture, design and implementation of one of the earliest distributed object-oriented database implementations. He is the lead author of eight books and has numerous publications in business as well as technical periodicals. He has given seminars and presentations in conferences, to technical and business communities. He has taught graduate and undergraduate courses in several universities around the world, where he provides his students a unique combination of academic depth combined with industry experience. Setrag holds a PhD in Computer Science from the University of Wisconsin - Madison.