在路上...

SCA的目的

Teamlet — Thu, 11 Jan 2007 06:48:00 +0000

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

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

SCA的起源

Teamlet — Thu, 11 Jan 2007 06:46:00 +0000

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

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

但是WSIF没有形成一个基于组件的架构模型，因此IBM在此基础上推出了一个面向服务的组件模型（Service Oritented Architecture, SCA）。

这个模型不但解决了统一调用的问题，还提出了一个基于组件的构建模型，并提供了许多面向企业计算的QoS能力。

因此，从技术的角度来说，SCA是WSIF的延续和扩展。

SCA Assembly Specification V0.9 (1)

Teamlet — Tue, 09 Jan 2007 13:48:00 +0000

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

JSR 260: Javadoc Tag Technology Update

Teamlet — Tue, 09 Jan 2007 06:25:00 +0000

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

JSR 259: Ad Hoc Networking API

Teamlet — Tue, 09 Jan 2007 06:19:00 +0000

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

JSR 258: Mobile User Interface Customization API

Teamlet — Tue, 09 Jan 2007 06:06:00 +0000

J2ME的手机用户界面定制API规范，目前处在最终审批的投票阶段，投票的结束日期是2007年1月16日。

JSR 257: Contactless Communication API

Teamlet — Tue, 09 Jan 2007 05:59:00 +0000

J2ME无线通讯API规范，最终发布时间为2006年10月17日。

JSR 256: Mobile Sensor API

Teamlet — Tue, 09 Jan 2007 05:54:00 +0000

这个规范定义了Mobile Sensor API。这个API可用于从内置传感器及用红外、蓝牙，或GPRS连接的传感器获取数据。内置传感器的例子有加速度计和给出终端状态数据的传感器，如网络信号强度传感器和电池充电传感器。规范最终发布时间为2006年4月10日。

JSR 255: Java Management Extensions (JMX) Specification, version 2.0

Teamlet — Tue, 09 Jan 2007 04:31:00 +0000

JSR 255 JMX 2.0 把目标定为更新 JMX 和 JMX Remote API ，从而从可用性的角度改善现有的接口。JSR 255把JMX API升级到2.0版本，Sun 计划将这一特性提供给Java SE 7.0 (Dolphin) 。目前规范处在组建专家组阶段。

JSR 254: OSS Discovery API

Teamlet — Tue, 09 Jan 2007 04:20:00 +0000

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)

终稿尚未发布。