三年前，当他开始计划为Boise公司——总部设在爱达荷州的工程建筑公司——实现SOA时，他调查了使用.NET或者J2EE作为开发环境中的优势和劣势。
“我确实感觉到J2EE平台的可测量性更好，健壮性更强，”他说。“在这三年内，我所从事的项目证明了这一点。的确，.NET大有前途，但是，我们选择的是J2EE平台。”
虽然，比较特殊地，他选择了Oracle公司的Fusion中间件，包括其BPEL管理者、企业服务总线，以及Oracle的Jdeveloper工具。但是，这并不意味着他能够忽视微软的产品。
“作为工程建筑公司，我们非常依赖微软的桌面技术，”他解释说。“我们所用到的大多数工程设计工具，都是采用了微软的桌面技术。我们必须相互交流。”
SOA项目的一个关键目标是，为应用程序(如预算以及财会程序)提供干净的、可靠的、在分离系统之间传输的数据，Colton说。这是非常重要的，举例说明，在预算和财会系统中，这些数据必须是完全一致的，以确保计划者和会计师能够察看并处理相同的数据。过去的数据都是采用手工传输的方式，这很难保证数据中没有错误或者数据完全匹配。
由于SOA项目的服务器端开发是用Java语言写的，但是，客户端所采用的系统是不同的，包括各种应用程序，也包括微软的应用程序，因此，与当前Web服务标准的结合就很难实现了，Coloton重申。使用Java语言写的组件必须既可以用在Java客户端，也能够用的.NET客户端。
从图纸上或者Visio图表中看起来很容易实现，但是，实际上并非如此，因为标准的采用和支持仍然需要进一步完善。
“SOA支持互操作性，”Colton说。“但是，我们需要处理的、关于SOA的、最大的技术问题是，互操作性至今还没有完善。”
尤其是他发现了，在J2EE平台和.NET平台上，W3C标准——用于数据类型，以及Web服务描述语言(WSDL)创建——的实现方法是不同的。
“只要我们开始使用，这两种选择都是很好的，”他说。“但是，这两种环境之间仍然存在这一些问题，因此，如果你打算写SOA环境下的Web服务，并且在这个SOA环境中，你希望客户端是运行在.NET上，而且要像Java客户端那样能够执行Web服务的话，你就需要注意这两种平台间存在的问题了。”
通过举例，他指出了两种环境处理远程过程调用(RPC)标准的方法。
“当你定义Web服务的类型时，你可以定义一个RPC类型的Web服务、一个RPC Literal类型的Web服务，以及一个document/literal类型的Web服务，”Colton解释说。“这三种类型是由开放标准定义的Web服务的负载类型。然而，微软仅仅选择实现RPC类型和document/literal类型的Web服务。他并没有实现RPC Literal类型的。另一方面，J2EE环境，虽然它支持这三种类型，但是，早期的使用向导构建的Web服务的Web服务描述语言(WSDL)，仅仅支持RPC类型和RPC Literal类型。”
虽然，这听起来好像是技术问题，但是，对于SOA项目而言，它是非常重要的——为不同的系统和用户通过国际型企业提供来自于所有消息中的精确的数据。
“你需要一个literal类型的原因是，基本上，负载都不是XML数据，”Colton解释说。“PDF文件就是一个例子。你希望传输PDF文件的话，你就需要采用literal类型作为负载类型。”
为了解决这一问题，开发团队必须仔细研究W3C标准，从而找出如何创建J2EE和.NET客户端都能够使用的Web服务描述语言(WSDL)。
“我们结束使用手工方法来构建这些Web服务描述语言(WSDL)从而进行相互交互了，”他说。“这其实是一个很大的挑战，因为在微软环境下——他能够接受的——以及J2EE环境中，我们没有足够多的例子。但是，我们需要解决这些问题。”
存在的困难是，早期的SOA技术有下降趋势。Colton说，从项目开始，在这个两年半的时间里，用于构建Web服务描述语言(WSDL)的、Oracle的Jdeveloper工具的向导已经不再具备绝对优势了。他相信，微软一定会改进.NET使其能够支持标准。虽然，交互性问题仍然存在，但是，华盛顿国际集团的项目组肯定能够解决这个问题。
“我们已经克服了这些困难，”Colton说。“我们现在感受到的不是前进过程遇到的困难，而是，我们现在已经把这个问题理解得非常透彻了。”构建一个既支持J2EE平台，同时也支持微软的.NET平台的面向服务的架构应用，这并不简单，但是，华盛顿国际集团公司应用程序整合主管Rich Colton说，他曾经参与过一个进行了两年半的项目，根据他的经验，同时支持J2EE和.NET是可以实现的。
|