SOA在仓库管理系统中的研究与应用毕业论文

目  录

1．绪论 1
1.1研究背景 1
1.1.1业务需求不断变化 1
1.1.2 SOA架构的提出 1
1.1.3国内外研究现状 1
1.2本文的主要研究内容和内容组织 2
2．面向服务体系结构 4
2.1软件体系结构概述 4
2.2软件体系结构发展演变过程 4
2.2.1传统的软件体系结构 4
2.2.2基于组件的软件体系结构 5
2.2.3面向服务的软件体系结构 5
2.3 SOA架构 6
2.3.1概述 6
2.3.2 基本架构 6
2.3.3 SOA的特点 8
2.3.4 SOA的设计原则 9
2.4 SOA的关键技术 10
2.4.1 XML介绍 10
2.4.2 SOAP介绍 10
2.4.3 WSDL介绍 11
2.4.4 UDDI介绍 11
2.4.5 Web Service介绍 11
3．SOA架构在仓库管理系统中的应用 13
3.1仓库管理系统的开发现状 13
3.2 SOA在仓库管理系统中应用的优点 14
3.3面向服务思想与传统的开发模式在仓库管理系统中应用的比较分析 14
4.基于SOA的仓库管理系统的设计与实现 17
4.1系统需求 17
4.2需求分析 17
4.3总体设计 19

copyright think58 [资料来源：http://THINK58.com]

4.3.1 Service树的构建 19
4.3.2模块划分 20
4.3.3系统模型 21
4.3.4开发设计工具 21
4.4模块实现 21
4.5数据库 25
4.6系统截图 26
结论与展望 28
5.1 SOA在仓库管理系统中的研究与应用总结 28
5.2 SOA发展展望 29
致谢 30
参考文献 31
面向服务体系结构
2.l软件体系结构概述
软件体系结构为软件系统提供了一个结构，行为和属性的高级抽象，有构成系统的元素的描述，这些元素的相互作用，指导元素集成的模式以及这些模式的约束组成[1]。软件体系结构不仅制定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。
    软件体系结构贯穿于软件开发和维护的全过程。开发过程中它能够帮助软件设计者全面而深刻的理解系统各层次之间的关系，从而更好的分析系统的性能。同时，软件体系结构是软件设计者之间以及设计者和用户之间快速高效交流的工具，提高需求分析和软件设计的效率，能够将用户提供的业务信息和设计者的设计思想更好的融合在一起。维护过程中，参照原有的软件体系结构，能够保证在不破坏完整性的前提下，对系统进行维护、扩充和升级。软件体系结构是应付复杂需求、提高开发效率、改善系统易维护性的有效措施。 think58

[来源：http://think58.com]

2.2软件体系结构发展演变过程
随着软件行业的不断发展，系统复杂度不断的增加，为了提高软件开发效率，软件体系结构发生了很大的变化。大体上可以分为三个阶段，传统的软件体系结构阶段、基于组件的软件体系结构阶段、面向服务的软件体系结构阶段。
2.2.1传统的软件体系结构
传统的软件体系结构是指在软件行业刚刚起步的阶段，程序规模不大，没有特别的考虑软件体系结构的问题，只是以语句为基本单位，由语句组成模块，通过模块的聚集和嵌套形成层层调用的程序结构。它强调的是结构化程序设计方法学，自顶向下、逐步求精，并注意模块的耦合性，这个阶段的应用程序都把操作的数据、用户的接口还有所有业务逻辑的处理都混杂在一个可以执行的包中。这种软件设计的方法仍然在规模较小、系统复杂度较低的系统中被大量使用，因为它需要少量的开发队伍和较短的开发周期，因为它的简单性会减少开发时间。但是它可重用性差、可维护性差、系统集成性也较差。
2.2.2基于组件的软件体系结构
组件是具有一定的功能，能够独立工作或能同其它组件装配起来协调工作的程序体。
随着软件行业的发展，开始慢慢的看到了软件复用的重要。从而，提出了基于组件的软件体系结构，他大大的增加了软件的可复用性，同时也提高了软件开发的效率和可维护性。从软件复用的角度看，面向对象技术实现了类级重用，它以类为封装的单位.组件技术将重用提到一个更高的层次上，它是对一组类的组合进行封装，并代表完成一个或多个功能的特定服务，也为用户提供了多个接口。整个组件隐藏了具体的实现，只用接口提供服务。与此同时，软件架构出现了多层的概念，其中经典的三层架构把的应用程序从下到上基本划分为数据层、逻辑层、和表示层。功能独立的各层可以重用它们需要的组件，从而使得软件开发效率大大的提高。数据层中涵盖了所有的数据格式。逻辑层独立出来专门处理系统的业务逻辑。表示层只需要把请求交给逻辑层，不需要考虑业务逻辑。比较流行的组件模型有CORBA和COM。其中受到广泛关注的.NET就能够基于COM组件进行开发的。然而在基于组件架构中的组件的使用上，存在一些问题：在异构系统调用困难，跨过防火墙调用更加困难。 copyright think58
 SOA的特点
SOA是一种粗粒度、松耦合的软件架构，其服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。这种模型具有下面几个特征：
1. 松散耦合
服务请求者到服务提供者的绑定与服务之间是松散耦合的。松散耦合旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。服务接口作为与服务实现分离的实体而存在，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。服务实现的修改完全不会影响到服务的使用者。
2. 粗粒度服务
服务粒度指的是服务所公开功能的范围，一般分为，细粒度和粗粒度。其中，细粒度服务是那些能够提供少量商业流程可用性的服务。粗粒度服务是那些能够提供高层商业逻辑的可用性服务。粗粒度服务可以灵活组合，稳定性强、重用性高。虽然细粒度的接口为请求者应用程序提供了更多的灵活性，它同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。粗粒度接口保证服务请求者将以一致的方式使用服务。面向服务的体系结构(SOA)不要求使用粗粒度接口，但是推荐使用它们作为外部集成的最佳实践。服务编排可以用来创建运行由细粒度操作组成的业务流程的粗粒度接口。

本文来自think58

[资料来源：THINK58.com]

3. 标准化的接口
服务描述的重点在于与几部分交互所用的操作：服务、调用操作的消息、构造这种消息的细节和关于向何处发送用于构造这种消息的处理细节的消息的信息。SOA通过服务接口的标准化描述，从而使得该服务可以提供给在任何异构平台和任何用户接口使用。该接口隐藏了实现服务的细节，允许独立于实现服务基于的硬件或软件平台和编写服务所用的编程语言使用服务。
4. 无状态服务
服务应该是独立的、自包含的请求，在实现时它不需要从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当需要依赖时，它们最好定义成通用业务流程、函数和数据模型，而不是实现构件(比如会话密钥)。当然，请求者应用程序需要服务调用之间的持久状态，但是这不应该与服务提供者分开。
2.3.4 SOA的设计原则
体系结构不同，它是以服务为单元，SOA与传统的软件为了能够保证SOA的优势能够体现的淋漓尽致，在设计企业系统架构时，应遵循一定的原则。下面从SOA整体和服务两个方面说明SOA的设计原则[4]。
从架构整体角度来说:
1. 必须完全理解企业的业务需求，以及企业未来的发展趋势。
2. 必须清晰所有服务之间的关系，服务之间要保证良好的松耦合关系，或者将依赖性减至最少，从而使系统达到较高的灵活性和敏捷性。
3. 在配置和使用这些服务的系统中，服务应该被相互独立地配置和更新。
从服务本身角度来说:
1． 服务与外界的交互完全通过公共接口来完成的，服务内部的实现对于外部来说是完全透明的。
2．在满足需求的前提下，服务提供的公共接口要尽可能的少，这样使用和维护都会相对容易。
3． 服务的接口是静态的，应该被设计得不用破坏本身便可进一步扩展。
4． 设计中应该在不损失或损害相关性、一致性和完整性的情况下，尽可能地进行粗粒度建模。通过一组有效设计和组合的粗粒度服务，业务专家能够有效地组合出新的业务流程和应用程序。 think58 [来源：http://think58.com]