为了让读者对基于Windows用户组的授权具有深刻的认识，接下来我们通过一个简单的事例来讲解在真正的应用中该授权模式如何使用。对于接下来演示的事例，我们将采用Windows认证和授权。至于授权的最终实现，我们采用的是在服务方法上面应用PrincipalPermissionAttribute特性方式的声明式授权。[源代码从这里下载] 目录： 步骤一、创建测试帐号 步骤二、创建服务契约和服务 步骤三、寄宿服务 步骤四、创建客户端程序 步骤一、创建测试帐号 在创
本系列先后通过《实例篇》、《概念篇》、《协议篇》和《编程篇》对WCF的可靠会话进行了详细探讨。作为本系列的最后一片，我们将深入到WCF的可靠会话体系的最底层，对实现可靠会话的实现原理进行深入剖析。如果读者仔细阅读本系列博文，相信会使读者对可靠会话的理解提升到一定的高度。 从《编程篇》中，我们不难看出可靠会话的编程仅仅围绕着一个对象，那就是绑定。绑定在整个WCF架构模型具有重要的地位。WCF整个架构模型由两部分构成，即服务模型（Service Model）层和信道（Channel）层，而绑定是信道层的缔造者，
前面两篇（《服务如何能被”发现”》和《客户端如何能够“探测”到可用的服务？》）我们分别介绍了可被发现服务如何被发布，以及客户端如果探测可用的服务。接下来我们通过一个简单的例子来演示如果创建和发布一个可被发现的服务，客户端如何在不知道服务终结点地址的情况下动态探测可用的服务并调用之。该实例的解决方案采用如右图所示的结构，即包含项目Service.Interface（类库）、Client（控制台应用）和Service（控制台应用）分别定义服务契约、服务（包括服务寄宿）和客户端程序。[源代码从这里下载，Dyn
上一篇演示的是绑定类型为NetTcpBinding情况下基于TLS/SSL的Transport安全模式的实现，接下来我们改用另外一种绑定：WS2007HttpBinding。对于基于HTTP的绑定，Transport安全模式的实现方式又根据寄宿方式的不同而具有一定的差异，我们首先来介绍自我寄宿的方式。 一、自我寄宿（Self-Hosting） 无论对于HTTPS还是SSL Via TCP，服务端都需要绑定一个证书。对于采用后者的NetTcpBinding，我们是通过ServiceCredentials这个服
元数据的发布方式决定了元数据的获取行为，WCF服务元数据架构体系通过ServiceMetadataBehavior实现了基于WS-MEX和HTTP-GET的元数据发布，针对这两种不同的协议，元数据获取的实现方式也是不同的。我们首先来实现基于WS-MEX的元数据获取方式。 [Source Code从这里下载] 一、 基于WS-MEX的元数据获取 ServiceMetadataBehavior通过创建MEX终结点实现了基于WS-MEX的元数据的发布，从《如何将一个服务发布成WSDL》系列文章的介绍我们知道：元数
对于基于Internet的应用，基于用户名和密码的认证方式是最为常用的，而WCF为你提供了不同模式的用户名认证方式。首先还是从用户凭证的表示说起。 一、用户名/密码认证的三种模式 基于用户名/密码的用户凭证通过类型UserNamePasswordClientCredential表示。而在ClientCredentials中，只读属性UserName表示这样一个用户凭证。你可以按照Windows凭证的方式为ChannelFactory<TChannel>或者ClientBase<TChannel>基于用户名/
本篇文章介绍可以算是WCF 4.0基于限流（Throttling）的新特性，是在修订《WCF技术剖析（卷1）》的时候编写演示实例的时候发现的。这个特性没有出现在官方文档上面，至少在MSDN上的相关介绍依然是错误的。 一、流量限制简介 WCF是一个基于多线程的消息监听、接收和处理框架体系，能够同时应付来自相同或者不同客户端的服务调用请求，并提供完善的同步机制确保状态的一致性。一方面，我们期望WCF服务端能够处理尽可能多的并发请求，但是资源的有限性决定了并发量有一个最大值。如果WCF不控制进入消息处理系统的并发
《上篇》对AddressHeader在服务端和客户端的作用，以及如何通过配置和编成的方式设置AddressHeader进行了详细介绍。现在我们通过一个实例来演示终结点的地址报头如何影响实现终结点选择的消息筛选机制。这个实例通过为服务端终结点指定地址报头实现针对客户端的授权，让经过许可的客户端才能访问这个服务。具体来说，我们将一个代码序列号的GUID作为终结点的地址报头。对于客户端发送的消息，只有具有相应的报头才能访问服务。[三个实例源代码下载地址：实例1、实例2和实例3] 一、无地址报头下服务调用（实例
在《原理篇》中我们谈到：如果采用自定义安全主体权限模式，我们可以通过自定义AuthorizationPolicy或者ServiceAuthorizationManager实现对基于当前认证用于相关的安全主体的提供，进而达到授权的目的。为了让大家对此有个更加深刻的认识，在这篇文章中我们会提供一个具体的例子。[源代码从这里下载] 目录： 一、创建自定义AuthorizationPolicy 二、创建自定义ServiceAuthorizationManager 三、通过自
在采用TLS/SSL实现Transport安全的情况下，客户端对服务证书实施认证。但是在默认情况下，这种认证仅仅是确保服务证书的合法性（通过数字签名确保证书确实是由申明的CA颁发）和可信任性（证书或者CA证书存储于相应的可信赖存储区）。而WCF提供服务证书并不限于此，客户端对服务认证的模式应该是这样的：服务端预先知道了服务的身份，在进行服务调用之前，服务端需要提供相应的凭证用以辅助客户端确认调用的服务具有预先确定的身份。对于这样的服务认证模式，具有两个重要的概念，即服务凭证和服务身份。 目录：
我们有两种典型的WCF调用方式：通过SvcUtil.exe（或者添加Web引用）导入发布的服务元数据生成服务代理相关的代码和配置；通过ChannelFactory<TChannel>创建服务代理对象。在这篇文章中，我们采用一种独特的方式进行服务的调用。从本质上讲，我们只要能够创建于服务端相匹配的终结点，就能够实现正常的服务调用。在WCF客户端元数据架构体系中，利用MetadataExchangeClient可以获取服务的元数据，而利用MetadataImporter将获取的元数据导入成ServiceEndp
我们传统的服务调用的模式都是这样的：客户端在设计时就预先知道目标服务的地址，并基于这个地址创建客户端终结点对服务进行调用。而我们即将介绍的新特性则是你在预先不知道目标服务的地址的情况下，可以动态地探测可用的服务并调用之。就像我们的无线网卡可以同态地获取周围可用的WIFI网络一样。 服务发现接触了客户端和服务端之间的依赖，允许服务的提供者可用动态的改变它的地址，也是新的服务可以很容易地被注册并为人所用。关键一点的事，服务发现并不是微软在.NET平台下的闭门造车，而是基于一个开放的标准，即我们接下来着重介绍的W
在java生态圈谈到Rpc，很多人可能就会想到Dubbo、Motan、Grpc等框架。但是你知道吗？作为Java编程全家桶的Spring已经内置了多种RPC的实现方式，可以直接使用。存在即合理，有些场景下其实并不需要Dubbo，Grpc等重量级的RPC组件，那么Spring的轻量封装就可以派上用场了。下面就来探索下Spring中的RPC的实现方式以及如何使用的。
RPC的全称是Remote Procedure Call，它是一种进程间的通信方式。允许像调用本地服务一样调用远程服务，它的具体的实现方式可以不同，例如Spring的HTTP Invoker，FaceBook的Thrift二进制私有协议通信。
在本篇文章中，我们将通过一个具体的实例来演示如何通过路由服务。在这个例子中，我们会创建连个简单的服务HelloServie和GoodbyeService。假设客户端不能直接调用这两个服务，需要使用到路由服务作为两者之间的中介。整个消息路由的场景如下图所示，中间的GreetingService.svc就是代表路由服务，而两个目标服务则通过HelloServie.svc和GoodbyeService.svc表示。路由服务使用的消息筛选器EndpointAddressMessageFilter，即根据包含在消息中
由于绑定对象由一系列有序的绑定元素组成，绑定元素最终决定着信道栈中信道的组成，而信道的组成最终又决定了信道栈对消息进行处理的方式和能力，所有要确定绑定的特性和能力，我们可以通过查看其绑定元素的构成来一窥究竟。为此我们我们写了一个简单的方法，用于列出一个具体的绑定对象所有的绑定元素，在介绍一个个具体的系统绑定中，我会使用该方法： 1: static void ListAllBindingElements(Binding binding) 2: { 3: BindingElementC
WCF所谓的安全审核就是针对认证和授权所做的针对EventLog的日志记录。我们不但可以设置进行审核的事件（认证成功/失败，授权成功或失败），还可以选择记录信息被写入的EventLog类型，即应用程序日志（Application）还是安全日志（Security）。WCF的安全审核是通过ServiceSecurityAuditBehavior服务行为实现的。 一、ServiceSecurityAuditBehavior服务行为 针对WCF安全审核的编程只涉及ServiceSecurityAuditBehavi
近半年以来，一直忙于我的第一本WCF专著《WCF技术剖析（卷1）》的写作，一直无暇管理自己的Blog。在《WCF技术剖析（卷1）》写作期间，对WCF又有了新的感悟，为此以书名开始本人的第三个WCF系列。本系列的目的在于对《WCF技术剖析》的补充，会对书中的一些内容进行展开讲述，同时会囊括很多由于篇幅的原因忍痛割弃的内容。 [第1篇] 通过一个ASP.NET程序模拟WCF基础架构 本系列的第一篇，我将会对WCF的基本架构作一个大致的讲解。不过，一改传统对WCF的工作流程进行平铺直叙，我将另辟蹊径，借助于我
ESB是企业服务总线（Enterprise Service Bus）的缩写，是中间件技术与Web Service等技术结合的产物，也是SOA系统中的核心基础设施。ESB就是一个服务的中介，形成服务使用者->ESB服务Proxy->服务提供者的生物链，中介的作用在不同应用中各有不同： 解耦中介 ：客户对实际服务提供者的身份、物理位置、传输协议和接口定义都是不知道也不关心的，交互集成代码提取到了业务逻辑之外，由ESB平台进行中央的宣告式定义。ESB平台实现协议转换 (WebService，Http，JMS...
WCF客户端和服务端的框架体系相互协作，使得开发人员可以按照我们熟悉的方式进行异常的处理：在服务操作执行过程中抛出异常（FaultException），在调用服务时捕获异常，完全感觉不到“分布式”的存在，如同典型的“本地”操作一般。为了实现这样的效果，WCF在内部为我们作了很多。 消息交换是WCF进行通信的唯一手段，消息不仅仅是正常服务调用请求和回复的载体，服务端抛出的异常，甚至是服务的元数据都是通过消息的形式传向客户端的。所以，实现异常与消息之间的转换是整个异常处理体系的核心，而WCF的异常处理框架就着
最近为公司完成了一个 ESB 的设计。下面简要说明一下具体的设计方案。 企业 SOA 整体方案 在前一篇《SOA、ESB、NServiceBus、云计算 总结》中说到，SOA 是面向服务的架构，其核心思想是把业务进行组件化，而业务组件的能力服务化。 我们的整个 SOA 的设计分为两个层面：一个是系统间的 SOA 设计，另一个则是单个系统内的 SOA 设计。系统间的 SOA 设计，主要是设计一个 ESB 系统来实现各业务系统间的交互。而系统内部的 SOA 设计，则是建立一个组件化的技术平台，使得系统的开发能以
SOAP、WSDL、XML Schema 已经可以完成点到点的调用，但点到点的调用不能完全发挥面向服务的特点
第1章 WCF简介 (WCF Overview) 1.1 SOA基本概念的和设计思想 1.2 WCF是对现有Windows平台下分布式通信技术的整合 1.3 构建一个简单的WCF应用 步骤一：构建整个解决方案 步骤二：创建服务契约 步骤三：创建服务 步骤四：通过自我寄宿的方式寄宿服务 步骤五：创建客户端调用服务 步骤
引言 重要的应用程序很少是单独存在的；如果不能与其他的应用程序一起使用，应用程序将难以发挥很大的作用。面向服务的体系结构往往将应用程序集成在一起，这样它们就可以协同工作并提高工作效率，每个应用程序都分成必须相互集成的各个部分。SOA 模型——服务使用者调用服务提供者——可能看起来相当简单，但是它提出了两个重要的问题： 使用者如何找到它需要调用的服务的提供者 使用者如何快速而可靠地调用服务，而网络实际上很慢且不可靠？ 对于这两个问题，有一个相当简单的答案，即采用称为企业服务总线 (ESB) 的方法。ESB 处
通过《如何将一个服务发布成WSDL[编程篇]》的介绍我们知道了如何可以通过编程或者配置的方式将ServiceMetadataBehavior这样一个服务形式应用到相应的服务上面，从而实现基于HTTP-GET或者WS-MEX的元数据发布机制。那么在WCF内部具体的实现原理又是怎样的呢？相信很多人对此都心存好奇，本篇文章的内容将围绕着这个主题展开。 一、 从WCF分发体系谈起 如果读者想对WCF内部的元数据发布机制的实现原理有一个全面而深入的了解，必须对WCF服务端的分发体系有一个清晰的认识。在这里我们先对
第1章 异常处理 （Exception Handling） 1.1. WCF基本异常处理模式 1.1.1. 当异常从服务端抛出（S101） 1.1.2. 异常细节的传播（S102） 1.1.3. 自定义异常信息 1.2. 错误消息与FaultException异常 1.2.1. 从SOAP Fault说起 1.2.2. 唯一可被传播的异常：FaultException 1.2.3. FaultException异常和错误消息之间的转换 1.3. WCF异常处理体系剖析 1.3.1. FaultFormatt
毕业了，一直更新技术博客，也跳槽到一家上市的公司，他们产品的主要通讯是通过Webservice,以前对Webservice 只是做了大致的了解，今天就在网上找一些开源的知识点，现在市面上主流的夸平台传送有JSON和SOAP两种数据格式，总结一下。以下转自至 http://yulimin.iteye.com/blog/128498
这部分将介绍一些相对深入的知识点，包括通过并发限流来保证服务的可用性，通过可靠会话机制保证会话信息的可靠性，通过队列服务来解耦客户端和服务端，提高系统的可服务数量并可以起到削峰的作用，最后还会对之前的
02 微服务架构设计 微服务架构设计 以业务为中心 高内聚低耦合 高度自治 弹性设计 日志与监控 自动化 03 实时消息推送技术演进 实时消息推送技术演进 接入层负载均衡基于http七层负载均衡，从HA演进到Nginx HA支持TCP与Http协议，支持8种负载均衡策略，支持通过URL健康检测，支持心跳检测，工作在网络4层和7层,但对ws协议支持不好，造成ws消息堆积 Nginx支持Http协议，工作在网络7层，支持WebSocket协议，支持通过端口健康检测，支持强大的正则匹配规则 Nginx分流： se
在完成了对于WCF事务编程（《上篇》、《中篇》、《下篇》）的介绍后，本篇文章将提供一个完整的分布式事务的WCF服务应用，通过本例，读者不仅仅会了解到如何编程实现事务型服务，还会获得其他相关的知识，比如DTC和AS-AT的配置等。本例还是沿用贯通本章的应用场景：银行转帐。我们将会创建一个BankingService服务，并将其中的转帐操作定义成事务型操作。我们先从物理部署的角度来了解一下BankingService服务，以及需要实现怎样的分布式事务。 一、从部署的角度看分布式事务 既然是实现分布式事务，那
要让作为服务消费者的客户端能够动态地发现可用的服务，首先的要求服务本身具有可被发现的特性。那么到底一个可被发现的服务和一个一般的服务有何不同呢？或者说如何让一个一般的服务在寄宿的时候能够被它潜在的消费者“探测”到呢？ 我们知道，WCF本质上就是消息交换的通信框架。不论是针对普通的服务操作的调用，还是定义在WS-Discovery中的服务的探测（Probe/PM）和解析（Resolve/RM），本质上都是一种消息的交换。它们并没有本质的不同，或者说唯一不同的就是消息的内容，前者是基于某个服务操作的请求和回复，
[续《上篇》]通过将TransactionFlowAttribute特性应用在服务契约的某个操作之上，并指定相应的TransactionFlowOption枚举直，仅仅定义了事务流转的策略而已。或者说，通过这种方式确定对事物流转的一种意愿，客户端是否愿意将当前事务流出，服务端是否愿意接受流入的事务，可以通过TransactionFlowAttribute特性进行控制。所以说，服务操作上定义个TransactionFlowAttribute特性是是否进行事务流转的总开关，真正的事务传播是建立在Transact
本篇主要介绍了 Quarkus 中的远程调用，项目的结构采用了传统的微服务模式。演示了如何编写符合 istio 的 Quarkus java 程序。
最近做项目时遇到了需要多用户之间通信的问题，涉及到了WebSocket握手请求，以及集群中WebSocket Session共享的问题。
面向服务的体系结构（SOA）引入了一种设计范式，该技术讨论了高度分离的服务部署，其中服务间通过标准化的消息格式在网络上通信，而不关心服务的实现技术和实现方式。每个服务都有一个明确的，公开的服务描述或服务接口。实际上，消息格式是通过SOAP进行标准化的，SOAP是2000年初由W3C引入的标准，它也基于XML--服务描述通过WSDL标准化，另一个W3C标准和服务发现通过UDDI标准化--另一个W3C标准。所有这些都是基于SOAP的Web服务的基础，进一步说，Web服务成为SOA的代名词 - 并导致其失去作为一种架构模式的本义。SOA的基本原则开始淡化。WS- *栈（WS-Security，WS-Policy，WS-Security Policy，WS-Trust，WS-Federation，WS-Secure Conversation，WS-Reliable Messaging，WS-Atomic Transactions，WS-BPEL等）通过OASIS，进一步使SOA足够复杂，以至于普通开发人员会发现很难消化。
SOA SOA 是通过功能组件化、服务化，来实现系统集成、解决信息孤岛，这是其主要目标。而更进一步则是实现更快响应业务的变化、更快推出新的应用系统。与此同时，SOA 还实现了整合资源，资源复用。 SO
什么是rpc？ rpc（Remote Procedure Call）封装了内部实现的远程调用过程就是rpc，rpc主要为了简化远程服务调用。java体系的rpc，除了dubbo，集java大成者spring还默认提供了如下等Rpc组件支持。本项目就是这些Rpc组件的接入使用示例，基础环境使用spring boot2.x版本
当应用了ServiceDiscoveryBehavior行为的服务通过标准终结点DiscoveryEndpoint被发布出来之后（《[WCF-Discovery]服务如何能被”发现”》），客户端就可以按照WS-Discovery中定义的方式对可用的目标方式进行探测和解析了。由于这个过程本质上就是一次普通的服务调用，具体来说是针对发布发现服务（非目标服务）的标准终结点DiscoveryEndpoint的调用，所以客户端也需要具有这么一个匹配的终结点。 目录： 一、DiscoveryClient
来源 | blog.csdn.net/weixin_34194702/article/details/88701309
最近做项目时遇到了需要多用户之间通信的问题，涉及到了WebSocket握手请求，以及集群中WebSocket Session共享的问题。 期间我经过了几天的研究，总结出了几个实现分布式WebSocket集群的办法，从zuul到spring cloud gateway的不同尝试，总结出了这篇文章，希望能帮助到某些人，并且能一起分享这方面的想法与研究。 以下是我的场景描述 资源：4台服务器。其中只有一台服务器具备ssl认证域名，一台redis+mysql服务器，两台应用服务器（集群） 应用发布限制条件：由于场景
SOA 是概念层级的架构模型，需要使用其他技术来具体实现 SOA 模型，比如 Web Service（主流方式）、组件服务、REST 服务等。
上面的内容大部分是围绕着Ad-Hoc模式展开介绍的。Managed模式和Ad-Hoc不同之处在于可用服务的终结点通过发现代理来统一管理。客户端在进行可用目标服务探测和解析的时候不再需要发送广播请求，而是直接向发现代理进行探测和解析请求就可以了。[源代码从这里下载] 目录 一、发现代理与Managed发现模式 二、通过继承DiscoveryProxy创建发现代理 三、实例演示：自定义发现代理服务 步骤一、创建自定义发现代理服务 步骤二
代码演示 1.Websocket Server 建立userid和session的绑定关系 @ServerEndpoint("/websocket/{businessType}/{userId}") @Component public class WebSocketServer { /** * 若要实现服务端与单一客户端通信的话，可以使用Map来存放，其中Key可以为用户标识 * 注意：allSession 只记录当前机器的 客户端连接，不是所有session连接 */ public static ConcurrentHashMap<String, Session> allSession = new ConcurrentHashMap<>(); @Resource private RedisService redisService; /** * 连接建立成功调用的方法 * * @param session 可选的参数。session为与某个客户端的连接会话，需要通过它来给客户端发送数据 */ @OnOpen public void onOpen(@PathParam(value = "businessType") String businessType, @PathParam(value = "userId") String userId, Session session, EndpointConfig config) { if (StringUtils.isEmpty(userId)) { return; } /** * 加入到本地map */ allSession.put(userId, session); } /** * 连接关闭调用的方法 */ @OnClose public void onClose(@PathParam(value = "userId") String userId, Session session) { if (StringUtils.isNotEmpty(userId)) { allSession.remove(userId); } } /** * 发生错误时调用 * * @param * @param */ @OnError public void onError(@PathParam(value = "userId") String userId, Session session, Throwable error) { } /** * 用户id * * @param userId * @param message */ public void sendMessageToOneUser(Integer userId, String message, String msgId) { if (userId == null) { return; } Session session = allSession.get(String.valueOf(userId)); if (session != null) { //所有Websocket Server 根据客户端userid找到对应session， 只有存在userid和session的绑定关系的Websocket Server才发送消息到客户端 session.getAsyncRemote().sendText(message); } else { System.err.println("session为空"); allSession.remove(userId + ""); } } } 2.所有Websocket Server 接收消息并处理 @Component @RequiredArgsConstructor public class CreateOrderConsumer implements BaseConsumer { private final WebSocketServer webSo
最近在ESB项目中，客户在各个系统之间的服务调用大多都是在oracle存储过程中进行的，本文就oracle存储过程调用web service来进行说明。其他主流数据库，比如mysql和sql service，调用web service的方法这里就不做介绍了，本文主要用来介绍oracle存储过程调用Web Service的方法。
在上一篇文章中，我们介绍了 ROS 的概况，希望你的安装已经完成了。在本文中，我们将介绍 ROS 的一些核心概念，熟悉所谓的行话。其目的是做一个简短的概念介绍，这些概念你可能会在浏览 ROS 教程或其他地方遇到。如果你按教程安装和配置，那么文件系统中应该有一个名为 catkin_ws 的目录（这取决于你如何设置配置文件）。那么，这个目录是什么，为什么它很重要呢？
一、 信道层与服务模型层(Channel Layer and Service Mode Layer) 对于一个分布式应用的开发与设计来说，通信问题是不得不考虑，同时也是最为复杂、最难实现的问题。在过去的若干年中, 微软先后推出了一系列广受欢迎的通信技术, 比如DCOM、Enterprise Service、.NET Remoting、XML Web Service、MSMQ等等。这些技术提供了各自的编程模型，是开发人员从繁琐的完全基于通信的编程中解脱出来，使之仅仅需要关注具体的业务逻辑。WCF是所有的这些通
WCF采用消息作为通信的唯一手段，它支持不同的消息交换模式（MEP：Message Exchange Pattern），比较典型的有以下三种MEP：One-Way、Request/Reply和Duplex。消息会被WCF的信道层发送到传输层，并通过相应的传输协议发送到目的地。对于TCP协议来说，其本身就能提供一个双工通道，所以能够对以上三种MEP原生的支持。而HTTP协议，大家都知道它天生就基于Request/Reply模式的，那么它是如何能够突破自己的局限，为One-Way和Duplex消息交换模式提供支
默认情况下，需要用户身份验证以防止匿名用户浏览和分析您实例上的项目，所以运行分析时需要传递这些参数。身份验证在全局安全 (/instance-administration/security/) 配置中强制执行。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
云直播
