FTP (File Transfer Protocol) is a common way of moving files between computers.  By default your RimuHosting server will not have FTP enabled.

Do you really need to run FTP? For example, if you are going to be the only person moving files to and from your server, then you may not need it.  Try our scp howto instead.

To enable FTP, first edit the vsftpd.conf file (e.g. vi /etc/vsftpd/vsftpd.conf).  Then:

• Consider changing anonymous_enable=YES to anonymous_enable=NO
• Uncomment the "nopriv_user=ftpsecure" line
• Uncomment the "write_enable=YES" line (else you'll get an error like '550 Permission denied.' from your FTP client when you upload a file or create a directory)
• Uncomment the "local_enable=YES" line (else you'll get an error like '500 OOPS: vsftpd: both local and anonymous access disabled!')
• Add a "chroot_local_user=YES" line. This will trap your FTP users in their own /home/username directory. Otherwise they will be able to see and update some files outside their home directory.

Then create a non-super user that vsftp will run as.  Note: this is not the FTP username you'll use when logging into your FTP server.

# create an unpriviledged user that will run the vsftpd service
adduser -s /sbin/nologin ftpsecure
sed --in-place 's/^anonymous_enable=YES/anonymous_enable=NO/ig' /etc/vsftpd/vsftpd.conf
sed --in-place 's/^anon_upload_enable=YES/anon_upload_enable=NO/ig' /etc/vsftpd/vsftpd.conf

Then, most redhat distributions you can then run:

chkconfig --level 35 vsftpd on && /etc/init.d/vsftpd start

Or, on a RedHat 8 distribution:

vi /etc/xinetd.d/vsftpd
# ... and change the disable = yes to disable = no

# then restart xinetd
/etc/init.d/xinetd restart

The ftp daemon will not let you log in as root (?why?).  Try a log in as a non-super user.  To create such a user:

# add the user, use the -s (shell) option if you do not want the 
# user to be able to ssh into the server (else skip it)
adduser -s /sbin/nologin yourusername
passwd yourusername
# you will be prompted for a password
# now, log in to your ftp server using this username and password

Locking FTP Users Into Their Home Directories

By default FTP users can read and write files any files on the server, provided they have access to read/write those files.

You can also set things up so that FTP users only see files under their home directory.  This can often be a more secure setup.  To do this just add chroot_local_user=YES in vsftpd.conf (and restart vsftpd). e.g.

sed --in-place 's/^anonymous_enable=YES/anonymous_enable=NO/ig' /etc/vsftpd/vsftpd.conf
sed --in-place 's/^anon_upload_enable=YES/anon_upload_enable=NO/ig' /etc/vsftpd/vsftpd.conf
if ! test -e /etc/vsftpd/vsftpd.conf; then 
    echo /etc/vsftpd/vsftpd.conf not found
elif grep -qai chroot_local_user=YES /etc/vsftpd/vsftpd.conf; then 
    echo "chroot_local_user directive already existed"
else 
    echo "Adding the chroot_local_user directive"
    echo "chroot_local_user=YES" >> /etc/vsftpd/vsftpd.conf
fi
/etc/init.d/vsftpd restart

When a user logs in, if there directory was /home/user/html, they would see /html. They're locked into /home/user, and /home/user becomes their root (/) directory.

读者定位为具有 Java 和 Ant 使用经验的开发人员。

读者可以学习到如何使用 Ant 解决一些多用户开发环境中，根据不同的目标环境编译成不同部署包的问题。

工作场景

现在有一个 web 项目，是多人进行开发的，通过 CVS 来管理。另外该项目还有一些测试人员，他们测试部署在测试服务器上的应用程序，发现 bug 后通过 bug 管理系统通知开发人员，在开发人员修复 bug 并经过本地测试后，由专门的人负责检出（check out）代码，编译打包后部署到测试服务器上。

该项目的成员小A就是负责检出代码、编译打包，并部署到服务器上的人。除了这个任务之外，他还是该项目的编程人员。在项目进入测试阶段后，小A在得到组中别的成员修复了 bug 并且检入（check in）了代码的消息后（也有可能是小A自己检入了代码），小A首先更新本地的代码，先在本地做测试，确认修复了 bug 后打成 WAR 包部署到测试服务器上，并通知测试人员已经修复了 bug，让测试人员继续进行测试。

小A的烦恼

在该项目中，有一些为测试方便开发而写的代码和页面，比如跳过用户认证，但是在部署到测试机环境的时候，需要删除这些代码和页面；另外作为一个具有灵活性和扩展性的应用程序，又有一些配置文件，配置文件中的值会根据环境的改变而变动。例如，在项目中使用了 Log4j 记录日志，需要给 Log4j 指定日志文件的保存路径，本地程序员开发的时候用的是 Windows 系统，给 Log4j 指定的也是 Windows 的文件系统，在测试阶段的时候，需要部署到 Linux 系统中，那么日志的保存路径也需要做相应的改动。部署到测试服务器上的时候，除了 Log4j 需要改之外，还有很多别的配置项目也需要变动，并且分散在各个 package 中。小A的烦恼也随之而来，每次他在做完本地测之后，就根据测试机的需要逐个找配置文件，更改相应的值，并删除那些为测试方便写的代码和页面，每天可能根据需要做好几次这样的事情，最烦的是他在快做完对测试机环境更改的时候，某开发人员突然通知小A说：“我又改了一点代码，刚检入，你再重打一个包吧。”，小A又不得不从头开始做新一轮的检出代码、本地测试、更改配置文件、删除不需要的文件、打包部署的工作。另外小A在测试阶段的后期被通知要求除了每次生成一个测试环境的 WAR 包外还必须生成一个在产品环境下的 WAR 包，他做的事情就更多了。

从上面的场景可以看出，小A的工作效率低而且容易出错，甚至有可能导致整个项目的工作效率低下。其实可以通过 Ant 来帮助小A快速而且有效地完成这个工作。在 Ant 中，根据目标环境的需要，可以把所有要更改的配置文件的项目集中写到某个配置文件中。这样根据不同的目标环境得到不同的配置文件，Ant 在编译包时根据不同的目标环境切换不同的配置文件即可。比如小A现在碰到的有 3 中环境：开发环境、测试环境以及产品环境，根据这三种环境可以生成三个不同的配置文件：develop_deploy.property、test_deploy. property和product_deploy. property，当小A想生成不同的包时只需在这三个配置文件之间切换就可以了。

在正式开始编写脚本之前，我们需要下载安装相应的软件。

• Eclipse：为了使 Ant 的开发更加简单，我们选择了 Eclipse3.1 作为开发环境。当然你可以使用任何你喜欢的文本编辑工具来开发你的 Ant。Eclipse 的最新版本可以在 http://eclipse.org/ 上下载。
• Ant：Ant 是基于 Java 的编译工具，它就像 C/C++ 中的 make，但是没有 make 那样难用。Ant 的最新版本可以在 http://ant.apache.org/bindownload.cgi 上下载。如果你用 Eclipse 来开发 Ant，则不用去单独下载 Ant，因为在 Eclipse 中已经集成了 Ant。
• CVS 客户端（cvs.exe）：CVS 可以在 http://www.nongnu.org/cvs/ 上下载

回页首

用 Eclipse3.1 来创建 Ant 脚本

如果你使用 Eclipse 来编写 Ant，建议使用 Eclipse 3.1 以后的版本。除了以前 Ant 编辑器提供的语法高亮，提示语法错误等功能外，Eclipse3.1 版本增加了许多新的功能。比如：脚本代码的折叠；快速定位某属性或者目标（target）段的定义；在同一 builder 文件中重构属性名和目标名（快捷方式Alt + Shift +R）；调试 Ant 脚本等。

下面我们就来看看 Eclipse 3.1 中对 Ant 的支持

• 打开“File”－“New”－“Project”－“Simple”－“Project”，点击“Next”，输入工程名“Ant”，然后点击直到“Finish”

• 在新建的 Ant 工程中，新建 Test.xml，并且拷贝下面的脚本。该段脚本的内容就不做介绍了，我们主要看 Eclipse 提供了哪些功能。注意这时候打开的并不是 Ant 编辑器，将内容拷贝进去之后，关掉打开的“Test.xml”，然后再重新打开它，这样 Eclipse 就会用 Ant 编辑器打开它，并且也语法高亮了。

  <?xml version='1.0' encoding='UTF-8'?> <project name='Test' default='init' basedir='.'> <property name='test' value='test'/> <target name='init'> <echo>${test}</echo> </target> </project>

  
  

• 自动提示和代码折叠功能。如果是 Ant 内置的命令或者前面已经定义的变量，编辑器会自动提示；编辑器右边的加/减号可以代码折叠。如下所示：

  

• 快速定位目标（target）或者定义变量处。在上图中，将鼠标移至 default=”init” 中的 init 上之后，按下 ctrl 键，鼠标变成手状，单击就可以定位到定义该目标的地方

• 快速重构目标名或者属性名。选中目标/属性名，按下 Alt + Shift + R，然后键入你要修改后的值，所有引用到的地方都会随之改动。如下图所示，选中 init 后，按下快捷键，改成 initial：

  

• 调试 Ant 脚本。在标签“<target name=..”的左边设置一断点，然后在编辑器中右击，出现的菜单中选“Debug As”－“Ant Build”，出现后的窗口与调试 Java 程序的界面差不多。

  这是调试窗口，这里可以选择单步跟进、跳出等：

  

  下面是运行时变量窗口。可以看到 test 变量的值是“test”：

  

  运行结果窗口：

  

由此可见，如果使用好 Eclipse Ant 编辑器所提供强大的功能的话能大大提高写 Ant 脚本的效率。

回页首

Ant 中使用 property（属性）文件

刚开始写 Ant 的初学者可能会把所有的信息都放在 build.xml 中，下面就是这样的一个例子。

<project name='testBuild' default='compile' basedir='.'>
<target name='init'>
	<mkdir dir='c:/temp/dest/testProj' />
</target>
<target name='compile' depends='init'>
	<javac srcdir='c:/temp/src/testProj' destdir='c:/temp/dest/testProj '/>
<echo>Build into c:/temp/dest/testProj, successfully.</echo>
</target>
</project>

在上面的例子中，所有的路径信息都是写在 build.xml 中。但是 Ant 脚本可能在不同的机器或者不同的系统上运行，也有可能一些值需要根据环境的不同而变化，在 Ant 中可以把所有这些可能变化的地方都放到一个配置文件中，然后在 Ant 脚本中引用这个配置文件就可以了，针对上面的例子，如下所示：

<project name='testBuild' default='compile' basedir='.'>
	<property file='build.properties'/>
	<target name='init'>
		<mkdir dir='${dest.dir}' />
	</target>
	<target name='compile' depends='init'>
		<javac srcdir='${src.dir}' destdir='${dest.dir}'/>
		<echo>Build into ${dest.dir}, successfully.</echo>
	</target>
</project>
build.properties的内容：
dest.dir=c:/temp/dest/testProj
src.dir=c:/temp/src/testProj

如果想在 Ant 脚本中引用值的话，只需用$符号开头，在一对'{}'中写入要引用的键值。如上例中，需要引用编译的目标路径用'${dest.dir}'。

回页首

使用 Ant 任务从 CVS 中检出（check out）源代码，并编译打包

Ant 中提供了 cvs 任务（Task）可以从 CVS 服务器中检出资源（注意：在使用 Ant 的 cvs 任务之前，请先将 cvs.exe 下载到你的机器，并且将它添加到你本地的 PATH 环境变量中，然后重新启动 Eclipse。否则在执行下面脚本的时候就会得到 error=2 的错误）。cvs 的可选用属性很多，在这里介绍经常使用到的几个属性。从 CVS 中检出资源一般需要指定：

• CVS 所在的服务器地址：目标 CVS 服务器地址
• 用户名：登录该 CVS 服务器你指定的用户名
• 密码：登录该 CVS 服务器需要的密码
• 库路径（Repository Path）：服务器中的库路径
• 模块名：当前需要检出的模块名，一般都是以工程的名字作为模块名
• 标签名：需要从 CVS 中检出哪个标签

在介绍使用 Ant 的 cvs 之前，先说一下本地的目录结构。在 C 盘的 temp 目录下，分别有四个目录，如下所示：

• build 目录：放编译后的类以及资源文件
• dist 目录：放生成的 jar 文件或者 war 文件
• lib 目录：放在编译过程中需要用到的 jar 文件
• src 目录：放从 cvs 中检出的源文件（包括 JSP 等）
  

在 Ant 中这样写就可以从中检出资源：

  <cvs cvsRoot=':pserver:username:pwd@cvs.server:/home/testPath' 
package='TestProj' dest=' c:/temp/src/testProj ' failonerror='true' />

这段脚本片断的意思就是从叫'cvs.server'的服务器中，用用户名是 username、密码为 pwd 的用户检出在库路径是 /home/testPath 下的 TestProj 模块（项目），检出后的资源放入本地目录 c:/temp/src/testProj 中。在上面这段脚本中，可以看到有很多值可能会根据不同的环境或者用户随之改变的，比如用户名和密码等；而且从脚本的重复可利用性来说，需要把有些值抽出来放到配置文件中，如服务器的地址和库路径等。因此把这些可能需要更改的地方放到 property 文件中，效果会更好。改完后的完整 Ant 脚本如下所示：

  <?xml version='1.0'?>
<project name='testWeb' default='checkout' basedir='.'>
	<target name='checkout'>
		<property file='TestWeb.properties' />
		<cvs cvsRoot='${cvs.root}' package='${cvs.projectName}' 
tag='${cvs.tag}' dest='${src.dir}' failonerror='true' />
	</target>
</project>

对应的 TestWeb.properties 文件内容如下所示：

base.dir=c:/temp/
src.dir=${base.dir}/src

cvs.server=cvs.server
cvs.user=username
cvs.pw=pwd
cvs.repositoryPath=/home/testPath
cvs.projectName=TestProj
cvs.root=:pserver:${cvs.user}:${cvs.pw}@${cvs.server}:${cvs.repositoryPath}
cvs.tag=

在检出了资源后，需要对其进行编译打包。为了使 Ant 脚本更加具有可读性和灵活性，我们需要对上面的 Ant 脚本进行一些改动。首先将 Ant 脚本中进行分段，如下所示：

<?xml version='1.0'?>
<project name='testWeb' default='all' basedir='.'>
	<target name='all' depends='init,clean,checkout,build'>
    <!--脚本的入口点-->
	</target>
	<target name='init'>
    <!--做初始化属性文件和设置classpath等设置初始条件-->
	</target>
	<target name='clean'>
     <!--删除上一次留下的没用的目录和文件-->
	</target>
	<target name='checkout'>	
     <!--从CVS中检出资源-->
	</target>
	<target name='build'>
     <!--编译源文件并打包到指定的目录-->
	</target>
</project>

上面的脚本中，总共分成了5个目标（target），脚本的入口点是'all'，all 按顺序调用 init，clean，checkout，build。其中：

• init 是用来做初始化属性文件和设置 classpath 等设置初始条件的事情
• clean 用来删除上一次留下的没用的目录和文件
• checkout 已经介绍过了，是用来从 CVS 中检出资源
• build 用来编译源文件并打 WAR 包到指定的目录

详细的 Ant 脚本可以参见随本文所附的 TestWeb.xml 和 TestWeb.properties。

回页首

编译过程与产生不同目标环境的脚本分开执行

在前面介绍的 Ant 脚本中，根据从 CVS 服务器中检出的资源打成了一个默认的 war 包，并没有考虑根据不同的目标环境来生成不同的包，从下一节开始介绍如何根据不同的环境来生成不同的部署包。

还有一个问题是：为什么需要把从 CVS 中检出资源、编译的过程跟根据目标环境打包的过程分开？

这是因为本身 CVS 检出资源是需要花一定的时间，如果资源比较多这个过程就会花费挺长时间；另外，在多人开发的情况下必须保证在生成不同的部署包的时候是用的是同一套代码生成的，否则会出现各个服务器上运行的版本不一致，如果检出资源、编译的过程跟生成包的脚本一起执行的话就会出现这个问题（比如小A在测试服务器测试通过的时候之后，再生成一个在产品环境下的部署包，如果分两次从 CVS 服务器中检出资源的话，在此期间可能会有开发人员往 CVS 服务器中检入代码，导致生成的版本不一致），因此，必须将这两个过程分开执行。现在我们开始建立另外一个 Ant 脚本文件，叫 deploy.xml，专门用来生成包；另外与 deploy.xml 相对应的还有一个 deploy.properties 文件。在 deploy.xml 中会引用 deploy.properties 文件。另外根据在前面的场景中碰到的环境，创建三个不同的属性文件, develop_deploy.property、test_deploy. property 和 product_deploy. Property，在打包的时候，根据不同的目标环境，将相应属性文件中的内容拷贝至 deploy.properties 文件中（或者也可以直接在 deploy.xml 中直接切换不同的属性文件），然后在 Eclipse 中直接执行 deploy.xml；如果在命令行中，可以用下面的命令来执行：

  ant –f deploy.xml

回页首

解开 WAR 包

我们首先得建立一个目录（这里是 unpack）用来存放解压后的文件。Ant 中提供了 unzip 命令用来解压 ear/war/jar 包。除了这个目录外，根据不同的目标环境，在运行目录下建立一个与目标环境相对应的目录，重新打好的 war 包就放在这个目录下，比如针对场景中的情况，如果需要创建一个产品环境下的部署包，我们可以建立一个 TestWebProduct 目录，目录名写在配置文件中（${pack.base.dir}）。

  <target name='init'>
		<echo>init in deploy</echo>
		<property file='deploy.properties' />
		<delete dir='${unpack.base.dir}' failonerror='false' />
		<delete dir='${pack.base.dir}' failonerror='false' />
		<mkdir dir='${unpack.base.dir}' />
		<mkdir dir='${pack.base.dir}' />
	</target>

	<target name='unpack'>
		<echo>unpack the ${war.name}</echo>
		<copy file='${dest.dir}/${war.name}' todir='${unpack.base.dir}' />
		<unzip src='${unpack.base.dir}/${war.name}' dest='${unpack.base.dir}/${projectName}' />
		<delete file='${unpack.base.dir}/${war.name}' />
	</target>

在 init 段中首先删除掉上次解压的目录和目标打包目录，然后重新建立目录；在 unpack 中，首先将编译好的默认 war 包拷贝至 unpack 定义的目录，解压之后把 unpack 下的 war 包删除。下面是这时候对应的属性文件。

projectName=MTSWeb
war.name=MTSWeb.war

#根目录
base.dir=c:/temp
#默认的war包所在的目录
dest.dir=${base.dir}/dist
#解压后的目录
unpack.base.dir=${base.dir}/unpack
#目标环境相对应的目录
pack.base.dir=${base.dir}/TestWebProduct

回页首

利用 Ant 提供的 filter 任务替换属性值

现在根据不同环境的需要，对某些配置文件的值做一些替换。在 Ant 中，提供了 filter 任务，使得替换值很方便。当然也可以使用下面介绍的正则表达式来替换属性值。filter 主要用来在同一行内容中的替换，而正则表达式一下子可以替换多行内容。filter 的使用例子：

  <filter token=' log4j.logger' value='INFO'/>
  <copy todir='${dest.dir}' filtering='true'>
    <fileset dir='${src.dir}'/>
  </copy>

这段脚本的意思就是在 src.dir 目录下的所有文件中，如果有预先定义好的'@log4j.logger@'占位符的话，在拷贝到 dest.dir 目录后，所有的占位符都被替换成了'INFO'。

你也可以将所有被替换的值放到某个属性文件中，filter 任务将属性文件中的每一个条目读出来并且设置成一个 Filter。如下所示：

  <filter filtersfile='deploy_env.properties'/>
  <copy todir='${dest.dir}' filtering='true'>
    <fileset dir='${src.dir}'/>
  </copy>

上面的脚本表示所有在 deploy_env 中出现的条目将被作为一个 filter，在拷贝到 dest.dir 目录后，所有 src.dir 目录中存在的占位符将被替换成 deploy_env 中的值。具体的例子可以参见随本文附带的 deploy.xml， deploy_env.properties 和 Test.properties。

其中 deploy.xml 是 ant 脚本，deploy_env.properties 中包含所有要替换的值，在 Test.properties 中是包含有占位符的资源文件。

回页首

利用正则表达式替换属性值

Ant 中支持多种正则表达式，在运行 Ant 的时候用哪种正则表达式可以通过设置 ant.regexp.regexpimpl 的值来切换，Ant 支持的的正则表达式有：

• java.util.regex package of JDK 1.4
• jakarta-regexp
• installation dependencies

正则表达式的例子：

<replaceregexp byline='true'>
<regexp pattern='正则表达式'/>
<substitution expression='将要替换的值'/>
<fileset dir='${unpack.war.dir}/WEB-INF' includes='web.xml'/>
</replaceregexp>

byline 属性用来确认被替换的时候是一次替换一行还是多行；pattern 属性用来指明正则表达式；substitution expression 中是替换的值，替换的值都定义在相对应的配置文件中；fileset 属性中的 dir 用来指定被替换文件所在的目录，includes 用来指定要替换哪个文件。需要注意的是，如果在正则表达式或者替换的值中出现'<'的话，需要用转义符'<'。

在 Eclipse3.1 中已经内置了对正则表达式的支持；但是如果你在命令行中运行需要正则表达式支持的脚本的话，则需要自己将正则表达式的包下载下来加到 classpath 中。在随文章的 deploy.xml 中提供了一个简单的替换属性文件的值的例子。正则表达式的例子可以在本文所带的 deploy.xml 中找到。

回页首

Ant 使用条件表达式，根据属性值删除不需要的文件

在生成部署包的时候，还有可能会根据目标环境的不同，删除一些不同的文件。比如在产品环境中那些作为测试需要的代码往往需要删除，但是测试环境中并不需要。因此就需要条件表达式来做判断。如下所示：

<target name='checkTestEnv'>
	<condition property='isTestEnv'>
		<istrue value='${deploy.isTestEnv}' />
	</condition>
	<antcall target='trueCondition' />
	<antcall target='falseCondition' />
</target>
<target name='trueCondition' if='isTestEnv'>
	<echo message='true condition in ${projectName}' />
</target>
<target name='falseCondition' unless='isTestEnv'>
	<echo message='false condition in ${projectName}' />
</target>

在上面的例子中，先读出 ${deploy.isTestEnv} 的值（在配置文件 deloy.properties 中），根据读出的值对属性 isTestEnv 设值，如果 ${deploy.isTestEnv} 的值是 true，isTestEnv 的值也是 true；否则是 false。然后分别调用目标段 trueCondition 和 falseCondition。在这里，表达式值的判断是用'istrue'，在 Ant 中还提供了很多别的表达式，比如 not/and/or，equals 等等，具体关于条件表达式的信息可以参考：http://ant.apache.org/manual/CoreTasks/condition.html ，该页也可以在随下载下来的文档中找到。

在段 trueCondition 中，判断 isTestEnv，如果是真的话就运行，否则不运行；在段 falseCondition 中，也判断 isTestEnv，如果是假就运行，否则不运行，在段中可以根据情况做相应的事情。条件判断式的例子可以在本文的 deploy.xml 中找到。

回页首

重新打包，并拷贝到不同的目录

在上面的替换过程完成后，调用 war 将 unpack 目录下的内容重新打包。

<target name='repack'>
	<war destfile='${pack.base.dir}/${projectName}.war' 
		basedir='${unpack.base.dir}/${projectName}'
		webxml='${unpack.base.dir}/${projectName}/WEB-INF/web.xml' 
		manifest='${unpack.base.dir}/${projectName}/META-INF/MANIFEST.MF'>
	</war>
</target>

详细的例子可以参见随本文的附件 deploy.xml 和 deploy.properties。

回页首

结论

通过本文可以看出编写好有效的 Ant 脚本能很好的解决在编译部署包的时候出现的问题，将那些变化的内容放到配置文件中，在部署的时候切换不同的配置文件就可以实现生成不同的部署包。文中也介绍了如何使用 Eclipse 来提高你编写/调试 Ant 脚本的效率。

用J2EE开发WebService

<?xml version="1.0"?>
<definitions name="StockQuote"
                targetNamespace="http://example.com/stockquote.wsdl"
                xmlns:tns="http://example.com/stockquote.wsdl"
                xmlns:xsd1="http://example.com/stockquote.xsd"
                xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
   <schema targetNamespace=http://example.com/stockquote.xsd
                 xmlns="http://www.w3.org/2000/10/XMLSchema">
      <element name="TradePriceRequest">
        <complexType>
           <all>
                <element name="tickerSymbol" type="string"/>
              </all>
           </complexType>
        </element>
        <element name="TradePrice">
            <complexType>
                <all>
                   <element name="price" type="float"/>
                 </all>
              </complexType>
           </element>
        </schema>
     </types>
     <message name="GetLastTradePriceInput">
         <part name="body" element="xsd1:TradePriceRequest"/>
     </message>
     <message name="GetLastTradePriceOutput">
         <part name="body" element="xsd1:TradePrice"/>
    </message>
    <portType name="StockQuotePortType">
        <operation name="GetLastTradePrice">
            <input message="tns:GetLastTradePriceInput"/>
            <output message="tns:GetLastTradePriceOutput"/>
         </operation>
      </portType>
      <binding name="StockQuoteSoapBinding"
                    type="tns:StockQuotePortType">
         <soap:binding style="document"
                                 transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="GetLastTradePrice">
            <soap:operation
                           soapAction="http://example.com/GetLastTradePrice"/>
            <input>
               <soap:body use="literal"/>
            </input>
            <output>
                <soap:body use="literal"/>
            </output>
         </operation>
      </binding>
     <service name="StockQuoteService">
        <documentation>My first service</documentation>
        <port name="StockQuotePort" binding="tns:StockQuoteBinding">
            <soap:address location="http://example.com/stockquote"/>
        </port>
     </service>
  </definitions>

它包含了以下的关键信息：
· 消息的描述和格式定义可以通过XML文档中的和 标记来传送。
· 标记中表示了消息传送机制。 (e.g. request-only, request-response, response-only) 。
· 标记指定了编码的规范 。
· 标记中表示服务所处的位置 (URL)。

WSDL在UDDI中总是作为一个接口描述文档。因为UDDI是一个通用的用来注册WSDL规范的地方，UDDI的规范并不限制任何类型或者格式描述文档。这些文档可能是一个WSDL文档，或者是一个正规的包含导向文档的Web页面，也可能只是一个包含联系信息的电子邮件地址。

现在Java提供了一个 Java API for WSDL (JWSDL)规范。它提供了一套能快速处理WSDL文档的方法，并且不用直接对XML文档进行操作，它会比JAXP更方便，更快速。

图 3 显示了如何使用WSDL 和 UDDI。



图 3

SOAP

当商业用户通过UDDI找到你的WSDL描述文档后，他通过可以Simple Object Access Protocol (SOAP) 调用你建立的Web服务中的一个或多个操作。

SOAP是XML文档形式的调用商业方法的规范，它可以支持不同的底层接口，象HTTP(S)或者SMTP。之所以使用XML是因为它的独立于编程语言，良好的可扩展性以及强大的工业支持。之所以使用HTTP是因为几乎所有的网络系统都可以用这种协议来通信，由于它是一种简单协议，所以可以与任何系统结合，还有一个原因就是它可以利用80端口来穿越过防火墙。 SOAP的强大是因为它简单。SOAP是一种轻量级的，非常容易理解的技术，并且很容易实现。它有工业支持，可以从各主要的电子商务平台供应商那里获得。

从技术角度来看，SOAP详细指明了如何响应不同的请求以及如何对参数编码。一个SOAP封装了可选的头信息和正文，并且通常使用HTTP POST方法来传送到一个HTTP 服务器，当然其他方法也是可以的，例如SMTP。SOAP同时支持消息传送和远程过程调用。以下是一个SOAP请求。

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"

<SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
    <SOAP-ENV:Header>
        <t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
           5
        </t:Transaction>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <m:GetLastTradePrice xmlns:m="Some-URI">
            <symbol>SUNW</symbol>
        </m:GetLastTradePrice>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

开源在今天的软件业已经很普遍，但开源是否意味着使用者可以对开源后的代码为所欲为呢？答案是否定的。开源运动同样有自己的游戏规则和道德准则。不遵行这些规则不但损害开源运动的健康发展，也会对违规者造成名誉和市场上的损失，更可能陷入法律纠纷和赔偿。

现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种。我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议。如果要开源自己的代码，最好也是选择这些被批准的开源协议。

这里我们来看四种最常用的开源协议及它们的适用范围，供那些准备开源或者使用开源产品的开发人员/厂家参考。

现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种。我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议。如果要开源自己的代码，最好也是选择这些被批准的开源协议。

BSD开源协议

BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。

但”为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：

1．  如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。

2．  如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。

3．  不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

Apache Licence 2.0

Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似：

1．需要给代码的用户一份Apache Licence

2．如果你修改了代码，需要再被修改的文件中说明。

3．在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。

4． 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。

Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

GPL

我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。

GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。

由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。

其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。

LGPL

LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL 允许商业软件通过类库引用 (link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。

GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。