soa | 易学教程

关于SOA/CBD/AOP/OO的体会

阅读更多关于关于SOA/CBD/AOP/OO的体会

出差途中看了几篇AOP的文章，总算对AOP有了一个初步的了解，是一个非常不错的技术，传统编程技术无法解决的横切(CrossCutting)问题在AOP中可以得到很好的解决。简单比较一下现有的几种技术SOA/CBD/AOP/OO。 SOA - Service Oriented Architecture (面向服务的架构) CBD - Component Based Development (基于构件的开发) AOP - Aspect Oriented Porgramming (面向方面的编程) OO - Object Oriented (Analysis / Design / Programming) (面向对象的分析/设计/编程) 这几种技术本质上体现的都是我们过去几十年软件开发的最佳实践经验。 1) 模块化 - 把复杂的系统(或问题)分而治之，内聚程度比较高的内容组合在一起形成模块，整个系统就是由一系列大大小小的模块所组成。跟复杂的系统相比，单个模块的粒度要小得多，便于管理和开发。这几种技术中，构件(Component)、服务(Service)就是一种对象(Object)，它们的模块化概念比较一致；AOP则是解决系统中的横切问题，把横切相关的解决方案模块化在一个方面(Aspect)中。 2) 抽象 - 这几种技术都是针对某一类具有普遍性的问题提出一个通用的解决方案

WSO2 governance registry and enterprise service bus (ESB) can be integrated?

阅读更多关于 WSO2 governance registry and enterprise service bus (ESB) can be integrated?

We use WSO2 tools for our SOA. We are examining the possibility of use of Registry Governance to manage the services available. I wonder if someone has already done the integration of Registry Governance and ESB, so that services are built on only one tool to another and replicated. Please have a look at [1] and [2] [1] http://wso2.org/project/esb/java/4.0.3/docs/deployment_guide.html [2] http://charithaka.blogspot.com/2011/11/wso2-deployment-synchronizer-sharing.html 来源： https://stackoverflow.com/questions/9619425/wso2-governance-registry-and-enterprise-service-bus-esb-can-be-integrated

微服务、SOA 和 API对比与分析

阅读更多关于微服务、SOA 和 API对比与分析

#0 系列目录# 聊聊服务架构深入浅出SOA思想微服务、SOA 和 API对比与分析 #1 简介# 在对比微服务架构和面向服务的架构（SOA）时，几乎不可能在它们彼此的关系上达成一致意见。如果应用程序编程接口（API）再加入混战，就会让理解它们的差异变得更加困难。一些人可能会说这些概念完全不同，它们各自解决自己的一组问题，而且拥有独特的应用范围。其他人可能更宽厚，认为它们实现了类似的目标，并且具有相同的工作原理。他们可能还会说微服务架构是一种 “细粒度的 SOA” 或 “SOA 的恰当应用”。 #2 一种过于简单的观点# 难以对比 SOA 和微服务的原因在于，它们的定义留有很大的解释空间。如果您仅拥有这两个概念的表面知识，可能会觉得它们很相似。一些关键方面（比如组件化、解耦和标准化通信协议）描述了最近几十年的大部分软件举措，所以我们需要进行更深入地分析。考虑以下简单定义：微服务架构是一种构造应用程序的替代性方法。应用程序被分解为更小、完全独立的组件，这使得它们拥有更高的敏捷性、可伸缩性和可用性。 SOA将应用程序的功能公开为更容易访问的服务接口，使得在下一代应用程序中使用它们的数据和逻辑变得更容易。如下图演示了这些定义。SOA 似乎拥有企业范围，应用程序在该范围内彼此通信。 SOA 通过应用程序之间的标准化接口来公开服务。微服务架构似乎拥有应用程序范围

Product Versioning Microservices

阅读更多关于 Product Versioning Microservices

问题 I go into microservices architecture based on docker and I have 3 microservices, which together create one product for example "CRM system". Now I want my client to be able to upgrade his product, whenever he wants to. I have 3 different versions of my microservices, which one should client see? I guess product version should be independent of microservices, because copying one of the microservices version would make me go into more trouble than having no version at all. So is there any

How should an ESB be packaged/deployed?

阅读更多关于 How should an ESB be packaged/deployed?

问题 I am trying to wrap my head around Apache Camel, which appears to be a lightweight ESB. If I understand Camel/ESBs correctly, then you can think of a Camel Route as a graph of nodes and edges. Each node is an endpoint on the route (can consume/produce messages). Each edge is a route between two different endpoints (1 producer and 1 consumer). Assuming that's correct, I have a practical question: what do best practices dictate about deploying your application's ESB/Camel Route? Should I

Transactions in microservices

阅读更多关于 Transactions in microservices

问题 I have read some articles about microservices architecture, but no one takes the topic of transaction. All that they says that this is hard to do it. Maybe someone can describe how to handle this? But not from domain side, but from technology side. Lets say that we have business case where we need to invoke two different services and both of them make some changes on database. But how to rollback if some error occurs on the second one? Who knows some libraries or design patter for this

SOA and WCF design questions: Is this an unusual system design?

阅读更多关于 SOA and WCF design questions: Is this an unusual system design?

I have found myself responsible for carrying on the development of a system which I did not originally design and can't ask the original designers why certain design decisions were taken, as they are no longer here. I am a junior developer on design issues so didn't really know what to ask when I started on the project which was my first SOA / WCF project. The system has 7 WCF services, will grow to 9, each self-hosted in a seperate console app/windows service. All of them are single instance and single threaded. All services have the same OperationContract: they expose a Register() and Send()

Transaction in SOA

阅读更多关于 Transaction in SOA

问题 Is there any possibility to propagate transactions between different SOA services which are from different platforms like .NET or Java? I know the transaction can flow in and out between WCF services which is coming from .NET. But I am not familiar with Java platform. Now I am working in a project which communicates the services from different platform. How can I maintain consistency in business? 回答1: If your client and server SOA infrastructure (and by extension, the underlying back-end

Integration between various Domain Driven Design systems

阅读更多关于 Integration between various Domain Driven Design systems

问题 I have recently been adopting Domain Driven Design principles, but I'm having a bit of trouble implementing Bounded Contexts and the integration between the contexts and/or other systems. For example, take the following systems: Warehouse/Stock Keeping System Entities would include 'Product' which would have properties such as 'Quantity', 'Location' Online Ordering System Entities would include 'Order', 'OrderLine', and 'Basket'. Would it also have its own Product entity which would have

微服务简单说

阅读更多关于微服务简单说

微服务简单说 1 微服务架构定义微服务一词源自马丁·福勒（Martin Fowler) 在2014 年的一篇博客： Microservices 该文章中对微服务定义如下： the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage