漫步云端 Java开发者的新选择

什么是云?

每个人对云的定义各自不同。我个人的理解是，从事非IT行业相关的公司，将其IT部分托管给专门的IT公司来做。由于他们自己不做IT，将其托管是可以理解的。另外，从事应用程序开发的公司，他们的重点在开发而非提供运行应用程序的设施及平台。由于开发人员和IT设施管理人员分工不同，此类公司将IT部分托管也是可以理解的。简而言之就是，你将你的东西托管在其他公司上运行。原来是有专门的托管公司，而现在，托管公司的职责逐渐被云基础设施所替代。云相对于托管公司的好处在于其弹性，当应用程序快速提高需求时云也能够很快适应。欲了解更加深入的了解云计算，可以参考本站的云计算专题。

云服务提供方

有了亚马逊EC2，你可以在虚拟机中安装你想要的一切。EC2提供了许多，但你仍然需要安装操作系统，网络服务器，网络或应用程序容器，数据库，以及你部署应用程序所需准备的一切。它提供一个虚拟机，而你所需要做的就是管理这个虚拟机中的一切。很有弹性，同时也有全面管理所面临的风险。对于云中的java来说再合适不过。

我认为Sun也会参与到这竞争中来，因为他们的网格计算应用程序的网站Network.com现在的改版信息就写着“Network.com正在改版中，我们正在添加一些令人振奋的新选择。现在我们还未准备好要展示我们的工作，不过我们欢迎来自您的建议与意见。有问题请随时联系我们。”这是有道理的，因为他们了解硬件，拥有Solaris，拥有Java，还有MySQL。

有了Google App Engine ，你无需使用虚拟机，也无需安装并管理操作系统，软件和数据库。到目前为止你还只能用Python在上面编程，而数据的提取和存储则通过DataStore(永久有效的服务)。你负责开发和部署你的应用程序。你还拥有Google账号，如Gmail等。不用操作系统，服务器和数据库，但是现在还限于Python和DataStore，由此导致现在的它还不是Java开发的选择。不过未来可能会支持更多的语言，最近有消息称Google下月发重大新品，App Engine或将支持Java。Google似乎对Python的喜爱超过Java。Sun也在尝试将Python整合进来，它找了两个Python开发者来开发Jython，通过它可以在JVM上运行Python。不管怎样，希望Google会将Java带到自己的引擎上——不行的话至少也有Jython。

微软Azure则纯粹是微软的技术了。Azure是一个开发、托管及管理的环境，配合微软Visual Studio的工具来协助可伸缩服务的创造，建设，调试，运行以及包装。一段时间内它都与Java无缘。

Force.com为Salesforce.com CRM应用程序服务，限定在其私有的Apex语言及Visualforce(表现层)。注意：Salesforce.com是一个SaaS(软件即服务)，Force.com是针对Salesforce.com CRM应用的PaaS(平台即服务)。SAP的Business ByDesign则是仅仅是SaaS。

Heroku限定使用Ruby on Rails，一款由Amazon EC2支持的语言。

可能有所遗漏，但以上清单中，只有Amazon EC2支持云中的Java。不过，Amazon EC2是一个IaaS(基础设施即服务)，还不是PaaS。所以我们需要找一个PaaS，以便于我们从管理OS，服务器以及网络和应用的容器中解放出来，专心在Java的开发中。一个名为Stax的新产品能够一定程度上解决这个问题。

Java的PaaS提供者

Stax是一款针对Java的PaaS，基础支持则是亚马逊EC2。可以将其想象成Google应用程序引擎，不过是用Java和MySQL数据库。Stax仅限Java，其目的在于令Java的开发，部署以及调整更加快速，而且你可以将应用程序部署在亚马逊基础设施上，而非Stax自己所提供的。Stax提供了建议的测试及生产的部署环境，一个本地开发模型，而且和现有的开发工具，框架及进程都融合的很好。其中包含了内置的应用程序模板，有流行的Java技术如Stuts，GWT，Wicket，JRuby on Rails，Jython等——但还不止如此。你可以通过Stax SDK将任意一个可以在网络容器中运行的应用程序部署于此。本地的Stax运行时是一个安装设置十分方便的环境，并为你的应用程序的包装及部署提供了一些工具。应用程序模板不过是将一些常用或有趣的配置整理到一起，使开发过程更加快速的手段之一。开发者可以随自己需求添加配置文件以及原本默认模板中没有的库。测试版期间的Stax是免费的。

云的特性及局限——Stax可以做什么?

将现有应用程序移至云端

运行现有的应用程序取决于该应用程序的“云友好”程度。Stax并没有打算取代普遍应用托管。Stax将重点放在弹性应用程序上，这些应用的需求可以通过计算资源的迅速改变而得到满足。这就是说任意一个应用实例可以随意的来，随意的走。这便为应用程序无差别的设置了一些设计限制，其中最大的两个是：

◆应用程序无法依赖于本地文件系统以实现其持久性

◆应用程序需要避免依赖本地服务器的记忆状态(除了caching in，这种情况下的应用只需要设计为当缓存丢失时从一个如DB的固定地点恢复缓存即可)

这就意味着现有的应用都将与Stax环境不兼容，不过Stax的创建者兼CEO，Spike Washburn表示说“这样具有伸缩性的编程手法将是应用程序的开发所需要的，因为无论在大环境的云上还是在私人的虚拟数据中心上，弹性基础设施的使用正在与日俱增。

Java应用在云中的监测，报告，调试和支持

由于应用程序是你开发的，所以你不需要调试支持。云需要为开发者提供一种功能，即有关他们程序运行所在的服务器的情况。就此，他们需要如报告/分析和监测/警报的API。这样，开发者的调试工作变得更加简便，并且对应用程序运行的状况也可以了如指掌，以便在第一时间做出反应。当然了，无论何时，开发者都需要了解他们自己应用程序的内部细节，所以日志就变成调试工作中无比重要的一部分。Washburn在交谈中说到，他们很快将推出监测/警报API，并计划提供更多功能和支持。

在其他应用程序服务器上的部署

Stax在设计上提供的Java网络容器(Tomcat)是与弹性计算云合成一体的。Stax的目标是帮助开发者达到应用程序部署灵活性的一个新的高度，这样不光方便了应用程序在弹性PaaS上部署所需要进行的向上或向下的调整，而且对于开发者而言，这种灵活性也方便他们将应用程序部署在他们自己的应用程序容器中。除了支持这种端到端的应用程序生命周期外，Stax还可以用于应用程序生命周期其中一部分的支持。比如说，在现在这个众人投往云端的趋势下，有些企业仍然不愿将整个生产线搬到云端上来，但是打算做一些小规模的开发以作测试用，所以，应用程序在两种环境下必须都能够运行(在Stax上测试，在他们自己的服务器环境上做生产)。

J2EE应用程序以及应用程序容器

目前为止，Stax还没有提供选择应用程序服务器实现的自由。只有Tomcat网络容器。

SPRing，JBoss Seam，JSF以及其他

只要能够在网络容器中运行的库，你都可以往里添加。Stax的初始应用模板其实主要是用来练手用，以帮助你熟悉一个系统的建立。里面有少许预建立好的应用程序配置，开发者用不了多久就能看完。在测试版反馈之后，他们将把新的Java模块系统(Java Module System)以及/或者OSGi也融合进来，以便于开发者创建新的应用程序方案。

如果你的应用程序需要Tomcat以外的支持，或者它需要访问本地文件系统，那么Stax恐怕不适合你。这种情况下你唯一的选择就是亚马逊EC2，或者你也可以等待其他的公司(Oracle，IBM?)推出“云中的Java”，看看那上面有没有你所期待的功能。