我的WCF之旅(7):面向服务架构(SOA)和面向对象编程(OOP)的结合——如何实现Service Contract的继承

简介:
当今的IT领域,SOA已经成为了一个非常时髦的词,对SOA风靡的程度已经让很多人对SOA,对面向服务产生误解。其中很大一部分人甚至认为面向服务将是面向对象的终结,现在的面向对象将会被面向服务完全代替。在开始本Blog之前,我先来谈谈我对SOA和OO的区别,首先申明,这只是一家之言,欢迎大家批评指正,并且关于SO的谈论不是本Blog的主题,只是主题的引子,在这里只是简单讨论而已 。

OO和SO之间具有共同的部分,在运用的领域上存在交集,只有在基于他们交集层面上谈论谁是谁非才有意义,下面是我对SO和OO的区别。

OO关注的是如何通过对实体属性和行为的封装来重塑模拟软件环境的真实实体。对SO关注的则是对现实生活的某个任务、功能的实现,说得通俗点,就是如果做好一件事情。所以对象是对Data和Behavior的封装,而Service则只是体现了一个Functionality。Service是粗粒度的,这样才能导致Contract的稳定;Service一般是Stateless的,给定什么样的输入,就会有对应的确定的输出;Service是Autonomous,基本上的实现封装在Service本身之中,这样可以使它对其它的Service产生最小的依赖。所以对Service建模是一件不太容易的事情:Service不能太大,否则实现起来不容易,还会增加对外界的依赖;也不能太小,否则整合这个Service的成本会令你望而却步。

Service是可组合的(Composable),通过整合相关的单独的,完成某个单个Task或者Activity的小的Service,可以很容易产生一个大的Service,这个Service可以完成一个Functionality的整个流程。比如我们现在把一个Task描述成一个Work flow,如果采用SO的原理来建模,我们可以把组成这个Workflow的单个Activity设计成一个service, 然后根据具体Workflow的特点(比如可能是一个简单的Sequential workflow,也可能是一个基于State machine的workflow)加上相关的条件很容易的把这些Service整合起来,实际上通过整合集成,我们生成一个新的Service。对OO,由于他面对的是一个的Object,具体在分布式中是一个个的Distributed object,要建立一个Composable object则很难(实际上这样也没有什么意义)。

在OO的概念中,一个Object的属性往往就是另一个Object,一个Function的实现往往要调用另一个Object的方法,而且这种层次结构可以无限延伸。这样就会导致真个Object体系变得异常脆弱,经常造成牵一发动全身的状况。用一个很时髦的词语来表达的,就是紧耦合(Tightly couple),Object之间的强依赖关系促成了这种紧耦合的、脆弱的体系结构。而OS则不一样,由于 构成Service体系的单个Service是自治的,Service之间的调用(调用的这个词语容易让人联想到RPC,如果找一个比较贴切的词语来代替,我觉得consume比较合适)是基于Contract的,Service之间Communication是通过Message的(Message不仅仅是Data的封装,还是对整个调用的描述,同时基于XML的Message描述和Message的传递都是符合一个开放的标准的),所有这些成就了SO的松耦合(Loosely couple)。

说了这么多,可能大家都觉得我都是在赞扬SO,都贬低OO。其实不然,上面所说的3个方面都是在讲应用的构建,而不是具体的编程模式。我想表达的是,曾经盛行的基于OO的理论,在企业应用构架方面,已经不能满足我们的需要了,我们迫切希望一种全新的理论来指导我们进行企业应用的构架和集成,而这个理论非SO不可。

而在编程模型层面,OO仍然是不可替代的编程模式。所以OO应用于Programming,而SO则更多地运用在Architecture。既然是这样,我们必须有一种调和剂来调和这两个运用不同原理的两个层面的差异,实现他们之间的无缝的结合。比如如何来对继承,多态,重载等基于OO行为的支持。在这方面,WCF为我们提供了很好的解决方案。所以我说WCF不但是为基于SOA的应用架构提供了技术支持,还通过相关的机制完成我们提出的这个“调和剂”的使命。

在上一篇文章[原创]我的WCF之旅(5):面向服务架构(SOA)对面向对象编程(OOP)的支持——如何实现Service Contract的重载(Overloading)中,我们谈到了WCF如何实现了对Overloading的支持,在这里我们通过一个Sample来讨论WCF对继承的支持。这个Sample中,我们通过一个WCF Service实现了提供天气信息的功能,或者说,我们实现了一个用作天气预报的WCF Service。

1.    我们照例来看看真个Solution 的结构:


整个Solution由以下4个project构成:

  • Artech.InheritanceHierarchy.BusinessEntity:这个Project通过定义的Class封装了在Client和Service端传递的数据,在本例中,我们定义了两个Class:BasicWhetherInfo和WindInfo,他们分别表示Client通过Service获得的基本天气情况和刮风的情况。
  •  Artech.InheritanceHierarchy.Service:这个Project是我们的Service,包括Service Contract和Service 本身。我们定义两个用作天气预报的Service:SimpleWhetherForecast和FullWhetherForecast,前面一个只用返回简单的天气状况的数据(Conditions和Temperature),FullWhetherForecast在SimpleWhetherForecast基础上增加了提供风向和风速的数据。
  • http://localhost/Artech.InheritanceHierarchy: 一个WCF Service Website,以IIS的方式对Service进行Host。
  • Artech.InheritanceHierarchy.Client: Client端。

2.    定义Artech.InheritanceHierarchy.BusinessEntity

BasicWhetherInfo.cs:

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.Serialization;

namespace Artech.InheritanceHierarchy.BusinessEntity
{
    [DataContract]    
    [KnownType(typeof(WhetherConditions))]
    public class BasicWhetherInfo
    {
        private WhetherConditions _condition;      
        private double _temperature;

        public BasicWhetherInfo(WhetherConditions condition, double temperature)
        {
            this._condition = condition;
            this._temperature = temperature;
        }


        [DataMember]
        public WhetherConditions Condition
        {
            get return _condition; }
            set { _condition = value; }
        }


        [DataMember]
        public double Temperature
        {
            get return _temperature; }
            set { _temperature = value; }
        }


        public override string ToString()
        {
            return string.Format("Conditions: {0}; Temperature: {1}", this._condition, this._temperature);
        }

    }


    public enum WhetherConditions
    
        Clear,
        Cloudy,
        Overcost,
        Rainy
    }

}

BasicWhetherInfo包含连个字段/属性:Condition和Temperature。属于Condition不属于基元(Primitive type)所以我们需要添加    [KnownType(typeof(WhetherConditions))]Attribute(由于跨AppDomain的数据传递要求传递的数据先辈Serialization。对于.NET中定义的Primitive type,比如string,int以及其他一些常用的类型,比如datetime,WCF具有一套默认的序列化机制,但是对于另外一些类型,Serializor在执行Serialization的时候 需要获得相关类型的Metadata的信息,WCF通过KnownType attribute向Serializor提供Metadata的信息。)。WindInfo中的Direction属性也是一样的原理。 

WindInfo.cs

using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.Serialization;

namespace Artech.InheritanceHierarchy.BusinessEntity
{
    [DataContract]
    [KnownType(typeof(WindDirection))]
    public class WindInfo
    {
        private WindDirection _direction;       
        private string _speed;

        public WindInfo(WindDirection direction, string speed)
        {
            this._direction = direction;
            this._speed = speed;
        }


        [DataMember]
        public WindDirection Direction
        {
            get return _direction; }
            set { _direction = value; }
        }


        [DataMember]
        public string Speed
        {
            get return _speed; }
            set { _speed = value; }
        }


        public override string ToString()
        {
            return string.Format("Direction: {0}; Speed: {1}", this._direction, this._speed);
        }

    }


    public enum WindDirection
    
        East,
        South,
        West,
        North,
        Northeast,
        SouthEast,
        Northwest,
        Southwest
    }

}

3.    定义Service:Artech.InheritanceHierarchy.Service

我们首先来定义Service Contract

ISimpleWhetherForecast.cs:

using System;
using System.Collections.Generic;
using System.Text;

using Artech.InheritanceHierarchy.BusinessEntity;
using System.ServiceModel;

namespace Artech.InheritanceHierarchy.Service
{
    [ServiceContract]
    public interface ISimpleWhetherForecast
    {
        [OperationContract]
        BasicWhetherInfo GetBasicWhetherInfo(string postalcode);
    }

}

IFullWhetherForecast.cs

using System;
using System.Collections.Generic;
using System.Text;
using System.ServiceModel;
using Artech.InheritanceHierarchy.BusinessEntity;

namespace Artech.InheritanceHierarchy. Service
{
    [ServiceContract]
    public interface IFullWhetherForecast:ISimpleWhetherForecast
    {
        [OperationContract]
        WindInfo GetWindInfo(string postalcode);
    }

}

我们定义了连个Interface作为Service Contract。其中IFullWhetherForecast继承ISimpleWhetherForecast。这里需要注意的是虽然IFullWhetherForecast继承ISimpleWhetherForecast,但是运用在ISimpleWhetherForecast中的ServiceContract Attribute却不能被IFullWhetherForecast使用,这是因为在定义System.ServiceModel. ServiceContractAttribute, 把运用在它之上的AttributeUsage的Inherited设为false, 导致它不能运用到派生的Class上面:

using System;
using System.Net.Security;

namespace System.ServiceModel
{
    [AttributeUsage(1028, Inherited = false, AllowMultiple = false)]
    public sealed class ServiceContractAttribute : Attribute
    {
        public ServiceContractAttribute();

        public Type CallbackContract getset; }
        public string ConfigurationName getset; }
        public bool HasProtectionLevel get; }
        public string Name getset; }
        public string Namespace getset; }
        public ProtectionLevel ProtectionLevel getset; }
        public SessionMode SessionMode getset; }
    }

}

我们接着为这两个Service Contract定义对应的Service。

SimpleWhetherForecastService:

using System;
using System.Collections.Generic;
using System.Text;
using Artech.InheritanceHierarchy.BusinessEntity;

namespace Artech.InheritanceHierarchy.Service
{
    public class SimpleWhetherForecastService:ISimpleWhetherForecast
    {
        ISimpleWhetherForecast Members
    }

}

为了代码的重用,我们让FullWhetherForecastService继承自SimpleWhetherForecastService,这样我们就不必重新定义GetBasicWhetherInfo方法了。

FullWhetherForecastService.cs:

using System;
using System.Collections.Generic;
using System.Text;
using Artech.InheritanceHierarchy.BusinessEntity;

namespace Artech.InheritanceHierarchy.Service
{
   public class FullWhetherForecastService:SimpleWhetherForecastService,IFullWhetherForecast
    {
        IFullWhetherForecast Members      
    }

}

4.    Host Service:http://localhost/Artech.InheritanceHierarchy

现在我们完成了Service的定义,现在我们来Host我们定义的Service,这次我们通过IIS的方式来host service。我们首先在该Website中引用Artech.InheritanceHierarchy.Service Project。然后为FullWhetherForecastService定义相应的.SVC文件(由于Service Contract的继承关系构成了一种Service Contract的层次结构,从而导致所有定义的Operation都出现在最底层的Contract中,由于SimpleWhetherForecastService的Operation没有被FullWhetherForecastServiceOverride,所以现在我们只需要Host FullWhetherForecastService就可以了)。

<%@ ServiceHost Service="Artech.InheritanceHierarchy.Service.FullWhetherForecastService,Artech.InheritanceHierarchy.Service" %>

接着我们在Web.config中为Service注册Endpoint。

<? xml version="1.0" ?>
< configuration  xmlns ="http://schemas.microsoft.com/.NetConfiguration/v2.0" >
     < system .serviceModel >
         < services >            
             < service  name ="Artech.InheritanceHierarchy.Service.FullWhetherForecastService"  behaviorConfiguration ="returnFaults" >
                 < endpoint  contract ="Artech.InheritanceHierarchy.Service.IFullWhetherForecast"  binding ="wsHttpBinding" />
             </ service >
         </ services >
         < behaviors >
             < serviceBehaviors >
                 < behavior  name ="returnFaults" >
                     < serviceDebug  includeExceptionDetailInFaults ="true" />
                     < serviceMetadata  httpGetEnabled ="true"   />
                 </ behavior >
             </ serviceBehaviors >
         </ behaviors >
     </ system.serviceModel >
     < system .web >
         < compilation  debug ="true" >
             < assemblies >
                 < add  assembly ="System.DirectoryServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
                 < add  assembly ="Microsoft.Transactions.Bridge, Version=3.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
                 < add  assembly ="SMDiagnostics, Version=3.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
                 < add  assembly ="System.IdentityModel.Selectors, Version=3.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
                 < add  assembly ="System.Security, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
                 < add  assembly ="System.Web.RegularExpressions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
                 < add  assembly ="System.Transactions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
                 < add  assembly ="System.Messaging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
                 < add  assembly ="System.ServiceProcess, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" /></ assemblies ></ compilation >
     </ system.web >
</ configuration >

5.    定义Client:Artech.InheritanceHierarchy.Client

到现在为止,我们完成了Service的定义和Host的工作,换句话说现在我们定义的Whether

 Forecast service已经可以访问,并暴露在这样的一个Address上:http://localhost/Artech.InheritanceHierarchy/FullWhetherForecastService.svc。现在我们来编写我们Client来访问这个Service。值得一说的是,现在这个Sample中,Client是一个独立的Application,我们既没有让他引用我们定义的Artech.InheritanceHierarchy.BusinessEntity(在WCF中,这个相当于Data Contract),也没有让它和Service共享同一个Service Contract。这很类似于在纯Web环境下调用Service。

我们通过添加Service reference的方式生成我们Client端的code, WCF中的添加Service reference同Web Service中的添加Web reference相识。通过添加Service reference,WCF会为我们生成基于Client的service contract,data contract,proxy,configuraiton,甚至为我们添加System.ServiceNModel dll的引用。下面就是我们生成的Code:

Code比较长,我们现在一部分一部分地来分析。

Part I:Data Contract

把这段代码基本上对应的我们在Artech.InheritanceHierarchy.BusinessEntity定义的Data Contract:两个Class:BasicWhetherInfo& WindInfo和连个Enum:WindDirection& WhetherConditions。不过有一点我觉得奇怪的是我们原来的BasicWhetherInfo& WindInfo的定义中,我Override了ToString方法,但是在生成的Class中,却没有相应的Code。我不清楚Microsoft对此事作怎么样的考虑,还是忽略了这一点。

Part II Service Contract

    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]    [System.ServiceModel.ServiceContractAttribute(ConfigurationName="Artech.InheritanceHierarchy.Client.WhetherForecastService.IFullWhetherForecast")]
     public  interface IFullWhetherForecast
     {        
        [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/ISimpleWhetherForecast/GetBasicWhetherInfo", ReplyAction="http://tempuri.org/ISimpleWhetherForecast/GetBasicWhetherInfoResponse")]
        Artech.InheritanceHierarchy.Client.WhetherForecastService.BasicWhetherInfo GetBasicWhetherInfo(string postalcode);
        
        [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IFullWhetherForecast/GetWindInfo", ReplyAction="http://tempuri.org/IFullWhetherForecast/GetWindInfoResponse")]
        Artech.InheritanceHierarchy.Client.WhetherForecastService.WindInfo GetWindInfo(string postalcode);
    }

在Service端,我们通过运用继承定义了一套Service contract的层次结构,并为处于最底层的Contract公开了一个Endpoint。在Client端,我们通过添加Service reference的方式生成了Client的Service contract的结构。不过Client的Service contract的结构是一种扁平的结构:通过一个Contract定义所有的Operation。

Part III Proxy

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
     public  interface IFullWhetherForecastChannel : Artech.InheritanceHierarchy.Client.WhetherForecastService.IFullWhetherForecast, System.ServiceModel.IClientChannel
     {
    }

    
    [System.Diagnostics.DebuggerStepThroughAttribute()]
    [System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
     public partial  class FullWhetherForecastClient : System.ServiceModel.ClientBase<Artech.InheritanceHierarchy.Client.WhetherForecastService.IFullWhetherForecast>, Artech.InheritanceHierarchy.Client.WhetherForecastService.IFullWhetherForecast
     {
        
        public FullWhetherForecastClient()
        {
        }

        
        public FullWhetherForecastClient(string endpointConfigurationName) : 
                base(endpointConfigurationName)
        {
        }

        
        public FullWhetherForecastClient(string endpointConfigurationName, string remoteAddress) : 
                base(endpointConfigurationName, remoteAddress)
        {
        }

        
        public FullWhetherForecastClient(string endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) : 
                base(endpointConfigurationName, remoteAddress)
        {
        }

        
        public FullWhetherForecastClient(System.ServiceModel.Channels.Binding binding, System.ServiceModel.EndpointAddress remoteAddress) : 
                base(binding, remoteAddress)
        {
        }

        
        public Artech.InheritanceHierarchy.Client.WhetherForecastService.BasicWhetherInfo GetBasicWhetherInfo(string postalcode)
        {
            return base.Channel.GetBasicWhetherInfo(postalcode);
        }

        
        public Artech.InheritanceHierarchy.Client.WhetherForecastService.WindInfo GetWindInfo(string postalcode)
        {
            return base.Channel.GetWindInfo(postalcode);
        }

}

现在我们可以通过FullWhetherForecastClient这个Proxy Class来访问Service了。虽然能完成我们的所有操作,但是这样的代码总觉得很别扭。我们希望的是以Service端定义结构进行Service的调用:Client具有两个Proxy:SimpleWhetherForecastClient和FullWhetherForecastClient。FullWhetherForecastClient继承自SimpleWhetherForecastClient。我们先删除我们生成的Code,按照以下的步骤来实现这样功能。

Step 1:定义Client端的Service Contract

ISimpleWhetherForecast

using System;
using System.Collections.Generic;
using System.Text;

using Artech.InheritanceHierarchy.BusinessEntity;
using System.ServiceModel;

namespace Artech.InheritanceHierarchy.Client
{
    [ServiceContract]
    public interface ISimpleWhetherForecast
    {
        [OperationContract]
        BasicWhetherInfo GetBasicWhetherInfo(string postalcode);
    }

}

IFullWhetherForecast.cs

using System;
using System.Collections.Generic;
using System.Text;
using System.ServiceModel;
using Artech.InheritanceHierarchy.BusinessEntity;

namespace Artech.InheritanceHierarchy. Client
{
    [ServiceContract]
    public interface IFullWhetherForecast:ISimpleWhetherForecast
    {
        [OperationContract]
        WindInfo GetWindInfo(string postalcode);
    }

}

除了namespace,和Service端的contract没有什么区别。

Step2:引用Artech.InheritanceHierarchy.BusinessEntity

Step3:   配置Endpoint

<? xml version="1.0" encoding="utf-8"  ?>
< configuration >
     < system .serviceModel >
         < client >            
             < endpoint  address ="http://localhost/Artech.InheritanceHierarchy/FullWhetherForecastService.svc"
              binding
="wsHttpBinding"  bindingConfiguration =""   contract ="Artech.InheritanceHierarchy.Client.IFullWhetherForecast" />
         </ client >
     </ system.serviceModel >
</ configuration >

因为Service端的Endpoint对应的Contract是Artech.InheritanceHierarchy.Service IFullWhetherForecast,所以我们适应对应的Client端的Contract:Artech.InheritanceHierarchy.Client.IFullWhetherForecast

Step 4:建立Proxy

SimpleWhetherForecastClient.cs

using System;
using System.Collections.Generic;
using System.Text;
using System.ServiceModel;
using Artech.InheritanceHierarchy.BusinessEntity;

namespace Artech.InheritanceHierarchy.Client
{
   public class SimpleWhetherForecastClient:ClientBase<IFullWhetherForecast>,ISimpleWhetherForecast
    {
       ISimpleWhetherForecast Members
    }

}

FullWhetherForecastClient.cs

using System;
using System.Collections.Generic;
using System.Text;

namespace Artech.InheritanceHierarchy.Client
{
    public class FullWhetherForecastClient:SimpleWhetherForecastClient,IFullWhetherForecast
    {
       
        IFullWhetherForecast Members
    }

}

现在通过SimpleWhetherForecastClient和FullWhetherForecastClient完全以OO的方式优雅地调用Whether forecast service。

WCF相关内容:
[原创]我的WCF之旅(1):创建一个简单的WCF程序
[原创]我的WCF之旅(2):Endpoint Overview
[原创]我的WCF之旅(3):在WCF中实现双向通信(Bi-directional Communication)
[原创]我的WCF之旅(4):WCF中的序列化(Serialization)- Part I
[原创]我的WCF之旅(4):WCF中的序列化(Serialization)- Part II
[原创]我的WCF之旅(5):Service Contract中的重载(Overloading)
[原创]我的WCF之旅(6):在Winform Application中调用Duplex Service出现TimeoutException的原因和解决方案
[原创]我的WCF之旅(7):面向服务架构(SOA)和面向对象编程(OOP)的结合——如何实现Service Contract的继承
[原创]我的WCF之旅(8):WCF中的Session和Instancing Management
[原创]我的WCF之旅(9):如何在WCF中使用tcpTrace来进行Soap Trace
[原创]我的WCF之旅(10): 如何在WCF进行Exception Handling
[原创]我的WCF之旅(11):再谈WCF的双向通讯-基于Http的双向通讯 V.S. 基于TCP的双向通讯

[原创]我的WCF之旅(12):使用MSMQ进行Reliable Messaging
[原创]我的WCF之旅(13):创建基于MSMQ的Responsive Service


作者:蒋金楠
微信公众账号:大内老A
微博: www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送,或者想看看个人推荐的技术资料,可以扫描左边二维码(或者长按识别二维码)关注个人公众号(原来公众帐号 蒋金楠的自媒体将会停用)。
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
相关文章
|
7月前
|
缓存 监控 数据格式
信息系统架构模型(2) SOA
信息系统架构模型(2) SOA
157 0
|
7月前
|
设计模式 安全 Java
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
112 0
|
4月前
|
Cloud Native 云计算 微服务
云原生时代:企业分布式应用架构的惊人蜕变,从SOA到微服务的大逃亡!
【8月更文挑战第8天】在云计算与容器技术推动下,企业分布式应用架构正经历从SOA到微服务再到云原生的深刻变革。SOA强调服务重用与组合,通过标准化接口实现服务解耦;微服务以细粒度划分服务,增强系统灵活性;云原生架构借助容器化与自动化技术简化部署与管理。每一步演进都为企业带来新的技术挑战与机遇。
135 6
|
5月前
|
负载均衡 监控 Kubernetes
Service Mesh 是一种用于处理服务间通信的基础设施层,它通常与微服务架构一起使用,以提供诸如服务发现、负载均衡、熔断、监控、追踪和安全性等功能。
Service Mesh 是一种用于处理服务间通信的基础设施层,它通常与微服务架构一起使用,以提供诸如服务发现、负载均衡、熔断、监控、追踪和安全性等功能。
|
5月前
|
Kubernetes API 微服务
「架构风格」SOA(面向服务)和微服务
**SOA与微服务对比摘要**: - **SOA**:企业级,服务粒度大,重用性强,常通过ESB通信,服务部署集中,技术栈统一。 - **微服务**:服务粒度小,单一职责,轻量级协议如REST,独立部署,技术多样性,去中心化治理。 - **区别**:服务大小、独立性、通信协议、部署方式和技术栈不同,微服务更强调敏捷和独立性。 - **示例**:Python Flask简单示例展示了服务创建,SOA服务间通过HTTP请求通信,微服务每个服务独立运行。 - **权衡**:涉及服务发现、负载均衡、容错和安全,常用技术如Docker、Kubernetes和API网关。
480 0
|
6月前
|
边缘计算 Cloud Native
“论SOA在企业集成架构设计中的应用”必过范文,突击2024软考高项论文
SOA架构,即面向服务的架构,它将系统中的所有功能都拆分为一个个独立的服务单元。这些服务通过相互间的沟通与配合,共同完成了整体业务逻辑的运作。在SOA架构中有几个核心概念:服务提供者、服务使用者、服务注册中心、服务规范、服务合同,这些概念清晰地阐述了服务应如何被提
240 6
“论SOA在企业集成架构设计中的应用”必过范文,突击2024软考高项论文
|
5月前
|
消息中间件 监控 中间件
业务系统架构实践问题之Service间网状调用如何解决
业务系统架构实践问题之Service间网状调用如何解决
|
5月前
|
消息中间件 安全 NoSQL
「架构」SOA(面向服务的架构)
**SOA**是构建灵活企业IT系统的架构模式,基于服务组件进行设计。它强调服务的自包含、模块化,通过服务识别、抽象、组合和交互实现业务流程。特点包括松耦合、重用性、互操作性和标准化。优点是灵活性、可维护性、可扩展性和成本效益,但也有复杂性、性能和治理问题。设计策略涉及业务能力识别、服务契约定义和服务目录建立。技术栈涵盖Java EE、.NET、SOAP、REST、服务治理工具和各种数据库、消息队列及安全标准。SOA旨在适应变化,但也需妥善管理和规划。
244 0
|
6月前
|
边缘计算 Cloud Native IDE
“论SOA在企业集成架构设计中的应用”写作框架,系统架构设计师
企业应用集成(Enterprise Application Integration, EAI)是每个企业都必须要面对的实际问题。面向服务的企业应用集成是一种基于面向服务体系结构(Service-OrientedArchitecture,SOA)的新型企业应用集成技术,强调将企业和组织内部的资源和业务功能暴露为服务,实现资源共享和系统之间的互操作性,并支持快速地将新的应用以服务的形式加入到已有的集成环境中,增强企业IT环境的灵活性。
131 0
|
7月前
|
监控 负载均衡 数据安全/隐私保护
探索微服务架构下的服务网格(Service Mesh)实践
【5月更文挑战第6天】 在现代软件工程的复杂多变的开发环境中,微服务架构已成为构建、部署和扩展应用的一种流行方式。随着微服务架构的普及,服务网格(Service Mesh)作为一种新兴技术范式,旨在提供一种透明且高效的方式来管理微服务间的通讯。本文将深入探讨服务网格的核心概念、它在微服务架构中的作用以及如何在实际项目中落地实施服务网格。通过剖析服务网格的关键组件及其与现有系统的协同工作方式,我们揭示了服务网格提高系统可观察性、安全性和可操作性的内在机制。此外,文章还将分享一些实践中的挑战和应对策略,为开发者和企业决策者提供实用的参考。