当前似乎人人都愿意谈论SOA以及它如何解决大部分(如果不是全部)的架构问题。而在本文中我不打算讨论创建SOA的优点。我想谈的是什么技术能最大程度地帮助我们创建面向服务架构。似乎大多数支持SOA的人都一直在讨论使用web services来实现。让我们现实一些。web services是一项不错的技术，但是还远远达不到它关于创建跨web的无缝集成的承诺。用Jave创建的web services常常无法访问.NET客户机，反之亦然(参阅Web Services Interoperability和Web services programming tips and tricks: Improve interoperability between J2EE technology and .NET)。即使最后成功地进行跨平台web services通信，还是会面对很多问题，比如版本控制、安全性，以及难以表示XML中的复杂数据结构。如果web services都不能解决SOA的实现问题，还有哪种技术能解决?
终极SOA技术的特征
如果让我来开发一项技术，以协助构建健壮的面向服务架构，我认为它必须具备一些特征。具体来说，是以下特征:
对处理网络故障的强力支持——网络随时都可能出现故障。我希望该技术能包含这一点，并提供抽象的概念和具体的工具以恰当地处理网络故障。
安全性——关于这一点已经说得够多了。
表示复杂概念/交换复杂的数据结构的能力——我不想因为技术不支持而无法提供某种服务。
跨平台的兼容性——我不想因.NET或传统的客户机不能使用构建于Jave基础上的SOA而烦恼。
易用性——鉴于新框架、新技术和新方法的不断涌现，谁有时间纠缠于一项难以使用的技术?
现在我可以断言，有一项现有的技术符合80%的要求:Jini。虽然Jini这个主题值得更深入的研究，而不仅仅是了解我在这里强加给您的内容，但还是让我解释一下为什么我认为Jini符合那些要求(其中的大部分!)。
在我看来，Jini为解决网络故障问题提供了终极支持。由诸如租用(leasing)和自动服务发现之类的功能可以看出，Jini技术不仅意识到连接网络的不确定性，而且还提供了处理该问题的概念和工具。
Davis项目是为解决Jini中棘手的安全性问题创建的，它已经被并入了2.0版本。支持安全性的构建与所使用的安全传输协议相结合，形成一个完美的安全性解决方案。
Jini使用的都是可移动代码。因为我是在创建Jini服务，而不仅仅受限于交换数据。是的，我知道RPC(远程过程调用)被认为已经过时了。XML才是大势所趋。但无论如何，就我个人而言，我从不曾看好它，但那又是另外一个话题了……
跨平台的兼容性体现在几个方面。的确，Java是“一次编写，到处运行”的(不是吗?)，但是我们希望非Java的客户机也能使用支持SOA的Jini。例如，让支持Corba的客户机能够连接到Jini。要获得关于连接到Jini的非Java客户机的更多信息，请参考与Jim Waldo的对话。
您可能已经注意到，我将易用性放到了最后。这是Jini的不足之处。遗憾的是，构建复杂的Jini服务仍然很麻烦(需要有黑巫术、献祭的羊和神秘的仪式，非一般人能为)。这令人沮丧。
行动呼吁
我坚信Jini具有成为支持健壮的面向服务架构创建的技术的潜力，前面我只是试图吊起您对Jini的胃口，现在我要催促您从百忙之中抽出一点点时间来了解更多有关Jini的知识。在Jini.org上有一个繁荣的社区，Sun的官方Jini站点上也有很棒的信息。当然，您要问了，如果我所言属实，为什么Jini没有成为一项主流技术?为什么并非大家都在谈论Jini?好吧，回到Jini技术的致命缺点:易用性。不是开玩笑，Jini很难，这限制了它的广泛使用。如果某个大公司(例如:Sun、BEA或者IBM)能认识到Jini的力量并构造一个Jini服务器，我相信很快人人都在创建Jini服务。想想看，如果使用当前的语言特性，只能使用某些类似 @Jini-Service的方式来注释方法，就如同一些框架允许创建web服务一样，那为什么不利用Jini来构建SOA?问题在于创建框架(即Jini服务器)并非一项平常的任务。社区已经开始使用像Rio之类的项目来应对这项挑战，但仍然有许多工作要做。因此我将以一个对前面提及的大公司的挑战结尾:突破条条框框的限制，认识到使用Jini创建SOA的潜力，然后致力于创建Jini服务器，使开发人员在该平台上能够轻松地使用一两个注释来创建和部署Jini服务。嘿，如果你们不做的话，JBoss大概会做的……
(责任编辑：铭铭)
