Mule ESB WebService Consumer 结合 DataMapper的使用

合集下载

微服务治理框架的技术选型

微服务治理框架的技术选型目录微服务治理框架的技术选型 (1)1 RPC (3)2 服务化 (4)3 微服务 (6)SOA服务化和微服务架构已经发展多年，市场上已经有很多成熟的商业和开源产品，我们没有必要从头搭建一套服务化管理和治理平台，完全可以基于开源服务化框架进行定制化，以适应我们的业务需要。

本文介绍各种流行的RPC框架、服务化管理和治理、微服务框架，并通过讲解其特点来帮助我们做技术选型。

1 RPC本节介绍简单的远程服务调用的技术栈。

1. JDKRMI自JDK1.4开始，JDK内置了远程服务调用的技术栈，可以帮助开发者创建基于Java到Java的分布式调用架构，一个Java进程内的服务可以调用其他Java进程内的服务，使用JDK内置的序列化和反序列化协议。

RMI是JEE规范中EJB远程调用的基础，然而，JDK内置的RMI服务并没有得到广泛应用，几乎没有哪家公司采用这种方式来构建服务化平台。

原因如下。

l RMI采用JDK自带的专用序列化协议，不能跨语言。

l使用了底层的网络协议，不如基于文本的HTTP可读，也不如HTTP被广泛认可和应用。

l开源框架的飞速发展，严重削弱了JDK资深技术的流行程度。

2.Hessian及BurlapHessian及Burlap都是Caucho公司提供的开源的远程调用协议，基于HTTP传输，防火墙通常会设置在某个端口上以允许特定的HTTP通信。

其中，Hessian将对象序列化成与语言无关的二进制协议；而Burlap将对象序列化成与语言无关的XML数据，数据是可读的。

两者都是与语言无关的，可以在多种语言的服务中互相调用。

Hessian及Burlap都适合传输较小的对象，对较大、复杂的对象，无论是在序列化方式上还是在传输通道上都没有RMI有优势。

由于服务化架构中大量的服务调用都是大规模、高并发的短小请求，因此，Hessian和Burlap协议在服务化架构中得到了广泛应用。

3. Spring HTTP InvokerSpring HTTP Invoker重用了JDK内置的对象序列化技术传输对象，这与RMI的原理一致，但是，它通过HTTP通道传输数据，在效率上应该略低于RMI，并且由于使用了JDK内置的序列化机制，因此也是不能跨语言的。

MuleESB简介

Mule ESBMule ESB简介什么是Mule ESB？Mule ESB是一种基于java的、轻量级的企业服务总线和集成平台，她允许开发者快速的、简单的连接应用，并能够实现数据的转换。

从2005年发表1.0版本以来，Mule吸引了越来越多的关注者，成为开源ESB中的一支独秀。

目前许多公司都使用了Mule，比如沃尔玛,惠普,索尼,Deutsche Bank 以及CitiBank 等公司。

Mule官方网站：/Mule ESB的主要功能如下：●服务的创建与管理（Service creation and hosting）：用Mule ESB作为一个轻量级的服务容器来暴露和管理可重用的服务。

●服务调解（Service mediation）：隐藏服务消息的格式和协议，将业务逻辑从消息中独立出来，并可以实现本地独立的服务调用。

●消息路由（Message routing）：基于内容和规则的消息路由、消息过滤、消息合并和消息的重新排序。

●数据转换（Data transformation）：在不同的格式和传输协议中进行转换数据。

Mule3Mule近期推出了Mule3，Mule3的新增特点-云连接（Cloud Connect）。

云连接提供了可以用简单安全的方式为企业提供基于云技术的数据和服务。

它的核心是IBeans，一个轻量级、可重用的接口，用于Web技术的连接扩展和数据服务。

Mule云包括以下内容1、Integration Beans （合成bean）：他们是可重用的云接口，可以注入到组件中，可以接受外部的服务，比如说亚马逊、推特、Facebook等，并且是一种简单的接收服务、管理安全机制的方法。

请求验证、数据传输、错误挂起等也可以通过这种方法来实现。

2、Rest / JAX-RS：（REST协议：即REST(Representational State Transfer表述性状态转移)是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。

ESB Mule 中间件技术

目前ESB与SOA的确切概念依然没有。但可以明确的说SOA就是一种服务集成思想，它的不同实现方式可能差别很大，目前SOA最常见的实现方式是SCA和 JBI。首先，ESB不是SOA。SOA的最常见的实现方式方式是SCA和JBI，而SCA的实现需要ESB，相反JBI则不需要ESB。其次，因为IBM和Oracle（收购了BEA和SUN的牛X 公司）都推崇SCA模式的SOA，因此SCA实际上已经成为SOA的事实标准，说道SOA，最先想到的就是 SCA模式了。最后，ESB是SCA架构实现不可缺少的一部分，ESB 产品脱离了具体的应用外，没有任何意义。ESB的作用在于实现服务间智能化集成与管理的中介。通过ESB可以访问所集成系统的所有已注册服务。
Enterprise Service Bus 技术介绍
刘刚 Peking University 2011-04-01
提纲
EAI、SOA与ESB
– – – – – – – – – 什么是EAI 什么是SOA EAI向ESB的发展 SOA与ESB的关系什么是ESB ESB功能模型 ESB最简功能定义 ESB常用技术与规范其它开源ESB实
4、服务质量
• 事务（原子事务、补偿、Web 服务事务（WS-Transaction）） • 各种确定的传递范例（例如 Web 服务可靠消息传递（WS-ReliableMessaging）或对 EAI 中间件的支持）
5、安全性
• • • • • 身份验证授权不可抵赖性机密性安全标准（例如 Kerberos 和 Web 服务安全性（WS-Security））
6、服务级别
• • • • 性能吞吐量可用性其他可以构成契约或协定的持久评估方法

基于mule的ESB解决方案

EIP经典案例Load Broker——Mule ESB实践author:mythmoon@Version 0.1(draft)转载保留出处读者背景:具有2年以上J2EE开发背景,熟悉Spring,Hibernate,Jbpm,Axis,Tuscany,Mule 等框架,对EJB,Jms,soap,ws-*,BPM,SCA\SDO等技术规范,对ESB,SOA,通讯网关有一定了解,同时对底层Socket通讯协议HTTP,FTP等也有一定了解.当然对主流数据库也要熟悉,在示例中,使用DB2 V8.1Load Broker案例背景Obtaining a Loan QuoteWhen shopping for a loan, a customer usually calls several banks to find the deal with the best possible interest rate. Each bank asks the customer for his or her social security number, the amount of the loan, and the desired term (i.e., the number of months until the loan has to be paid off). Each bank then investigates the customer's credit background, usually by contacting a credit agency. Based on the requested terms and the customer's credit history, the bank responds with an interest rate quote to the consumer (or declines thankfully). Once the customer has received quotes from all banks, he or she can then select the best offer with the lowest interest rate.A Consumer Talking to Banks to Get a Loan QuoteFigure I-1Because contacting multiple banks with a loan quote request is a tedious task, loan brokers offer this service to consumers. A loan broker is typically not affiliated with any one bank but has access to many lending institutions. The broker gathers the customer data once and contacts the credit agency to obtain the customer's credit history. Based on the credit score and history, the broker presents the request to a number of banks that are best suited to meet the customer's criteria. The broker gathers the resulting quotes from the banks and selects the best offer to pass back to the consumer.A Loan Broker Acting as IntermediaryFigure I-2Load Broker 分析设计Designing the Message FlowWe want to design a loan broker system using integration patterns discussed in the previous chapters. To do this, let's first list the individual tasks that the loan broker needs to perform.1.Receive the consumer's loan quote request.2.Obtain credit score and history from credit agency.3.Determine the most appropriate banks to contact.4.Send a request to each selected bank.5.Collect responses from each selected bank.6.Determine the best response.7.Pass the result back to the consumer.Let's see which patterns could help us design and implement the loan broker. The first step describes how the broker receives the incoming request. "Messaging Endpoints," so for now, let's skip over this step and assume the message is somehow received by the load broker. Next, the broker has to retrieve some additional information: the customer's credit score. A Content Enricher sounds like the ideal choice for this task. Once the broker has the complete information, the broker must determine the appropriate banks to route the request message to. We can accomplish this with another Content Enricher that computes the list of recipients for the request. Sending a request message to multiple recipients and recombining the responses back into a single message is the specialty of the Scatter-Gather. The Scatter-Gather can use a Publish-Subscribe Channel or a Recipient List to send the request to the banks. Once the banks reply with their rate quotes, the Scatter-Gather aggregates the individual rate quotes into a single quote for the consumer using an Aggregator. If we model the message flow using these patterns, we arrive at the following design:Simple Loan Broker DesignFigure I-3We have not yet accounted for the likely event that each bank may use a slightly different message format for the loan request and response. Because we want to separate the routing and aggregation logic from the banks' proprietary formats, we need to insert Message Translators into the communication lines between the broker and the banks. We can use a Normalizer to translate the individual responses into a common format:Complete Loan Broker DesignFigure I-4扩展:核心技术与实现方案Sequencing: Synchronous versus AsynchronousSo far, we have described the flow of the messages and the routing and transformation patterns we can use to describe the design of the loan broker component. We have not yet discussed the timing of the broker operation. We have two primary choices:∙Synchronous (Sequential): The broker asks one bank for the quote and waits for a response before contacting the next bank.∙Asynchronous (Parallel): The broker sends all quote requests at once and waits for the answers to come back.We can use UML sequence diagrams to illustrate the two options. The synchronous option implies a sequential processing of all loan requests (see the following figure). This solution has the advantage of being simpler to manage because we do not have to deal with any concurrency issues or threads. However, it is an inefficient solution because we do not take advantage of the fact that each bank possesses independent processing power and could be executing requests simultaneously. As a result, the consumer might have to wait a long time for an answer.Synchronous, Sequential Processing of Loan RequestsFigure I-5The asynchronous solution issues all requests right away so that each bank can start processing. As the banks finish the computation, they return the results to the loan broker. This solution allows for a much quicker response. For example, if all banks take a similar amount of time to produce a loan quote, this solution is almost n times faster, where n is the number of banks we are dealing with. The loan broker now must be able to accept the loan quote reply messages in any order, because there is no guarantee that responses arrive in the same order that requests were made. The following sequence diagram illustrates this option. The open arrowhead on a loan quote request indicates an asynchronous invocation.Asynchronous, Parallel Processing of Loan RequestsFigure I-6Another significant advantage of using asynchronous invocation via a message queue is the ability to create more than one instance of a service provider. For example, if it turns out that the credit bureau is a bottleneck, we could decide to run two instances of that component. Because the loan broker sends the request message to a queue instead of directly to the credit bureau component, it does not matter which component instance processes the message as long as the response is put back onto the response channel.Addressing: Distribution versus AuctionUsing a Scatter-Gather to obtain the best quote allows us to choose from two addressing mechanisms, a Recipient List or a Publish-Subscribe Channel. The decision primarily depends on how much control we want to exert over the banks who are allowed to participate in a specific loan request. Again, we have a number of choices:∙Fixed: The list of banks is hard-coded. Each loan request goes to the same set of banks.∙Distribution: The broker maintains criteria on which banks are a good match for a specific request. For example, it would not senda quote request for a customer with a poor credit history to a bankthat specializes in premier customers.∙Auction: The broker broadcasts the request using aPublish-Subscribe Channel. Any bank that is interested is allowed to subscribe to the channel and "bid" on the request. Banks can subscribe or unsubscribe at will. Each bank can still apply its own criteria on whether to submit a bid.Figure I-7Which option is best for our scenario? As always, there is no simple "and the answer is...," but the choice is driven by both business and technical preferences and constraints. The first option is simple and gives thebroker control over the list of banks. However, if new banks come and go frequently, the solution can result in an administrative burden. Also, the bank may not be happy to be receiving a bunch of irrelevant requests, because each request incurs a certain internal cost for the bank. Also, to maintain the simplicity of this approach, the aggregation strategy is more likely to require all banks to submit a response. Banks may want to reserve the right to withhold from the bid.A distribution approach (using a Recipient List) gives the broker more control over which bank to involve in each loan request. This allows the broker to be more efficient by reducing the number of requests. It also allows the broker to prefer certain banks based on the business relationship. On the downside, it requires additional business logic to be implemented and maintained inside the loan broker component. Both the distribution and the fixed approach require a separate Message Channel for each participant in order to control the message flow.Using a Publish-Subscribe Channel broadcasts a loan request to all subscribing banks and lets each bank determine which requests to service. Each bank can use a Message Filter or implement a Selective Consumer to filter out undesirable loan requests. This approach renders the loan broker pretty much maintenance-free in cases of adding or removing banks, but it requires more work on the side of the banks. This solution requires only a single Message Channel , but it has to be implemented as a Publish-Subscribe Channel. Many efficient publish-subscribe schemes use IP Multicast that typically does not route across wide-area networks or the Internet. Other implementations emulate a Publish-Subscribe Channel by using an array of Point-to-Point Channels and a Recipient List. This approach preserves the simple semantics of a Publish-Subscribe Channel but is less efficient in its use of channels and network bandwidth. For additional trade-offs between routing and publish-subscribe plus filtering, see the description of the Message Filter.Aggregating Strategies: Multiple Channels versus Single ChannelWhen receiving loan quotes from the bank, we have similar design choices. We can have all banks submit their responses to a single response channel, or we can have a separate response channel for each bank. Using a single channel reduces the maintenance burden of setting up a separate channel for each participating bank but requires each bank's reply message to include a field identifying the bank who issued the quote. If we use a single response channel, the Aggregator may not know how many responsemessages to expect unless the Recipient List passes this information to the Aggregator (we call this an initialized Aggregator). If we use an auction-style Publish-Subscribe Channel , the number of possible responses is unknown to the loan broker, so the Aggregator has to employ a completeness condition that does not depend on the total number of participants. For example, the Aggregator could simply wait until it has a minimum of three responses. But even that would be risky if temporarily only two banks participate. In that case, the Aggregator could time out and report that it received an insufficient number of responses.Managing ConcurrencyA service such as a loan broker should be able to deal with multiple clients wanting to use the service concurrently. For example, if we expose the loan broker function as a Web service or connect it to a public Web site, we do not really have any control over the number of clients and we may receive hundreds or thousands of concurrent requests. We can enable the loan broker to process multiple concurrent requests using two different strategies:∙Execute multiple instances.∙ A single event-driven instance.The first option maintains multiple parallel instances of the loan broker component. We can either start a new instance for each incoming request or maintain a "pool" of active loan broker processes and assign incoming requests to the next available process (using a Message Dispatcher). If no process is available, we would queue up the requests until a process becomes available. A process pool has the advantage that we can allocate system resources in a predictable way. For example, we can decide to execute a maximum of 20 loan broker instances. In contrast, if we started a new process for each request, we could quickly choke the machine if a spike of concurrent requests arrives. Also, maintaining a pool of running processes allows us to reuse an existing process for multiple requests, saving time for process instantiation and initialization.Because much of the processing required by the loan broker is to wait for replies from external parties (the credit bureau and the banks), running many parallel processes may not be a good use of system resources. Instead, we can run a single process instance that reacts to incoming message events as they arrive. Processing an individual message (e.g., a bank quote) is a relatively simple task, so that a single process may be able to service many concurrent requests. This approach uses system resources more efficiently and simplifies management of the solution, since we have tomonitor only a single process instance. The potential downside is the limited scalability because we are tied to one process. Many high-volume applications use a combination of the two techniques, executing multiple parallel processes, each of which can handle multiple requests concurrently.Executing multiple concurrent requests requires us to associate each message in the system to the correct process instance. For example, it may be most convenient for a bank to send all reply messages to a fixed channel. This means that the reply channel can contain messages related to different customers' concurrent quote requests. Therefore, we need to equip each message with a Correlation Identifier to identify which customer request the bank is responding to.Three ImplementationsIn order to implement the loan broker example, we have three main design decisions to make: We have to select a sequencing scheme for the requests, select an addressing scheme for the banks, and define an aggregation strategy. In addition, we have to select a programming language and a messaging infrastructure. In aggregate, these individual options result in a large number of potential implementation choices. We chose to implement three representative solutions to highlight the main trade-offs between the different implementation options. As with all examples in this book, the choice of specific technologies is somewhat arbitrary and does not indicate the superiority of a specific vendor's technology. The following table highlights the characteristics of each solution:Table I-1The first implementation uses synchronous Web services implemented in Java and Apache Axis. The communication with each bank occurs over a separate HTTP channel, which serves as both a request and reply channel. Therefore, the aggregation strategy is based on individual reply channels and does not require correlation. The second implementation uses an asynchronous approach with message queues. We implement it using Microsoft's MSMQ, but an implementationusing JMS or IBM WebSphere MQ could look very similar. The last implementation uses an Auction approach and leverages TIBCO's publish-subscribe infrastructure and the TIB/IntegrationManager tool that implements the Process Manager pattern. In option B and C, all reply messages arrive on a single channel and the implementations use Correlation Identifiers to associate reply messages to customer loan quote inquiries.系统结构设计网络物理结构LoadBroker 包括web主机,ESB主机,流程主机运行在内网中。

ESB的开源框架Mule介绍

2013-8-14
3
ESB实现功能
• 传输器，转换器，路由器三者是ESB的公共核心功能。 • 还包括事务、安全、异常管理、JMX管理架构、服务质量保证、定义和发现已部署服务等。
2013-8-14
4
开源ESB框架
有三种比较流行的ESB开源框架，分别是 OpenESB ServiceMix Mule
2013-8-14
8
二 Mule介绍
• • • • Mule框架简介 Mule框架作用和强项 Mule框架构成 Mule与SOF框架关系
2013-8-14
9
Mule介绍
Mule 是一个基于ESB架构理念的消息平台。是开放源码界最早成立的ESB项目之一。其实现思想是不用更改既有系统，直接透过组态设定，就可连接各服务端点。 Mule将POJO对象包装成UMO对象，再提供简单和一致的接口供外界访问，而访问者不需要关心实现的细节。
11
Mule应用场景
2013-8-14
12
Mule总体框架
2013-8-14
13
Mule Manager
• Mule Manager是Mule server 实例的中心 (也称为一个Mule Node)。其主要的角色是管理各种对象，比如Mule实例的连接器、端点和转换器。这些对象然后被用来控制进出服务组件的消息流，并且为 Model和它所管理的组件提供服务。
2013-8-14
5
OpenESB
OpenESB项目实现了一个运行期企业服务总线(Enterprise Service Bus:ESB)使用 JBI(Java业务集成)作为核心基础。 OpenESB可以让你集成企业应用与Web Service松散地连接成复合的应用程序。这使得你可以无缝地组合与拆解该复合应用程序，并认识到一个真正面向服务架构(SOA)的优点

Mule ESB使用手册

Mule ESB Studio v3.3 安装使用手册1***初级教程***如果你还没有做好准备，请到下载免费的社区版Mule ESB，按照网站上的说明启动Mule Studio，并且选择一个工作区（另外，你还可以下载30天免费试用的企业版Mule ESB）2安装Mule Studio安装前，请确认你的机器上已经安装了1.6版本的JDK。

最后请确认你的JDK环境变量配置是否正确2.1 导出将下载的文件解压到你的硬盘分区的根目录下，例如：C:\1. 执行找到C:\MuleStudio目录，运行muleStudio.exe启动Studio2. 选择工作区点击OK使用默认的工作区3使用Studio模板1. 点击File菜单，选择New > Mule Project2. 出现New Mule Project面板后，为你的项目输入名称和一个简短的说明，如图：3. 在Server Runtime选项上选择你将要使用的Mule运行时版本，如图：4. 点击旁边的复选框，根据现有的模板创建项目，单击项目，选择你想要使用的模板创建项目，如图：5. 点击Finish按钮，Mule Studio会创建并打开一个新的项目，完成预创建和预配置的流程6. 在Mule Studio的Package Explorer栏中，右键点击mule-config.mflow文件，选择RunAs > Mule Application7. 停止运行该项目，请在Mule Studio控制台点击红色的Terminate按钮，如图：4运行独立的例子1. 到Mule ESB Standalone目录下，找到Examples目录下你想运行的例子2. 拷贝.zip文件的例子到$MULE_HOME/apps目录下，例如：运行Flight Reservationexample的例子，拷贝mule-example-flight-reservation-3.3.0.zip到$MULE_HOME/apps 目录下，如图：3. 启动Mule，运行这个例子5启动Mule Studio如果你在安装过程中启动了Mule Studio，并且已经在运行了，请跳过本节的其余部分，直接进行：创建新项目如果当前Mule Studio没有启动，通过完成下面的步骤启动应用程序1. 找到Mule Studio安装目录2. 执行muleStudio.exe3. 点击OK使用默认的工作区6创建新项目1. 如果你看到是各种控制组件的应用程序窗口（右下图），请直接进入第2节。

mule——精选推荐

muleMule⼊门⽂档零、前提在按照本⽂进⾏操作之前，假设您的系统已经具备以下前提：已经安装了Sun公司的JDK1.4或JDK5.0版本，推荐使⽤JDK5.0。

正确设置了JAVA_HOME环境变量到JDK⽬录（注意不是JRE⽬录）。

确保%JAVA_HOME%\bin路径在系统寻找路径中。

安装有Eclipse3.2或以上版本的开发环境。

安装有Apache Tomcat 5.0或以上版本，推荐使⽤5.5。

⽂档假设Tomcat的安装⽬录为%TOMCAT_HOME%。

⼀、下载与安装到Mule的官⽅⽹站（/doc/ce7750612.html/display/MULE/Download）上下载Mule 的最新稳定版，⽬前是1.3.3（/doc/ce7750612.html/ccount/click.php?id=17），也可以使⽤社区版的1.4.1（/doc/ce7750612.html/ccount/click.php?id=33）。

本⽂档以1.3.3版为例，1.4.1请参照⽂档⾃⾏修改。

下载后得到⼀个ZIP格式的压缩⽂件mule-1.3.3.zip，将该⽂件解压⾄任⼀⽬录，假设为C:\mule-1.3.3，本⽂档以环境变量MULE_HOME表⽰该⽬录。

⼆、运⾏Echo⽰例Mule⾃带了很多⽰例，从最简单的echo⽰例到⼀个⽐较完整的贷款中介服务loanbroker。

每个⽰例程序都分为ant和maven两个版本，它们分别位于%MULE_HOME%\examples\ant和%MULE_HOME%\examples\maven⽬录下。

⽂档将以ant版本为例说明如何运⾏echo⽰例。

1、到apache官⽅⽹站的ant项⽬下载页（/doc/ce7750612.html/bindownload.cgi）上下载ant1.7.0（/doc/ce7750612.html/ant/binaries/apache-ant-1.7.0-bin.zip），下载后将⽂件解压到任⼀⽬录（假设为C:\apache-ant-1.7.0，⽂档中表⽰为ANT_HOME环境变量）。

Mule简介

Mule简介Mule是什么？Mule是⼀个轻量级的基于Java的ESB消息框架，它允许⽤户快捷地连接多个应⽤并且在这些应⽤之间交换数据。

Mule使⽤了SOA的体系结构思想，可以⽅便的集成已有的应⽤。

它是可升级的、⾼分布式的对象代理，可以通过异步传输消息技术来⽆缝的处理服务与应⽤之间的交互。

Mule框架提供了⼀个可升级的环境，可以把⾃⼰的业务组件部署在⾥⾯。

Mule管理所有组件之间的交互，不管它们是在同⼀个虚拟机中还是在internet上，也不管底层使⽤的传输⽅式。

Mule围绕着企业服务总线（ESB）架构进⾏设计，保证了不同的组件或者应⽤可以通过公共的消息总线进⾏交互，公共的消息总线⼀般是由JMS或者其他消息服务器来实现。

在应⽤中会使⽤不同的技术，包括JMS,Web Services，JDBC，HTTP等等，Mule可以很好地处理他们之间的交互。

Mule有以下的优点：(1)Mule组件可以是你需要的任何类型。

你可以很容易地集成⼀切从⼀个"plain old Java object"（POJO）到另⼀个框架的组件。

(2)Mule和ESB模型允许组件重⽤。

不像其他的框架，mule允许你使⽤⼀个已有的组件⽽不需要改变。

组件不需要任何特定的mule代码，并且没有要求的API。

业务逻辑和消息逻辑保持完全分离。

(3)消息可以是任何格式，从SOAP到⼆进制图像⽂件。

mule对体系结构不强制任何设计限制，⽐如XML消息或者WSDL服务。

(4)你可以以多种拓扑结构开发mule，不仅仅是ESB。

因为它是轻量级的和可嵌⼊的，mule可以有效地减少到市场的时间，并且增强项⽬参评，⽐如安全性，可扩展性。

mulesorce提供了管理⼯具运⾏管理你的开发(Mule HQ)和基础设施(Mule Galaxy)。

理解消息框架应⽤⽹络化的好处是使得⼀个应⽤能够发送数据到另⼀个应⽤。

但是许多应⽤不能够读取和处理另⼀个应⽤的数据。

ESB部署WebService接口

1 统一待办1.1 概述门户系统做为用户访问各集成应用系统的统一入口，用户访问企业内部信息资源时只需要登录到门户系统，就可使用门户系统集成的各个应用，而待办做为各系统中用户需要处理的工作，门户系统需要提供收集建投内部应用系统中产生的待办信息，并且进行统一展现的功能，即统一待办功能。

统一待办应用业务涉及到的系统其中包括本期门户系统建设过程中所需集成的OA、WCM、EAM系统。

为保证门户系统接入各应用系统待办信息的规范性，现就各应用系统接入实现做统一要求，以确保门户系统统一待办功能实现的规范性、重用性及安全性。

不满足本技术方案提供的接入规则的相关应用系统，应参考本文档完成对应用系统改造后方可进行门户系统统一待办接入工作。

统一待办实现共分为以下部分：➢系统待办信息获取➢系统待办信息展示➢系统待办信息处理1.2 待办信息获取设计思路：应用系统通过门户系统提供的webservice接口向门户系统统一待办系统库写入代表信息，如下图数据获取设计示意图步骤如下：1.应用系统需获得最新的待办信息。

2.应用系统通过门户接口，将获得的最新待办信息发送到门户系统。

3.统一待办系统将应用系统提供的待办信息展示给用户。

4.应用系统通过调用集成接口后获得信息，可以判断发送信息操作是否正常。

1.3 待办信息展示设计思路：应用系统将最新的待办信息发送到统一待办系统中，并最终展示到门户首页上的待办栏目上，如下图待办栏目页面待办集中展示设计示意图场景如下：在所有的待办类标题前加上”请办理”，待阅类标题前加上”请审阅”。

此外，如果信息是未办或者未阅，用红色表示1.4 待办信息处理设计思路：用户点击门户系统上“待办栏目”里的一条待办时，弹出一个新页面，首先同应用系统实现SSO ，然后跳转到应用系统的待办页面，完成待办处理后，由应用系统调用门户接口通知门户系统，并关闭弹出的待办处理页面，门户系统负责即时刷新门户待办页。

如下图：用户应用系统接口应用系统待办处理页面统一待办处理页面SSO 跳转处理完成后，门户统一系统刷新待办栏目统一待办数据库统一待办信息获取接口修改待办状态统一待办栏目点击待办时弹出统一待办系统应用系统待办信息集中处理设计示意图1.5 系统待办规范1.5.1 WebService服务端服务地址：http://域名:8080/jicpending/services/IPandingInterfaceWebservice?wsdl服务文件：服务方法：方法1.putPandingInfo：新待办方法2.changePangdingStatus：当OPTTYPE值为2时，则表示修改待办，当为3时，则表示删除待办方法3.仅供OA系统使用. putOaPandingInfo：新待办，方法4. 仅供OA系统使用changeOaPangdingStatus：当OPTTYPE值为2时，则表示修改待办，当为3时，则表示删除待办，仅供OA系统使用服务参数：具体定义如下表表描述11.5.2 新待办➢第一步：应用系统有新待办信息时，调用门户系统接口，将数据传送给门户系统提供的接口，流程如下：WebService接口图在此过程中，各个应用系统以传递对象的形式传递参数，提供的参数自身包括的值为以下表说明，另外，OA系统传递参数的时候不用传递对象，只要依次传入以下表说明即可。

Mule入门篇

2021/5/9
- 14
Mule配置文件
2021/5/9
- 15
Mule配置文件(2)
2021/5/9
- 16
FAQ
2021/5/9
- 17
结束
2021/5/9
- 18
● 服务端点 EndPoint
端点的功能相当于网关，或者说是连接服务组件到外部消息的通道，它可以位于本地也可以位于网络上，如图所示， Mule可以被配置为在端点上拦截消息，如果需要，然后将消息进行转换，转换后再传递给服务组件。
● 消息路由 Router
消息路由控制组件如何接收消息，以及在处理后应该发送到何处去，入站路由控制服务如何处理入站消息（如，有选择地允许那些符合特定标准的消息），出站路由控制服务处理完消息后该将其发往何处（如，将其发送到接收者的列表，或将消息拆分，然后发送到不同的端点），如图5所示。路由是和过滤器结合工作的，过滤器指定限制条件，只有符合条件的消息才能被路由到服务，并包括一个表达式从当前消息中提取信息。
● 面向服务
将系统进行功能化，每个功能提供一种服务。现在非常流行WebService技术以及SOA（面向服务架构）技术。
2021/5/9
-1
一、Mule 引言
SOA(Service-Oriented Architecture) 面向服务架构
概念： SOA是一个组件模型,它将不同应用程序的功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
Mule基于Java平台，是一个轻量级的消息框架，可让您快速，轻松地连接您的应用程序

ESB产品MULE学习笔记系列：一、怎样让Mule在webapp中结合Spring使用

ESB产品MULE学习笔记系列：一、怎样让Mule在webapp中结合Spring使用ESB产品MULE学习笔记系列：一、怎样让Mule在webapp中结合Spring使用从形势来看，如果应用不使用 Spring 就感觉有点落伍——说法有点别扭：好像有点过。

诚然， Spring 给我们带来了太多的好处，以至于几乎大部分的产品都以声称能够整合 Spring 为荣， Mule 也不能免俗：）从官方来看， mule 与 spring 的结合有三种做法：1 、 Using Spring as a Component FactoryHow to configure the Spring Container with Mule so that Managed components and other Mule objects can be loaded from Spring.2 、 Configuring the Mule Server From a Spring ContextA Mule server is just a bunch of beans! How to load a Mule instance from the Spring Container.3 、 Configuring a Spring context using Mule XmlThere are lots of reasons why you might want to use Mule and Spring together, but configuring Mule in Spring bean Xml can be a verbose process. Now you can configure it using Mule Xml and mix Spring beans in the configuration.1.1.1. Using Spring as a Component Factory我下面首先尝试的是第一种。

MuleSoft与其产品Mule ESB产品说明书

MuleSoft与其产品Mule ESB产品说明书简介Mule ESB是一个基于Java的轻量级企业服务总线和集成平台，允许开发人员快速便利地连接多个应用，并支持应用间的数据交换。

Mule ESB支持集成现有系统而无论其底层采用何种技术，如JMS、Web Services、JDBC、HTTP以及其他技术。

整体结构从上图可见，Mule通过Transports/Connectors与外围的异构系统连接，提供Routing （路由）、Transaction Management（事务管理）、Transformation（转换）、Message Broker（消息代理）、Transportation Management（传输管理）、Security（安全）等核心模块。

Mule可以单独使用，也可以架设在常用的应用服务器上。

Mule ESBMule是当下使用最多的开源集成平台。

MuleESB价格低廉，配置、扩展简单，而且灵活性强，使得它非常流行。

Mule 是由MuleSoft（前身是MuleSource）开发的一个基于ESB架构理念的消息平台。

Mule ESB的核心是一个基于SEDA的服务容器，该容器管理被称为通用消息对象（Universal Message Objects /UMO）的服务对象，而这些对象都是POJO。

所有UMO和其他应用之间的通信都是通过消息端点（message endpoint）来进行的。

这些端点为众多的分立的技术，比如Jms, Smtp, Jdbc, Tcp, Http, Xmpp, file 等等，提供了简单和一致的接口。

架构说明：1.Mule主要有三个核心组件：传输器transport、路由器router、转换器transformer；2.transport负责在应用之间传递消息，router负责指导消息的传递路径，transformer负责消息格式的转换；3.可以在router中引入过滤器来针对消息内容进行过滤，实现基于内容的路由，并且只需通过xml即可完成，无需编写java代码；4.支持事务、安全、异常管理、JMX管理架构, 提供管理控制台（企业版）；5.支持与Apache CXF、Spring和ActiveMQ的集成；6.提供Eclipse插件作为IDE开发Mule应用；Mule ESB的其他特性1.Mule中的组件可以是任何类型，你可以把POJO或者其他系统的组件集成进来；2.可以使用现存的任何组件而无需改变，也不需嵌入Mule的特定代码，不需调用Mule的API，业务逻辑和消息逻辑完全分离；3.消息可以是任何格式，如SOAP或二进制的图像文件；4.支持任何传输之上的异步，同步和请求响应事件处理机制.；5.Mule提供了一种简单而又强大的方式与RESfFul服务交互，即MuleRESTPack。

MuleESB开篇

MuleESB开篇经过对一些ESB产品的调研，我们最终选择了MuleESB。

既然决定在项目中使用，自然免不了一番学习。

MuleESB提供了一个消息框架，用于程序之间的数据交换。

应用被封装成为服务，服务包含服务组件、消息路由和其它一些配置。

Transport使得服务间的数据在不同渠道内得以传送，并且transport在对数据的传输过程中，对需要格式转换的数据进行数据转换。

MuleESB 不是取代现有程序架构，相反，MuleESB利用如Apache CXF、Spring等开源项目，对自己的项目进行了功能加强。

MuleESB 得以较好的解决各个系统、各种平台、各种复杂情况的整合。

Mule支持多种编程模型，常用的有Web Service，Web Service Proxy，以及基于JMS 的消息发布订阅等。

我们的项目主要用到这三点：1、Web Service:在Mule上开发并发布一个Web Service供客户端调用。

2、Web Service Proxy：用来将客户端的WS请求直接转发至相应的远程WS服务端处理，并返回处理结果，Mule本身不做任何处理。

3、基于JMS的消息发布订阅：采用JMS标准，提供异步的、基于消息发布订阅的调用机制，这类应用需要独立部署消息中间件，如ActiveMQ,IBM MQ等等。

至于MuleESB到底是什么，不多说，宏观概念性的东西网上很多。

但网上关于Mule的中文学习资料非常少，更没有多少实战经验可以参考，在我的学习过程中，主要研究了Mule官方文档，同时自己也做了一些Demo，下面几篇博客将翻译几篇Mule官方文档，同时共享一些自己做的Demo，不是一天两天的活，项目紧，我的时间更紧，别催我，哈哈主要参考：/p/mule/开源中国/MuleESB官网。

Mule开源ESB资料整理

Mule总体架构:Mediation：SeparatingBusiness Logic from MessagingReference:/documentation/display/MULE3CONCEPTS/ Mediation+-+Separating+Business+Logic+from+MessagingMule ESB 能够处理通过多种协议发送的消息，消息的传递和转换对于服务组件来说是完全透明的，Mule通过服务中间件来转换消息，使每个需要该消息的组件都能收到自己满足自己的消息协议的消息。

在传输消息的过程中，Mule 不会统一消息的格式，也就是说对于需要转换协议的消息，mule才会对其进行转换，而对于不需要转换的消息，mule是不会对其进行转换的。

Mule在消息传递的过程中还允许对消息的内容的添加和丰富，使得消息接收端能够接受到一些额外的消息。

总结：这个组件，对应于ESB功能点中的通信功能，主要是提供协议的转换。

该组件的核心是transformer。

该组件在ESB 中属于底层的组件，相当于ESB的功能点中的协议标准转换。

Orchestration：Routing Messages Between Components Reference：/documentation/display/MULE3CONC EPTS/Orchestration+-+Routing+Messages+Between+Service+Co mponents该组件的主要作用是负责服务组件之间的消息路由，它并不关心消息是如何接受和发送的。

组件关系的是数据本身的处理，包括数据的过滤，转化，路由。

在消息的处理上，Mule提供了三种方法：1.Flows,它是Mule3新加的方法。

是最强大的也是最灵活的处理方式。

你能够自主的选择Mule提供的全部的消息处理器，包括过滤器，转换器，路由器，组件和其他来创建满足你需要的处理逻辑。

MuleESB介绍

MuleESB介绍1. 简介Mule ESB是⼀个基于Java的轻量级企业服务总线和集成平台，允许开发⼈员快速便利地连接多个应⽤，并⽀持应⽤间的数据交换。

Mule ESB⽀持集成现有系统⽽⽆论其底层采⽤何种技术，如JMS、Web Services、JDBC、HTTP以及其他技术。

2. 整体结构图整体结构从上图可见，Mule通过Transports/Connectors与外围的异构系统连接，提供Routing（路由）、Transaction Management（事务管理）、Transformation（转换）、Message Broker（消息代理）、Transportation Management（传输管理）、Security（安全）等核⼼模块。

Mule 可以单独使⽤，也可以架设在常⽤的应⽤服务器上。

图架构简图外围系统的服务请求通过Mule ESB的Transport接⼊，Mule通过Transformer进⾏数据的格式转换，然后经过Inbound Router进⾏消息过滤（内部通过配置filter实现）后交给Mule的Component进⾏业务逻辑处理，处理后的结果通过Outbound Router确定传递给哪个接收⽅，然后通过Transformer进⾏数据格式转换，通过Transport连接⾄接收⽅，传递信息。

此图描述的是Mule中的⼀个典型场景的处理过程，涵盖了Mule中的各个关键组件。

其中某些处理步骤不是必须的，如Inbound Router、Transformer。

后续可以看到⼀些其他场景的处理。

3. 功能a. 服务中介将业务逻辑和消息发送分离屏蔽服务的消息格式和协议提供任意位置的服务调⽤提供协议桥接b. 数据转换在应⽤间交换不同格式的信息操作消息的负载内容，包括加密、压缩和编码转换在异构的传输协议的数据类型间格式化消息c. 消息路由基于消息内容和复杂规则路由消息消息的过滤、聚合以及重新排列序号d. 服务创建和托管暴露端点、EJB、Spring Bean以及POJO作为服务作为轻量级的服务容器进⾏服务托管Mule ESB中有⼀些基本的概念，理解这些基本概念后才能理解Mule的内部机制。

Mule ESB调用外部WebService(Basic)

调用外部WebService(Basic)M ule E SB(社区版) 实例分享(Web Service Consumer调用外部WebService)本文分享Mule ESB使用Web Service Consumer组件调用外部WebService的简单的实例,无参数的WebService方法不在这里陈述,直接使用即可很简单,这里重点分享有参数的WebService方法的调用:需要准备的辅助工具:SoapUi。

准备WebService接口的过程忽略,咱们直接来看如何进行Mule ESB部分的开发：我们这里为了简明扼要的阐述清楚WebService的调用方式,直接使用Set Payload组件获取参数并返回Xml给consumer组件调用AnyPoint Studio中Message FLow视图模式下的截图如下：对应的Configuration Xml视图截图如下：大体调用的流程知道了，那么重点来了，在使用组件过程中有几个需要注意的地方：1、Set Payload配置①选择输出的格式为xml②在Value中写入符合调用格式的xml内容③获取uri参数，若使用URL参数请使用[message.inboundProperties.'http.query.params'.get('pkid')]2、Xml文档格式（★★重点★★）这里我们需要使用前文提到的辅助工具：SoapUi，文档格式的获取分两步：第一步：通过SoapUi调用你想调用的WebService中的方法，调试通过。

第二步：获取调试通过的SoapUi调用WebService方法时发送的报文，进行转换：发送的报文在下图的红框区域：转换步骤：①复制报文体（Body中的内容）②将xmlns属性标签复制到报文体中最终获得xml格式如下:3、WebService的配置①添加组件并双击看到如下界面②配置引入WebService服务③选择要使用的方法经过如上步骤后，小伙伴们开始愉快的debug之旅吧。

esb 实现方式

esb 实现方式摘要：1.ESB概念及作用2.ESB实现方式分类3.常见ESB实现技术4.ESB在企业中的应用场景5.如何选择合适的ESB实现方式6.总结正文：一、ESB概念及作用ESB（Enterprise Service Bus，企业服务总线）是一种企业级的消息传输架构，它用于在不同的企业应用系统之间进行通信。

ESB的作用在于实现系统间的解耦，降低系统间的耦合度，提高系统的可扩展性和可维护性。

二、ESB实现方式分类1.基于传统消息队列的ESB实现：通过消息队列来实现消息的发送和接收，如RabbitMQ、Kafka等。

2.基于Web服务的ESB实现：借助Web服务技术，如SOAP、RESTful API等，实现系统间的通信。

3.基于事件驱动的ESB实现：通过事件驱动架构，实现系统间的解耦和异步通信。

4.基于微服务的ESB实现：在微服务架构中，ESB作为微服务之间的通信桥梁，实现服务的发现、路由、负载均衡等功能。

三、常见ESB实现技术1.IBM Websphere：一款成熟的企业级ESB产品，支持多种消息传输协议和应用集成技术。

2.Apache CXF：一个开源的Java框架，支持SOAP、REST等Web服务技术，并提供服务注册、发现等功能。

3.Mule ESB：一款基于Java的开源ESB框架，支持多种消息传输协议和应用集成技术。

4.Spring Cloud：基于Spring Boot的微服务框架，内置了Netflix OSS 组件，提供服务注册、发现、路由等功能。

四、ESB在企业中的应用场景1.系统集成：ESB可用于整合企业内部的各种异构系统，实现系统间的互联互通。

2.业务流程整合：通过ESB实现企业内部的业务流程整合，提高业务运行效率。

3.跨企业通信：ESB可用于实现企业间的跨系统通信，如供应链管理、电子商务等场景。

4.微服务架构：ESB作为微服务之间的通信桥梁，实现服务的解耦和模块化。

esb使用方法

esb使用方法【原创版4篇】目录（篇1）1.ESB 简介2.ESB 使用方法3.ESB 的优点4.ESB 的缺点5.总结正文（篇1）1.ESB 简介ESB（Enterprise Service Bus，企业服务总线）是一种用于实现企业级应用程序集成的技术。

ESB 作为中间件，起到了连接各种不同类型应用程序和服务的作用，它可以将分散在企业内部的各种 IT 资源进行整合，实现高效的数据交换和业务流程协同。

2.ESB 使用方法（1）安装和配置 ESB首先，需要下载并安装 ESB 软件，例如 Apache ServiceMix、Mule ESB 等。

安装完成后，根据需求对 ESB 进行配置，如设置数据源、定义服务接口、配置消息处理器等。

（2）发布服务在 ESB 中发布服务，需要将服务接口和实现捆绑成一个服务单元。

服务发布者将服务单元部署到 ESB 上，并注册相应的服务信息。

（3）消费服务服务消费者通过 ESB 提供的服务注册表查找服务提供者，建立服务调用关系。

当需要调用服务时，服务消费者通过 ESB 发送请求，服务提供者处理请求并返回结果。

（4）管理和监控ESB 提供了管理和监控功能，可以对服务进行生命周期管理，如启动、停止、暂停等操作。

同时，可以对服务调用情况进行监控，实时了解服务运行状况。

3.ESB 的优点（1）提高集成效率ESB 可以降低企业内部各种 IT 资源之间的耦合度，简化应用程序集成，提高整体集成效率。

（2）提高系统可扩展性ESB 采用松耦合的设计理念，使得企业应用程序可以灵活地进行扩展和调整，满足不断变化的业务需求。

（3）提高系统可靠性ESB 具有服务容错、负载均衡等功能，可以确保企业级应用程序在面临各种异常情况时仍能正常运行。

4.ESB 的缺点（1）学习成本较高ESB 作为一种复杂的集成技术，需要开发者具备一定的技术背景和经验，学习成本较高。

（2）部署和维护成本较高ESB 软件本身需要一定的硬件资源，同时，ESB 的部署和维护过程相对复杂，需要投入较多的人力和物力。

ESB部署WebService接口(统一用户和待办)

1 统一待办(WebService方式)1.1 概述门户系统做为用户访问各集成应用系统的统一入口，用户访问企业部信息资源时只需要登录到门户系统，就可使用门户系统集成的各个应用，而待办做为各系统中用户需要处理的工作，门户系统需要提供收集建投部应用系统中产生的待办信息，并且进行统一展现的功能，即统一待办功能。

统一待办应用业务涉及到的系统其中包括本期门户系统建设过程中所需集成的OA、WCM、EAM系统。

为保证门户系统接入各应用系统待办信息的规性，现就各应用系统接入实现做统一要求，以确保门户系统统一待办功能实现的规性、重用性及安全性。

不满足本技术方案提供的接入规则的相关应用系统，应参考本文档完成对应用系统改造后方可进行门户系统统一待办接入工作。

2.应用系统通过门户接口，将获得的最新待办信息发送到门户系统。

3.统一待办系统将应用系统提供的待办信息展示给用户。

4.应用系统通过调用集成接口后获得信息，可以判断发送信息操作是否正常。

此外，如果信息是未办或者未阅，用红色表示1.4 待办信息处理设计思路：用户点击门户系统上“待办栏目”里的一条待办时，弹出一个新页面，首先同应用系统实现SSO，然后跳转到应用系统的待办页面，完成待办处理后，由应用系统调用门户接口通知门户系统，并关闭弹出的待办处理页面，门户系统负责即时刷新门户待办页。

如下图：待办信息集中处理设计示意图1.5 系统待办规1.5.1 WebService服务端服务地址：域名:8080/jicpending/services/IPandingInterfaceWebservice?wsdl服务文件：服务方法：方法1.putPandingInfo：新待办方法2.changePangdingStatus：当OPTTYPE值为2时，则表示修改待办，当为3时，则表示删除待办方法3.仅供OA系统使用. putOaPandingInfo：新待办，方法4. 仅供OA系统使用changeOaPangdingStatus：当OPTTYPE值为2时，则表示修改待办，当为3时，则表示删除待办，仅供OA系统使用服务参数：具体定义如下表表描述11.5.2 新待办➢第一步：应用系统有新待办信息时，调用门户系统接口，将数据传送给门户系统提供的接口，流程如下：WebService接口图在此过程中，各个应用系统以传递对象的形式传递参数，提供的参数自身包括的值为以下表说明，另外，OA系统传递参数的时候不用传递对象，只要依次传入以下表说明即可。

MuleESB使用手册

Mule ESB Studio‎v3.3 安装使用手册‎1***初级教程***如果你还没有‎做好准备，请到http://www.muleso‎f 下载免费的社‎区版Mule‎ESB，按照网站上的‎说明启动Mu‎le Studio‎，并且选择一个‎工作区（另外，你还可以下载‎30天免费试‎用的企业版M‎u le ESB）2安装Mule‎ Studio‎安装前，请确认你的机‎器上已经安装‎了1.6版本的JD‎K。

最后请确认你‎的J DK环境‎变量配置是否‎正确2.1 导出将下载的文件‎解压到你的硬‎盘分区的根目‎录下，例如：C:\1. 执行找到C:\MuleSt‎u dio目录‎，运行mule‎Studio‎.exe启动S‎t udio2. 选择工作区点击OK使用‎默认的工作区‎3使用Stud‎io模板1. 点击File‎菜单，选择New > Mule Projec‎t2. 出现New Mule Projec‎t面板后，为你的项目输‎入名称和一个‎简短的说明，如图：3. 在Serve‎r Runtim‎e选项上选择‎你将要使用的‎M ule运行‎时版本，如图：4. 点击旁边的复‎选框，根据现有的模‎板创建项目，单击项目，选择你想要使‎用的模板创建‎项目，如图：5. 点击Fini‎s h按钮，Mule Studio‎会创建并打开‎一个新的项目‎，完成预创建和‎预配置的流程‎6. 在Mule Studio‎的Packa‎ge Explor‎e r栏中，右键点击mu‎le-config‎.mflow文‎件，选择RunAs > Mule Applic‎a tion7. 停止运行该项‎目，请在Mule‎Studio‎控制台点击红‎色的T erm‎inate按‎钮，如图：4运行独立的例‎子1. 到Mule ESB Standa‎l one目录‎下，找到Exam‎ples目录‎下你想运行的‎例子2. 拷贝.zip文件的‎例子到$MULE_H‎O ME/apps目录‎下，例如：运行Flig‎ht Reserv‎a tionexampl‎e的例子，拷贝mule‎-e xampl‎e-flight‎-reserv‎a tion-3.3.0.zip到$MULE_H‎O ME/apps 目录‎下，如图：3. 启动Mule‎，运行这个例子‎5启动Mule‎ Studio‎如果你在安装‎过程中启动了‎M ule Studio‎，并且已经在运‎行了，请跳过本节的‎其余部分，直接进行：创建新项目如果当前Mu‎le Studio‎没有启动，通过完成下面‎的步骤启动应‎用程序1. 找到Mule‎ Studio‎安装目录2. 执行mule‎Studio‎.exe3. 点击OK使用‎默认的工作区‎6创建新项目1. 如果你看到是‎各种控制组件‎的应用程序窗‎口（右下图），请直接进入第‎2节。