译文

译者：YY

注： 这是一篇从TSS首页上弄下来的文章，不代表我的观点。有些句子实在不然该怎么翻译，就猜上去了，很可能根本就背离了原意（-_-!）。我本是一个最初级的译者，接下来将列出有疑问的一些片段，希望关心俺的朋友们帮俺看看，这是俺第一次在blog上贴翻译拙作。

 

从SOA到SOI 是否是一个更好的选择？

SOA很精彩但它是一个高级的概念，我期待着有一天，SOA变成SOI，Services Oriented Implementation（面向服务的实现）。假设这样一个应用服务器，我可以在其上运行 Java，C++，甚至Perl或其它流行的语言，并且在一个引擎下管理它们，这个引擎紧紧跟随由世界顶级专家制定的规范，因为我需要保护我的投资（不要因为规范的改变而付之东流）。

当今的应用服务器都做的很好，他们为以下技术提供基础功能：线程和数据库连接池、发布应用程序、集群、基于web的管理系统等等，在我们的代码之外，还要保持这些细节是一项可怕的工作，如果有一天我们不得不为这些细节工作编码，那真的是很痛苦。把应用从一个服务器移到另一台服务器是相对容易些的。

所以我们提出SOI的设想，可以在一个单独应用服务器上运行Java，C++和Perl的应用程序。这是一个巨大的梦想，但它并不是不切实际的。我们还缺少：诊断、安全模块、集成框架、属性管理、审核、许可管理、analytics & instrumentation、持久层，等等。

但是，现在还没有SOI服务器，商业上利用混合各种已经存在的技术和自定义码来解决它们的问题。每一个商家都用自己的服务器来使用servlet，并且大家都认同而热衷于此。我们需要的是共性，而不是对不同问题的批判，当然了，任何人都可以争辩说，每一家公司都有它们自己的需求，我们怎么能解决这个问题呢？目前业界使用Servlet！关键的技术是把服务框架（例如属性管理）从实现中分离出来，例如在上述例子中，假设有一个Windows程序，通过Java或其它途径来管理属性。我们都可以做出这样一个系统，但它并不是一个好的解决办法，它并没有建立在标准之上，而且这样的资源不能比较轻易地重用。

这样问题是可以解决的！我相信有才能，并且踏实去做，还有要有供应商的支持，我们可以达到目的。现在已经有一些工作做在前面了，既有技术也有规范，如：

Diagnostics – log4j, JMX, and SNMP

Security model – Liberty Alliance, SAML

Auditing – log4j, Sarbans-Oxley

Property Management – JNDI, Preferences, JDO, ORM, etc.

License Management – only vendor technologies. Little in the way of adopted standards or open implementations.

Persistence – RDBM, JDO, ORM, the list goes on

Integration – MOM, ESB, SOAP and Web Services

 

这是一个能实现的梦想吗？企业会永远成为技术与标准竞争的混合体吗？在回答这个问题之前，想想，如果一家公司获得另一家公司的产品而且二者必须集为一个整体，需要多大的花费？但是这样的事情经常在发生。费用是巨大的！有人细读这个挑战并且有兴趣来做吗？

 

Milton Smith
[email][e-mail][/email]