首先，创建一个无状态会话EJB来实现应用逻辑。这里唯一的问题是设计接口方法声明，使用方法上需要传递简单对象。考虑到这些作为复杂类型的对象，它除了有get/set功能来处理属性（遵循JavaBean规范）外没有其他的功能。同时也可以支持复杂类型数组和复杂类型嵌套。关键是在设计原则上要保持方法的简单以及服务本身的驱动器行为。如果异构是一个设计目标，那么不要把Web services当作对象串行化技术来考虑，而应当作是一种展示业务事件功能的一个方法。
然后, 用wsgen Ant任务创建.ear文件。在WLS产品销售时WebLogic捆绑这个功能以及Ant 1.3版本。产品文档中提供了该如何正确的完成该任务的详细描述。我的build.xml脚本文件包括以下的部分：
text="/${beanname}" protocol="http">
path="${jardest}/ejb_${beanname}.jar">
uri="/${beanname}"/>
程序定义了一个新的webservice target任务。它依靠一个叫做 init 的对象，依据常规在init target中定义了环境变量和参数。我所有的脚本文件都定义了 beanname 变量，它以各种不同的方式命名必需的文件。这个target将在一个运行中的WLS实例上创建和部署.ear文件。WLS 6.1 以一种非常简单的方法实现了SOAP和WSDL的一个保守的子集。它影响了已经由EJB建立起来的框架，同时还向开发者展示在不用添加任何Java代码情况下，如何对现存的EJB组件做成Web services。
不可避免的旅程颠簸
我正在处理一个项目它需要.NET客户端可以调用部署WLS上的服务。这段的代码在用本地类型（由XML模式定义）作为参数或返回值时工作正常。不幸的是，复杂类型或任何类型的序列则完全是另外一回事。在现实中这种限制有时是无法接受的。我求助于WLS参考文档看到了一个注释声明说WLS6.1支持微软SOAP Toolkit 2.0 SP2。作为 在W3C (WWW 联合会) XML委员会的一个关键的成员，微软在他的.NET框架中采用了2001 XML模式（XSD）规范。而SOAP Toolkit 2.0是基于1999年推荐的版本，WLS 6.1也是。
当今Web services正被认为是互操作的万能药，本文章对正确理解它也是有必要的。新技术一方面在发展同时它也同时也在变成类似于SOAP和WSDL等协议的基础。可以理解的是，应用服务器厂商必须提供稳定的和可靠的基础组件，它们必须要不犹豫的去支持最新的和最好的工业规范。我相信我的这些问题是可以解决的，在给出了简单的和精确的基于XML的Web services技术的情况下，我决定比较深入的研究互操作能力的问题。
互操作能力的问题
这篇文章略述了开发者必须面对的XML相关的互操作能力的问题，给出了WLS和.NET目前的状态。它们能分别被分类在两个涉及到WSDL 和 SOAP相关的领域。 WSDL (Web Services Description Language ，Web服务描述语言) 似乎是一个合理的起始点，因为在调用一个新创建的Web services之前，它必须被绑定以用于该过程的调用。
WSDL 堆栈互操作的问题
当WLS的Web services被部署时，一个能被公共访问的网页(JSP)是互用的。这个页面包含二个链接：第一个链接产生可以描述这个服务的WSDL文件，第二个链接允许下载一个习惯上称为client.jar的文件。这个.jar文件包含客户端代理类，SOAP 编码/解码和一些由BEA提供的用于简化服务调用的基础类。这是除了客户端应用相关的代码外的唯一需要在CLASSPATH中指定的.jar文件。对于基于Java的客户端，WSDL是外部的并且它只对UDDI注册有用。对于非Java客户端，情况则是相反的。
考虑到这个问题，我知道首先可做的是，要创建由C#代码编写的客户端代理程序(虽然VB.NET会是一个同样可行的替代方案)。作为一个有C/C# 背景的Java程序员，我几乎可以立即适应C#，它是我要选择的语言。在下载并安装 ASP.NET 软件包之后，我立即学习微软的Web services包括编译WSDL来产生代理代码的方法。 它们可以经由命令行执行WSDL.EXE程序或者通过使用Visual Studio.NET来访问。这些工具能够通过HTTP访问并且能在一个步骤内获取和编译WSDL。WSDL编译器产生一个以 .cs 为扩展名的源文件，它是通过在WSDL文件中 service XML元素的名字属性来命名的。 这个文件随后被编译成 .dll文件。 从客户端代码通过实例化产生的代理类来调用服务，并且这种方法的调用就好像是客户端的一种本地化的调用。我的情况是，由WLS创建的WSDL文档没有用.NET提供的编译器正确的编译。
我在WLS上创建和部署的Web services被命名为PresentationController并且它拥有一个名为dispatchAction的方法。这个方法有5个参数。前四个是简单的字符串类型，最后一个是NameValuePair JavaBean实例的数组。由WLS产生的WSDL文件显示在Listing 1中（这篇文章中的源代码可以从 www.sys-con.com/weblogic/sourcec.cfm 下载）。注意在文档头部的description元素。名字空间（namespace）属性参考了1999版的XSD说明。这是三个必须对WSDL做的对2001版兼容性提出的改变中的第一个。因为我的代码利用了NameValuePair JavaBean，WSDL包含一个内在的XSD模式，并附加了一个schema元素。 这个元素包含了任何复杂类型的标准XSD定义，他们可以被服务描述所引用。1999版的XSD规范允许复杂类型成员用attribute（属性）元素表示，而2001版的规范用element（元素）元素。同样，2001版规范要求所有的复杂类型成员都要被附在一个sequence元素里，用来保持顺序发生。这种修改了的以及与MS兼容的WSDL文件显示在Listing 2 中。我写了一个简单的工具用DOM(Document Object Model，文档对象模型)来解析原来的WSDL文件，进行我先前所讲到的更改并产生更改后的文档。这种功能的代码在Listing 3中。一个灵活的方法将创建一个servlet filter，其用于不通过中间文件来做这种在线的转换。这个练习留给读者。
SOAP堆栈互操作问题
另一种互操作问题围绕着SOAP消息从客户端到服务器的传送。当使用WSDL时，.NET平台SOAP消息遵照XSD－2001规范。对于大部分的消息与WLS FastParser 是向后兼容的。问题存在于SOAP 数组类型中，该类型用于对来自客户端的序列进行编码。本地类型的序列也有这个问题。按照WLS发布的注解，有一个已知的问题，#055596：“WLS Web services不支持SOAP 1.1 版本的多参数混合数据类型。” 此外，没有给出workaround。XSD－2001版提供一个灵活的最优化的技术，它允许一个节点在多个地方被引用。对于大量的序列这样做可以大大的减少消息的大小，因此保存了带宽并且减少了解析的次数。类似于WSDL转换，它需要一种机制用于过滤SOAP的交互。
为了截取和改变SOAP XML的有效负载，微软的 .NET框架提供了一个API。 它被称为SOAP扩展并且既可以用于客户端代理也可以用于 .NET主机服务。 Listing 4包含了一个被称为DispatchExtension的C# 源程序代码，以及和它相关DispatchExtensionAttribute属性类。它超出了这篇文章所要详细描述的怎样写.NET SOAP扩展的范围；只说fixXML( )方法做了大部分工作就足够了。为了简单着想，完全的丢弃并且重构消息体是一种很有效的方法。作为给读者的一个练习，这个代码可以增强为自动发现数组类型以及应用智能过滤。
当你编写和编译你的SOAP扩展代码的时候，这是最后一个步骤。那就是要在你的生成的代理类中用适当的方法注册属性类。下面的C#代码片断来自PresentationController 代理类，展示了它是如何完成这些的：
[DispatchExtension()]
public string dispatchAction(string arg0, string arg1,
string arg2, string arg3, NameValuePair[] arg4) {
在上面的代码片断中，DispatchExtension的属性构造器被放置在dispatchAction方法前。注意！如果你改变你的服务接口，你需要重新进行这个变更。
结论
当面临解决互操作的挑战时，在基础设施厂商改进他们的产品，改善其产品的不足的同时，请要确定为适配器代码最后的移除订制计划。
希望WLS发布的下一个版本可以包括 XML 串行化 / 非串行化基础结构以及SOAP 编码/解码的升级版来解决这些问题。除此之外，通过回调接口操作，SOAP交互的能力将会有大的提高。总的来说，BEA已经在他目前发布的产品版本中，在传送基层Web services性能方面做了极好的工作。这个结合了由.NET提供的优秀工具的平台，将向开发者提供构建系统方面最好的工具集。
[@more@]
然后, 用wsgen Ant任务创建.ear文件。在WLS产品销售时WebLogic捆绑这个功能以及Ant 1.3版本。产品文档中提供了该如何正确的完成该任务的详细描述。我的build.xml脚本文件包括以下的部分：
text="/${beanname}" protocol="http">
path="${jardest}/ejb_${beanname}.jar">
uri="/${beanname}"/>
程序定义了一个新的webservice target任务。它依靠一个叫做 init 的对象，依据常规在init target中定义了环境变量和参数。我所有的脚本文件都定义了 beanname 变量，它以各种不同的方式命名必需的文件。这个target将在一个运行中的WLS实例上创建和部署.ear文件。WLS 6.1 以一种非常简单的方法实现了SOAP和WSDL的一个保守的子集。它影响了已经由EJB建立起来的框架，同时还向开发者展示在不用添加任何Java代码情况下，如何对现存的EJB组件做成Web services。
不可避免的旅程颠簸
我正在处理一个项目它需要.NET客户端可以调用部署WLS上的服务。这段的代码在用本地类型（由XML模式定义）作为参数或返回值时工作正常。不幸的是，复杂类型或任何类型的序列则完全是另外一回事。在现实中这种限制有时是无法接受的。我求助于WLS参考文档看到了一个注释声明说WLS6.1支持微软SOAP Toolkit 2.0 SP2。作为 在W3C (WWW 联合会) XML委员会的一个关键的成员，微软在他的.NET框架中采用了2001 XML模式（XSD）规范。而SOAP Toolkit 2.0是基于1999年推荐的版本，WLS 6.1也是。
当今Web services正被认为是互操作的万能药，本文章对正确理解它也是有必要的。新技术一方面在发展同时它也同时也在变成类似于SOAP和WSDL等协议的基础。可以理解的是，应用服务器厂商必须提供稳定的和可靠的基础组件，它们必须要不犹豫的去支持最新的和最好的工业规范。我相信我的这些问题是可以解决的，在给出了简单的和精确的基于XML的Web services技术的情况下，我决定比较深入的研究互操作能力的问题。
互操作能力的问题
这篇文章略述了开发者必须面对的XML相关的互操作能力的问题，给出了WLS和.NET目前的状态。它们能分别被分类在两个涉及到WSDL 和 SOAP相关的领域。 WSDL (Web Services Description Language ，Web服务描述语言) 似乎是一个合理的起始点，因为在调用一个新创建的Web services之前，它必须被绑定以用于该过程的调用。
WSDL 堆栈互操作的问题
当WLS的Web services被部署时，一个能被公共访问的网页(JSP)是互用的。这个页面包含二个链接：第一个链接产生可以描述这个服务的WSDL文件，第二个链接允许下载一个习惯上称为client.jar的文件。这个.jar文件包含客户端代理类，SOAP 编码/解码和一些由BEA提供的用于简化服务调用的基础类。这是除了客户端应用相关的代码外的唯一需要在CLASSPATH中指定的.jar文件。对于基于Java的客户端，WSDL是外部的并且它只对UDDI注册有用。对于非Java客户端，情况则是相反的。
考虑到这个问题，我知道首先可做的是，要创建由C#代码编写的客户端代理程序(虽然VB.NET会是一个同样可行的替代方案)。作为一个有C/C# 背景的Java程序员，我几乎可以立即适应C#，它是我要选择的语言。在下载并安装 ASP.NET 软件包之后，我立即学习微软的Web services包括编译WSDL来产生代理代码的方法。 它们可以经由命令行执行WSDL.EXE程序或者通过使用Visual Studio.NET来访问。这些工具能够通过HTTP访问并且能在一个步骤内获取和编译WSDL。WSDL编译器产生一个以 .cs 为扩展名的源文件，它是通过在WSDL文件中 service XML元素的名字属性来命名的。 这个文件随后被编译成 .dll文件。 从客户端代码通过实例化产生的代理类来调用服务，并且这种方法的调用就好像是客户端的一种本地化的调用。我的情况是，由WLS创建的WSDL文档没有用.NET提供的编译器正确的编译。
我在WLS上创建和部署的Web services被命名为PresentationController并且它拥有一个名为dispatchAction的方法。这个方法有5个参数。前四个是简单的字符串类型，最后一个是NameValuePair JavaBean实例的数组。由WLS产生的WSDL文件显示在Listing 1中（这篇文章中的源代码可以从 www.sys-con.com/weblogic/sourcec.cfm 下载）。注意在文档头部的description元素。名字空间（namespace）属性参考了1999版的XSD说明。这是三个必须对WSDL做的对2001版兼容性提出的改变中的第一个。因为我的代码利用了NameValuePair JavaBean，WSDL包含一个内在的XSD模式，并附加了一个schema元素。 这个元素包含了任何复杂类型的标准XSD定义，他们可以被服务描述所引用。1999版的XSD规范允许复杂类型成员用attribute（属性）元素表示，而2001版的规范用element（元素）元素。同样，2001版规范要求所有的复杂类型成员都要被附在一个sequence元素里，用来保持顺序发生。这种修改了的以及与MS兼容的WSDL文件显示在Listing 2 中。我写了一个简单的工具用DOM(Document Object Model，文档对象模型)来解析原来的WSDL文件，进行我先前所讲到的更改并产生更改后的文档。这种功能的代码在Listing 3中。一个灵活的方法将创建一个servlet filter，其用于不通过中间文件来做这种在线的转换。这个练习留给读者。
SOAP堆栈互操作问题
另一种互操作问题围绕着SOAP消息从客户端到服务器的传送。当使用WSDL时，.NET平台SOAP消息遵照XSD－2001规范。对于大部分的消息与WLS FastParser 是向后兼容的。问题存在于SOAP 数组类型中，该类型用于对来自客户端的序列进行编码。本地类型的序列也有这个问题。按照WLS发布的注解，有一个已知的问题，#055596：“WLS Web services不支持SOAP 1.1 版本的多参数混合数据类型。” 此外，没有给出workaround。XSD－2001版提供一个灵活的最优化的技术，它允许一个节点在多个地方被引用。对于大量的序列这样做可以大大的减少消息的大小，因此保存了带宽并且减少了解析的次数。类似于WSDL转换，它需要一种机制用于过滤SOAP的交互。
为了截取和改变SOAP XML的有效负载，微软的 .NET框架提供了一个API。 它被称为SOAP扩展并且既可以用于客户端代理也可以用于 .NET主机服务。 Listing 4包含了一个被称为DispatchExtension的C# 源程序代码，以及和它相关DispatchExtensionAttribute属性类。它超出了这篇文章所要详细描述的怎样写.NET SOAP扩展的范围；只说fixXML( )方法做了大部分工作就足够了。为了简单着想，完全的丢弃并且重构消息体是一种很有效的方法。作为给读者的一个练习，这个代码可以增强为自动发现数组类型以及应用智能过滤。
当你编写和编译你的SOAP扩展代码的时候，这是最后一个步骤。那就是要在你的生成的代理类中用适当的方法注册属性类。下面的C#代码片断来自PresentationController 代理类，展示了它是如何完成这些的：
[DispatchExtension()]
public string dispatchAction(string arg0, string arg1,
string arg2, string arg3, NameValuePair[] arg4) {
在上面的代码片断中，DispatchExtension的属性构造器被放置在dispatchAction方法前。注意！如果你改变你的服务接口，你需要重新进行这个变更。
结论
当面临解决互操作的挑战时，在基础设施厂商改进他们的产品，改善其产品的不足的同时，请要确定为适配器代码最后的移除订制计划。
希望WLS发布的下一个版本可以包括 XML 串行化 / 非串行化基础结构以及SOAP 编码/解码的升级版来解决这些问题。除此之外，通过回调接口操作，SOAP交互的能力将会有大的提高。总的来说，BEA已经在他目前发布的产品版本中，在传送基层Web services性能方面做了极好的工作。这个结合了由.NET提供的优秀工具的平台，将向开发者提供构建系统方面最好的工具集。
[@more@]
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9650775/viewspace-921373/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/9650775/viewspace-921373/
扫一扫
631
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
