在路上...

        SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用。

        这种方式也使得客户的企业应用具有良好的分层架构，能够很好的分离应用的业务逻辑和IT逻辑，不但易于应用的构建，也易于应用的更改和部署。

        基于组件的编程一直是软件业简化编程和提高效率和质量的一个重要方法，但是往往对于不同语言我们有不同的组件模型，从而需要不同的调用方式。比如在J2EE技术领域，我们就有EJB，POJO，JDBC，JMS等，这对于开发人员来说是一个极大的挑战。

        为了给这些不同的接口提供一个统一的调用方式，IBM提出了WSIF （Web Service Invocation Framework，具体请参考http://ws.apache.org/wsif/ ），并将它贡献给Apache组织。WSIF作为Web Service领域的一个规范，提供了一种基于Java API统一调用各种服务的能力。

          （全文共772字）——点击此处阅读全文

1 Assembly Model  装配模型

1.1 Introduction  介绍

This chapter describes the SCA Assembly Model, which covers
这章介绍SCA装配模型，内容包括

*A model for the assembly of tightly coupled services
紧密耦合服务的装配模型

*A model for the assembly of loosely coupled service-oriented systems
松散耦合的面向服务系统的装配模型

The chapter starts with a short overview of the SCA Assembly Model.
这章的一开始简短地概述SCA的装配模型。

The second part of this chapter describes the design-time Assembly of tightly coupled services through the use of Modules.
本章第二部分描述设计时期通过使用模型来完成紧密耦合服务的装配

The third part of this chapter covers the SCA deployment-time artifacts - how an SCA system (i.e. the SCA runtime) composes loosely coupled services using Subsystems which configure modules.
本章的第三部分涵盖SCA部署时期的中间组件(由组件组成的粒度更大的组件)，一个SCA系统(例如,SCA运行时期)怎样使用通过配置模型实现的子系统来组成松散耦合的服务.

The next part of the chapter covers Bindings, which describes how SCA makes use of specific access methods such as Web services.
本章的下一个部分包括绑定,绑定描述SCA怎样利用指定的访问方法,比如web服务。

The final part of this chapter defines how the SCA assembly model can be extended.
本章最后一部分定义SCA装配模型怎样能被扩展。

术语解释：

SCA ：Service Component Architecture——服务组件架构

Assembly ：装配，组装，合成

tightly coupled  ：紧密偶合

loosely coupled ：松散偶合

design-time：设计时期,也称坐设计时,指系统在做设计时候的那段时间

deployment-time：部署时期

runtime：运行时期,等同与run-time

artifacts：产品,作品,人工制品。这里理解为由多个组件组成更大粒度的组件,称为中间组件。中间组件在层次上位于下层组件和子系统之间，所以这么称呼。

更新Javadoc的标签技术规范。规范定义了新的标签，在生成的Javadoc表现方面主要目的是增加文档的可读性，提供更加丰富的信息，使Javadoc更适合开发人员学习和使用APIs。

特别网络通讯API规范，属于J2ME平台，允许移动设备之间在特别的网络环境中实现点对点的通讯。初期草案评审已经在2006年3月01日结束。

OSS 业务发现API规范 (JSR 254)

OSS（Operational Support System）运营支撑系统，一般指为电信运营商及其网络提供业务管理、库存管理、工程、规划和维护功能的系统。
 
OSS/J发布Web Services 集成规范 - 支持基于Web Service的SOA，满足电信运营商需求    2006/02/20

OSS/J（OSS Through Java）是以JAVA技术为动力的OSS（运营支撑系统）解决方案。日前在SYS-CON Italia上，WBT News Desk宣布OSS/J为其Trouble Ticket API(JSR 91)新添了一项用于集成Web Services 的规范。服务提供商能够通过基于web services的OSS/J， 直接为客户和业务伙伴提供OSS服务，而无需花重金去打造客户端软件或客户通信软件。
OSS/J 定义了一系列完成特定功能的API，加速OSS/BSS解决方案的开发，解决各个应用协同工作的问题。所有OSS/J发布的API均通过最新的Java社区进程（JCP）标准化认证。OSS/J 是当前唯一提供所有参考实现、兼容性测试工具、认证产品清单以及全套工具、适配器和扩展插件的开放OSS标准。所有的OSS/J API均可免费下载。
Web service规范的发布最终完成了OSS/J API 集成规范，同时解决了B2B的集成。
" 这是我们完成OSS-aware 面向服务架构(SOA)的最后一步，可以实现对下一代电信网络及服务的管理， " Sun Microsystems的 Philippe Lalande 发表了看法，他也是该项目的负责人。" 由于 OSS/J 技术现在在全世界范围内被服务提供商广泛采取，我们不断地收到关于该API Roadmap的有效反馈。运营商告诉我们，他们需要灵活的方案来支持不同的集成策略。这个反馈让我们预见到未来的业务形式需要web service，于是我们发布了这套规范来满足他们迫切的需求。"
规范支持基于web services的SOA，满足全球运营商的需求。OSS/J 技术根据电信管理论坛(TMF)提出的下一代运营支撑系统（NGOSS）框架而设计， 该框架提供架构指导、信息和数据模型以及业务进程模型。OSS/J web service 规范是TMF关于Web Services Enablement的首个实现。
“我们欣喜地看到OSS/J的web services规范与TMF的Web Service Enablement项目思想完全吻合，”电信管理论坛的CTO Martin Creaner这样说。“这个真实世界模型是对NGOSS 框架真实性的一个重要确认。该框架作为一个技术无关的架构，将继续在电信领域证明它的价值。NGOSS，OSS/J 和基于Web service 的面向服务架构一起走向成熟，在很多方面经历都是相同的。”
Vodafone Germany网络管理首席工程师Joerg Frankenberger 在评论其可用性时说，" 随着OSS/J web service 规范的发布，Vodafone 能够有效地集成合作伙伴和供应商集中到全球OSS体系架构中。这不仅会降低集成费用，更有利于在互通的网络上实现战略合作。我们预计使用OSS/J技术后，会节约20%甚至更多的集成开销。新增web service规范后还会继续增加节约的金额。"
预计2006 年4月发布其他关于web service 规范说明的OSS/J API。
其它通过JCP项目标准化认证的OSS/J API包括：

OSS 服务开通 (JSR 89)
OSS 服务质量 (JSR 90)
OSS 故障单 (JSR 91)
OSS 计费(JSR 130)
OSS 库存 (JSR 142)
OSS 通用 (JSR 144)
OSS 服务质量管理 (JSR 210)
定价 (JSR 251)
OSS 业务发现 (JSR 254)
故障管理 (JSR 263)
订购管理 (JSR 264)

终稿尚未发布。

5  XML Parsing Specification
6  Unified Printing API (Java Print Service API)
10  Preferences API Specification
13  Decimal Arithmetic Enhancement
14  Add Generic Types To The JavaTM Programming Language
15  Image I/O Framework Specification
41  A Simple Assertion Facility
47  Logging API Specification
51  New I/O APIs for the JavaTM Platform
54  JDBCTM 3.0 Specification
55  Certification Path API
56  Java Network Launching Protocol and API
57  Long-Term Persistence for JavaBeansTM Specification
59  J2SETM Merlin Release Contents
72  JavaTM GSS API
163  JavaTM Platform Profiling Architecture
166  Concurrency Utilities
174  Monitoring and Management Specification for the JavaTM Virtual Machine
175  A Metadata Facility for the JavaTM Programming Language
176  J2SETM 5.0 (Tiger) Release Contents
199  JavaTM Compiler API
200  Network Transfer Format for JavaTM Archives.
201  Extending the JavaTM Programming Language with Enumerations, Autoboxing, Enhanced for loops and Static Import
202  JavaTM Class File Specification Update
203  More New I/O APIs for the JavaTM Platform ("NIO.2") 
204  Unicode Supplementary Character Support
206  JavaTM API for XML Processing (JAXP) 1.3
208  JavaTM Business Integration (JBI)
250  Common Annotations for the JavaTM Platform
268  JavaTM Smart Card I/O API
269  Pluggable Annotation Processing API
270  JavaTM SE 6 Release Contents
277  JavaTM Module System
292  Supporting Dynamically Typed Languages on the JavaTM Platform
294  Improved Modularity Support in the JavaTM Programming Language
901  JavaTM Language Specification
915  J2SETM 1.4 (Merlin) Maintenance Review
916  J2SETM 1.4 (Merlin) Beta 2 Maintenance Review
917  J2SETM 1.4 (Merlin) Beta 3 Maintenance Review
918  J2SETM 1.4 Release Candidate
923  J2SETM 1.4.2 (Mantis) Beta
924  JavaTM Virtual Machine Specification

在JCP分类中，J2SE平台相关规范显示的是43个，是因为把其中199  Java Compiler API 显示了两遍，也统计了两遍。实际上J2SE平台相关规范是42个。

JSR 248: Mobile Service Architecture MSA 移动服务架构。

MSA for CLDC规范定义了移动电话上的下一代Java平台，当然是基于CLDC的J2ME平台。

MSA for CLDC的目的是为了减少J2ME平台的API分裂，为开发者定义一个高操作性的应用程序和服务环境。

JTWI（Java Technology for Wireless Industry，JSR 185）定义了一系列的规范来强制实现JTWI规范的设备必须实现某些JSR，例如MIDP2.0，WMA和MMAPI等。MSA for CLDC可以认为是JTWI的第2版，它规定了一个高度集中的J2ME平台运行环境。

在JSR 248中共定义的组成JSR如下所示：

JSR 75 – PDA Optional Packages for the J2ME Platform Version 1.0

JSR 82 – Java APIs for Bluetooth Version 1.1

JSR 118 – Mobile Information Device Profile 2.0 Version 2.0.1

JSR 135 – Mobile Media API Version 1.1

JSR 139 – Connected Limited Device Configuration 1.1 Version 1.1

JSR 172 - J2ME Web Services Specification Version 1.0

JSR 177 – Security and Trust Services API for J2ME Version 1.0

JSR 179 – Location API for J2ME Version 1.0.1

JSR 180 – SIP API for J2ME Version 1.0.1

JSR 184 - Mobile 3D Graphics API for J2ME Version 1.1

JSR 185 – Java Technology for the Wireless Industry Version 1.0

JSR 205 – Wireless Messaging API 2.0 Version 2.0

JSR 211 – Content Handler API Version 1.0

JSR 226 - Scalable 2D Vector Graphics API for J2ME Version 1.0

JSR 229 – Payment API Version 1.0

JSR 234 – Advanced Multimedia Supplements Version 1.0

JSR 238 – Mobile Internationalization API Version 1.0

Java数据挖掘API 2.0 （JDM 2.0，JSR-247）的目标是为数据挖掘工具创建一个标准的Java  API，以便Java应用程序访问它们。JDM承诺让数据挖掘变得像JDBC那样容易使用，使数据挖掘成为企业级Java开发者工具箱中的一个新成员。这篇文章介绍了数据挖掘的基本概念，并展示了一些使用JDM进行数据挖掘的例子。在JSR-73 JDM 1.0 之上增加挖掘功能和算法。

More ... http://www.artima.com/lejava/articles/data_miningP.html

JSR-244则规定了Java EE 5总体框架下需要具备的技术特性。

JSR 243: Java Data Objects 2.0 Java 数据对象,即JDO 2.0

Java数据对象(Java Data Objects，JDO)是一个应用程序接口(API)，它是Java程序员能够间接地访问数据库，也就是说，不需使用直接的结构化查询语言(SQL)语句。JDO是作为Java数据库连接(JDBC)的一个补充来介绍的，而JDBC是一个支持使用SOL语句对流行的数据库程序进行访问的接口。有了JDO，程序员就可以使用类来定义数据对象，然后支撑程序就会根据类的定义来管理对给定数据库的实际的数据访问了。

使用JDO的好处

·简便性（Portability）：使用JDO API编写的程序可以在不同开发商的多种可用的实现上运行，不用修改一行代码，甚至不用重新编译。

·透明地访问数据库（Transparent database access）：应用程序开发者编写代码透明地访问底层数据存储，而不需要使用任何数据库特定代码。

·易用性（Ease of use）：JDO API允许开发者只需要关注他们自己范围内的数据模型（Domain Object Model，DOM），而持久化的细节就留给JDO实现。

·高性能（High Performance）：Java应用程序开发者不需要担心数据访问的性能优化，因为这个任务已经委派给了JDO实现，它通过改善数据访问的模式以获得最佳性能。

JSR 242: Digital Set Top Box Profile - "On Ramp to OCAP" ,数字机顶盒简表规范。这是 J2ME Connected Limited Device Configuration (CLDC) 设备的规范。 

OCAP(Open Cable Applications Platform，开发的有线电视应用平台)，OCAP要求有线电视网络系统和消费者的终端接收设备都支持它才有效，其标准化可以避免重复开发、减少开发成本，并且会促进交互式的节目指南、游戏下载、数字视频录制等应用的普及。该规范为数字机顶盒对OCAP提供了支持环境。

JSR 237: Work Manager for Application Servers，应用程序服务器工作管理（Work Manager for Application Servers），该规范为任务的并发执行提供简单的、容器可管理的编程模型。

JSR 235 服务数据对象(SDO)。SDO是Java平台的一种数据编程架构和API，它统一了不同数据源类型的数据编程，提供了对通用应用程序模式的健壮支持，并使应用程序、工具和框架更容易查询、读取、更新和检查数据。

SDO 的目标

　　SDO 的目标有很多，从某种程度上讲 SDO 看起来好像是 J2EE 的一把多功能“瑞士军刀”，因为它包含的特性可实现多种不同种类的功能，基本来讲，SDO 及其相关的技术设计有以下五大主要专题:

　　简化数据访问:第一个目标是提供对多种企业信息系统 (EIS) 的统一的数据访问，包括数据库、遗留应用程序(使用 JCA)、XML 或者是 Web 服务数据源。通过使用 SDO 的一种独特而简单的模型，应用程序摆脱了使用多种 API 和框架进行数据访问的复杂工作。

　　数据提取:使用 SDO 后，数据的表示是独立于其数据源的，它采用了一种叫做 Domain Store 的 J2EE 模式，这种级别的数据提取有很多优点，例如使数据操作变得更容易，实现了不同层之间的松耦合。

　　数据操作:一旦检索到信息后，SDO 会提供一种统一的编程语言进行数据操作，简单的说，就是通过使用 API 及其接口，SDO 客户机可以读取数据和修改数据。SDO 为此提供了连接和断开连接的两种模型，下文中将对此做详尽的介绍。

　　数据传输:SDO 有一部分概念是关于传输对象 (Transfer Object) 和传输对象组装程序 (Transfer Object Assembler) 模式的。数据封装到 SDO 对象中后，它就可以在 J2EE 层间高效地传输。

　　设计模式的采用:SDO 的一个关键目标是鼓励大家采用公用的 J2EE 模式，这也是 SDO 体系结构以一些广为人知的模式为基础的原因，例如传输对象 (Transfer Object)、数据访问对象 (Data Access Object)、传输对象组装程序和 Domain Store等。如果使用了 SDO，应用程序就可以从这些经过了验证的设计策略中受益，从而可以推动分层技术和松耦合的发展。

JSR 233: J2EE Mobile Device Management and Monitoring Specification --J2EE 移动设备管理和监测规范

 此JSR定义了J2EE平台的扩展集，目的是远程监测和管理移动设备中的软件。

JSR 233 为 Java 设计了一套脚本语言 API。这一套 API 提供了在Java 程序中调用各种脚本语言引擎的接口。任何实现了这一接口的脚本语言引擎都可以在 Java 程序中被调用。

JSR 227 为J2EE定义灵活的数据绑定和数据访问标准。JSR 227提出了一种可以声明式地将Web用户界面组件绑定到异构的后端数据源的功能。例如，JavaServer Faces组件（例如，一个网格组件）可以被绑定到关系数据或来自Web服务的XML数据。与服务数据对象(Service Data Objects ，SDO)关系密切。规范目前处在审批过程中。

JSR 225: XQuery API for Java (XQJ)    XQJ 是用于查询 XML 数据的 Java API。本规范目前还处在初期的草稿阶段，已经进行了二次评审。

XQuery 是一种用于文件和数据库中基于 XML 标记文档内容的新型查询语言。

XQuery是一种发展得最为慎重的W3C标准，因而演化得也最为缓慢，XQuery也因此而闻名。造成这种现象的一个主要原因就是，对于如何获得以XML形式存储的信息，业界还没有什么经验。许多公司仍然在这个领域创新，并且正不断产生大量的经验信息，这些信息必须经过处理和提炼，才能使解决XML查询问题的水平达到令人满意的程度。

XQuery还不是W3C推荐标准。最新的工作草案已经有了显著的进展，并且正在被许多不同的供应商或多或少地实现。一些市场主导供应商例如BEA和Software AG已经决定发布一些基于这些工作草案的产品，但是直到其成为W3C的推荐标准前，这些厂商并不准备紧跟这一标准。由于最终发布版的延迟推出，有关其实施的大规模市场推广计划尚未开始。

XQuery低公开度的另一个原因就是，到目前为止，还没什么证据能表明XML格式的数据存储能够成为将关系型数据存储拉下马的通用技术。虽然XML数据库展现出很多有价值的和特殊的特性，但是它们在市场渗透方面与面向对象数据库比较相似。这两种数据库都可以很方便地解决专业问题，并且适用于中小型系统。不过，随着存储问题复杂性的增加，XML和面向对象数据库看起来都没有关系型数据库那样容易扩展。实际上，像关系型数据库那样运作可能也不会取得成功。只有在技术方面的大踏步前进才会减少对关系型数据库管理系统遗留项目的大量投资。

XQuery 的诞生

由于各种各样的原因，W3C 在 1998 年召集了一个工作小组讨论 XML 文档查询的方案，并且于 1999 年成立了 XML 查询工作组。这个工作组从 2000 年开始与扩展样式语言（XSL）工作组合作。

XML 查询工作组包括的成员涉及查询语言设计、查询优化和 SQL 标准演变等领域，具有代表性的公司有 IBM、AT&T、BEA、贝尔实验室、DataDirect、微软和Oracle，他们共同工作并形成了一系列的文档，这些文档包括需求规范、数据模型和查询代数、处理模型、形式语法、用例、序列化规范和一个 XQuery 语言规范。

在今年的早些时候，XML 查询工作组交付了一个 XQuery 1.0 规范的工作草案，用于公开评审以及与 XSL 工作组共同推动 XPath 2.0 规范的发展，XPath 是用于提供对文档内容寻址的语法规范。XQuery 1.0 支持所有的 XPath 2.0 表达式。两者之间的一个不同之处是 XQuery 表达式返回一个排好序的节点序列，而 XPath 表达式返回的是一个节点集合。XQuery 通过返回与文档顺序一致的节点序列来保持与 XPath 的兼容。

XQuery 如何工作？

在 XQuery 语言中的一个查询包含了一个或几个查询表达式。XQuery 支持条件表达式、元素构造器和 FORM、LET、WHERE、RETURN（FLWR） 表达式，表达式包括了一些运算符、函数调用、量化、类型检查和路径表达式。一些 XQuery 表达式求出简单节点的值（例如元素和属性）或原子节点的值（例如字符串和数字）。查询也能求出这两种节点的次序和简单值。

XQuery 的查询结果是 XML 查询数据模型的实例。它使用了 XML schema 类型并且提供编译时的静态类型和运行时的动态类型，同时也支持原始的和衍生的类型。

在任何关于 XQuery 的讨论中，你可能都会经常听见与 FLWR 表达式相关的内容，这是一种用 FOR、LET、WHERE、RETURN 子句来进行查询、过滤和传送记录的语法。一个 FLWR 表达式创建一些绑定，应用一个谓词逻辑，并且产生一个结果集。FOR 用于创建对选定节点的绑定，而 LET 用于创建对单个节点的绑定，FOR 子句可以嵌套使用，这在 XQuery 反复对结果序列进行循环处理时非常有用。

XQuery 没有遵循 SQL 的一些惯例。例如，SQL 没有节点的实质概念，并且不能基于一棵树中节点位置进行遍历或存储信息。而 XQuery 1.0 目前并不支持数据的更新，虽然这点在新版本的计划中将得到支持。

但是 XQuery 和 SQL也共享了一些相似的概念。这两种语言都提供了关键字用于投影和变换操作（如 SQL 中的 SELECT 和 XQuery 中的 RETURN）。SQL 支持表的联合，XQuery 也支持多个文档之间的联合。XQuery 也能通过 WHERE 进行信息过滤，通过 ORDER BY 进行排序。XQuery 和 SQL 都提供了函数调用和用户自定义函数等功能。

More ...

http://dev2dev.bea.com.cn/techdoc/200409243.html

http://www.ibm.com/developerworks/cn/db2/library/techarticles/mag_03q3north/north.html

JSR 223 在2006年12月11日发布了最终稿。

JSR-223 定义了一些接口，用来衔接使用 Java 实现的脚本语言和 Java 本身通讯，是Java与Scritps 互操作的一个桥梁。主要职责差不多是让 Java 执行动态语言脚本，访问动态语言执行中产生的变量、函数等，同时让动态语言能够在它的范围内访问到 Java 空间里面的指定变量，达到互操作的目的。

JSR-223 除了一个标准的给用户使用的接口之外应该还有一部分给 Scripts Provider 让他们将自己的实现符合这个规范，达到一致的目的。

JDBC 4.0 规范在2006年12月11日发布了最终稿。

JDBC 4.0 API 规范寻求通过提供开发的简易性的重要特征和在使用工具和API 水平上的改善来促进Java应用程序进入SQL 数据存储。
通过使用为JSR-176 Java 2 标准版1.5 软件而计划的新Java 语言特征，比如定义在JSR-175 中的注解和定义在JSR-014 中的泛型，
以及提供一套JDBC 工具类，SQL 开发者就能够在从JDBC API 中获利的同时更容易地进入SQL 数据源。