Activiti Source Analysis (framework, core class ...) ）

http://jiangwenfeng762.iteye.com/blog/1338553

Activiti is the industry's most popular Java workflow engine, the relationship between Activiti and JBPM5 and how to choose is not the topic to be discussed in this article, the relevant content can be Baidu a bit. Activiti from an architectural point of view is relatively good, is very object-oriented, I have read the code structure of the great open source software, personally think better than spring,hibernate.


Activiti's BASIC programming framework

Activiti based on Spring,ibatis and other open source middleware as a software platform, on top of this building a very clear development framework. The diagram above lists the core components of Activiti.

1.ProcessEngine: The abstraction of the process engine, for the developer, it is the facade that we use Activiti, through which we can get all the services we need.

2.XXService (Taskservice,runtimeservice,repositoryservice ...): Activiti packages different stages of services in different service according to the lifecycle of the process (definition, deployment, operation) , the user can use the interface of a particular stage very clearly. These service instances can be obtained through processengine. Taskservice,runtimeservice,repositoryservice is a very important three service:

Taskservice: The interface associated with each task node, such as complete,delete,delegate, during process operation

Repositoryservice: Process definition and deployment-related storage services.

Runtimeservice: Process runtime related services, such as Startprocessinstancebykey.

For the relationship between Processengine and Xxservice, you can look at the following picture:

3.CommandContextIntercepter (commandexecutor): Activiti uses the command mode as the basic development mode, each method defined in the service above corresponds to the corresponding command object (xxcmd). The service delegates various requests to the XXCMD,XXCMD to determine the recipient of the command, and returns the result after the recipient executes. Commandcontextintercepter, as its name implies, is an interceptor that intercepts all commands and performs some common operations before and after the command executes. such as Commandcontextintercepter's core approach:

  Java code      public <t> t execute (Command<t> command)  {       CommandContext context =  Commandcontextfactory.createcommandcontext (command);          try {   //Pre-execution Save context          context.setcommandcontext;          context.setprocessengineconfiguration ( processengineconfiguration);         return next.execute (command) ;//execute Commands                 } catch  ( Exception e)  {         context.exception (e);                } finally {         try {  //CloseContext, internally flush session, persisting data to DB            context.close ( );         } finally {  //release context             context.removecommandcontext ();            context.removeprocessengineconfiguration ();          }       }               return null;     }    

The details of the command mode, there is a lot of information on the Internet, do not expand here. I just wanted to say that I saw Activiti's two-point experience after this design:

1) a product or a project, technically must have a clear, unique development model or called development style (really do not know how to say the right), we often say that we want a team of all the code written by all have a unified style, like a person written out, very idealistic, but it is difficult, often we are through the " Norms "To constrain everyone to do so, and the norm is after all things outside the program, the subjective is very strong, not abide by the norms of the situation occurs frequently." And if the architect gives a clear development model and uses some of the underlying components to reinforce it, it's hard to rule out the way the programmer is going, because that means you're not writing a job. As Activiti does, the overall nature of the programming style is ensured by explicitly command as the basic development model, supplemented by Event-listener.

2) The advantage of using command mode, what I feel most here is separation of duties, decoupling. With command, each service is a role-based facilitator or controller, and he doesn't need to know exactly what to do, he just gives the task to the individual commands. The direct benefit is that the bloated, omnipotent big class is gone. And this is often the most hated place in our usual development.

4. Core business Objects (Task,processinstance,execution ...): o The class under the Rg.activiti.engine.impl.persistence.entity package is the core business object of Activiti. They are real objects, not fake objects that only have data that doesn't behave, and people who engage in Java enterprise Development may be accustomed to the following hierarchies: Controller->service->dao->entity, Entity is only the Java object of the data table in ormapping, there is no behavior (Getter/setter can not be counted as behavior), for object-oriented, this is certainly problematic, remember to hear people say such words "using object-oriented language design and development and Object-oriented design and development are different ", object-oriented is" encapsulation "," polymorphism ", the pursuit is to meet the" open-closed "principle, the responsibility of a single object of society. If you agree with the above, then believe that Activiti will make you feel more comfortable, take taskentity as an example, its UML class diagram is as follows:

(Figure 2:taskentity Class)

The taskentity implements 3 interfaces: Task,delegatetask and PersistentObject. Where PersistentObject is a declarative interface that indicates that taskentity needs to be persisted. An interface is a statement of a role, a description of a duty, and taskentity is the specific player of the role, so taskentity must assume responsibilities such as complete,delegate.

But there is some regret that such an important behavior as complete is not described in 3 interfaces (because of the tense duration). ^_^), so "abstract-oriented" programming is not yet fully done for taskentity. But at least Activiti told us:

1) Keep in mind that oriented to abstract programming, the responsibility of splitting into different interfaces, so that the interface to reflect the responsibility of the object, instead of caring about the role of the specific object to achieve;

2) entity can and should be the real object.

Context component for 5.Activiti

The context is used to hold long, global information about the life cycle. The Activiti context class (under the Org.activiti.engine.impl.context package) maintains the following three types of information:

(Figure 3:context Class)

Commandcontext: The command context, which maintains the necessary resources for each command, such as the session required for persistence.

Processengineconfigurationimpl: Configuration information related to the process engine. It is the global configuration information of the whole engine, mailserverhost,datasource and so on. Single case. The instance is instantiated when the process engine is created and calls the stack as shown below:

(Initialization of Figure 4:processengineconfiguration)

ExecutionContext: Just seeing this kind of feeling is a little strange and doesn't understand what it does. Look at the example of its code holding executionentity. And executionentity is a very important class in Activiti,//todo

6.Activiti Persistence Framework (component)

Activiti uses Ibatis as the Ormapping tool. On this basis Activiti designed its own persistence framework and looked at a graph:

(Figure 5:activiti Persistence framework)

The top-level interface is the session and Sessionfactory, which is very well understood.

The session has two implementation classes:

Dbsqlsession: To put it simply, Dbsqlsession is responsible for the execution of the SQL expression.

Abstractmanager: Simply put, Abstractmanager and its subclasses are responsible for object-oriented persistence operations

The difference between dbsqlsessionfactory and genericmanagerfactory is well understood.

The persistence framework is also initialized when the process engine is established, as shown in Figure 4.

7.event-listener components

Activiti allows client code to intervene in the execution of the process. A basic component is provided for this purpose, see figure:

(Figure 6: The basic component of the user code intervention process)

The types of code that users can intervene include: Tasklistener,javadelegate,expression,executionlistener.

Processengineconfigurationimpl holds an instance of Delegateinterceptor, which makes it easy to call handleinvocation at any time.

8.Cache components

I'm interested in the cache implementation of Activiti, but what I've learned (perhaps not yet) is that the implementation of its cache is quite simple, with the cache implemented in Dbsqlsession:

Java code protected List<persistentobject> insertedobjects = new arraylist<persistentobject> (); protected map<class<?>, map<string, cachedobject>> cachedobjects = new Hashmap<class<?>,   Map<string,cachedobject>> ();   protected list<deleteoperation> deletedobjects = new arraylist<deleteoperation> (); protected list<deserializedobject> deserializedobjects = new arraylist<deserializedobject> ();

That is to say, Activiti is the memory-based list and map to do the caching. How to use it specifically. Take the Dbsqlsession.selectone method as an example: