如果从概念层来看,我更喜欢把SOA归为企业架构的范畴,从企业架构出发把业务分解为不同业务域的服务,关注系统间的服务互联互通的规范,并不关心如何实现。也就是说在企业架构上使用SOA支撑业务,而在方案架构使用微服务架构来实现.

SOA 宣言

面向服务是一种规范行为的范式。面向服务架构(SOA)是一种应用于面向服务而形成的一种架构。

我们一直以来运用面向服务来帮助组织始终如一的交付可持续的业务价值, 以提高灵活性和成本效益来符合变化的业务需求。

在我们的工作中, 我们会作如下优先排序:

  1. 业务价值 高于 技术策略

  2. 战略目标 高于 特定项目的效益

  3. 内在互操作性 高于 定制的集成

  4. 共享的服务 高于 特定目标的实现

  5. 灵活性 高于 优化

  6. 不断演进的提炼 高于 在最开始追求完美

也就是说, 我们认为右边的要素有其价值,但我们更加重视左边要素的价值

 

SOA 指导原则

我们遵循如下原则:

  1. 尊重组织的社会和权力结构

  2. 认识到SOA最终需要在许多层面上做出改变

  3. 采用SOA的范围可以多种多样, 确保工作量可控并处于有意义的范围内

  4. 产品和标准本身既不会给你 SOA ,也不会为你应用面向服务的范式

  5. SOA 可以通过不同的技术和标准来实现

  6. 建立一套基于行业和社区标准的统一的企业标准和政策

  7. 追求外在的统一性,同时允许内在的多样性

  8. 通过与业务和技术的利益相关者协作来识别服务

  9. 考虑目前和未来的使用范围,从而最大限度的提高服务的用途

  10. 验证服务满足业务需求和目标

  11. 演进服务及其组织方式来应对实际的使用

  12. 分开一个系统中以不同速率变化的不同方面

  13. 减少隐含的依赖,并公布所有外部依赖, 以增强系统的健壮性, 减少依赖变化造成的影响

  14. 在抽象的没一个层次,围绕一个紧密结合和可管理的功能单位来组织每一个服务

微服务架构的特征

Martin Fowler 在他的文章中总结了Micro Service的特点:

  1. 围绕业务能力来组织

  2. 做产品而非做项目

  3. 智能终端加弱通道

  4. 去中心化治理

  5. 去中心化数据管理

  6. 基础设施自动化

  7. 为应对失败而设计

  8. 演进式设计

The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
Leonid Felikson
October 2010
History of The SOA Manifesto
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
2
•The SOA Manifesto was published in October 2009
•The Annotated SOA Manifesto, Insights and Commentary about the SOA Manifesto, was published in November 2009
•By October 2010, the SOA Manifesto has been translated to 9 languages:
–Chinese, Dutch, French, German, Italian, Portuguese, Russian, Spanish and Tamil
•By October 2010, the Annotated SOA Manifesto has been translated to 5 languages:
–Dutch, French, German, Russian and Spanish
Semantics First
•What does the word “paradigm”mean:
–from Greek: παράδειγμα paradeigmameaning pattern
–from Greek: paradeiknunaimeaning to compare
–composite from para-and the verb deiknunai"to show"
–The Oxford English Dictionary defines paradigm as "a pattern or model, an exemplar“.
•“Paradigm” has been used in linguistics and science to describe distinct concepts.
•Paradigm is “the generally accepted perspective of a particular discipline at a given time”.
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
3
Service orientation is a paradigmthat frames what you do.
(The SOA Manifesto)
Semantics First, cont’d
•SOA is not type of technology, nor it is a software product
•SOA is a type of Architecture
•We can’t buy SOA like we buy a technology product or tool
•Goals of SOA are rather strategic, not tactical
•Applying service orientation as a consistent, systematic discipline
•All types of architecture are affected by service orientation: business, data, infrastructure, application, security, integration
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
4
Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.
Semantics First, cont’d
•Service orientation is a method of achieving target state defined by set of sustainable, strategic business goals and benefits
•Modeling reality by designing and developing software as a service, by applying service orientation principles
•Delivering new business capabilities is easier (due to intrinsic service composability and interoperability) –> business agility
•Service reuse contributes into cost effectiveness
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
5
We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agilityandcost effectiveness, in line with changing business needs.
Six Core Values of SO Prioritized
•Business drives, technology supports
•Impact on all phases of software life cycle
•Supported by all other SO values and principles
•Services model “horizontal” business capabilities and therefore are strategically positioned to be enterprise-scoped, not project-scoped
•Services are repeatable and shareable –> “multi-purpose”, cross-project solutions vs. “single-purpose”, “silo” legacy applications
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
6
Business value over technical strategy.Strategic goals over project-specific benefits.
Six Core Values of SO Prioritized, cont’d
•Interoperability is ability to exchange and use information
•Practicing service orientation leads to interoperability by design, not by customization
•Services exhibit encapsulation of “multi-purpose” business logic, therefore can be shared and reused –> cost effectiveness, agility
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
7
Intrinsic interoperability over custom integration.
Shared services over specific-purpose implementations.
Six Core Values of SO Prioritized, cont’d
•Optimization remains valuable (i.e. for performance reasons)
•Flexibility –> interoperability
•Flexibility includes ease of composability, therefore agility in delivering new business capabilities
•Business change is “norm”
•Services are designed and built to change
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
8
Flexibility over optimization.Evolutionary refinement over pursuit of initial perfection.
Fourteen Guiding Principles
•Gain executive management buy-in and support
•Hide technology language while talking to executive management
•Establish community-centric mindset
•Make SOA adoption as business-driven, not technology-driven
•SOA projects require new approach in funding models, project management, software development life cycle, etc.
•SOA impacts not so much technology architecture, but more business and data architectures
•SOA changes governance model and processes
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
9
Respect the social and power structure of the organization.Recognize that SOA ultimately demands change on many levels.
Fourteen Guiding Principles, cont’d
•Manage scope of SOA adoption
•Domain-centric vs. enterprise-centric approach
•SOA Governance is priority for any scope of SOA adoption
•See “big picture”, start from “small” steps
•We can’t buy SOA!
•SOA enabling products don’t warrant success of SOA approach!
10
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you.
Fourteen Guiding Principles, cont’d
•Service orientation is technology and vendor neutral paradigm
•Just like we can write code with different programming languages, we can realize SOA with variety of technologies
•Rely on industry standards and policies, but consider having your own
•Have principles and policies that work for stakeholders, not against them
•Ensure quality not quantity of standards and policies in use
11
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
SOA can be realized through a variety of technologies and standards.Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.
Fourteen Guiding Principles, cont’d
•Unified, federated endpoint layer is based on standards used for presenting exposed interfaces
•Consistent application of industry standards ensures unity from end-user view
•Internally, variety of technologies and programming models and platforms can be used; stand-alone or working together
•SOA is not a technology-centric effort and shouldn’t be viewed as such
•Variety of stakeholders work together on SOA adoption program
•Not only does SOA require business-IT collaboration, but it helps to moderate it
12
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
Pursue uniformity on the outside while allowing diversity on the inside.Identify services through collaboration with business and technology stakeholders.
Fourteen Guiding Principles, cont’d
•Service orientation promotes reuse
•Services are designed for change and expended reuse
•Services granularity impacts potential reuse
•Service usage and effectiveness at fulfilling business requirements need to be verified and measured
•Tools are required to measure fulfillment of business needs and expectations
13
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
Maximize service usage by considering the current and future scope of utilization.Verify that services satisfy business requirements and goals.
Fourteen Guiding Principles, cont’d
•Services in production require continuous performance assessment and ongoing feedback of customer satisfaction
•Services are in constant evolvement process
•Services are resilient and adaptive to change in response to real world usage
•Service-oriented approach allows decomposition of large business problem to deal with smaller concerns
•Separation of agnostic and non-agnostic business logic allows design of numerous layers of abstraction and helps to shield service-comprised systems from the impacts of change.
•Therefore, with service orientation we achieve higher degree of change resilience.
14
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
Evolve services and their organization in response to real use.Separate the different aspects of a system that change at different rates.
Fourteen Guiding Principles, cont’d
•Transparency of services helps to establish trust between providers and consumers of services
•Reducing internal dependencies makes integration easier
•Several service design patterns help to achieve greater degree of decoupling, i.e. service façade pattern
•Well-designed and well-defined functional context of the service leads to well-composed business capabilities
•Choose the best granularity for your services based on desired business context and functionality
15
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change. At every level of abstraction, organize each service around a cohesive and manageable unit of functionality.
Conclusion
•The SOA Manifesto’s defined service-oriented principles unify community, establish priorities and values, and provide pragmatic guidelines
•This document is a great step towards a common understanding of key success criteria for SOA as an important strategic element in today’s agile business environment
•It finds ways of clearly defining objectives and goals for a subject of such significant magnitude of complexity
The SOA Manifesto: Establishing a Common Understanding About SOA and Service-Orientation
16

SOA宣言和微服务特点的更多相关文章

  1. 软件架构的演进,了解单体架构,垂直架构,SOA架构和微服务架构的变化历程

    软件架构演进 软件架构的发展经历了从单体结构.垂直架构.SOA架构到微服务架构的过程,博客里写到了这四种架它们的特点以及优缺点分析,个人学习之用,仅供参考! 1.1.1      单体架构 特点: 1 ...

  2. SOA与ESB,微服务与API网关

    SOA与ESB,微服务与API网关 SOA: ESB: 微服务: API网关: 参考资料: 1.漫画微服务,http://www.sohu.com/a/221400925_100039689 2.SO ...

  3. 【转】SOA架构和微服务架构的区别

    SOA架构和微服务架构的区别 https://blog.csdn.net/zpoison/article/details/80729052

  4. SOA架构和微服务架构的区别与特点

    1.SOA架构和微服务架构的区别 首先SOA和微服务架构一个层面的东西,而对于ESB和微服务网关是一个层面的东西,一个谈到是架构风格和方法,一个谈的是实现工具或组件. 1.SOA(Service Or ...

  5. 通俗地理解面向服务的架构(SOA)以及微服务之间的关系

    SOA是一种软件的应用架构方法,它基于面向对象,但又不是面向对象,整体上是面向服务的架构.SOA由精确的服务定义.松散的构件服务组成,以及业务流程调用等多个方面形成的一整套架构方法. 这话是不是听起来 ...

  6. SOA 架构与微服务架构的区别

    注重重用,微服务注重重写 SOA 的主要目的是为了企业各个系统更加容易地融合在一起. 微服务通常由重写一个模块开始.要把整个巨石型的应用重写是有很大的风险的,也不一定必要.我们向微服务迁移的时候通常从 ...

  7. 单体架构、SOA架构、微服务架构

  8. Atitit.架构设计趋势 设计模式 ---微服务架构  soa

    Atitit.架构设计趋势 设计模式 ---微服务架构  soa 什么是微服务架构?1 .微服务与SOA的关系 :微服务架架构师面向服务架构(SOA)的一种特定实现1 微服务与康威定律2 微服务的一些 ...

  9. [转]系统架构演变--集中式架构-垂直拆分-分布式服务-SOA(服务治理)-微服务

    一.系统架构演变 1.1. 集中式架构 当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本.此时,用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键. 存在的 ...

随机推荐

  1. active mq 配置

    <transportConnectors> <!-- DOS protection, limit concurrent connections to 1000 and frame s ...

  2. Android-Dialog风格Activity开发

    1.设置窗口风格 : ①在Manifest中设置主题属性android:theme="@android:style/Theme.Dialog",或者 Theme.Holo.Dial ...

  3. dynamic web project

  4. 【转】Web前端开发:为何选择MVVM而非MVC

    在Web中充斥着所谓的MVC框架,而在我看来,因为一些关键性的技术原因,MVC在Web前端开发中根本无法使用(对的,是无法,而不是不该) 在Web中充斥着所谓的MVC框架,而在我看来,因为一些关键性的 ...

  5. 远程连接windows时剪贴板失效解决方法

    1:打开任务管理器2:找到结束进程rdpclip,找不到可以不管.3:手工新建任务里输入rdpclip,运行即可.

  6. 高通音频 媒体喇叭增益隐藏参数(一个QACT无法修改的参数)

    源文件位置:modem_proc\multimedia\audio\avs\src\sndhwg2.c sndhw_init()函数,2520行左右:pm_set_speaker_gain(PM_SP ...

  7. Laravel5.1 模型初探

    Laravel的模型也是访问数据库的,它更加面向对象,一个模型对应着一张表 我们可以使用模型对数据做一些增删改查的操作. 1 创建模型 创建模型是可以使用Artisan控制台的: php artisa ...

  8. Laravel 5.1 Blade模板引擎

    为什么要使用blade 它是干什么用的? blade模板引擎使我们写HTML页面的地方,使用它是因为它能给我们提供很多的遍历,减少代码的重复率 提高开发效率.我们写blade的路径是 resource ...

  9. iOS 数组的去重(普通的无序的去重和排序好的去重)

    本文转载至 http://blog.csdn.net/zhaopenghhhhhh/article/details/24972645 有时需要将NSArray中去除重复的元素,而存在NSArray中的 ...

  10. poj1742

    Coins Time Limit: 3000MS   Memory Limit: 30000K Total Submissions: 33998   Accepted: 11554 Descripti ...