摘要：软件开发里面的中间件和构件是什么？一、中间件 中间件是一类软件名，属 己上层的应用软件提供运行与开发的环境，帮助用户开发和集成应用软件。它不仅仅要实现互连，还要实现应用之间的互操作；最突出的特点是其网...

软件开发里面的中间件和构件是什么？

一、中间件 中间件是一类软件名，属 己上层的应用软件提供运行与开发的环境，帮助用户开发和集成应用软件。

它不仅仅要实现互连，还要实现应用之间的互操作；最突出的特点是其网络通信功能。

最流行的交易中间件为Tuxedo。

有两个关键特征，为上层的应用层服务；必须连接到操作系统的层面，并确保持运行工作状态。

中间件是一种应用于分布式系统的基础软件，位于应用与操作系统、数据库之间，主要用于解决分布式环境下数据传输、数据访问、应用调度、系统构建和系统集成、流程管理等问题，是分布式环境下支撑应用开发、运行和集成的平台。

中间件产品开发的核心思想是抽取分布式系统对于数据传输、信息系统构建与集成等问题的共性要求，封装共性问题的解决方法，对外提供简单统一的接口，从而减少开发人员面对上述共性问题时的难度和重复性工作量，提高系统的开发效率。

二、构件构件是面向软件体系架构的可复用软件模块。

构件（component）是可复用的软件组成成份，可被用来构造其他软件。

它可以是被封装的对象类、类树、一些功能软件工程中的构件模块、软件框架（framework）、软件构架（或体系结构Architectural）、文档、分析件、设计模式（Pattern）等。

1995年，Ian.oraham给出的构件定义如下：构件（Component）是指一个对象（接口规范、或二进制代码），它被用于复用，接口被明确定义[8]。

构件是作为一个逻辑紧密的程序代码包的形式出现的，有着良好的接口。

像Ada的Package、Smalltalk-80和C++的class和数据类型都可属于构件范畴。

但是，操作集合、过程、函数即使可以复用也不能成为一个构件。

开发者可以通过组装已有的构件来开发新的应用系统，从而达到软件复用的目的。

软件构件技术是软件复用的关键因素，也是软件复用技术研究的重点。

有谁知道什么是SOA参考架构？

SOA 参考架构 （Reference Architecture） 是一个框架，使各个项目都有一个遵从的依据，借以促进一致性、最佳实践典范，和标准化。

参考架构并不受限于目前的 IT 现况，而应该针对一个经过深思熟虑的愿景目标，可以说是 IT 指导未来所有的新开发工作，借以实现该目标的参考依据。

一般来说，2-3 年的规划，是一个比较合适的涵盖范围，既能提供足够的时间来达成面向服务的转型，而又不至于过于长远而虚幻。

因此，参考架构提供了一个沟通目标愿景的方 法，协助部门和角色各异的 IT 人员，逐渐朝向该目标会合。

什么是中间件

引言 软件架构是一门学科，开始于 20 世纪 70 年代。

面对不断增加的复杂性和开发复杂实时系统的压力，作为主流系统工程和软件开发的基本构造，软件架构应运而生。

与任何其他久经考验的学科一样，软件架构在诞生之初也面临许多挑战。

软件架构表示系统的结构和行为方面。

在早期为软件架构编写文档说明时，所使用的文本和图解表达常常不足或者不够精确。

所需的是某种一致并得到充分理解的伪（或元）语言，以便将对软件架构进行表示和编写文档说明的不同方式统一起来。

在学术研究的推动下，在用于开发有效软件架构文档说明的最佳实践和指导原则方面，工程和计算机科学领域已取得了长足的发展。

在本系列中，您将了解如何编写软件架构文档说明。

了解编写文档说明的不同方面：系统上下文、体系结构概述、功能体系结构、操作体系结构和体系结构决策。

在这第一篇文章中，了解软件架构是什么，以及为该学科的不同方面编写文档说明的重要性。

回页首软件架构不同的研究人员已解释了软件架构是什么，并且他们对有关如何最好地表示软件系统的体系结构具有不同的观点。

其中没有哪一种解释是错误的；每种解释都具有自己的价值。

Bass L 等人抓住了软件架构的本质： “程序或计算系统的软件架构是该系统的结构，包括软件组件、那些组件的外部可见的属性，以及那些组件之间的关系” 。

此定义重点关注由粗粒度的构造（软件组件）所构成的体系结构，可以将这些构造看作是体系结构的构建块。

每个软件组件或体系结构构建块具有某些外部可见的属性，这是它向其他体系结构构建块公开的属性。

软件组件的内部设计和实现细节不是系统的其他部分所关心的内容，系统的其他部分只是将某个特定组件视为一个黑盒。

该黑盒具有某些所公开的属性，其他软件组件可以使用这些属性来共同实现业务或 IT 目标。

软件架构在恰当的粒度级别标识体系结构构建块。

软件架构还标识那些构建块如何彼此相关，并进行文档记录。

与软件工程相关的体系结构涉及到将单个系统分解或划分为一组可迭代地、渐进地和独立地构造的部分。

各个部分彼此具有显式的关系。

当组合在一起时，各个部分就形成了系统、企业或应用程序的体系结构。

关于体系结构与设计之间的区别，存在一些混淆。

正如 Clements P 等人 所指出的，所有体系结构都是设计，但不是所有设计都是体系结构。

需要绑定以使系统满足其功能性和非功能性需求和目标的设计本质上是体系结构。

体系结构将体系结构构建块视为黑盒，而设计则处理体系结构构建块的配置、自定义和内部工作。

体系结构将软件组件与其外部属性绑定在一起。

设计通常要比体系结构松散得多，因为它允许以更多的方式遵守组件的外部属性。

设计还考虑用于实现组件内部细节的各种方法。

软件架构可以递归地使用。

请考虑一个属于某个系统的软件架构组成部分的软件组件 （C1）。

软件架构师将该组件及其应该公开的属性、功能和非功能特性及其与其他软件组件的关系交给系统设计人员。

设计人员在分析软件组件 C1 之后，决定将该组件分解为更细粒度的组件（C11、C12 和 C13），其中每个组件提供可重用的功能，这些功能将用于实现 C1 的要求属性。

设计人员详细设计了 C11、C12、C13 及其接口。

此时，对设计人员来说，C11、C12 和 C13 是体系结构构造（或组件）；其中每个构造具有显式定义的外部接口。

对设计人员来说，C11、C12 和 C13 是软件组件 C1 的体系结构，并且这些构造需要进一步的改进和设计，以处理它们的内部实现。

通过将大型、复杂的系统划分为小型的构成部分并集中于每个部分，可以递归地使用体系结构。

体系结构使用共同满足行为和质量目标的体系结构构建块将系统绑定在一起。

参与者必须能够理解体系结构。

因此必须为体系结构编写足够的文档说明，下一个部分将对此进行讨论。

回页首编写体系结构文档说明的重要性参与者：体系结构的下游设计和实现用户。

为体系结构的定义、维护和增强功能进行投资的人。

向参与者传达您正在构建的系统蓝图的关键是为系统体系结构编写文档说明。

软件架构通过不同的视图进行表示——功能、操作、决策等等。

没有任何单一视图能够表示整个体系结构。

并非所有视图都需要表示特定企业或问题领域的系统体系结构。

架构师将确定足以表示所需软件架构范畴的视图集。

通过编写不同视图的文档说明并捕获每个部分的开发，您可以向开发团队和业务及 IT 参与者传达有关该不断发展的系统的信息。

软件架构具有一组其预期要满足的业务和工程目标。

体系结构的文档说明可以向参与者传达这些目标将如何实现。

为体系结构的各个方面编写文档说明，有助于架构师弥补用白板描述解决方案（使用框线图方法）与以对下游设计和实现团队有意义的方式表示解决方案之间众所周知的差距。

体系结构的框线图留下了大量有待解释的空间。

需要揭示的细节通常隐藏并令人混淆地固守在那些框线背后。

文档说明还可以促进创建切合实际并且可以系统开发（例如遵循标准模板）的体系结构构件。

作为一门学科，软件架构是非常成熟的。

您可以利用最佳实践和指导...

什么是物联网的中间件,是软件系统吗？

看到目前各式各样RFID的应用，企业最想问的第一个问题是：“我要如何将我现有的系统与这些新的RFID Reader连接？”这个问题的本质是企业应用系统与硬件接口的问题。

因此，通透性是整个应用的关键，正确抓取数据、确保数据读取的可靠性、以及有效地将数据传送到后端系统都是必须考虑的问题。

传统应用程序物联天下与应用程序之间（Application to Application）数据通透是通过中间件架构解决，并发展出各种Application Server应用软件；同理，中间件的架构设计解决方案便成为RFID应用的一项极为重要的核心技术。

RFID中间件扮演RFID标签和应用程序之间的中介角色，从应用程序端使用中间件所提供一组通用的应用程序接口（API），即能连到RFID读写器，读取RFID标签数据。

这样一来，即使存储RFID标签情报的数据库软件或后端应用程序增加或改由其他软件取代，或者读写RFID读写器种类增加等情况发生时，应用端不需修改也能处理，省去多对多连接的维护复杂性问题。

RFID中间件是一种面向消息的中间件（Message-Oriented Middleware,MOM），信息（Information）是以消息（Message）的形式，从一个程序传送到另一个或多个程序。

信息可以以异步（Asynchronous）的方式传送，所以传送者不必等待回应。

面向消息的中间件包含的功能不仅是传递（Passing）信息，还必须包括解译数据、安全性、数据广播、错误恢复、定位网络资源、找出符合成本的路径、消息与要求的优先次序以及延伸的除错工具等服务。

RFID中间件可以从架构上分为两种： 以应用程序为中心（Application Centric）的设计概念是通过RFID Reader厂商提供的API，以HotCode方式直接编写特定Reader读取数据的Adapter，并传送至后端系统的应用程序或数据库，从而达成与后端系统或服务串接的目的。

以架构为中心（Infrastructure Centric）随着企业应用系统的复杂度增高，企业无法负荷以HotCode方式为每个应用程式编写Adapter，同时面对对象标准化等问题，企业可以考虑采用厂商所提供标准规格的RFID中间件。

这样一来，即使存储RFID标签情报的数据库软件改由其他软件代替，或读写RFID标签的RFID Reader种类增加等情况发生时，应用端不做修改也能应付。

RFID中间件的特征 一般来说，RFID中间件具有下列的特色： 独立于架构（Insulation Infrastructure） RFID中间件独立并介于RFID读写器与后物联网端应用程序之间，并且能够与多个RFID读写器以及多个后端应用程序连接，以减轻架构与维护的复杂性。

数据流（Data Flow） RFID的主要目的在于将实体对象转换为信息环境下的虚拟对象，因此数据处理是RFID最重要的功能。

RFID中间件具有数据的搜集、过滤、整合与传递等特性，以便将正确的对象信息传到企业后端的应用系统。

处理流（Process Flow）RFID中间件采用程序逻辑及存储再转送（Store-and-Forward）的功能来提供顺序的消息流，具有数据流设计与管理的能力。

标准（Standard） RFID为自动数据采样技术与辨识实体对象的应用。

EPCglobal目前正在研究为各种产品的全球惟一识别号码提出通用标准，即EPC（产品电子编码）。

EPC是在供应链系统中，以一串数字来识别一项特定的商品，通过无线射频辨识标签由RFID读写器读入后，传送到计算机或是应用系统中的过程称为对象命名服务（Object Name Service,ONS）。

对象命名服务系统会锁定计算机网络中的固定点抓取有关商品的消息。

EPC存放在RFID标签中，被RFID读写器读出后，即可提供追踪EPC所代表的物品名称及相关信息，并立即识别及分享供应链中的物品数据，有效率地提供信息透明度。

业务架构,功能架构,系统架构,技术架构,应用架构都是什么关系

就是指支持企业业务运营的一整套信息系统的架构，完整的IT架构应该包括：1、各业务应用系统，比如PDM、SCM、CRM等2、各管理应用系统，比如OA、ERP、HR等3、支持与运行上述各应用系统的中间件软件、数据库软件、操作系统等4、上述各软件系统运行的硬件设施，比如服务器、存储设备等5、支持上述系统被正常访问的各种网络设备、机房环境设施等6、保障上述软硬件系统安全运行的安全设施，包括各种软硬件级别的防火墙、防病毒、防攻击工具，安保措施、供电保障等7、保障上述所有设备与措施正常运转运营的一整套IT组织与IT管控体系

企业的IT 架构是什么意思

1. 企业的IT 架构就是指支持企业业务运营的一整套信息系统的架构，完整的IT架构应该包括：各业务应用系统，比如PDM、SCM、CRM等；各管理应用系统，比如OA、ERP、HR等；支持与运行上述各应用系统的中间件软件、数据库软件、操作系统等；上述各软件系统运行的硬件设施，比如服务器、存储设备等；支持上述系统被正常访问的各种网络设备、机房环境设施等；保障上述软硬件系统安全运行的安全设施，包括各种软硬件级别的防火墙、防病毒、攻击工具，安保措施、供电保障等；保障上述所有设备与措施正常运转运营的一整套IT组织与IT管控体系。

2. 企业架构是对真实世界企业的业务流程和IT设施的抽象描述，它是包括企业战略、组织、职能、业务流程、IT系统、数据、网络部署等的完整、一体化描述，企业架构反映了企业业务的状况，并体现了业务与IT的映射关系，能明确各类IT设施对业务的支撑关系。

3. 企业架构领域原则上的关注点是企业范围内的业务需求的识别、规范、及优先级划分，企业架构如同战略规划，可以帮助企业执行业务战略规划及IT战略规划。

在业务战略方面，定义企业愿景/使命、目标/目的/驱动力、组织架构、职能及角色；在IT战略方面，定义企业的业务架构、数据架构、应用架构、和技术架构。

SOA（面向服务的系统构架）技术是什么,谢谢！

面向服务的体系结构（service-oriented architecture,SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。

接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。

这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。

松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。

而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。

我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。

虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。

由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。

不同之处在于接口本身。

SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture,CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。

然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language,XML）为基础的。

通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language,WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language,IDL）可比了。

Web 服务并不是实现 SOA 的惟一方式。

前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。

但是为了建立体系结构模型，您所需要的并不只是服务描述。

您需要定义整个应用程序如何在服务之间执行其工作流。

您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。

因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。

例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。

因而，工作流还可以在 SOA 的设计中扮演重要的角色。

此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。

因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。

最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。

因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。