<welcome-file-list>
	<welcome-file>index.do</welcome-file>
</welcome-file-list>

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

情景： 法院一般对一个案子有以下一个流程

       立案à分案à审判à结案

其中

立案阶段 ---- 立案人员

分案阶段 ---- 分案人员

审判阶段 ---- 法官

结案阶段 ---- 法官

上述的立案人员，分案人员，法官各自都是一个Group

一个案件加入有8个属性

a b c d e f g h

每个阶段不同组的人员处理案件的属性为

立案阶段 ---- 立案人员 -- a b

分案阶段 ---- 分案人员 – c d

审判阶段 ---- 法官     --e f

结案阶段 ---- 法官     --g h

一．           需要工作流的本质

根据上述的情景，试想一下没有工作流的情况，我们一般的实现方式

为了将问题简单化

定义一个model为Case --- 案件

其中Case里面有一个属性，专门纪录案件状态，为state

在立案状态，state =’L’

  分案状态，state =’F’

  审判状态，state =’S’

  结案状态，state =’J’

还有一个与案件相关的Repository，CaseRepository

以及处理案件的用例ProcessCaseService

我们只分析处理案件用例里面的3个子用例

1．    取得相关案件    List getCases(String userName)

2．    改变案件状态    void changeCaseState(String userName)

3．    由立案人员建立一个案件 void createCase(String userName)

4．    处理案件        void dealCase(BussinessDomain business)

还有一个处理用户和用户组的用例ProcessOrganizationService

里面的相关的用例有

1．取得相关的用户组 String getGroupName(String userName)

立案人员有3个用例与之相关

1．  只获得与立案阶段相关的案件

2．  将案件状态改变为分案状态

3．  建立一个处于立案阶段的案件

4．  处理立案阶段案件的相关数据

分案人员同样与立案人员有相似的用例

整一个案件的处理过程，也就是整一个处理案件的主线

立案à分案à审判à结案

而这一个过程，涉及到的相关的业务逻辑有

1．只获得属于自己处理阶段的相关案件

2．改变案件状态

3．案件状态对应的groupName

当业务逻辑发生变化的时候,比如有的地方法院实现分案，后立案

分案à 立案à审判à结案

那么，针对这个法院，我们就要对我们原来存在的系统进行代码的修整

原来是立案人员建立一个案件

现在由分案人员建立一个案件

需要修正的代码是void createCase(String userName)

这个时候，又有的地方法院分案阶段处理的案件属性是a和b,而不是原来的c和d

需要修正的代码是void dealCase(BussinessDomain business)

当dealCase业务逻辑复杂的时候，所需要修改的代码是海量的

这时候，又有的法院的案件处理是分案人员负责立案，立案人员负责分案

需要修正代码的地方是

void changeCaseState(String userName)

void createCase(String userName)

void dealCase(BussinessDomain business)

这里只是法院的业务流程，每个行业都有每个行业自己的业务流程，为了将对业务流程的处理这一部分，抽取出来，并且尽可能的少修改代码，就有了工作流引擎的产生

二．           wfmc定义的域模型

业务流程是什么？业务逻辑的那些部分是属于业务流程？哪些业务逻辑是要划分给工作流引擎的呢？

1．  什么是需要根据实际情况系统要发生改变

根据情景

(1) 一般法院的案件处理流程为

立案à分案à审判à结案

而有的法院为

   分案à 立案à审判à结案

这4个阶段的先后顺序会发生变化

(2)       有的地方法院分案阶段处理的案件属性是a和b,而不是原来的c和d

不同阶段需要处理的案件相关数据发生变化

(3)       有的地方法院是分案人员负责立案，立案人员负责分案

角色所要负责处理的相应阶段的事情发生了变化

这个情景只是法院的情况，不同的领域，业务流程也不一样。为了将所有领域的业务流程的抽取出来，标准化组织对此做出了明确的定义，并定义了元数据模型，也就是我们开发过程中的业务流程相关的model类

如下图

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

事务是所有数据库系统的一个基本概念。 一次事务的要点就是它把多个步骤捆绑成了一个单一的，不成功则成仁的操作。 其它并发的事务是看不到在这些步骤之间的中间状态的，并且如果发生了一些问题， 导致该事务无法完成，那么所有这些步骤都完全不会影响数据库。

比如，假设一个银行的数据库包含各种客户帐户的余额，以及每个分行的总余额。 假设我们要记录一次从 Alice 的帐户到 Bob 的帐户的金额为 $100.00 的支付动作。那么，完成这个任务的简单到极点的 SQL 命令象下面这样

UPDATE accounts SET balance = balance - 100.00
    WHERE name = 'Alice';
UPDATE branches SET balance = balance - 100.00
    WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Alice');
UPDATE accounts SET balance = balance + 100.00
    WHERE name = 'Bob';
UPDATE branches SET balance = balance + 100.00
    WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Bob');

这些命令的细节在这儿并不重要；重要的是这里牵涉到了好几个独立的更新来完成这个相当简单的操作。 我们的银行官员会希望要么所有这些更新都生效，要么全部不起作用。 我们当然不希望一次系统崩溃就导致 Bob 收到 100 块不是 Alice 支付的钱， 也不希望 Alice 老是不花钱从 Bob 那里拿到物品。我们需要保证：如果在操作的过程中出了差错， 那么所有这些步骤都不会发生效果。把这些更新组合成一个事务就给予我们这样的保证。 事务被认为是原子的：从其它事务的角度来看，它要么是全部发生，要么完全不发生。

我们还需要保证：一旦一个事务完成并且得到数据库系统的认可， 那么它必须被真正永久地存储，并且不会在随后的崩溃中消失。 比如，如果我们记录到了一个 Bob 撤单的动作， 那么我们不希望仅仅在他走出银行大门之后的一次崩溃就会导致对他的帐户的扣减动作消失。 一个事务型数据库保证一个事务所做的所有更新在事务发出完成响应之前都记录到永久的存储中（也就是磁盘）。

事务型数据库的另外一个重要的性质和原子更新的概念关系密切： 当多个事务并发地运行的时候，那么每个事务都不应看到其它事务所做的未完成的变化。 比如，如果一个事务正忙着计算所有分行的余额总和， 那么它不应该包括来自 Alice 的分行的扣帐和来自 Bob 分行的入帐，反之亦然。 所以事务必须是黑白分明的，不仅仅体现在它们在数据库上产生的永久影响出发，而且体现在它们运转时的自身的可视性上。 一个打开的事务做的更新在它完成之前是其它事务无法看到的，而到提交的时候所有更新同时可见。

在 PostgreSQL 里，一个事务是通过把 SQL 命令用 BEGIN 和 COMMIT 命令包围实现的。 因此我们的银行事务实际上看起来象下面这样

BEGIN;
UPDATE accounts SET balance = balance - 100.00
    WHERE name = 'Alice';
-- 等等
COMMIT;

如果在该事务的过程中，我们决定不做提交（可能是我们刚发现 Alice 的余额是负数）， 那么我们可以发出 ROLLBACK 命令而不是 COMMIT 命令，那么到目前为止我们的所有更新都会被取消。

PostgreSQL 实际上把每个 SQL 语句当做在一个事务中执行的来看待。 如果你没有发出 BEGIN 命令，那么每个独立的语句都有一个隐含的 BEGIN 和（如果成功的话） COMMIT 语句包围在周围。 一组包围在 BEGIN 和 COMMIT 语句中间的语句有时候被称做事务块。

我们可以通过使用 savepoints 的方法，在一个事务里更加精细地控制其中的语句。 保存点允许你有选择性地抛弃事务中的某些部分，而提交其它剩下的。 在用 SAVEPOINT 定义了一个保存点后，如果需要，你可以使用 ROLLBACK TO 回滚到该保存点。 则该事务在定义保存点到回滚到它之间的所有数据库更改都被抛弃，但是在保存点之前的修改将被保留。

在回滚到一个保存点之后，这个保存点仍然保存着其定义，所以你可以回滚到这个位置好几次。 当然，如果你确信你不需要再次回滚到一个保存点，那么你可以释放它，这样系统可以释放一些资源。 要记住：释放或者回滚到一个保存点都会自动释放在其后定义的所有保存点。

所有这些都发生在一个事务块内部，所以所有这些都不可能被其它事务会话看到。 当且仅当你提交了这个事务块，这些提交了的动作才能以一个单元的方式被其它会话看到， 而回滚的动作完全不会再被看到。

还记得我们的银行数据库吗？假设我们从 Alice 的帐户上消费 $100.00， 然后给 Bob 的帐户进行贷记加款，稍后我们发现我们应该给 Wally 的账号贷记加款。 那么我们可以像下面这样的保存点来做：

BEGIN;
UPDATE accounts SET balance = balance - 100.00
    WHERE name = 'Alice';
SAVEPOINT my_savepoint;
UPDATE accounts SET balance = balance + 100.00
    WHERE name = 'Bob';
-- 呀！加错钱了，应该用 Wally 的账号
ROLLBACK TO my_savepoint;
UPDATE accounts SET balance = balance + 100.00
    WHERE name = 'Wally';
COMMIT;

这个例子当然是实在太简单了，但是通过使用保存点，我们可以对事务块有大量的控制。 并且，ROLLBACK TO 是除了事务全部回滚，重新来过之外的唯一可用的， 用于重新控制一个因错误而被系统置于退出状态下的事务的方法。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

weather 和 cities 表。考虑一下下面的问题：你想确保没有人可以在 weather 表里插入一条在 cities 表里没有匹配记录的数据行。 这就叫维护你的表的参考完整性。 在简单的数据库系统里，实现（如果也叫实现）这个特性的方法 通常是先看看 cities 表里是否有匹配的记录， 然后插入或者拒绝新的 weather 记录。 这个方法有许多问题，而且非常不便，因此 PostgreSQL 可以为你做这些。

新的表声明看起来会象下面这样：

CREATE TABLE cities (
        city            varchar(80) primary key,
        location        point
);

CREATE TABLE weather (
        city            varchar(80) references cities(city),
        temp_lo         int,
        temp_hi         int,
        prcp            real,
        date            date
);

然后我们试图插入一条非法的记录：

INSERT INTO weather VALUES ('Berkeley', 45, 53, 0.0, '1994-11-28');

ERROR:  insert or update on table "weather" violates foreign key constraint "weather_city_fkey"
DETAIL:  Key (city)=(Berkeley) is not present in table "cities".

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

这个查询是一个左手边外连接， 因为在连接操作符（译注∶LEFT OUTER JOIN）左手边的表中的行在输出中至少要出现一次， 而在右手边的行将只输出那些与左手边行有对应匹配的行。 如果输出的左手边表的行没有对应匹配的右手边表的行，那么在右手边行的字段将填充空（NULL）。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

转自
http://www.theserverside.com/tt/articles/article.tss?l=SpringLoadedObserverPattern

This article describes an easy process of implementing the observer pattern in the Spring framework (Spring Core). Also discussed in this article are a few of the Spring Core classes as well as an easy way to start the Spring Framework in any project. Finally, this article shows developers and designers that the Spring framework is a great reason to continue design pattern advocacy in your projects.

Recently, it seems when developers use the Spring framework to improve their projects they focus only on simple object oriented design techniques. Unfortunately some of the more brilliantly researched patterns are forgotten in place of a brilliant framework (Spring). Although the Factory Pattern and the Singleton Pattern are built into Spring, other patterns such as the Decorator Pattern, the Adapter Pattern, and the Observer Pattern are often forgotten because of the new ideas Spring has to offer. Fortunately, design patterns and the Spring framework can exist in the same application. In this article I show how the commonly used Observer Pattern fits nicely in the Spring Framework.

Observer Pattern

The Observer Pattern is also known as a publisher and subscriber design pattern. The pattern is useful when you have one publisher and many subscribers (one-to-many) that are interested in the publisher's state or messages. Additionally, interested subscribers have the ability to register and unregister as they please. Lastly, subscribers are notified of the publisher's messages automatically (that is, by no effort of their own). Figure 1 is an example of a typical observer pattern.

Figure 1. Observer Pattern

I chose to use a more widely accepted diagram to describe the Observer Pattern so you will notice that the aforementioned publisher is actually the Subject in this diagram. The subscriber is the Observer in the diagram. The intimate details of the Observer Pattern are far outside of the scope of this article, but a note worthy topic is how the Spring framework can be used to leverage good object oriented design techniques while creating the concrete classes of this pattern.

A normal concreteObserver class is required to have code similar to this constructor (or a similar “setter” method to achieve the registering of the Observer with the Subject):

public concreteObserver(Subject s) {
	s.addListener(this);
}

Below you will see how the Spring framework wires the two concrete classes together with XML and not with code inside the classes. Ultimately, this allows the developer to avoid any unnecessary coupling of the concrete classes.

Spring Considerations

Since this article covers only the most simple implementation of the observer pattern, I utilize only the required Spring framework jars. At a minimum you need to have the spring-core.jar, the spring-context.jar, and the spring-beans.jar from the Spring framework distribution. Also to avoid any run time errors you need the commons-logging.jar from the Apache Commons project in your class path.

Each of these jars provide a specific role that make using the Spring framework possible. First is the spring-core.jar; this jar is required for all Spring applications. It includes Spring's dependency injection classes as well as other classes that are used to create Spring beans. The spring-context.jar contains the ApplicationContext interface. This interface is used to start the Spring framework in my included example project.

The last Spring jar is the spring-beans.jar. It contains the DesposibleBean interface which the FileSystemXmlApplicationContext bean sub-interfaces. I do not directly use the DesposibleBean interface but I use the FileSystemXmlApplicationContext bean to located the XML file used to configure the Spring framework. The code that implements these classes is shown in Listing 6.

Wiring The Observer Pattern with Spring

To illustrate the Observer Pattern concretely, I chose to create a Town Crier class that sends messages to any registered Town Resident class. To keep this example simple, I developed the same interfaces shown in Figure 1, but the concrete classes are TownCrier and TownResident. All four of these classes are shown in Listings 1 through 4.

After I created the TownCrier (Listing 3) and two TownResident (Listing 4) classes I created an incomplete version the ObserverContext.xml file (Listing 5). This file contains the Spring definitions of the concrete implementation beans. Since this example is simple, I chose not to use any of the more complex attributes of the bean tag.

Typical Bean tags for the shown classes:

At this point, I was able to run my ExampleRun class (Listing 6), but nothing eventful actually happened. This is because the TownResident classes were not “wired” into the TownCrier class.

To perform the wiring of the Observer Pattern I chose to use Spring's MethodInvokingFactoryBean class. This process is a very simple way of calling a method on a class and ultimately passing a parameter into method. In this example, the parameter is the bean definition of a townResident. A snapshot of this bean definition is:

    
    addListener
    
    
      
    
    

As you can see, the targetObject is the townCrier bean, the targetMethod is the addListener method and the argument is the townResident1 bean. This configuration is the only code needed to compose the concrete implementations of the TownCrier with TownResident class.

Now that I have the beans wired together using the MethodInvokingFactoryBean class, I can run my ExampleRun class and see that my TownResident classes are receiving messages from the TownCrier class. Results shown in Example 1.

Conclusion

A few lessons learned in this article include a simple way to start the Spring framework, how to use the MethodInvokingFactoryBean, and an efficient implementation the Observer Pattern in the Spring framework. Since this is a minimal approach to the Spring framework, I was able to show the relationship between the ApplicationContext and it's implementation FileSystemXmlApplicationContext class. This process for starting Spring applications is a very easy way to leverage an incredible framework.

Part of this framework is the MethodInvokingFactoryBean. When using it you are free to employ any parameter available to you such as an Integer, a String, or in our case, another Spring bean. By allowing you to expose methods in your context xml files you can be as flexible as you can dream. This article has covered the addListener() method of the Observer Pattern. I would like to extend a challenge to you to figure out how to implement the removeListener() method using strictly the Spring framework.

Lastly, the Observer Pattern is a common and very useful pattern. The practices shown in this article provide an example of how the concrete implementation of the Observer interface can be developed with no additional coupling to the concrete implementation of the Subject interface. This feature of Spring encourages good object oriented design techniques. As a final note, there is really no reason developers and designers can not find ways to marry proven design patterns with beautifully developed frameworks.

Listing 1. The Observer Interface

package springobserver;
public interface Observer {
  public void update(String messageText);
}

Listing 2. The Subject Interface

package springobserver;
public interface Subject {
  public void addListener(Observer o);
  public void removeListener(Observer o);
  public void notifyListeners();
}

Listing 3. The Town Crier

package springobserver;

import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

public class TownCrier implements Subject {

	private List townResident = new ArrayList();
	private String messageText;

	// this message is added so I can give 
	// this class a reason to call notifyListener.
	public void setMessage(String message){
		System.out.println("I'm the Town Crier and " +
				"I've got a message: " + message);
		this.messageText = message;
		this.notifyListeners();
	}
	
	public void addListener(Observer o) {
		this.townResident.add(o);
	}

	public void removeListener(Observer o) {
		if (this.townResident.contains(o)){
			this.townResident.remove(o);
		}
	}

	
	// call the update method on 
	// each observer (town resident)
	public void notifyListeners() {
		for (Iterator iter = townResident.iterator(); iter.hasNext();) {
			Observer listener = (Observer) iter.next();
			listener.update(messageText);
		}
	}

}

Listing 4. The Town Residents

package springobserver;

public class TownResident implements Observer {
	public void update(String messageText) {
		System.out.println("Greetings my name is: " + this);
		System.out.println("I heard: " + messageText);
	}

-------- new class --------
package springobserver;

public class TownResident2 implements Observer {
	public void update(String messageText) {
		System.out.println("Greetings my name is: " + this);
		System.out.println("I heard: " + messageText);
	}

}

Listing 5. The Application Context XML (ObserverContext.xml)

	
	
	
	
	          
       
	
	
    
    
        
    
      
      addListener
      
      
        
      
      
    
    
    
        
    
      
      addListener
      
      
        
      
      
             
 
 

Listing 6. Example Run

package springobserver;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;

public class ExampleRun {
	public static void main(String[] args) {
		// launch the spring frame work.
		ApplicationContext ctx = new FileSystemXmlApplicationContext(
				"/config/ObserverContext.xml");
		// grab the Town Crier out of the spring 
		// framework and send a message too all observers
		TownCrier crier = (TownCrier) ctx.getBean("townCrier");
		crier.setMessage("It is 1 O'Clock and all is well!");
	}
}

Example 1. System Output

I'm the Town Crier and I've got a message: It is 1 O'Clock and all is well!
Greetings my name is: springobserver.TownResident@80fa6f
I heard: It is 1 O'Clock and all is well!
Greetings my name is: springobserver.TownResident2@1b9ce4b
I heard: It is 1 O'Clock and all is well!!

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

无论是struts ,还是 webwork, 对于组件的复用主要集中在业务逻辑层..通过action调用不同的manager去实现服用.

但如果把backingbean看成action,那我觉得绝对是对jsf的一种滥用了

而jsf对于组件的复用,却应该复用在web层.....不同的页面可以调用相同的backingbean组件,也就是把manager直接提取为backingbean.

这样页面的灵活性相当的高...当然在struts, webwork里面通过的方式也有间接的解决服用性的办法

seam更是将实体bean和会话bean和jsf的backingbean结合到了一起

随着jsf1.2和jsp2.1的出现之后,相信jsf能走得更好...

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师