cuiyi's blog(崔毅 crazycy)

记录点滴 鉴往事之得失 以资于发展
数据加载中……

可移植性(侧重Web Service)分析

本系列文章目录结构

       我对 SOA 的认识(一)(结合平时累积的笔记,不排除有引用) ( 修改版 )

       我对 SOA 的认识(二)(结合平时累积的笔记,不排除有引用)

       我对 SOA 的认识(三): SOA WebService 战略与战术

       SOA 和目前业成熟应用的 JavaEE 应用方案的一点看法

       JavaEE 中的三层结构和 MVC

       SOA 服务模型分析设计的一些概念

       SOA 涉及的组件和服务概念的整理(摘自水木)  

  SOA 涉及的 想 & 产品 & 技术

  可移植性(侧重Web Service )分析

10   任志宏关于 如何使用 IBM SOA 相关技术、产品和服务实现一个典型的业务场景 (转)

非常感谢你的阅读,如果你觉得好或者对你有帮助,请积极给一个留言反馈以示鼓励。  

提到这个话题,不免得提及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

posted on 2006-11-24 22:20 crazycy 阅读(871) 评论(2)  编辑  收藏 所属分类: JavaEE技术SOA、WebService、BPEL

评论

# re: JSR181规范的研究分析(JSR181 及 更深入化改进)  回复  更多评论   

actually you can find the function of annotaion, it will help to understand jsr181's real function.
2006-12-02 11:57 | fengtianxp[匿名]

# re: 可移植性(侧重Web Service)分析  回复  更多评论   

hao crazycy da ge
i want 2 learn
2007-04-22 15:08 | 思宽

只有注册用户登录后才能发表评论。


网站导航: