Tutorial of SOAP with Attachments API for Java
随着web 服务、SOA 概念的兴起，和诸多 SOA 应用的实践，Java 阵营也审时度势，趁势推出相应的 API 以应对这一变化。SOAP 是 Java web 服务栈中很基础的一项技术，web 服务间以 SOAP 消息来互相通信。
SOAP with Attachments API for Java(简称 SAAJ) 就是 Java 阵营为访问 web 服务所提供的基础设施，它简化了对 SOAP 的处理。
SAAJ 包含 2 部分 APIs，其一用于创建消息，添加消息内容，其二则用于建立连接，发送 SOAP 消息。
Categorized in: SOA · Tagged with: SAAJ, SOAP, Webservice, XML
Structures of SOAP with Attachments
还是图形看起来更直观：
—-
Categorized in: SOA · Tagged with: SOAP, Webservice
SMTP Transport Binding for SOAP
SOAP 除了可以 bind 到 HTTP 上外, 也可以 bind 到 SMTP 上. 其实个人感觉, SOAP bind 到 SMTP 上的场景很少会使用到, 通常限于 one-way operation (比如通知等不需要响应). 如果需要实现 request/response, 那么是需要多做一些工作的(下文会有叙述).
soap:binding element 的 transport 属性需指定一个 http://xxx(例如:http://schemas.xmlsoap.org/soap/smtp) URL 来表明所要 binding 的 protocol. 似乎这个 URL 是任意形式, 只要能让调用方知道要使用什么协议即可. 在 soap:address 要给定 mailto:xxxx@xxx.xxx 这样形式的 URI.
<service name=”StockQuoteServiceBinding_service”>
[...]
Categorized in: SOA · Tagged with: SOAP, UDDI, Webservice, WSDL, XML
Which style of WSDL should I use? (reship)
A Web Services Description Language (WSDL) binding style can be RPC or document. The use can be encoded or literal. How do you determine which combination of style and use to use? The author describes the WSDL and SOAP messages for each combination to help you decide.
Categorized in: SOA · Tagged with: schema, SOAP, UDDI, Webservice, WSDL, XML
软件及服务的松耦合
软件的模块性:
模块可分解性（Modular Decomposability）——如果一种软件构造方法能有助于把一个软件问题分解为若干较简单的子问题、并用一个简单的结构将这些子问题连接起来、而且能够独立地对各个子问题作进一步分解，那么该方法就满足模块可分解性。
模块可组合性（Modular Composability）——如果一种方法，由它生产出的软件元素，未来可在不同于最初被开发的环境中通过彼此自由组合的方式来产生新的系统，那么该方法就满足模块可组合性。
模块可理解性（Modular Understandability）——如果一种方法，由它生产出的软件，人类读者无需了解其他模块（或最多只需研究少许其他模块）便可理解每一个模块，那么该方法就有利于模块可理解性。
模块连续性（Modular Continuity）——如果一种方法，在由它得到的软件架构中，功能规格上的微小改动只会引起一个（或少量）模块的变化，那么该方法就满足模块连续性。
模块保护性（Modular Protection）——如果一种方法，在由它得到的架构中，一个模块在运行时出现异常条件不会影响到该模块之外（或最多只蔓延到少数周边模块），那么该方法就满足模块保护性。
服务的模块性:
可分解性（Decomposability）——如果一种方法能有助于把一个软件问题分解为若干较简单的子问题、并用一个简单的结构将这些子问题连接起来、而且能够独立地对各个子问题作进一步分解，那么该方法就满足可分解性。
可组合性（Composability）——如果一种方法，由它生产出的软件元素，未来可在不同于最初被开发的环境中通过彼此自由组合的方式来产生新的系统，那么该方法就满足可组合性。
可理解性（Understandability）——如果一种方法，由它生产出的软件，人类读者无需了解其他模块（或最多只需研究少许其他模块）便可理解每一个模块，那么该方法就有利于可理解性。
连续性（Continuity）——如果一种方法，在由它得到的软件架构中，功能规格上的微小改动只会引起一个（或少量）模块的变化，那么该方法就满足连续性。
保护性（Protection）——如果一种方法，在由它得到的架构中，一个模块在运行时出现异常条件不会影响到该模块之外（或最多只蔓延到少数周边模块），那么该方法就满足保护性。
自查性（Introspection）——如果一个方法，由它得到的架构提供了“允许在运行时查询并检查模块结构及模块间通信结构”的机制，那么该方法就满足自查性。
远程性（Remoteability）——如果一个方法，由它得到的架构提供了“允许托管于不同物理环境下的不同模块与之进行模块通信”的机制，那么该方法就满足远程性。
异步性（Asynchronicity）——如果一个方法，由它得到的架构不假定模块调用将被立即响应，那么该方法就满足异步性。换言之，它假定网络或被调用模块有延迟。
面向文档（Document Orientedness）——如果一个方法，在由它得到的架构中，内部模块间的通信消息均是明确定义且互相知道的、而且各次调用之间不存在隐式的状态共享，那么该方法就是面向文档的。
标准化的协议信封（Standardized Protocol Envelope）——如果一个方法，由它得到的架构要求所有模块通信都共用一种通用信封消息格式，那么该方法就满足标准协议信封。
分散式管理（Decentralized Administration）——如果一个方法，由它得到的架构不需要对所有模块进行集中管理，那么该方法就符合分散式管理。
原文:
SOA定义的松耦合
Loose Coupling in SOA Defined
Categorized in: Design Patterns, SOA · Tagged with: DesignPatterns, SOA, Webservice
设计与开发 JAX-WS 2.0 Web 服务
Naveen Balani, 开发经理, IBM2007 年 11 月 29 日
通过使用 Java™ API for XML Web Services (JAX-WS) 技术设计和开发 Web 服务，可以带来很多好处，能简化 Web 服务的开发和部署，并能加速 Web 服务的开发。通过此教程，可以了解如何开发将其功能作为 Web 服务公开的示例订单处理程序，从而进行所有这些工作以及其他任务。完成了此教程后，您将能够应用这些概念和新获得的知识，来使用 JAX-WS 技术为应用程序开发 Web 服务。
JAX-WS 简介
为何使用 JAX-WS？
JAX-WS 是用于简化使用 Java 构造 Web 服务和 Web 服务客户机的工作的技术。该技术提供了完整的 Web 服务堆栈，可减少开发和部署 Web 服务的任务。JAX-WS 支持 WS-I Basic Profile 1.1，后者可确保使用 JAX-WS 堆栈开发的 Web 服务能够供采用 WS-I Basic Profile 标准使用任意语言开发的任意客户机使用。JAX-WS [...]
Categorized in: Java, SOA · Tagged with: Java, JAX-WS, Webservice
JAX-WS 开发 web service
JAX-WS 代表 Java API for XML Web Services. JAX-WS 技术用于创建 web services 和 clients, 彼此之间使用 XML 通信. JAX-WS 允许开发者编写 message-oriented 和 RPC-oriented web services.
通过使用 JAX-WS, clients and web services 具有一个很大的优势: Java 编程语言的平台中立性. 另外, JAX-WS 是不受限制的: 一个 JAX-WS client 能够访问一个非运行于 Java 平台的 web service, 反之亦然. 这种灵活性是可能的, 因为 JAX-WS 使用 World Wide Web Consortium (W3C) 定义的技术: HTTP, [...]
Categorized in: Java, SOA · Tagged with: Java, Webservice
UDDI 规范 v3.0.2 – UDDI Programmers APIs 之 Custody and Ownership Transfer API Set
本节定义 UDDI Custody and Ownership Transfer API Set. 通过创建一个实体, 一个发布者可以拥有该实体的所有权, 称他为这个实体的所有者. 一个保管节点必须通过授权机制维护一个实体和它的发布者的所有权关系. 多节点注册中心的每个节点必须保证集成了实体保管功能. 同样, 一个节点务必不可允许改变一个实体, 除非这个节点已经保管了这个实体.
Custody and Ownership Transfer API Set 使得一个注册中心的任意节点能够相互间从一个节点向另一个节点转移一个或多个 businessEntity or tModel 的保管关系, 也允许从一个发布者向另一个发布者转移这些数据的所有权. 一个 businessEntity 所包含的实体例如它的 businessService, bindingTemplate, 和 publisherAssertion 结构作为这个 businessEntity 保管关系转移的一部分进行转移.
从保管转移的视角来说, 参与这种转移的发布者总是不同的人, 尽管可能具有这种情况: 这些发布者都是同一个人. 这两个节点可能是不同的节点, 也可能是相同的节点; 两者发布者间的节点内(intra-node)转移简单退化为节点保管关系没有变化这种情况. 因而, 在节点内(规范上为inter-node, 注:这里应该是规范笔误)转移的情况下, 暗含的是所有权转移. 在节点内(intra-node)转移时, 这种转移使得两个发布者间进行所有权转移.
例如, 一个 UDDI 注册中心, UDDI-1, 可能允许每个节点(由节点1A, 1B [...]
Categorized in: SOA · Tagged with: SOAP, UDDI, Webservice, WSDL
(
(4.00 out of 5)
