Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Separate business flow from actions

Introduction to Java Services Orchestration for Actions

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

In developing Web applications, we often see that business flow and logic are implemented together in actions, such as backing-beans in JavaServer Faces (JSF) and action classes in Struts. With the help of existing frameworks, e.g., Enterprise JavaBeans and Spring, we can separate business logic, but business flow remains embedded.

Business process management (BPM) standards, e.g., Business Process Modeling Notation (BPMN) and Business Process Execution Language (BPEL), provide a way to separate business flow by describing it with XML-based documents. This approach also provides the benefit of being able to design applications based on service-oriented architecture (SOA). However, this approach doesn't work well with "actions" in Web applications. The granularity of actions is too low for BPM/workflow products. They target higher scopes such as B2B applications and enterprise application integration, and assume business analysts will describe the processes as shown in Figure 1. But with lower granularity, like actions, the potential for flow reuse is greater.

Figure 1. Comparison of granularity

For a smaller scope, in this article, I propose the use of J-SOFA (Java Services Orchestration for Actions) for Java developers. J-SOFA is a framework for orchestrating services that correspond to a method of a class—either a plain-old Java object (POJO) or Web service.

Due to the differences in granularity, J-SOFA doesn't support asynchronous messaging, state management, monitoring, and so on, functionalities that BPM/workflow products available today support; but such unsupported functionalities could be supplied by working with said BPM/workflow products. This article's services orchestration framework focuses specifically on improving reusability of business flow as well as services.

Figure 2 illustrates that separated flows can be reused from other applications.

Figure 2. Reusable business flow and services

Sample action in JSF

Let's take a look at some sample action code in a Web application developed using JSF. Our example is a simplified model search application, which responds with model information corresponding to the model ID the user entered. You can download all the source code for this sample from Resources.

In the search form JSP (JavaServer Pages) page, there is a text box and a Submit button for entering the model ID. The JSP page invokes the showModel() method in a backing bean named ModelBean, as shown in Listing 1:

Listing 1. inputText and Submit button in search.jsp

 <h:inputText id="modelId" value="#{ModelBean.modelId}" />
<h:commandButton type="submit" value="Submit" action="#{ModelBean.showModel}" />



To generate the model information page (search result page), the Model object and a list of features are created in showModel() and set into the properties:

Listing 2. showModel() method in backing bean

 public String showModel() {
   if (modelId > 0) {
      ModelService modelService = new ModelService();
      BeanUtils.copyProperties(this, modelService.create(modelId));
      setFeatures(modelService.getFeatures(modelId));
   }
   ...
}



Advanced developers can separate business logic from the action as shown in the above code. The logic for creating Model and features is implemented as a model service and is called through the interface. However, could we keep this method simple even if someone else took over maintenance of this backing bean? Doing so might prove difficult because all developers don't understand the benefits of isolation between presentation and business tiers. If a developer with a different perspective handles maintenance, she/he might add business logic in showModel(). This situation is not unusual in projects because the programming language, like Java in this sample, allows us to implement any logic using its powerful expression ability. Therefore, we should use another language to implement business flow, instead of Java.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources