背景
一流的新英格兰大学已通过一项战略性的多年基础设施现代化项目，以替换过时的系统，并在最大程度地利用所有IT投资回报的同时，提高IT能力。 该项目涉及升级硬件，购买新软件以及培训开发和运营团队。 现代化策略的核心是面向服务的体系结构（SOA）的实现。
SOA是一种体系结构的开发方法，它强调用于设计分布式应用程序而不是特定技术的总体平台。 SOA的主体是直接定义到系统或业务流程的软件服务的定义和实现，而不论其位置或所有权如何，这些服务都包括接口以及在运行时对其进行管理的策略。 SOA的优势包括交互系统和平台之间的松耦合，基于行业标准的无处不在的集成机制，支持按需创建复合服务以及在提高运营效率的同时利用现有资产的能力。
图1面向服务的体系结构
从传统的应用程序开发和部署到基于服务的方法的过渡非常重要，并且不可能在一夜之间付诸实践。 大学的IT部门与合作伙伴Collaborative Consulting合作，概述了逐步采用SOA的路线图。 增量方法的优势之一是可立即获得投资回报，并且能够选择转换顺序以最好地满足大学的短期和长期目标。 本文的其余部分描述了一个为期六个月的项目，该项目通过使用1060 Research的NetKernel实现面向资源的企业服务总线（ESB）来启动SOA采用过程。
问题域
高等教育机构不断受到来自学生，教职员工和校友的压力，他们需要提供他们一生所习惯的在线服务，包括通过直观界面和简化的自动化流程实时24/7全天候访问信息。 同时，来自管理层，指导委员会和董事会的压力越来越大。 因此，在投资于新功能时，高等教育机构的IT部门（例如大学的IT部门）必须精明而务实。
大学的IT部门支持各种应用程序，包括诸如PeopleSoft之类的商业现货（COTS）产品，基于客户信息控制系统（CICS）构建的大型机遗留应用程序以及使用Oracle应用服务器门户构建的现代J2EE Web应用程序。 此外，许多应用程序都与第三方应用程序服务提供商（ASP）进行交互，并向数据仓库（DW）提供历史信息。 所有这些都必须与新的SOA方法集成和协调。
该大学历来使用IBM MQ和FTP集成了业务系统。 这种传统方法导致了许多点对点（P2P）集成。 这些P2P集成的维护成本很高，并且导致消费者和提供商之间的紧密耦合。 但是，现有环境已经在使用轻量级消息交换状态转移（MEST）方法，该方法可用于进一步创新。 企业服务总线（ESB）是消息总线体系结构的子类型，它提供了更分离的环境，并且尽管其具有较高的前期部署成本，但已确定ESB的价值在同时扩展系统的成本保持线性和可预测1 。
大学的IT部门只有一小撮敬业的架构师和软件工程师，其中许多人在任职期间已开发了高等教育领域的专业知识。 由于小组很小，因此每个成员经常担当多个角色，包括支持和管理。 因此，IT部门需要一种解决方案，该解决方案可以完成以下任务：
- 通过利用可重用服务和复合应用程序来满足不断增长的消费者需求
- 减少或消除P2P集成
- 利用现有资产和技能提高运营效率
解
1.概述
可以使用许多不同的模式和技术来实现面向服务的体系结构。 常规方法使用WS- *规范中概述的模式，并且可以从广泛的技术产品中进行选择，这些产品从诸如Apache ServiceMix之类的开源解决方案到诸如Cape Clear和Sonic Software之类的商业套件。 不幸的是，WS- *规范处于不断变化的状态，可能使试图消化1300页以上详细信息的开发人员不知所措。 例如，如果遵守所有规范，那么将需要执行以下步骤/任务来实现SOAP服务：
- 使用业务流程建模表示法（BPMN）对流程进行建模。
- 使用WSDL定义服务接口，并将服务注册到通用描述，发现和集成（UDDI）存储库。
- 使用BPMN生成业务流程执行语言（BPEL）脚本，该脚本从服务注册表访问服务。
- 使用WS-Policy定义管理对服务的访问的策略。
对市场上的商业ESB套件进行了评估，并且由于IT小组相对较小，因此决定寻求一种解决方案，该解决方案将导致低摩擦的系统，该系统可以促进一小部分IT资源可以促进的创新类型承担并且不会强迫该组织成为依赖单个供应商的集中服务所有权模型。 大学的领域非常多变，包括流程更改，应用程序更改和集成更改。 因此，所需要的是反映大学真正本质的整体架构和策略。
由于消息请求已经建立为整个大学的中央传输机制，因此采用了RESTful或面向资源的方法来实现SOA。 REST基于一整套广为接受的标准，例如HTTP和XML，并且所需的开发步骤，工具箱和执行引擎要少得多。 RESTful SOA方法的三个主要优点包括更低的进入成本，更快的上市时间和灵活的体系结构。 面向资源的方法超越了RESTful方法，并提供了更深入，更可扩展且独立于传输的基础。 REST设计模式提倡使用HTTP，而面向资源的体系结构则支持连接到HTTP的服务以及诸如JMS或SMTP的传输。
尽管诸如Codehaus Mule之类的几种ESB实现都支持REST，但只有1060 NetKernel是在面向资源的计算平台2 （因此称为“ ROC”）上构建的。 面向资源的计算的核心是将信息（资源）的逻辑请求与传递请求的物理机制（代码）分开。 与传统方法相比，使用ROC构建的服务已被证明是小型，简单，灵活的，并且所需的代码更少。 这使其成为构建技术平台的理想技术。
2.技术平台
NetKernel是面向资源的中间件，提供核心的企业服务总线（ESB）功能，寻址，路由和数据转换，并且可以充当服务注册表编排引擎。 NetKernel是一项功能丰富的产品，还提供了XML转换，缓存管理和多线程处理的高级功能，以及包括HTTP和JMS在内的多种传输协议以及使之能够配置常规Web服务的SOAP引擎。 NetKernel是异构企业集成的坚实基础。
从概念上讲，NetKernel提供对由通用资源标识符（URI）地址标识的资源的访问。 所有URI地址都在逻辑地址空间内进行管理。 基于REST的微内核处理所有对资源的请求，从地址空间解析URI并返回该资源的表示形式。 还可以向微内核发出请求以创建新资源或更新或删除现有资源。
在物理上，NetKernel系统由模块组成，这些模块通过URI地址公开公共服务接口和资源。 与Java EAR相似，模块包含源代码和资源配置。 模块可以在逻辑上将另一个模块的公开服务和资源导入，将它们合并到地址空间中。 由于导入是指模块的逻辑名并可以指定版本号，因此可以在实时系统中同时运行和更新多个版本。 服务请求通过传输注入NetKernel，传输是驻留在系统边缘的事件检测器。 服务使用者可以通过任何受支持的传输（例如HTTP或JMS）发送请求。
图2技术平台
HTTP是无状态请求-响应应用程序协议。 请求消息结构由命令，标头和主体组成。 响应消息由状态，标头和正文组成。 客户端和服务器使用传输控制协议（TCP）套接字交换这些消息。 可以使用安全套接字层（SSL）协议在传输层保护客户端-服务器交互，而可以使用加密和数字签名来保护消息本身。 最后，可以使用HTTP基本认证或HTTP摘要认证模式3来认证客户端。
Java消息服务（JMS）API提供了用于实现异步服务的平台。 但是，API需要提供程序，在这种情况下为IBM WebSphere MQ。 IBM MQ是面向消息的中间件（MOM），并在应用程序之间提供基于队列的通信通道。 使用点对点或集线器和分支拓扑来实现通道。 除了传输消息，MQ还可以处理工作流，流程自动化，数据转换，监视和管理。
3.面向资源的服务
面向资源的服务提供对资源的与传输无关的无状态访问。 资源是信息的抽象。 例如，学生的注册是一种抽象，可以具有代表性形式，例如网页，XML文档或PDF文件。 服务使用资源标识符或地址公开每个资源表示。 资源标识符实际上是相对的通用资源指示符（URI）。 URI由两部分组成，方案（例如HTTP和FTP）和地址。 URI的第二部分是相对的。 地址/ domain / account / 45322是相对的，直到将其与诸如http，http：// domain / account45322之类的方案关联为止。
图3面向资源的服务概念模型
该服务定义了一组可在资源上调用的操作Create，Read，Update和Delete 。 另外，某些动作可能会触发规则或业务逻辑。 当请求资源时，将返回该抽象资源的物理不可变表示形式。 可以根据业务逻辑（例如消费者的类型）返回不同类型的表示形式。 例如，大多数后端进程需要XML文档，而前端进程可能需要JSON对象。 该服务还可以接收创建新资源或更新现有资源的表示。 最后，服务可以接收删除资源的请求。
图4面向资源的服务交互模型
传输驻留在系统的边缘，并且在检测到事件时会发出相应的内部根请求。 例如，HTTP传输侦听消费者对统一资源定位符（URL）的请求，并指定访问方法（例如GET，PUT，POST和DELETE）。 URL转换为内部相对URI，访问方法转换为操作。 在通过JMS进行请求的情况下，URI和操作作为消息头参数传递。 此外，如果应返回资源表示形式，则在标头中指定返回队列参数。
在RESTful系统中，对资源的访问是无状态的，这意味着每个请求都必须具有一种将上下文作为元信息传递的方式。 通常，传输定义了一个消息结构，该消息结构包括头和主体。 标头用于传递元信息，而正文用于传递资源表示。 例如，如果面向资源的服务通过HTTP公开，则可以在标头中传递身份验证信息，并且如果服务通过JMS公开，则可以将相同的信息作为加密的标头参数传递。
面向资源的服务使用Maven 4构建，并打包为NetKernel模块。 Maven是用于在“项目”的上下文中构建和管理软件的工具。 Maven项目由项目对象模型（POM）XML定义。 POM定义了软件的依赖性，构建过程和部署结构（例如JAR，WAR，EAR）。 此外，Maven项目可用于生成项目网站和部署软件。 在这种情况下，Maven将服务打包在NetKernel Module中，并将有关这些服务的信息发布到注册表。
图5面向资源的服务开发
4.面向资源的企业服务总线（ESB）
使用NetKernel实现了面向资源的企业服务总线（ESB）。 NetKernel的核心是RESTful或面向资源的微内核，负责解析对物理代码端点的逻辑URI请求并在可用的CPU内核上调度该请求。 虽然在应用程序结构中定义了逻辑地址到物理代码的映射，但是逻辑地址到物理代码的实际绑定仅在请求期间才发生，然后被丢弃。
由于对微内核的每个请求都是重新绑定的，因此系统管理员可以在系统运行时自由更改逻辑地址与物理代码之间的关联，从而启用诸如实时实时代码更新之类的功能。 实际上，性能不会因这种间接和绑定而降低，反而会提高，因为URI地址充当NetKernel内部缓存的键。 如果重新请求任何资源并且依赖项没有更改，则将返回缓存的表示，而不是重新计算。
使用面向资源的微内核具有几个关键优势。 首先，服务交互处于逻辑而非物理级别。 这导致交互耦合松散，从而在更改物理实现时减少了对消费者和提供者的影响。 其次，请求的结果被缓存，从而降低了服务组合和编排的总成本。 例如，如果一组协调服务依赖于一个公共服务，则很少执行该公共服务的基础物理代码。 最后，对微内核的所有内部请求都是异步的，从而随着更多的CPU被添加到主机服务器中，处理可以线性扩展。
ESB主要负责服务供应和安全性。 服务供应涉及通过诸如HTTP和JMS的传输向消费者提供面向资源的服务。 传输将外部URI和访问方法映射到内部面向资源的服务和操作。 无论采用哪种传输方式，请求的主体（例如XML Document或JSON对象）都作为名为“ param”的参数传递。 因此，面向资源的服务与特定于传输的逻辑的细节脱钩，实际上，可以在不影响现有代码的情况下随时添加其他协议。
图6面向资源的服务供应
面向资源的服务又委托给NetKernel提供的一组自定义基础结构服务和核心服务。 NetKernel提供了广泛的核心服务集。 例如，存在用于XML和SOAP处理，CRON作业计划以及SMTP交互的核心服务。 核心服务大大减少了实现面向资源的服务所需编写的代码量。 自定义基础结构服务用于公开可以在高等教育领域中利用的功能。
对ESB的每个请求都首先经过身份验证，然后被授权和（在某些情况下）审核。 传输程序根据用户名密码组合对传入的请求进行身份验证，然后将授权和审核委派给安全服务。 授权涉及验证所标识的使用者是否具有适当的特权。 特权由相对URI和操作组成。 作为示例，消费者可以被授权阅读但不能更新或删除由相对URI / domain / student / identifier / profile标识的资源学生档案。 未经授权的请求将自动进行审核，并且存在基于所标识的使用者或特权进行审核的选项。 帐户，特权和审核信息存储在嵌入式Hypersonic数据库中。
图7面向资源的服务安全性
摘要
除了运行时服务管理解决方案（例如Actional或ManagedMethods）之外，用于实现ESB的中间件对于任何成功的SOA计划都是必不可少的。 没有ESB，组织将使用Web服务来增加昂贵的点对点（P2P）交互的数量。 尽管在ESB的组成和用途方面存在广泛的分歧，但大多数人可以在一组核心功能（包括服务寻址，消息转换和消息路由）上达成一致。 使用NetKernel中间件实现的ESB提供了这些功能以及更高级的功能，例如服务注册和编排。
NetKernel产品使大学能够实施面向资源的ESB。 面向资源的ESB本质上是一个基于开放标准的企业集成框架。 该框架使企业能够减少或消除昂贵的点对点交互，并缩短引入新功能的上市时间。 此外，与基于WS- *标准的传统企业集成框架相比，此框架的入门成本更低。 此外，由于NetKernel和ROC提供了基于每个服务的集成，因此大学可以将集成功能推向网络的边缘（作为URI），从而实现更好的服务管理和可伸缩性。 简而言之，该框架为组织提供了前所未有的企业架构敏捷性。
在不到六个月的时间里，由三个软件架构师组成的团队使用NetKernel中间件实现了面向资源的ESB和一些初始的面向资源的服务。 ESB的成功实施启动了大学对SOA的逐步采用。 以资源为导向的方法使团队可以利用现有资产和技术技能。 展望未来，大学的IT部门现在能够通过利用可重复使用的服务和组合应用程序来满足不断增长的消费者需求，同时减少或消除P2P集成。
780
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
