‘What?!’ I hear you say - how could this happen? The project in question was fairly simple - get information and store it in a database. The problem is , despite being mainstream for the last 6 years, there is no standard, easy ‘drag and drop’ method of doing these applications in Java. C# does it in Visual Studio. Oracle does it with Forms. With Java (and despite having doing 10 or so of these projects), there is still too much plumbing that the developer needs to know.
I’m expecting a deluge of ‘have you tried project X’ on this post. And yes, I expect that an Eclipse based tool will probably fill the gap. But for these simple applications , there is no standard way of doing this (standard being a solution that dominates the market in the way Struts did the Web App framework space, until recently). But we’ve been waiting 6 long years!
All of which brings me to Ruby. Ruby on Rails’ sweet spot is exactly these kind of simple, ajax enabled , no frills ‘get info from web and store it on database’ applications. Enterprise Java’s sweet spot is the heavy lifting workflow , Rules , Calculations, Integration with Legacy and other systems , web services and basically anything to do with Business logic. The two are a perfect complement to each other, which is why the news that JRuby now runs Ruby on Rails is especially interesting.
JRuby is a version of Ruby that runs in the Standard Java Virtual Machine (JVM). It means that (1) You don’t have to install Ruby, which might meet resistance in a corporate environment. It also means (2) that all the methods you have available in Java you have available in Ruby. The O’Reilly Ruby site and this Javaworld Article are good places to start learning more about Ruby and linking it into Java. Fellow O’Reilly Blogger Steve Anglin also has more information about the latest JRuby release.
More on Technology in plain English
]]>
参考：http://www.tusc.com.au/tutorial/html/index.html
一?/span>Enterprise Beans
?/span>EJBQ?/span>Enterprise Java BeansQ中定义了两U不同类别的Enterprise Bean Q?/span>
l 会话 Bean (Session Bean)
l 实体Bean (Entity Bean)
1. 会话 Bean (Session Bean)
hSession Beans看作d而非持久数据Q只有这P你才能清晰地理解使用它的场合和原因。比如说Q?/span>Session Bean可能会对数据库内的用戯行检索操作，但ƈ不把用户表示为持久的业务对象?/span>Session Beans可以同其他类型的Java beans通信Q这U能力已l超Z数据库事务概念之外。在q种方式下工作的分布式应用程序特别适合于采?/span>Session Beans?/span>
所有的Session Beans都派生于javax.ejb.SessionBeancR就像其名称那样Q?/span> Session Beans只存在于单一客户会话中。这里的客户可能?/span>Java Servlet、桌面应用程序、别?/span>EJB乃至采用Java Bean的其他事务信息方式?/span>Session Bean的生存期从客L序发h触开始，在客户通过调用EJB宿主接口?/span>remove()Ҏ昑ּ破坏bean时终止。会话还会在预先讄的时间终止，而这U时间设|则?/span>EJB容器内确定。考虑到服务器的资源，开发者往往会设法避免处?#8220;时”讄而在~写客户E序时做相应的g期处理。此外，开发者还应该?/span>EJB容器重新启动的时候小?/span>Session Bean的短暂寿命；客户E序可以重新获得同类bean的引用，但很有可能却不是同一bean?/span>
Session Beans可以是无状态也可以是有状态的Q因而两者会昄Z同的行ؓ?/span>Session Bean的状态概늱gHTTP讄Q客L序和服务器之间的交互Q在q种情况下就?/span>bean自nQ发生在定义的环境之内。有状态的Session Bean会在多个Ҏ调用的情况下保存客户?/span>bean的有关信息。有状态的Session Bean只能同一个客L序通讯Q而无状?/span>Session bean的实例却可以同时和若q个客户E序通讯?/span>
会话 Bean 是调用它的客L代码要完成的工作。当客户端与服务器徏立联p，那么一个会?/span> Bean 徏立v来了。根据会?/span> Bean 的状态不同有分ؓ:
A. 状态会?/span> Bean (Stateful Session Bean)
B. 无状态会?/span> Bean (Stateless Session Bean)
1.1 状态会?/span> Bean (Stateful Session Bean)
当客h和服务器建立q接之后Q状态会?/span> Bean (Stateful Session Bean) 一直在客户机和服务器之间保持着用户的某个状态。例如：用户使用银行?/span>ATMӞl过验证之后Q用户可以连l执行多ơ操作，在这个过E当中，用户的合法状态将一直被保留Q直到她信用卡取出Q结束这ơ操作。这Ӟ状态会?/span> Bean (Stateful Session Bean) 也就被销毁?/span>
1.2无状态会?/span> Bean (Stateless Session Bean)
当客h和服务器建立q接之后Q无状态会?/span> Bean (Stateless Session Bean)处理单一的用戯求或商务q程。无状态会?/span> Bean (Stateless Session Bean)不需要从以前的请求中提取M状态。例如，用户的用户密码确认。用戯入密码后Q发送请求。组件返回真或假来确认用P一旦过E完成，无状态会?/span> Bean (Stateless Session Bean) 也宣告结束?/span>
2. 实体Bean (Entity Bean)
实体Bean (Entity Bean)只是数据模型Q它不包括商务逻辑。实?/span>Bean (Entity Bean)可以关p?/span>/对象数据库的数据映射到内存中供其它组件用。实?/span>Bean (Entity Bean)是一直存在的Q而且h很高的容错性能。实?/span>Bean (Entity Bean)能供允许多用户同时访问?/span>
二、会?/span> Bean (Session Bean)
Ejb的执行过E是被放在一?/span>EJB容器中进行的Q所以客L不会直接调用我们写好?/span>Enterprise Bean Q而是调用EJB容器生成的一?/span>EJBObject (EJB对象)来实现。那么，我们在编写服务器端的Enterprise Bean Ӟp考虑q点。既然客L不能直接讉KQ就?/span>EJBObject来代劻I所以在~写服务器端Ӟp~写服务器端的一个接口（RemoteQ用来与客户p，实力?/span>EJBObject。要生成EJBObject p调有Home 接口Q来建立q个实力?/span>
以下是会?/span> Bean 的代码分析：
A.Enterprise Bean c：sailorsy.class
1.setSessionContext(SessionContext ctx)Ҏ
它是EJB容器?/span>Enterprise Bean互相作用的关口?/span>
import java.rmi.*;
import javax.ejb.*;
public class sailorsy implements SessionBean{
private SessionContext ctx=null;
public voic setSessionContext(SessionContext ctx){
this.ctx=ctx;
}//setSessionContext
}//class sailorsy
2.ejbCreate(…)Ҏ
它可以初始化Enterprise Bean ,可以定义不同?/span>ejbCreate(…)ҎQ每个方法所带的参数不同。但是，必许要存在至一U?/span>
import java.rmi.*;
import javax.ejb.*;
public class sailorsy implements SessionBean{
private SessionContext ctx=null;
public voic setSessionContext(SessionContext ctx){
this.ctx=ctx;
}//setSessionContext
public void ejbCreate() {
}//ejbCreate
}//class sailorsy
3.ejbPassivate()Ҏ
如果初始化的Enterprise Bean q多Q?/span>EJB容器其中的一些挂PpassivateQ?/span>,释放他们所占用的空间?/span>
import java.rmi.*;
import javax.ejb.*;
public class sailorsy implements SessionBean{
private SessionContext ctx=null;
public voic setSessionContext(SessionContext ctx){
this.ctx=ctx;
}//setSessionContext
public void ejbCreate() {
}//ejbCreate
public void ejbPassivate() {
}//ejbPassivate
}//class sailorsy
4.ejbActivate()Ҏ
?/span>ejbPassivate正好相反Q它被挂v?/span>Bean从新调回?/span>
import java.rmi.*;
import javax.ejb.*;
public class sailorsy implements SessionBean{
private SessionContext ctx=null;
public voic setSessionContext(SessionContext ctx){
this.ctx=ctx;
}//setSessionContext
Creating a Stateless Session Bean
This chapter covers how to create a stateless session EJB component. This bean will be responsible for authenticating the user by communicating with the database using Data Access Object (DAO) which encapsulates Java Database Connectivity (JDBC) code. A DAO has all attributes (fields) and behavior (methods) corresponding to the bean it is being used for.
All customers, supplier and manager of MyStore have been assigned a unique username and userid to access services of MyStore, but in order to access these services all these entities have to first login into the system (MyStore). The method for authentication is named loginUser, which takes two String parameters, username and password and returns the userID if authentication is successful.
Note : This method loginUser is a business method, normally business methods carry out operations or processing on values EJB components. From clients perspective, clients can see only business methods and invoke them on bean.
Tasks :
- Create a J2EE project named MyStore.
- Create a Stateless Session Bean named StoreAccess.
- Add a business method in bean named loginUser with the following signature
public String loginUser (String username, String password)
- Create a DAO named StoreAccessDAOImpl under package au.com.tusc.dao. Generate the DAO interface.
- Implement the method named loginUser, generated in DAO interface, in StoreAccessDAOImpl. Method signature is
public String loginUser (String username, String password)
- Add callback methods and implement them.
- Deploy StoreAccess bean.
- Create your test client named SessionClient under package au.com.tusc.client.
- Run your client and test the bean.
Create J2EE Project :
Now, lets start to write our first component of this tutorial.
Go to File > New > LombozJ2EE Project, project creation wizard will pop up.
Insert Project Name MyStore > Next .
Under Java Settings Check source, should be MyStore/src , libraries pointing to $JAVA_HOME > Go Next as shown in fig below.
Note: This step is shown in chapter1, as there is a bug in eclipse 2.1, so its important that you check your library settings are right.
Under Create J2EE Module, select Web Modules tab > Add.., enter Module name as OnlineStore > OK as shown in figure below.
Under Create J2EE Module, select EJB Modules tab > Add.., enter Module name as MyStoreMgr > OK .
Under Create J2EE Module, select Targeted Servers tab > Select JBOSS 3.2.1 ALL > Add.. > Finish.
Create Stateless Bean :
Go To Package Explorer > Expand Mystore (project) node > select src, right click and menu will pop up.
On pop up menu > New > Lomboz EJB Creation Wizard.
Enter package name au.com.tusc.session, bean name StoreAccess and select bean type as stateless > Finish.
This will create a package named au.com.tusc.session under src and StoreAccessBean under that package as shown in the figure below.
As we can see from the figure below it has created a class level tag @ejb.bean, which has assigned the bean type, name and its JNDI name which will be generated in Home interface. This tag will also generate deployment descriptors in ejb-jar.xml and jboss.xml file as well once you generate your EJB classes, which is covered later on in this chapter.
Note: It will generate the bean name, jndi-name and type of bean in the file. Also, the name of file is appended with word 'Bean' as you gave the name of the bean as StoreAccess only. Again, be careful with naming conventions, specifying the bean name only in the wizard without adding the word 'Bean' to the name as the wizard appends that for you.
Expand MyStoreMgr/META-INF node under Package Explorer. You will find there are seven files which are generated by Lomboz using Xdoclet as shown in the figure below.
Now we are going to generate all the interfaces including Home, Remote, DAO and other helper classes. We will explain why later on, but for the time being just follow the steps.
But before we get too excited, there are a few concepts to cover here.
Go to MyStoreMgr/META-INF > select and open ejbGenerate.xml.
Note: Lomboz uses this file to generate required interfaces and helper classes, so in the event that you have special needs then you will have to customize this file. See ejbdoclet under the Xdoclet documentation.
'ejbGenerate.xml' file is generated only once when you create your EJB module. So any changes made in this file will be reflected even if you modify your bean class and generate your classes again and again.
|
As we can see from the code snippet of file shown in figure at right, there are following tags defined. <dataobject/> is defined for generating data Objects for holding values of EJB component's persistent fields, which correspond to columns in the associated table in the database. Note: <dataobject/> has been deprecated in favour of Value Object which is more powerful in terms of relationships (1-1, 1-n and n-m). <utilobject/> Creates method for generating GUID and for accessing Remote and Local Home objects. <remoteinterface/> Generates remote interfaces for EJBs. <localinterface/> Generates local interfaces for EJBs. <homeinterface /> Generates remote home interfaces for EJBs. <localhomeinterface/>Generates local home interfaces for EJBs. <entitypk/>Generates primary key classes for entity EJBs. <entitybmp/>Creates entity bean classes for BMP entity EJBs. <entitycmp/> <session/> Generates session bean class. Note : There is no tag for generating a DAO. So, we have to include this <dao/> tag. For details, please refer ejbdoclet under Xdoclet documentation. |
|
|
As we can see from the code snippet from this file the following tags are defined. <jboss/> is a JBOSS specific tag required for JBOSS. You have to specify datasource, datasourcemapping and preferredrelationmapping. As it differs for different databases, so you may have to specify values appropriate to your environment. If these tags are commented out in JBOSS they default to the correct values for the built-in Hypersonic SQL database, but for the moment we'll set them anyway. |
|
The other two files which are of importance to us are ejb-jar.xml and jboss.xml. The file ejb-jar.xml has all the deployment descriptors for beans and jboss.xml has the JBOSS specific deployment descriptors required by JBOSS.
Note : ejb-jar.xml file is generated every time you generate interface and helper classes for your bean. For the first time, it is empty, and jboss.xml will be generated every time when you will generate your classes for your bean.
Setup DAO :
Now, let's customize ejbGenerate.xml for setting up a DAO.
We have included a <dao> tag specifying the destination directory for the generated DAO interface and what pattern to be used.
Note : For details, please refer ejbdoclet under Xdoclet documentation.
|
We have included the datasource, datasoucremapping and preferredrelationmapping as shown in code snippet of ejbGenerate.xml file on right. datasource="java:/DefaultDS" is a local JNDI name for data source to be used. datsourcemapping="Hypersonic SQL" maps data object/value objects and their types to columns and data types associated with these columns. preferredrelationmapping="foreign-key" defines type of database to be used. Note : For more details, please refer JBOSS documentation.
Since we are using the Hypersonic database, these parameters are appropriate to that. These parameters relate to the configuration file standardjbosscmp-jdbc.xml which controls the CMP-to-JDBC mappings for JBOSS. This resides in $JBOSS_HOME/server/conf/ , e.g. /opt/jboss/jboss-3.2.1/server/default/conf/. Code snippet from standardjbosscmp-jdbc.xml is shown in figure at right. |
|
Note : The way Xdoclet works is bit different from some conventional styles of programming, as the Xdoclet tags will generate these (home and remote) interfaces along with necessary helper classes, which then will used in Bean and DAO Implementation class. However, until these are generated, we cannot write any business methods in Bean and JDBC wrappers in the DAO Implementation class. If this seems confusing then just follow the steps, and hopefully it will become more clear.
Create DAO Interface :
Since we are going to use a DAO to access the database for this Stateless Bean, we have to create a DAOImpl class which will implement that generated DAO interface.
Go to src > add package named au.com.tusc.dao > Add a class StoreAccessDAOImpl in that package.
Now go to your Bean class and declare this tag at the class level (that is at the top) as shown below to generate the DAO interface.
@ejb.dao class="au.com.tusc.session.StoreAccessDAO"
impl-class="au.com.tusc.dao.StoreAccessDAOImpl"
Expand StoreAccessBean node under Package Explorer. Right click and a pop up menu will appear.
On that menu go to Lomboz J2EE > Add EJB to module. Select EJB '[MyStoreMgr]' > OK.
Expand MyStoreMgr node under MyStore Project in Package Explorer. Right click and a menu will pop up.
Go to Lomboz J2EE > Generate EJB Classes as shown in the figure below.
|
EJB interfaces and helper classes are generated under ejbsrc/au.com.tusc.session directory as shown in the figure at the right. Seven files are generated. StoreAccess is the remote object interface. StoreAccessLocal is the local object interface. StoreAccessSession extends our bean class named StoreAccesBean. StoreAccessHome is the remote home interface. StoreAccessLocalHome is the local home interface. StoreAccessUtil is a helper class which has methods for accessing Home and LocalHome interface along with generating GUID. StoreAccesDAO is the DAO interface which we will use to implement our StoreAccessDAOImpl under au.com.tusc.dao. StoreAccessDAO is generated by this tag declared in StoreAccesBean shown below. If you don't declare this tag in that file it won't generate this interface. @ejb.dao class=au.com.tusc.session.StoreAccessDAO impl-class=au.com.tusc.dao.StoreAccessDAOImpl Other files of interest which are generated are ejb-jar.xml and jboss.xml under MyStoreMgr/META-INF. |
|
|
As shown in the figure on the right, a few descriptors are generated in the ejb-jar.xml file. These descriptors are generated by the following tag declared in the StoreAccesBean file. @ejb.bean name ="StoreAccess" jndi-name="StoreAccessBean" type="Stateless" This tag is added by Lomboz's bean creation wizard. |
|
This tag also generates the following descriptors in jboss.xml as shown in the code snippet below.
So now we know which tags are responsible for generating classes, interfaces and descriptors.
Add Business Method :
Next step is to add a business method in the bean.
Go to StoreAccesBean > Right click > Select New on pop up menu > Select Lomboz Ejb Method Wizard.
Add a business method with the following signature: public String loginUser (String username, String password).
Select Method Type as Business and Interface as Remote as shown in the figure below..
This wizard generates a loginUser method in our bean class, with the method level tag '@ejb.interface' shown below.
This tag is responsible for generating this method in the Remote Interface (in this case it is StoreAccess which will be created once you generate your classes). This tag is covered later on in this chapter.
|
Now, This business method needs to invoke a method on the DAO, which will communicate with the database. Therefore we add another tag on this method, so that a method with this signature is generated in DAO interface which we can implement in the DAOImpl class. Then this business method can invoke the method in DAOImpl class to get the desired result. @dao.call name="loginUser" So add this tag at the method level as shown in the figure at right. Now generate your EJB classes again as shown in the steps we went through earlier. Note: OK, OK! For reference these are the steps you have to follow. Expand 'MyStoreMgr' node under 'MyStore' Project in Package Explorer. Right click and a pop up menu will appear. Go to Lomboz J2EE > Generate EJB Classes. |
|
After generating the classes, we look at first the generated DAO interface and then the generated Session Class.
In StoreAcessDAO two methods are generated.
1. init() by default.
2. loginUser(), generated by tag shown below.
@dao.call name="loginUser"
Note: Please do not edit any class generated by Xdoclect.
In StoreAcessSession two methods of our interest are
1. getDAO() creates instance of DAOImpl calss.
2. loginUser(), calls loginUser method in DAOImpl class, which we have to implement.
Code snippet from 'StoreAccessSession'.
Implement DAO Interface :
Now, we will implement methods in the StoreAccessDAOImpl class.
|
First import the following packages. javax.naming.InitialContext; javax.sql.DataSource; java.sql.Connection; java.sql.PreparedStatement; java.sql.ResultSet; java.sql.SQLException; Change your class declaration so that StoreAccessDAOImpl implements StoreAccessDAO. Add a field to store the JDBC resource factory reference. private DataSource jdbcFactory; In init() method, locate the reference "jdbc/DefaultDS" using the JNDI API, and store the reference in variable jdbcFactory. Lookup string is "java:comp/env/jdbc/DefaultDS". Code Snippet is shown in the figure on the right. Now add the required code in loginUser(). |
|
|
In method loginUser(), first get the connection to the database using the jdbcFactory. Create a SQL statement which searches for userid in the table StoreAccess where userid and password is provided for each user. Return userid if successful, else raise SQLException. Code snippet is shown in the figure on the right. Go back to your loginUser method in StoreAccessBean class. |
|
In StoreAcessBean class under the loginUser method just add some debug statements, as shown below in this code snippet.
Note : We don't have to call the loginUser method in StoreAccessDAOImpl, as it being invoked by the loginUser method in StoreAccessSession class which inherits StoreAccessBean class, that is the StoreAccessSession class has overridden this method.
Code snippet from StoreAccessSession shown below.
Add Callback Methods :
Now, add callback methods to complete this bean as shown below.
- setSessionContext.
- UnsetSessionContext.
Note : These callback methods are invoked by the EJB container.
Add a field to store sessionContext.
protected SessionContext ctx;
Add method setSessionContext with sessionContext as parameter and assign that to the sessionContext variable as shown below in the code snippet.
Similarly add method unsetSessionContext, assign context variable to null as shown above.
Note : StoreAccessSession class inherits the StoreAccessBean abstract class and implements SessionBean, which will override all methods of interface SessionBean. So after finishing the methods in the bean class, generate your EJB classes again. SessionContext methods will be overridden as shown in figure below. Code snippet from StoreAccessSession shown below.
Now let's look at the generated Home and Remote interfaces.
In the case of the Remote interface all business methods declared in the bean are also generated with the same signature. This is due to the class level tag declared in the StoreAccess Bean as discussed above after adding business methods. Code snippet for tag is shown below.
So, loginUser is generated in a Remote Interface called StoreAccess as shown below because of this tag.
In the case of the Home Interface only one method is created named 'create', which is generated by default because of the <homeinterface/> tag in ejbGenerate.xml as shown below.
Also, other then that, it has JNDI_NAME and COMP_NAME (which is the logical name to lookup the component) is also generated, these are generated because of this tag declared at class level in 'StoreAccessBean' class shown below in figure.
Note : For further options associated with these tags please refer to the 'ejbdoclet' documentation in Xdoclet.
Now, all the aspects are pretty much covered, and our bean's functionality is complete. Now for the deployment descriptors..
Deploy Bean :
In order to deploy our bean we have to declare a few tags in the StoreAccessBean class as shown below in the code snippet.
Add the tag shown below in at the class level (at the top).
@ejb.resource-ref res-ref-name="jdbc/DefaultDS"
res-type="javax.sql.Datasource"
res-auth="Container"
This tag will generate deployment descriptors in ejb-jar.xml, as the bean has to know which datasource you are going to connect to, what is its type, etc. This will generate these descriptors as shown in code snippet below.
Add the tag shown below in StoreAccessBean at the class level (at the top).
@jboss.resource-ref res-ref-name="jdbc/DefaultDS" jndi-name="java:/DefaultDS"
This tag will generate deployment descriptors in jboss.xml, as the application server has to know with what jndi-name datasource it has been registered with. This will generate these descriptors as shown in the code snippet below.
Now, everything is complete, and it's time to deploy the bean.
First, regenerate your EJB classes as shown in the steps above for the final time.
Note : We have regenerated the classes again and again, in order to explain every step and its result. Once you are familiar with these steps you will need much fewer of these iterations. Either way, it doesn't matter, as your implementation always remains untouched by this process.
Go to Lomboz J2EE View > expand node MyStore > expand MyStoreMgr > select 'Jboss 3.2.1 ALL' .
Right click > select Debug Sever on the pop up menu as shown in figure below.
Go to MyStoreMgr node in LombozJ2EE view > right click > select Deploy on the pop up menu as shown in the figure below.
And now wait for your deployment result.
If everything goes fine, you will have this message under your console as shown in the figure below.
So, now our bean is deployed successfully, let's create our test client, which will invoke the loginUser method on 'StoreAccessBean'.
Create your Test Client :
Go to Project MytStore node > select src node > right click.
Select New on pop up menu > select Lomboz EJB Test Client Wizard as shown in the figure below.
Select package name au.com.tusc.client, name as SessionClient and select Ejb Home as au.com.tusc.session.StoreAccessHome and Ejb Interface as au.com.tusc.session.StoreAccess as shown in the figure below.
This will generate the required methods for you in your SessionClient class and you have to just invoke the loginUser method on the bean as shown below.
Now the last step is to write code in your client.
So add these lines under the testBean method as shown in figure below.
System.out.println("Request from client : ");
System.out.println("Reply from Server: Your userid is " +
myBean.loginUser("ANDY","PASSWD"));
Test your Client :
Now, in order to test your client, Select SessionClient node > Go at top level menu and select the icon with the 'Running Man'.
On that select 'Run as' > select 'Java Application', as shown below.
Now under your console, if you get your reply for 'ANDY' as 'U2', then your call is successful as shown below.
Note : So our Stateless Session Bean is deployed and tested successfully and from now onwards you should be comfortable using Lomboz. In future we will not go into the detail of the steps for using Lomboz and will concentrate more on other aspects of beans.
结
通过表示J2EE应用E序中的d或者行动?/span>Session Beans可以因此而处理大量的状态。尤其是在同其他EJB合用的情况下。理?/span>Session Beans的瞬时现象对开发者的工作会带来莫大的帮助。有状态和无状?/span>Beans的细微差别就如同充分利用其行Z样重要。在掌握以上的概念之后，正确的设计和实现Session Beans必然会显著改q?/span>EJB应用E序的功能和效率?/span>
]]>
程文是一个zip文g. 文的中心流E是 processdefinition.xml . 文g中主要信息是程? processdefinition.xml也包含关于动作和d的信?/tt> . 程文也包含其他流E相x档比如类,dui-form ...
发布文文可以通过3U方式来? 用流E设计器工具, 用antd或编E实?
发布d通过设计器工具依然在开发阶D?
发布d文通过antd如下:
<target name="deploy.par">
<taskdef name="deploypar" classname="org.jbpm.jpdl.par.ProcessArchiveDeployerTask">
<classpath --make sure the jbpm-[version].jar is in this classpath--/>
</taskdef>
<deploypar par="build/myprocess.par" />
</target>一ơ发布多个流E文? 用嵌套的fileset元素. file属性是可选的. 其他ant d属性是:
- cfg : cfg 可选的, 默认值是'hibernate.cfg.xml'. hibernate配置文g包含jdbc connection属性和mapping 文g.
- properties : 属性是可选的q且覆盖所有来自hibernate.cfg.xml的同样属?
- createschema : 如果为true, jbpm数据库模式将在发布之前被建立.
程文也可通过~程来发使用c?org.jbpm.jpdl.par.ProcessArchiveDeployer
程定义基本不会改变,因ؓ预测所有流E定义变化是非常困难?
围绕q个问题, jBPM 有一个久l考验的流E版本机?版本机制允许多个同名的流E定义在数据库中同时存在. 程实例使用最后的可用版本q且q且在同一个流E里持箋执行知道生命周期l束.当较新的版本被发? 较新的徏立实例将用最新的版本,同时老的程实例用老的程定义保持执行.
程定义是组合声明指定图和一l相关的java classes. Java classes 能被jBPMq行旉环境?U方式? 让这些class被jBPM classloader看到. q是把你的委?cL?jar文g然后?jbpm-[version].jar . java classes 也能被包括进程文. 当你包括你的委托cd程文档(它们对jbpm classloader是不可见?, jBPM 用这些class版本. 关于程载入的信息参?13.2章节, “委托?/font>
当流E案被发布? 它在jBPM数据库中生成一个流E定? 程定义可以被版本化Z基本的流E定义名?当命名的程案被发布时,发布者将分配l它一个版本数? Z分配数字,发布者将查询同名的流E最高版本数字加1.没有名字的流E定义版本数字ؓ-1.
]]>
Java的进展都是围l着JSR形式的规D明书q行的。最q，q个家族中又新添了一个成员，那就是JBI(Java Business Integration)。它是一U企业服务ȝ(Enterprise Service Bus,ESB)Q用于Ş成一U关键基设施片段Q我们能够用Java实现面向服务的架构。我们将在本文中探讨JBI有关概念以及一U名为SeviceMix的开源实现?
JBI的主要目的是提供一个基于服务的q_作ؓ对现有Java/J2EEq_功能的扩展。由于Web services已经实际应用于J2EE中，而且ESB和SOA{术语与其说是技术推动力倒不如说更是市场概念Q所以让我们一hq一下到底什么是Java/J2EE中所谓的“基于服务的q_”?
当前的J2EE部v都运行在一个基上，那就是应用服务器。应用服务器本n׃个独立的部分l成——Servlet容器和EJB容器Q它们分别用于部|JSP/Servlets和EJB构g。在它们中的M一个，你都能用Web services。但是，在Q何环境中以分散的方式使用services是很困难的工作，而JBI的目的就是ؓ完成q个d提供一个专门的环境?
JBI的最底层是一个容器，它与J2EE中的容器一样定义了自n的部|构件。在我们深入之前Q让我们先详l了解一下JBI的主要构惟?
首先Q它x了Web services的核心部?在终端之间传输的SOAP 消息/信封。这U数据段或标记能够包含被服务于很多应用的信息。不仅如此，Ҏ发送端或接受端的不同，它还能协助把某个业务逻辑与数据适配?
现在Q回q头来看看今天的Web services。在Web services出现之前Q对于很多企业应用来_使用面向消息的中间gpȝ或者MOM实现异构pȝ之间的通信已经_了。Web services的出现同h处于q个目的。用MOM的基于消息的架构和Web services很类|被服务的数据也能在应用之间进行无~操作?
q种场景可以被应用到典型的J2EE环境中，q过JMS或JAX-RPC{技术进行服务。这U做法对单部|是可行的，但正如前面提到的Q当q行很复杂的设计Ӟ现有的容器则昑־很难用。于是JBI试图解决q个问题?
JBI提供了一U正规消息\由器(Normalized Message Router,NMR)Q说白了Q就是一个地炏V在q个地点Q所有基于消息的数据片段——SOAP片段、MOM消息、HTTP数据或其它信息——被聚合、集中、应用到业务逻辑、传输，如果有必要则被{换成其它格式q后被分派到最l目的地?
先前的描q说明了Z么JBI被称为ESB。它很适合企业U应用，因ؓ它通过一Uȝ型架构的Z消息的手D到达了适应大范围的消费者和提供者的目的。现在，让我们看看除了NMRq有什么构成了JBI?
和JBI环境直接交互的是两个部分QJBI machine和JBI binding。JBI machine定义了部|构件以及在环境中管理它们的方式。本质上Q它是提供商设计的黑盒，用于在JBI中支持他们自q模型。另一斚wQJBI binding则被环境通过专门的业务协议与外部世界q行通信?
现在Q再让我们把q些概念攑ֈ真实的JBI实现ServiceMix中。ServiceMix是完全用JBI的思想开发的一个开源项目。它可以支持多种l定Q包括HTTP、JMS、^面文件以及RSSQ还提供了一pdcMBPEL、Schema Validation、JCA 和缓存等服务?
与ServiceMix协作的还有基于JMX的管理接口以及用来与JBI构g通信的对本地客户端API。尽本文不对ServiceMix功能做进一步说明，但你可以很容易地下蝲该Y件然后l学习。下面，让我们来看看一个可部v在ServiceMix上的真实的JBI构gQ这样你会对它有Ҏ性认识?/p>
Listing for JBI Components - File Sender & File Receiver.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:my="
<!-- the JBI container --> <container id="jbi"> <property name="useMBeanServer" value="true"/> <property name="createMBeanServer" value="true"/> <property name="dumpStats" value="true"/> <property name="statsInterval" value="10"/> <components> <!-- Write files to the outbox directory --> <component id="fileSender" service="foo:fileSender" class="org.servicemix.components.file.FileWriter"> <property name="directory" value="outbox"/> <property name="marshaler"> <bean class="org.servicemix.components.util.DefaultFileMarshaler"> <property name="fileName"> <bean class="org.servicemix.expression.JaxenStringXPathExpression"> <constructor-arg value="concat('sample_', /sample/@id, '.xml')"/> </bean> </property> </bean> </property> </component> <!-- Look for files in the inbox directory --> <component id="filePoller" service="foo:filePoller" class="org.servicemix.components.file.FilePoller" destinationService="foo:fileSender"> <property name="workManager" ref="workManager"/> <property name="file" value="inbox"/> <property name="period" value="1000"/> </component> </components> </container> <!-- the work manager (thread pool) for this container --> <bean id="workManager" class="org.jencks.factory.WorkManagerFactoryBean"> <property name="threadPoolSize" value="30"/> </bean> </beans> JBI规格说明书本wƈ没有定义构g应该如何~码。请注意QServiceMix用XML风格的语法定义了两个核心构gQ关联到特定的类和属性。在把这U结构部|到ServiceMix以后Q环境就会创ZU查询构Ӟ负责从系l和其它构g中读取存档信息，然后把读取的D回到文gpȝ? 该文件系l是JBI中非常基本的场景Q因Z息就是从JBI环境(NMR)原样集中的，然后被返回到同样cd的绑?文gpȝ)。但是很明显Q一旦JBI环境有能力把M业务逻辑适配成数据，例如BPEL或schema validationQ然后重定向到其它类型的l定Q例如HTTP或RSSQ那么就不只是返回到文gpȝ了? 正如你意识到的一P当一用到JBIQ操U及分发数据的可能性就很大Q但即JBI用Java的方法实CSOAQJSR-208规格说明书还是受C批评。IBM和BEA是Java/J2EE领域的两个主要推动者，他们׃支持q个新项目。尽如此，q是有像ServiceMixq样的小目开发者和一些闭源开发组l打赌，一个培育良好的JBI市场和J2EE的情况差不多? 假如你正在Java中用Web services或者ؓ了复杂的集成d使用Z消息的设计，你应该对JBI的进展特别关心，因ؓ它能为执行这Ld提供更健壮的q_。就你对JBI/ESB是否能加入J2EE协议栈还存有怀疑，l箋xq是有帮助的Q因为它可能会成为应用服务器领域像Spring那样的事实上的“第三容器”或轻量U的容器扩展QؓJava提供SOA能力?
]]>