当前似乎人人都愿意谈论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大概会做的……
评论
- Cebess的评论非常中肯。当我写此文时，我正在参加一个电话会议。我们正试图针对我们所进行的特定项目弄清楚他所说的关于开发SOA的问题。但是对于为什么Jini没有得到广泛应用这个问题，我认为我可以试着回答。几年前我的团队就开始研究Jini。我们发现，阻碍Jini发展的一个很大的因素是其赢利性的许可证模式，这使工具制造商（如BEA）难以实现收益。这种情况可能已经改变了，但是当时看起来似乎Jini模型技术上没有问题，它的问题在于不允许进入市场。这个问题不会出现在Java（甚至是J2EE）社区中。
发表人：nix66 7月，27, 2005年，09:47 AM
- 我发现大多数讨论SOA（具体来说是企业级）的人都似乎忽略了一个重要因素——模拟。根据定义，服务之间是互相依赖的。如果企业级SOA得到有效开发的话，Greenfield开发应该是能够避免的。因为服务在开发或模型环境中有效并不意味着它们在复杂的生产环境中也能发挥作用。因为虽然设计服务的目的是为了提供结果，但这并不意味着它会在要求的等待时间内提供结果。我认为服务交互模拟是SOA理念固有的要求，而在当今的市场上却并未有效地体现出来。如果模拟得不到有效处理，整个企业在生产中进行无法预料的交互时就会像一座纸片搭成的房子那样轰然倒塌。
发表人：cebess，2005年7月20日，05:48 AM
- 在2004年9月6日的ComputerWorld中有一篇很有意思的文章，是关于Orbitz对Jini的使用的。
发表人：skaterdude，2005年7月18日，09:58 AM
- 我承认Jini没有引起我足够的注意，我已经将其列入我的学习日程表中了。但是我不认为供应商参与到这个领域中会改变形势。可以通过一些注释（就如J(2)EE层，从EJB到WS到JDBC）或一组工具（参见IncaX f.e.）使其变得容易使用。但是我们现在所处的阶段是由业务需求和特征驱动的，而不是由实现方式驱动的。因此我认为我们更需要@Transactional、@Clustered、@Cache、@GridDistributed(mode=DivideAndConquer)等等，而不是“@Jini-Service”，它使Jini（或其他用于实现以用户为中心的中间件服务的技术）成为一种实现技术（可能确实是最好的一种），但是这并不是供应商的利益所在。
（T111）
