非常感谢你的阅读，如果你觉得好或者对你有帮助，请积极给一个留言反馈以示鼓励。
提到这个话题，不免得提及Java设计理念，以及与Web Service可移植性密切相关的三个JSR规范：JSR1.9、JSR175、JSR181
提到可移植性，我们又不免想到如下方式：
①XML配置文件屏蔽差异，类似Facade Pattern的形式统一入口
②注释
③类似JBoss提出的Micro-Container
我们进入正文：
Java一个理念是：Write Once， Run AnyWhere。Java哲学：Java追求平衡的哲学--即简单和力量的共赢。
从目标可以看出可移植性是Java的一个设计理念。
但Java世界的可移植性束缚苦恼着许多跨应用服务器的开发者、部署者。
JSR109
A. 目标：以一种可移植和互操作的方式为J2EE构建和访问Web服务（即Web Service在J2EE上的实现）。它指定了下面的条目：
a. 客户端编程模型：无论客户端如何访问Web服务，Web服务就像一个普通的远程对象一样（即J2EE如何把Web Service作为传统的远程对象来访问）；
b. 服务器端编程模型：Web服务怎样作为SLSB或JAX-RPC形式的Servlet实现（即怎样用Servlet和SLSB来实现Web Service并使Web Service具有和它们一样的生命周期）
c. 部署模型：使用部署描述符来定义可以在所有符合J2EE规范的应用服务器之间移植Web Service（即如何在应用服务器上部署Web Service）
B. 个人观点：a、b两点表现尚可，c着实不让人满意，因为实现互操作的目标没有问题，但是可移植性着实难以让人满意，问题关键是：部署描述符：
C. 疑问：为何JSR109不明确规定部署描述符的明确XML Schema，尤其是文件名、文件的标签、以及部署的文件个数。
JSR175（Java语言元数据工具）
A. 目标：用于 Java 编程语言的元数据,就是使用注释编程
B. 个人观点：①简化了开发尤其是配置文件 ②可移植性成为可能 ③类似“静态类”机制成为可能
说明：只要加载了类，类中的注释可以是运行中的，加载类的时候完成了配置，而这个加载可以是入口函数的调用、可以是Servlet加载。
我们知道只要加载了类，静态类变量、静态方法就自动被初始化到内存中；同理，要是有“静态类”.......
C. 疑问：注释能否像接口、类那样进行功能自定义化呢？！
D. 摘录：
JSR175仅仅有少量的注释类型变量，而这些有趣的注释类型变量主要来自于其他的JSRs：
•JSR 250: Java平台的公共注释
•JSR 220: 企业级JavaBeans 3.0
•JSR 224: 基于XML的Java API Web Services (JAX-WS) 2.0
•JSR 181: Java平台的Web Services Metadata
JSR181（Java Web服务元数据）
A. 目标：致力于Java Web Service。
基本理念：Java Web服务仅仅是带有某些标注的普通Java对象（POJO）。使用带有Java标注的Java语言编写Web服务，并且任何符合规范的处理器都能处理这些标注，并生成适用于目标运行时环境的Web Service。
涉及范围：
①定义用于进行Web服务应用程序编程的带注释的Java语法
②提供可促进和加速开发的简化Web服务开发模型
③提供可通过工具进行操作的语法
④定义构建和部署Web服务的标准，而无须了解通用API和部署描述符的知识和使用相关实现
B. 个人观点：由于规范没有指定web服务的运行环境，只提供了一个处理带注释的java文件的模型，以及到Java EE运行期间的环境的映射。这不免又存在不可移植性。
本文主要谈论可移植性，我们首先分析为何会出现这个现象？
首先我们知道J2EE中，部署后的应用程序的入口是META-INF文件夹，而这个文件夹下的部署描述文件则带有基本的描述信息。
在Web Service中， META-INF下具有部署描述符：webservices.xml和jax-rpc-mapping.xml；以及服务描述文件.wsdl。
webservices.xml依然没有逃脱出JSR109在可移植性不足的阴影，那我们可以知道，由于WSDL是国际规范，XML Schema明确加以描述，只要消除了部署描述符的差异，可移植性必然增强。
那如果没有部署描述符如何？
首先，我们来分析webservices.xml的作用：Web服务入口下的webservices.xml告诉容器在何处查找WSDL，以及将什么接口和实现用作Web服务。
同时，我们知道这些信息的解析起到了一个注册表的作用:map(uri-wso对象) wso对象包含:wsdl文件,jax-mapping文件,服务接口、实现类，等。
那我们有两种策略：
①运行中生成部署描述符－Java的注释
②放弃部署描述符的概念－
解释第①中做法：
JSR181处理器，一定要在运行中生成符合J2EE规范的部署描述符，而不是部署前就已生成好。
方式<一>：静态类，部署时必然要部署java类，如果有静态类（JVM增加功能）概念，则可以通过带注释的静态类来完成。
方式<二>：Servlet加载一个类，这个类中具备完善的注释，Servlet的加载机制必然导致类的加载，利用运行时注释生成部署描述符。
解释第②中做法：
不兼容是因为没有严格的XML Schema来描述部署描述符，而入口却是这些部署描述符的XML文件；
如果有部署描述符（包含运行中生成），无非是解析XML文件得到一个类似注册表的作用；
我们直接由java类来生成这些内存注册信息，而不是通过运行时注释。
方式<一>：静态类，部署时必然要部署java类，如果有静态类（JVM增加功能）概念。
方式<二>：Servlet加载一个类，这个类中具备完善的注释，Servlet的加载机制必然导致类的加载，利用运行时注释生成内存注册信息。
这两种方式不由得想起是否可以在META-INF下放置一个类？
是否可以类似Servlet机制，从Class-Loader入手？
是否可以继续改进JVM，直接可认出直接加载的类？
考虑到各集团的利益,可以看出JCP更多的致力于改良,而改革动作很少,改良往往意味着不能更好的满足新需求的呼唤,也埋下隐患.
Thanks very much to visit blog, welcome your feedback, your feedback is the Driver && Power to me