没有合适的资源?快使用搜索试试~ 我知道了~
WebSphere Application Server Best Practices for an Application
3星 · 超过75%的资源 需积分: 3 21 下载量 129 浏览量
2008-08-27
22:49:53
上传
评论
收藏 241KB PDF 举报
温馨提示
试读
46页
This white paper describes some best practices for implementing a development infrastructure in which to create applications for WebSphere Application Server. The goal is to have the development of WebSphere applications be performed in a consistent, reliable and repeatable manner. To accomplish this, there must be processes and procedures in place. Furthermore, these processes and procedures must be well-documented, as well as reasonable, understood, and communicated throughout the development organization.
资源推荐
资源详情
资源评论
2
Introduction 3
Purpose 3
Intended Audience 3
WebSphere Application Server Tooling 3
Ideal WebSphere Development Environment 4
Studio Integration 4
Development Test Integration 5
The Development Process 6
Developing WebSphere applications using WebSphere Studio Application Developer 7
Outputs of the Development Process 15
The EAR File 15
Additional Outputs from Development 16
Sample Installation Procedure 16
Application Packaging 20
WebSphere Studio Application Developer zipCreation Utility 20
Application Environment 22
Property Files 23
Automated Build Process 24
ANT - The Java Build Language 24
The preDeploy Tool 28
Summary 29
Appendix A 30
Appendix B 33
Appendix C 35
Appendix D 37
Topics for Future Consideration 42
Application Requirements and Design 42
Migrating the WebSphere Studio Application Developer Workspace 42
Organizing a Development Effort 42
WebSphere Studio Application Developer and Meta Data 42
J2EE Packaging and WebSphere 42
References 43
Redbooks 43
On the Web 43
White papers 43
Acknowledgments 44
Contact Information 44
Trademarks 44
Terms and Conditions 44
3
Introduction
Purpose
This white paper describes some best practices for implementing a development infrastructure in
which to create applications for WebSphere
® Application Server. The goal is to have the
development of WebSphere applications be performed in a consistent, reliable and repeatable
manner. To accomplish this, there must be processes and procedures in place. Furthermore,
these processes and procedures must be well-documented, as well as reasonable, understood, and
communicated throughout the development organization.
Intended Audience
This paper assumes that the reader is familiar with the J2EE 1.2 specification; if not in complete
detail, then at least with the concepts and packaging. Terms like EAR (Enterprise Application
Archive), WAR (Web Application Archive), and EJB (Enterprise Java Bean) JAR (Java
Archive) should be familiar to the reader. A wealth of information, including the complete J2EE
specification can be found at Sun’s Java™ website: http://java.sun.com/j2ee/.
This paper also assumes that the reader knows how to use the tools that ship with WebSphere
Application Server 4.0, Advanced Edition.
WebSphere Application Server Tooling
The target production environment described (or assumed) here is WebSphere Application
Server 4.0, Advanced Edition. Some tools, such as wscp and the Application Assembly Tool
(AAT), ship with WebSphere Application Server Version 4.0x. More information about wscp
can be found in the WebSphere Application Server InfoCenter in Section 6.6.0.2.2. More
information about AAT can be found in the InfoCenter in Section “6.3: Assembling applications
and generating deployment code.”
Many people creating applications for WebSphere Application Server will use WebSphere
Studio Application Developer
1
. There are two open source products that are heavily used with
WebSphere Studio Application Developer: the Concurrent Versions System (CVS) and Jakarta
ANT. This paper will assume that the Software Configuration Management (SCM) repository
being used is CVS. More information about CVS can be found at http://www.cvshome.org/
.
ANT is a scripting language to aid in building applications. More information about ANT can be
found at http://jakarta.apache.org/ant/.
1
When we say WebSphere Studio Application Developer, we are referring to the new WebSphere tooling based on
Eclipse. This is WebSphere Studio 4.0 or later. WebSphere Studio comes in a number of editions, but the
differences are not relevant to this paper.
4
Ideal WebSphere Development Environment
The ideal WebSphere development environment contains two distinct integration points within
the control of the development organization. The terms Studio Integration and Development
Integration Test will be used to distinguish these two processes, as shown in Figure 1. (For the
purpose of this paper, the author will assume that WebSphere Studio Application Developer is
the development tool of choice. Integration, therefore, will be done using WebSphere Studio
Application Developer. This same principal applies for other environments as well; when using
VisualAge™ for Java for development, VisualAge for Java should also be used for integration
testing.) Let’s review each of these integration points at a high level.
Figure 1. Ideal WebSphere Application Environment
Studio Integration
Within WebSphere Studio Application Developer, a team of developers will share a
development stream, a WebSphere Studio Application Developer term meaning the latest code
in the repository. Each developer updates his/her workspace with the shared code from the
stream. As they make changes to the code, the developers test their changes, then release the
changes to the shared stream. This is done almost continually, daily at a minimum. (Although,
technically speaking, each developer is performing integration as they create and test code, this
basic activity alone is not considered “integration” for the purposes of this paper.)
Then, on a periodic basis, someone is responsible for taking all of the latest released changes and
integrating them in WebSphere Studio Application Developer. A senior developer or technical
5
leader typically does this more formal level of integration. Important activities that occur at this
integration point include:
• All unit tests are executed across the entire application.
• When the application has passed all tests, it is then “versioned”.
It is recommended that this integration cycle occur at least once a week. A nice summary of the
release and version cycle is, Release frequently and version often.
Proponents of Extreme Programming talk about “continuous integration.” Although not always
explicitly mentioned in this paper, the concept of continuous integration is implied. Developers
must push their code to the team as quickly as possible, and should incorporate team changes
into their code as quickly as possible. While some of the principals of Extreme Programming
will be referenced in this discussion, a full explanation is beyond the scope of this paper. More
information about Extreme Programming can be found in the References section below.
Development Test Integration
Development Test Integration has two primary objectives:
• Flush out any differences between the development environment and the production
environment.
• Test the deployment of the application.
It is recommended that the development group has its own machine/node on which to deploy its
application. This development environment should reasonably match the production
environment; at a minimum, it should have the same application server edition, version, etc., run
on the same operating system (including patches, etc.), and use the same database product. The
unit tests are run again in this environment.
In WebSphere Studio Application Developer 4.0, development will most likely be based on the
WebSphere Application Server 4.0 Advanced Single Server Edition, which is the test server that
is “inside” of WebSphere Studio Application Developer. A production server will most likely be
either WebSphere Application Server Advanced Edition or Enterprise Edition. Also, WebSphere
Studio Application Developer is typically run on Windows, while the production environment
will often be UNIX. The unit tests run on the platform used in Development Test Integration
will test any subtle differences between the WebSphere Application Server editions, as well as
any differences due to a different operating system.
Finally, the process to deploy the application into a WebSphere Application Server is also tested
at this stage. This test could be as simple as testing the installation instructions, or as complex as
creating and testing a script that will install the application. More on this later.
剩余45页未读,继续阅读
资源评论
- sun_java_org2012-11-02多谢分享,不过是英文的
billyjiang83
- 粉丝: 0
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功