Defonds 的专栏

与民间信仰不同的是，很多信息技术神话在现实中有一定的基础 - 尽管它们并非完全正确。以云计算为例。很难再想出来另一种技术能如此充满神话色彩了。尽管如此，最顽固的几个神话在现实生活中还是有一定根据的：1. 云计算不安全过去，企业在他们的应用周围部署外围安全工具 (防火墙)。他们也因此自以为高枕无忧了。公有云 SaaS、IaaS 和 PaaS 则需要一些保护安全的新方案。云安全确实需要大量应有的调查。

乍看之下 SOA 的安全似乎没有什么特别之处。毕竟，它 (和其它架构场景一样) 涉及相同的基本主题，如认证、授权、身份、信任、机密性、完整性以及策略管理。尽管如此，SOA 架构其实更加难以进行安全把控 - 足以让安全分析师累成狗。1. 安全不能够违反 SOA 设计原则SOA 服务是可以服用的、松耦合的、可以发现以及可协同的。安全不能够妨碍 SOA 的 9 大设计原则。2. 遗留的安全模型SOA 常

SOA 架构设计原则曾经被深受误解。SOA 设计原则实际上只是一系列经久考验的针对服务设计的最佳实践。《SOA 指南》系列搜集到的关于 SOA 的资源包括概述、设计原则以及安全最佳实践。范围工具基础SOA 图解一张图来帮你理解 SOA。SOA 市场打造你自己的企业级 SOA 市场。SOA 解惑一些误导的澄清。现实世界里的 SOASOA 理想愿景之外的一面。大 SOA世界上最大的 SOA。设计最佳实

SOA 曾经一度是技术领域中最难以理解的一个概念。SOA 似乎让很多人感到困惑 - 一般来讲这是由于人们认为它拥有几乎神奇的力量。事实上 SOA 是一个很简单的概念：SOA 由诸如 C++ 和 Java 之类的面向对象语言里的设计原则演化而来。SOA 将这些个设计原则使用于提升到企业级应用。它为企业级应用建立了一个可重用的服务库，库里的服务彼此之间是松耦合的。SOA 已经成为企业级应用架构师们最喜

SOA 解惑SOA 不是一种技术，它是一种设计方法。最近一段时间我碰到了很多关于 SOA 的具有误导性的文章。尤其是，有些人混淆了 SOA 和诸如 BPM、ESB 以及复合事件处理 (CEP) 之类的技术之间的关系。这些困惑其实是没有必要的，因为 SOA 和这些技术之间的关系非常简单。SOA 和 ESB9 个 SOA 设计原则之一就是服务之间要松耦合。ESB 是实现 SOA 服务之间解耦的最常见的

Web Service 安全 (WSS) 是对 SOAP 协议的一个安全加固。WSS 允许对 SOAP 消息进行签名和加密。它还允许给 SOAP 消息附加安全令牌。可以扩展的体系结构WSS 拥有一个可以扩展的体系结构，能够支持可插拔的签名格式以及加密算法。WSS 还支持各种安全令牌，包括 X.509 证书、Kerberos 认证、用户名/密码、SAML 安全标记以及自定义令牌。WSS 并不保证安全

每个人都知道 SOA 的安全将会是一个挑战。但是为什么呢？经常会使 SOA 安全复杂化的 9 个要素：遗留应用的安全将服务和应用松耦合跨组织界限操作的服务动态的信任关系组合服务形形色色的新老技术混杂需要不断地遵循越来越多的标准列表解决方案的灵活性和可以定制性的要求1. 遗留应用的安全封装了遗留应用的 SOA 服务必须要考虑到遗留应用的安全模型。很多遗留应用有着硬编码的、专有的安全模型。2. 将服务

SOA 设计原则可以追溯到 2004 年。从那以后，SOA 是典型的以服务编制 (orchestrated，译者注：orchestrated 在字面上翻译为 "管弦乐编曲"，而管弦乐演奏是由一名乐队的指挥来统一的进行指挥和控制，是为 "编制") 为核心。也就是说，SOA 适用于驱动预定义的业务处理。这种老的服务模型，通常被称为 SOA 1.0，忽视了静态业务模型以外的事件。因为一切都需要进行提前建

SOA 安全实现起来可以是非常容易的 - 前提是你选择的方式要正确。松耦合的、可发现的、可共用的安全工具一个简单的工具：WS-Security 对 web services 进行了加强，为 SOA 安全提供了你需要的一切：访问控制、加密、信任、传输安全以及不可抵赖。消息示例WS-Security 将时间戳、授权、凭证、令牌、签名以及加密信息添加到 SOAP 消息头里面。SOAP 消息的 body

SOA 其实针对业务和集成服务的一系列设计原则。这些 SOA 设计原则保证了服务的高灵活性和高可复用性。SOA 是一个广泛部署的、成熟的架构方法。也正是由于它如此流行，也产生了一些常见的谬论：1. SOA vs ESB关于 SOA 和 ESB 有几种常见的误解：SOA 和 ESB 是互相竞争的两种技术SOA 和 ESB 是一个意思ESB 是 SOA 所必需的事实上 SOA 和 ESB 是互补的。E

SOA 具备能够帮你打破技术孤岛、简化技术栈、缩减成本并提高质量等巨大潜力。尽管如此，经常会有一些政治障碍影响 SOA 策略的实现：技术孤岛对彼此的行为几乎没有可见性部门之间相互竞争，几乎没有去进行服务共享的动力预算问题 - 谁来为共享服务买单？企业级架构团队曾经使用各种办法来打破这些孤岛并进行服务复用：为通用服务创建相关负责部门行政强制：强制大家去共享自己的服务合作：鼓励大家去共享自己的服务但是

SOA 服务具备清除边界和技术差异的能力。这给我们带来了一个灵活和可定制的架构，但是同时也带来了大量的安全挑战。以下是 SOA 安全的相关的一些方面：SOA 的安全不仅仅是一个技术问题 - 对于任意 SOA 安全解决方案来讲都会面临业务和技术两方面的问题。SOA 安全不仅要考虑到服务层面，而且还要兼顾组织和基础设施层面。原文链接：Soa Security From 50000 Feet，发布日期：

SOA 和 mashup - 两种驱动更快/更廉价服务开发的架构模式。它们都被用于构建可复用的服务 - 但是它们之间有哪些区别呢？SOA 其实是一套由 9 大设计原则组成用于构建高可复用服务的设计方法。如果我们根据这 9 大设计原则来对 mashup 进行评估的话，结果会怎样呢？√ 服务协同mashup 常常是基于诸如 XML、HTTP、REST、Web Services、RSS 以及 Atom

SOA 行为失败的原因有很多，但是最重要的一个原因是 - 缺乏服务复用。很难对 (上述案例的) 未来做出预测。如果你今天没有对自己的服务进行 SOA 化治理的需求，那么这种需求也就永远不会提上日程。按理来说对服务进行 SOA 化设计才应该是优先级高的需求。原文链接：This Is What Soa Failure Looks Like，发布日期：2011 年 2 月 18 日。作者简介John S

这 10 个 SOA 设计模式是如此之重要，其应用是如此之广泛，以至于它们都有些显而易见了。1. 服务无关服务无关实现对多种业务通用的逻辑。将服务无关的逻辑分离成离散的服务以方便服务的重用和整合。原则：复用，服务整合2. 服务无关的声明服务无关的服务应该显式声明它们是服务无关的。这样对于后续的设计者和架构者来说能够清楚哪些服务是被设计用来进行重复使用的。原则：复用，服务整合3. 服务无关的事务服务

面向服务的架构 (SOA) 设计要尽可能地简单。在设计一个 SOA 服务的时候要谨记这 9 大设计原则：1. 标准服务契约服务要遵循一个服务描述。2. 松耦合服务之间的依赖最小化。3. 服务抽象服务将自己的业务逻辑封装起来，对外部世界是隐藏的。4. 服务复用业务逻辑切割成多个服务以实现复用的最大化。5. 服务自治服务应该有对它们封装的逻辑的控制权。6. 服务无状态理想情况下，服务应该是没有状态的。

在现实世界中，SOA 常常是失败的。确保 SOA 成功的最好的实践是熟悉 SOA 的设计模式和成功案例。一个成功案例SOA 是解决数据管理问题的一个强大工具。在你的企业里是否存在数据不一致的问题？将存在这种问题的数据实体的 CRUD (Create、Read、Update 和 Delete) 都封装在同一个服务中。这是对你的数据进行集中控制和方便访问的一个简单办法。我们这个成功案例就是这样 - A

1.背景1.1.Linux 服务器情况# cat /etc/issueRed Hat Enterprise Linux Server release 6.1 (Santiago)Kernel \r on an \m1.2.Win7 客户端情况Win7 旗舰版 sp1，4G内存，双核 CPU 主频 3.0G。1.3.Oracle 服务器情况10.2.0，部署在上述 RedHat 上。2.AWR 报告

关于企业级架构的定义，在主流企业级架构师当中至今仍存在争议。企业级架构是一个新兴领域，至今还在经历着很大变化。企业级架构的定义一个合理的定义是：企业级架构是一个组织的信息技术的规划和设计的过程和产物。~ Simplicable详细定义以下对企业级架构进行了详细定义：企业级架构是一个组织技术进行设计的过程，包括：1. 业务和技术的一个蓝图2. 业务和 IT 策略3. 该组织所期望的 IT 路

灯光、音乐、白色礼服、领带、高雅的房间。这是什么？对于人类来讲回答这种问题很简单 - 这是因为我们人类的大脑能够很好地对事件的识别和解释进行适配。但是在技术的世界里，复杂事件处理 (Complex Event Processing，CEP) 仍然是一个具备挑战的新兴领域。事件是什么？事件就是改变。被称为事件监视器的工具被用来检测时间、状态、位置、水平等方面的改变。先设置一个临界值 - 突破这些临界

RPC vs SOAP无论在商业、政治、人际关系，甚至在拯救生命的过程中，通信在任何领域都是至关重要的。通信被证明最重要的另一个领域是计算机网络。如果没有合适的通信手段，一个典型的服务请求者和服务提供者就无法达成。在互联网领域中，有一个叫做 Web Service 的事物。它主要适用于网络中两台电子设备之间的简单通信。截至目前来讲 Web Service 中最常用的就是 RPC (Remote P

《整合 spring 4(包括mvc、context、orm) + mybatis 3 示例》一文简要介绍了最新版本的 Spring MVC、IOC、MyBatis ORM 三者的整合以及声明式事务处理。现在我们需要把缓存也整合进来，缓存我们选用的是 Redis，本文将在该文示例基础上介绍 Redis 缓存 + Spring 的集成。关于 Redis 服务器的搭建请参考博客《Redhat5.8 环

大道至简；至繁归于至简。(以简为美，深入浅出，化繁为简。)~列奥纳多·达·芬奇云计算是一个简单而又直观的概念。然而，它被如此多的炒作包围着，以至于专家们都要想方设法让它听起来很复杂。这些直截了当的定义可以帮我们从天花乱坠的炒作中把它们给理顺清楚：云计算云计算通过网络 (通常是因特网) 来提供服务。而这些服务的具体实现细节则隐藏于 "云" 的背后。这是一个很有意义的抽象，因为一个云的用户并不需要去了

我们生产的渠道对接系统出现大量推送运营商信息失败的现象。问题最终定位到 mongo 身上：.00:03:05.425 [http-nio-9100-exec-53] ERROR c.d.r.s.i.CarrierOpRepServiceImpl - 存储运营商数据失败，Timeout waiting for a pooled item after 120000 MILLISECONDS; ne...

前边系列的文章中我们定义了一系列的 EA 原则 - 我们该如何利用它们呢？要从 EA 原则中汲取相关价值需要遵循以下四个步骤：1. 接受度在企业范围内缺乏接受度的原则是没有意义的。你必须说服掌权者。2. 推销将这些原则推销给其他人，尤其是 Cx0 们。这里的目标是让公司的高层领导能够在彼此之间的讨论中涉及到这些原则。3. IT 治理如果你有一个架构项目的评审处理 (作为 IT 治理的一个部分) -

企业级架构具有一个崇高的使命：使 IT 与业务保持一致 (译者注：参见维基百科《Business-IT alignment》)。大多数企业中，EA 团队并不具备实现这一目标的权力或影响力。那么哪里才是企业的 EA 所适合的呢？这是一个 Cx0 和 EA 社区内一直有争议的问题。IT 总监很普遍的是 EA 团队向 IT 总监 / 总经理汇报。优点：鼓励 EA 团队去依赖和 IT 及业务团队的合作。缺

现今 IT 开发领域，架构师的职位如雨后春笋般涌现出来，而且企业架构师的需求持续上涨。是一种新的时尚还是只是一个新的噱头？是 IT 头衔的通货膨胀还是一时的昙花一现？IT 市场上对架构师的需求还会越来越多吗？本文将为你揭开这些谜底。

大多数商业公司在上个世纪 60 和 70 年代开始投资于信息技术。到了 80 年代中期 - 这些公司里的很多已经有复杂的系统和集成了。这一复杂性驱动了企业级架构的需求。John Zachman 1987 年的《信息系统架构框架》文章通常被认为是关于企业级架构讨论的首次公布。该文起始语句如下：信息系统架构的主题受到越来越多的关注。很显然从 1987 年起企业级架构就是一个热门话题了。原文链接：How

想象一下你的铁杆 IT 极客与公司高管谈话的情景。他们会谈论些什么呢？这听起来像一个呆伯特漫画...我知道...但它却突出了一个大问题 - 如何跨越业务和 IT 之间的鸿沟。企业级架构是跨越这一鸿沟的一个尝试。(尝试)去高效地将业务战略、目标以及优先事项转化为 IT。不止于此，企业级架构力求从 IT 支出中将业务价值最大化。企业级架构是一个相当复杂的话题。对于任何复杂的话题，最好的解释方式就是图片

战略决定结构是一个业务原则，它规定组织的办事处、部门、团队、过程和技术是为了实现公司的战略而设计的。这个似乎理所当然，但是实际上相反情况屡有发生。例如，技术部门可能要为技术实现制定战略，仅仅是因为这(技术)是技术部门所做的事情。同样，在产品层面，如果一个公司有一个制造牙刷的部门，那么这个部门将倾向于去制定更好或更有利可图的牙刷的战略，而不管这是否符合公司整体战略。战略决定结构的原则通常是通过自上而

你会如何向你奶奶解释企业级架构？为什么我会问这个问题？几年前，我参与进为一个新的海外研发中心雇佣 200 多名开发者。这意味着在为期一年的时间内进行 300 - 400 次技术面试。我很快意识到要从这些粘贴-复制开发者(译者注：拷贝复制式开发见维基百科的解释：Copy and paste programming)中区分出真正的人才是多么的困难(通过一个 30 分钟的电话面试)。原因在于：沟通技能。

远程过程调用 (RPC) 是一种协议，通过它一个应用可以在无需了解网络细节的情况下去请求位于网络中另一台电脑上的应用所提供的服务。过程调用有时也称为方法调用或者子程序调用。RPC 基于 CS (client-server) 模型。请求程序是客户端，提供服务的程序是服务端。就像一个一般的本地过程调用那样，RPC 也是一个同步操作，要求请求程序一直阻塞直到收到远程过程的返回结果。尽管如此，通过使用轻量

CQ 的构建基于 OSGi 容器，所以自定义的代码和功能能够通过 OSGi 提供的 feature 添加到 CQ。要将自定义的代码部署到 OSGi 容器，开发者必须将他们的代码作为一个 bundle 进行打包。一个 OSGi bundle 只是一个添加了额外元数据的 jar 文件。本文将详细介绍如何使用 Apache Maven 来创建一个 OSGi bundle，以及如何将该 bundle 部署

企业级架构 (Enterprise architecture，EA) 是对包括业务和技术在内的组织结构管理的实践。这是一个远远超出大多数企业级架构团队预算、能力和影响力的巨大任务。因此，EA 团队通常开发一个价值主张，但这只是企业架构理论的一小部分。下面是扩大企业架构价值的几种办法。小型或新的 EA 团队将会很好地从这个列表中交付一个单一的价值主张。信息技术治理将 IT 治理过程的策划和支持融进企

一个当前状态架构蓝图是你们企业的高层体系结构。在大多数企业中，由企业架构团队对蓝图负责。每个业务单元和共享的技术服务都要有蓝图。由业务架构师和解决方案架构师负责创建并维护它们。蓝图对业务和 IT 效率至关重要。当前状态蓝图涉猎以下信息：当前状态蓝图在概念、逻辑和物理层次上捕捉业务、数据和实现架构。原文链接：What is a Current State Enterprise Architectur

架构是事物结构的一个规划。设计是事物创建的一个规划。弄明白架构和设计之间有什么区别的一个简单办法是去将一个办公大楼的架构与其内部设计进行对比。架构提供的是一系列的结构，比如房间、楼梯的样例，诸如水、暖、通风和空调之类的基础服务。内部设计提供的是内部材料、装饰风格、地板、家具以及咖啡机和厨房之类的附加服务。架构 vs 设计设计是事物构建的一个方案。从根本上来讲，架构是一种设计，但其只涉及到结构。定义

CQ 的构建基于 Apache Sling，而 Apache Sling 这是构建于一个 OSGi 容器之上 (确切来讲是 Apache Felix)。OSGi 容器的行为 (就类文件的加载方式以及在 classpath 中可用) 和大多数 Java 开发者所习惯那样略有不同。要确保类能够在 OSGi 容器中可用，需要使用一个特定的方式对它们进行打 jar 包，包括向标准的 MANIFEST.MF

RPC vs Web Service使用 SOAP 协议创建 Web Service 需要使用两个备选方案：文档型 SOAP 协议或者 RPC SOAP 消息协议。RPC 指的是远程过程调用，它是一种协议，指定的程序通过它可以去请求指定的位于另一台远程主机上的另一个应用中的服务。在使用 RPC 的时候，无需去了解该应用的网络细节。一个指定的过程调用指的是作为子程序调用甚至函数调用。在使用 RPC

本文是《Linux 服务器运行健康状况监控利器 Spotlight on Unix 的安装与使用》的姊妹篇，Linux 的 Spotlight 监控请参考该篇博客。1.本文背景Oracle 版本：10g Enterprise Edition Release 10.2.0.5.0 - 64bit，部署于 Red Hat 服务器Windows：Win7 旗舰版 sp12.Spotlight on Or

本文是《JVM 性能调优实战之：一次系统性能瓶颈的寻找过程》 的后续篇，该篇介绍了如何使用 JDK 自身提供的工具进行 JVM 调优将 TPS 由 2.5 提升到 20 (提升了 7 倍)，并准确定位系统瓶颈：我们应用里静态对象不是太多、有大量的业务线程在频繁创建一些生命周期很长的临时对象，代码里有问题。那么问题来了，如何在海量业务代码里边准确定位这些性能代码？本文将介绍如何使用阿里开源工具 TP...