初探Apusic ESB服务组合之演示

初探Apusic ESB服务组合之演示


1. 前言
2. 开发环境
3. 业务场景介绍
4. 模拟已有的业务服务
4.1. 北京中介:客户信用度服务和利率比较大小服务
4.2. 上海银行:贷款利率服务
4.3. 深圳银行:贷款利率
5. 开始使用ESB 服务器
5.1. ESB安装及配置
5.2. 启动ESB服务器
6. ESB网络配置
7. ESB服务组合设计
7.1. 服务组织
7.2. 增加业务流程节点
7.3. 导入现有业务服务到服务总线中
7.4. 导出新的业务服务
7.5. 上下文参数设计
7.6. 业务流程节点属性设置
7.7. 上传服务
8. 客户端程序访问整合的业务服务
9. 总结

1. 前言

本示例模拟一个业务场景,展示了如何使用Apusic ESB来进行业务组合的功能。

2. 开发环境

Apusic ESB 5.1 + Apusic 5.1 + Adminconsole5.1 +ApusicStudiom5 + xfire1.2.6 + axis1.4

3. 业务场景介绍

现在我们假设在北京有一家贷款中介公司,对外提供贷款服务。目前,有一个业务流程目前是这样的:

1)客户到柜台登记,提出贷款申请。

2)客服人员根据这个客户的ID,从现有系统中的“客户信用度”服务中,得到该客户的最大贷款额度。

3)然后,手工登录深圳某家银行,从银行对外公布的“贷款利率”服务中,得到该客户在深圳这家银行的贷款利率。

时间: 2024-10-11 10:28:07

初探Apusic ESB服务组合之演示的相关文章

精通SOA(一):构建服务组合

尽管面向服务的体系结构或 SOA 仍然是新生事物,但许多公司正逐步认识到需要采用 SOA 方法作为 执行满足业务需求的解决方案的方法.采用这种方法的一个关键步骤是构建可重用服务的组合. SOA 表示新应用程序的设计.开发和集成方式的根本性转变.它还将企业应用程序的开发简化为模块 化业务服务,可以轻松地对其进行集成和重用. SOA 的一个主要优点是缩小了业务和 IT 之间的差距.作为需求收集活动的一部分,将业务和技术需 求与机构的与项目有关的主要业务目标相对应,将对确保项目与业务需求同步大有帮助.

Netflix提高邮寄影碟和在线播放服务组合价格

新浪科技讯 北京时间7月13日上午消息,在线影片租赁提供商Netflix12日宣布将大幅提高同时使用邮寄影碟和在线播放服务用户的月服务费.分析人士认为,此举意在引导用户选择Netflix的在线播放服务. Netflix说,公司将邮寄影碟和在线播放服务组合的月服务费提高60%. Netflix表示,需要提供邮寄影碟和在线播放服务的美国用户每月需花费7.99美元用于邮寄租碟,虽然无限制但一次只能租一张影碟,同时再加7.99美元享受无限制的在线播放服务,算起来每月的费用是15.98美元.而以前此类服务

企业服务总线ESB的概念及应用

 ESB全称为Enterprise Service Bus,即企业服务总线.它是传统中间件技术与XML.Web服务等技术结合的产物.ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素.ESB的出现改变了传统的软件架构,可以提供比传统中间件产品更为廉价的解决方案,同时它还可以消除不同应用之间的技术差异,让不同的应用服务器协调运作,实现了不同服务之间的通信和整合.从功能上看,ESB提供了事件驱动和文档导向的处理模式,以及分布式的运行管理机制,它支持基于内容的路由和过滤,具备了复杂数据的

微服务架构的核心要点和实现原理

微服务架构中职能团队的划分 传统单体架构将系统分成具有不同职责的层次,对应的项目管理也倾向于将大的团队分成不同的职能团队,主要包括:用户交互UI团队.后台业务逻辑处理团队与数据存取ORM团队.DBA团队等.每个团队只对自己分层的职责负责,并对使用方提供组件服务质量保证.如果其中一个模块化组件需要升级.更新,那么这个变更会涉及不同的分层团队,即使升级和变更的改变很小,也需要进行跨团队沟通:需求阶段需要跨团队沟通产品功能,设计阶段需要跨团队沟通设计方案,开发阶段需要跨团队沟通具体的接口定义,测试阶段

微服务基础

微服务基础篇 1: service consumer -> Proxy Server ->Load Balance -> Service Discovery -> Target Service 2: Broser curl Other -> Zuul -> Ribbon -> Euraka -> Restful API zuul: 是边缘服务,用来提供动态路由,监控,授权,安全,调度等功能,将权限控制等一些业务逻辑抽离出来,单独放到Zuul里,使得服务组件更

Kubernetes和Spring Cloud哪个部署微服务更好?

Spring Cloud 和Kubernetes都自称自己是部署和运行微服务的最好环境,但是它们在本质上和解决不同问题上是有很大差异的.在本文中,我们将看到每个平台如何帮助交付基于微服务的架构(MSA),它们擅长哪个领域,并且如何两全其美的使用从而在微服务之旅上获得成功. 背景 最近我读了 A. Lukyanchikov的一篇非常棒的文章(https://dzone.com/articles/microservice-architecture-with-spring-cloud-and-do),

微服务架构 原来应用开发还可以这么美好

单体应用这种传统开发思维已经难以在新时代站住脚了. 一个简单的应用会随着时间推移逐渐变大.在每次的sprint中,开发团队都会面对新"故事",然后开发许多新代码.几年后,这个小而简单的应用会变成了一个巨大的怪物. 一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦.敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它.因此,修正bug和正确的添加新功能变的非常困难,并且很耗时.另外,团队士气也会走下坡路. 最后,单体式应用使得采用新架构和

微服务架构的优势与不足

微服务正在博客.社交媒体讨论组和会议演讲中获得越来越多的关注,在Gartner的2014 Hype Cycle上它的排名非常靠前.同时,软件社区中也有不少持怀疑论者,认为微服务不是什么新东西.Naysayers认为这就是SOA架构的重新包装.然 而,尽管存在着不同的争论,微服务架构模式却正在为敏捷部署以及复杂企业应用实施提供巨大的帮助. 首先我们看看为什么要使用微服务. 开发单体式应用 假设你正准备开发一款与Uber和Hailo竞争的出租车调度软件,经过初步会议和需求分析,你可能会手动或者使用基

正在考虑微服务架构的松耦合?小心这些陷阱!

本文讲的是正在考虑微服务架构的松耦合?小心这些陷阱![编者的话]本文阐述了作者在构建松耦合的微服务架构中遇到的一些挑战,并给出了相应的方法,包括:如何处理多个微服务间共享数据的场景,如何演进微服务API,如何处理微服务安全,以及如何组合微服务等. 微服务是一种新的架构,它使用简单.轻量.松耦合的服务来构建系统,这些服务彼此可以独立开发和发布. 如果你还不了解这些基础概念,请阅读Martin Fowler的文章.如果你想拿它和SOA进行比较,请看Don Ferguson的演讲.Martin Fow