非常感謝你的閱讀，如果你覺得好或者對你有幫助，請積極給一個留言反饋以示鼓勵。
?
提到這個話題，不免得提及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