【图文】ESB 配置、应用_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
ESB 配置、应用
&&ESB 培训资料
大小：370.50KB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢（1）jbpm的模型是采用UMLActivity；（2）jbpm提供了可扩展的Event-Acti；（3）jbpm提供了灵活的条件表达式机制，来辅助；（5）借助hibernate的ORM的优势，jb；当然，还有一些优点，是很多开发人员并不太注意的，；（1）jbpm的Node机制非常灵活，开发人员可；有很多灵活的优点，当然也少不了存在一些“局限”；（1）很显然
（1） jbpm的模型是采用UML Activity Diagram的语义，所以便于开发人员理解流程。
（2） jbpm提供了可扩展的Event-Action机制，来辅助活动的扩展处理。
（3） jbpm提供了灵活的条件表达式机制，来辅助条件解析、脚本计算的处理。
（4） jbpm提供了可扩展的Task及分配机制，来满足复杂人工活动的处理。
（5） 借助hibernate的ORM的优势，jbpm能够很容易支持多种数据库。
当然，还有一些优点，是很多开发人员并不太注意的，比如：
（1） jbpm的Node机制非常灵活，开发人员可以很容易定制“业务化语义的节点”，并满足运行时候处理的需要。
有很多灵活的优点，当然也少不了存在一些“局限”。
（1） 很显然，只能有一个start-state。
（2） jbpm依靠Token来调度和计算，在同一个时刻中，一个ProcessInstance只允许一个Token对象只存在一个Node中（分支当然用Child Token对象处理）。所以本质上就不支持“multi-instance”模式。
（3） jbpm作为一款开源的工作流引擎，其更多的是关注“如何辅助你更容易的让流程运行完成”，但是并不记录“流程运行的历史和轨迹”。这一点可能是东西方文化的差异性所在，因为国内的流程应用，比较关注“运行轨迹”。
至于其他的一些局限，比如不支持“回退”、“跳转”等操作，这也是因为东西方文化的差异所在。西方人认为“往回流转的情况肯定也是一种业务规则所定义，那么肯定可以通过分支或条件来解决”，而东方则把“回退作为一个人性化管理和处理的潜在特点”。所以诸如此类的一些“特定需求”，估计只能通过扩展jbpm来实现了，甚至有时候，简单的扩展是无法解决问题的――正如上一节所说的那样，“引擎的抽象”会影响“引擎的应用”的复杂度支持。
jBpm流程模型与定义对象
6.1 首先解决如何形式化描述一个流程的问题
这里说的“定义流程”并不是说jbpm3中那个基于eclipse plugin的图形化建模工具。而是如何去解决“形式化的描述一个流程”的问题。
形式化的描述流程并不是一个简单的问题，从上世纪七十开始，人们就在探索用各种各样多的模型来描绘流程：Petri Net, FSM, EPC, Activity Diagram, 以及近来的XPDL MetaModel等等，延伸到如今的BPEL,BPMN,BPMD等等。
jBpm采用了Activity Diagram的模型语义：其将用Start State、State、Action State（Task Node）、End State、Fork、Join、Decision、Merge、Process State这几个“元素”的组合来描述任何一个流程。其中Action State是Activity Diagram中的标准语义，在jBpm为了便于大家理解和使用，jBpm采用了TaskNode这个语义。
在WfMC的Workflow Reference Model中，对流程引擎的功能描述，其中就包含一项：解析流程定义。如果想满足这这功能，前提条件就必须有最基本的两个：
（1） 有一套形式化的描述语言（通常为xml格式）。利用这个描述语言可以描述一个流程的定义。比如WfMC所提出的XPDL这个描述语言。当然，jBpm也有自己的一套，名为jPDL，也是一个xml格式的。
（2） 有一套对象集可以反映流程的定义模型和结果，一般叫做定义对象。流程引擎就需要把“xml格式的流程定义”解析为一套对象，而这套对象的结构则反映了流程的结构。
我们暂且不去探讨jPDL那个形式化的xml语言，而把重心放在jBpm那套定义对象中。因为这个定义对象是属于Engine Kernel的一部分。
6.2 抽象的节点（Node）和转移（Transition）
面向对象的继承性、多态性可以让我们从最抽象的部分来描述对象。那么这套定义对象也需要从最基础的“抽象”说起。 process的本质就是“节点”和“有向弧”，当然你也可以说是Node和Link，或者Node和Transition，或者Activity和Transition等等之类的。jBpm采用的是Node和Transition来表示“节点”和“有向弧”。于是乎，在jbpm中你可以看到这样的结构关系：
对于一个节点来说，从定义角度，其只关心几个事情：
（1） 这是个什么类型的节点。这个节点可能是start state，也可能是一个task node，或者是一个fork。
（2） 这个节点的转入Transition和转出Transition。
可能有的人会说，还需要关心节点的转入转出的类型，比如And Splite或者Xor Join之类。这个并没有错，因为很多流程模型的节点元素需要考虑这个，比如WfMC的XPDL模型。但是jBpm的节点是没有这样的属性的，或者说的更准确些，是Activity Diagram模型的节点没有这样的特性。活动图是采用“Fork”、“Join”这样的节点来解决“分支”问题。
6.3 流程：节点与转移的组合
仅利用节点和转移的组合，就可以表达一个“过程（Process）”。当然这个流程只能告诉人们“大概的业务过程”，当然不包括很复杂的信息。如下图所示：
这是一张非常标准的“活动图”，如果我们用jbpm的设计器，看看这样一张“流程
不论你如何绘画，改变不了这张图的本质：它就只有两个基本元素：节点和转移。只是有的节点是start-state，有的是task-node，有的是join，有的是end state而已。
JBoss ESB ESB同SOA之间的关系：ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。
可以这样说，ESB是特定环境下(SOA架构中)实施EAI的方式：首先，在ESB系统中，被集成的对象被明确定义为服务，而不是传统EAI中各种各样的中间件平台，这样就极大简化了在集成异构性上的考虑，因为不管有怎样的应用底层实现，只要是SOA架构中的服务，它就一定是基于标准的。
其次，ESB明确强调消息(Message)处理在集成过程中的作用，这里的消息指的是应用环境中被集成对象之间的沟通。以往传统的EAI实施中碰到的最大的问题就是被集成者都有自己的方言，即各自的消息格式。作为基础架构的EAI系统，必须能够对系统范畴内的任何一种消息进行解析。传统的EAI系统中的消息处理大多是被动的，消息的处理需要各自中间件的私有方式支持，例如API的方式。因此尽管消息处理本身很重要，但消息的直接处理不会是传统EAI系统的核心。ESB系统由于集成对象统一到服务，消息在应用服务之间传递时格式是标准的，直接面向消息的处理方式成为可能。如果ESB能够在底层支持现有的各种通讯协议，那么对消息的处理就完全不考虑底层的传输细节，而直接通过消息的标准格式定义来进行。这样，在ESB中，对消息的处理就会成为ESB的核心，因为通过消息处理来集成服务是最简单可行的方式。这也是ESB中总线(Bus)功能的体现。其实，总线的概念并不新鲜，传统的EAI系统中，也曾经提出过信息总线的概念，通过某种中间件平台，如CORBA来连接企业信息孤岛，但是，ESB的概念不仅仅是提供消息交互的通道，更重要的是提供服务的智能化集成基础架构。
最后，事件驱动成为ESB的重要特征。通常服务之间传递的消息有两种形式，一种是调用(Call)，即请求/回应方式，这是常见的同步模式。还有一种我们称之为单路消息(One-way)，它的目的往往是触发异步的事件，发送者不需要马上得到回复。考虑到有些应用服务是长时间运行的，因此，这种异步服务之间的消息交互也是ESB必须支持的。除此之外，ESB的很多功能都可以利用这种机制来实现，例如，SOA中服务的性能监控等基础架构功能，需要通过ESB来提供数据，当服务的请求通过ESB中转的时候，ESB很容易通过事件驱动机制向SOA的基础架构服务传递信息。
3、 Jboss ESB的主要特征和功能
①Jboos esb 4.2主要的特性包括：
支持普通的通知框架。支持的Transports包括JMS (JBossMQ, JBoss Messaging, Oracle AQ and MQSeries), email, 数据库或文件系统. 推荐的缺省 JMS 实现是JBoss Messaging 1.2.0GA.
jBPM 集成.
支持WS-BPEL.
支持Web Services.
使用特定的ESB 服务器改进部署和配置.
支持Groovy.
trailblazer 例子.
许多quickstart 例子.
支持使用Smooks or XSLT转数据 .
支持交互步骤松耦合的侦听器和动作模型.
使用Drools或者 XPath 基于内容的路由.
支持JAX-R和jUDDI注册 .
提供允许non-ESB traffic与ESB进行集成的网关.
图形化的配置编辑器.
高性能和可靠性
JBossESB是JBoss推出的ESB的实现,也是JBoss的SOA产品的基础.JBossESB是一个基于消息的中间件(Message Oriented).
假设一个简单的系统集成场景来开始阐述JBossESB的设计和概念。
A系统(Endpoint A) C
Message ->
Message --> B系统 (Endpoint B)
所以,如果简单的对于JBossESB定义的话,我们可以定义以下三个概念:
Message Listener (接收“inbound” message)
Message Filter (发送 \” message)
Message (消息对象)
JBossESB 是一个面向服务(Service Oriented)的架构,所以在ESB内部的要么是一个Service, 要么是一个Message. 这里的Service就是指具有实现业务逻辑的服务,也可以是一个实现路由(Router)，或者数据转化(Transformation)的服务. 就拿上面的这个例子,系统A发送一个Message给 ESB的一个服务,我们假设叫做S1, 那么S1收到Message后,做一些处理,转到S2的服务,S2再把处理后的结果发送给系统B. 这样就实现了A和B之间通过ESB的通信.
System A -> message -> S1 -> S2 ->....
-> message -> System B
那么在ESB内部是怎么去表达一个服务呢?这里引入了EndpointReference的概念,简称EPR. 有了服务之后,服务之间是通过什么样的传输层(比如JMS, FTP, HTTP)来通信呢? 所以ESB的内部也引入了Courier的API, 来统一抽象传输层. 刚我们也看到了,ESB的内部无非就是一系列的服务, 但是我们怎么来保存/注册这些服务的呢? JBossESB是使用jUDDI来注册和保存这些服务元数据的。
JBossESB的几个重要概念
在要了解和运行JBossESB之前,我们最好了解下JBossESB中比较重要的几个概念。
①Message (消息)
ESB内部所交流/传递的都是消息,所以可见这个消息格式的重要性. 在JBossESB中, 定义了一个Message的对象,它是有以下几个部分构成的。
(1). Header (用来存放From, To, Reply-to等Addressing的信息).
(2). Body (存放信息主体)
(3). Attachment （用来存放附件等)
(4). Properties
(5). Context (主要是存放一些类似事务的信息等)
目前在Body里面一般来说存放两种格式的数据,一个是串行化数据(Serialized Object ),另外一个是XML文件,比如常见 的SOAP的payload. 在ESB中,还有两个定义,一个叫ESB-aware Message, 我们上面所讲的Message就是ESB-aware Message, 正如名字说讲的,它是属于ESB内部的Message对象. 还有个叫 ESB unaware Message,也就是说他同样也是一个message,比如SOAP Message,但是如果把soap message直接让ESB来处理，是处理不了的,所以呢? 经常的在Listener 监听的端口会有个Adapter (在JBossESB里叫做Gateway)来负责把ESB-unaware message 转成 ESB-aware message。
②Service (服务)
ESB的内部服务是用EPR来映射的. ESB的内部服务可以是任何的一个服务,比如说一个FTP的服务,一个基于文件系统的服务等等, 那么这个时候我们就需要用EPR来对这个服务进行描述.在EPR这个类里,主要是描述了这个服务的URI,以及所必须的一些元数据. 目前在JBossESB中提供的EPR有: FileEPR,EmailEPR,FTPEPR, HibernateEPR等等. 我们在注册服务的时候,是将EPR的信息注册到UDDI的容器里, 但不仅仅是EPR, 还有一些辅助信息,比如定义服务的category-name, service-name. 这些将在后面继续介绍。
③Listeners, Gateway
Listener的作用是负责监听端口,一般来说,客户端是发送消息到Listener,然后有Listener把消息传递给ESB, 我们可以把Listener看做是inbound router. 在JBossESB中,我们是叫GatewayListener, 它一般来说做两件事情.
监听Message.
ESB-unaware message和 ESB-aware message的互转.
目前ESB支持的Gateway有: JMSGatewayListener, JBossRemotingGatewayListener, FileGatewayListener等等. 在MessageComposer这个类里的compose/decompose方法来负责ESB-unaware信息和ESB-aware信息的转化。
三亿文库包含各类专业文献、高等教育、行业资料、应用写作文书、各类资格考试、幼儿教育、小学教育、SOA系统架构调研40等内容。　
　SOA系统架构调研_IT/计算机_专业资料。SOA系统架构调研一. SOA原理与应用 1. SOA原理 2. SOA技术构成 3. SOA实施应用 4. SOA治理二. 开源SOA优势与劣势及选型... 　这得归功于 SOA 架构中的若干实施原则。 *应用功能的服务化:将应用程序打散成服务是 SOA 实施的关键之一。一方面,遗留系统的功能和数据不能丢弃, 只有重用才能... 　基于SOA的银行系统架构研究_电脑基础知识_IT/计算机_专业资料。基于 SOA 的银行...著名金融企业的决策者调查报告显示,超过 80%的 企业在他们的系统中采用了 SOA... 　SOA真正面目:优势与不足_IT/计算机_专业资料。SOA真正面目,SOA优势与不足,SOA优点和缺点SOA (service-oriented architecture),面向服务的架构,恐怕是近一段时间以来... 　基于Spring框架的SOA系统架构的实现 [摘要] 本文对 Spring 框架和 SOA 系统架构原理进行简要的阐述, 将 Spring 框架技术应用到 SOA 系统架构中, 并用一个简单... 　本文 在 soa 架构的基础上,讨论了基于 soa 的软件测试的难点和基本方法,设计了基于 soa 架 构的软件测试方法。 一引言 软件测试是基于 soa 架构的信息系统的一... 　浅谈J2EE架构--SOA_IT/计算机_专业资料。浅谈J2EE架构--SOA1.1. 对新业务系统开发的支持 基础数据维护系统总体采用分布式架构设计,基于标准的 J2EE 平台开 发。子... 　服务层是 SOA 的基础,可以直接被应用调用, 从而有效控制系统中与软件代理交互的人为依赖性。 SOA 的关键是“服务”的概念。它是作为一种面向服务的架构,是一种...从DevOps看EDA -解道Jdon
& & & &&& & &
　　首先我们看看一个案例，一家娱乐公司价值10亿美元项目需要涉及创建一个新的系统以及集成现有系统，主要问题是如何从一个系统状态变化传播到其他系统的生态系统？例如,如果一个客人购买一张票，我们怎么知道这种票是否存在？属于哪个特定的客人？这样我们可以显示他的资料吗?
　　我们采用的方式是将这些系统使用事件驱动架构。从高一层来看，这意味着当有趣的事情发生在系统的记录(SOR)中，我们要求系统能够发出事件来标识当前资源已经被改变。在上述的背景下具体售票的例子中：当一个客户购买一张票，我们需要票务系统发出&创造&事件，标识这张新票，然后,通知其他系统创建了新票。这是图1所示。
　　使用EDA应用程序有不同的实现，最常见的是利用企业服务总线(ESB)。ESB提供了标准的机制系统用来发布消息给ESB，系统也可以从ESB订阅消息。消息有两种形式：
队列Queue: 队列方便点到点消息传递,这意味着消息生产者可以发送消息到一个消息消费者
主题Topic: 主题使用发布-订阅消息传递，这意味着消息生成方可以将消息发布到零个或多个订阅者
　　队列和主题有自己的特定的业务场景。例如,如果你想要一个消息只处理一次，那么就使用一个队列。如果你想发送一个消息到一个特定的目的地，也是使用一个队列。如果你想要一个消息被任意数量的其他系统处理，那么使用一个主题。
　　因此,在EDA我们倾向于主题,因为我们想启用新系统能够订阅改变现有系统，而无需改变现有的系统。因为消息生产者不需要知道对其订阅用户，那么我们说这两个系统之间的关系是松散耦合的。换句话说，如果我们添加一个新的系统，比如说一个分析系统，用来跟踪不同的客人的信息，我们就不需要更新票务系统来支持分析系统，分析系统只要订阅由票务系统的主题事件即可。图2显示了这个图形。
　　图2显示了当票务系统引发一个事件，客户档案服务以及分析引擎将接收这个事件。新系统可以订阅票务系统的主题和集成它，这些都不需要改变票务系统。
　　队列必须保证能交付，这意味着当一个消息发布到队列中，ESB将Hold住消息在队列中直到有人从队列中删除它。另一方面主题是发布消息给所有用户，然后消息即消失。这将导致另一个问题：如果你的主题侦听器死机了呢？你会错过了事件吗？在正常情况下,答案是&是的&，你将错过，这就是一个问题！幸运的是，大多数消息代理(ESB的一部分，用来管理消息)有持久订户的概念。如果一个用户注册成为持久订户，那么ESB将Hold住这一信息，直到你的主题侦听器能够接收消息。从操作的角度来看，您需要确保所有关心主题的监听器能够接收所有事件，那么就要以持久durable方式订阅主题。
轻量和重量事件
　　事件本身有两种形式：
轻量Light-weight
重量Heavy-weight
　　轻量级事件包含改变资源的标识符,然后需要监听器回去调用SOR获得资源的详细信息。如图3所示：
　　重量事件包含事件细节，这样回调SOR记录就不需要：
　　所以你应该使用轻量级还是重量级事件?这,有一个权衡。事件是不能保证同一时间到达-事件是异步的。所以如果票务系统发布以下事件:
更新票记录
将额外特性加入票
　　但是你接受的事件是如下顺序：
将额外特性加入票
更新票记录
　　如果事件担负的机票信息(重量级事件)，那，您将创建机票，将特性添加到票，然后覆盖机票已经更新的状态，这样机票最后状态就不包括新添加的特性。结果是，你不会再有票的当前状态。怎么解决这个问题？方法之一是要求事件的时间戳，然后做一些本地处理，以确保你有最新的事件和丢弃任何过早的事件。
　　这里存在一个大量的细节工作且容易出错，所以更理想的解决方案是使用一个轻量级的事件和回调。在这个例子中，票务系统是票的&真理之源&，所以，当你进行回调，你将会得到保证总会得到票的正确状态。但这是有代价的，即你的票务系统需要能够支持因为回调产生额外的负载。
　　在当前这个项目中，我们有两个场景：新系统可以支持轻量级事件产生的额外负载，遗留系统,不支持重量级事件生成的额外的负载。作为DevOps工程师，你是在最好让您的开发人员知道这个建议，因为你了解系统是否可以支持额外的负载。但同时，如果系统可以支持额外的负载和选择轻量级事件，你需要计划基础设施可以支持负载。它并不是小事：在我们的项目中,生成的票务系统每天超过500
k的事件,这是一个大量的额外负载!
工作流程和手工监听
　　大多数esb提供工作流的概念，一个工作流当接受到一个事件然后执行可配置的动作。如图4所示：
　　结合面向服务的体系结构与ESB工作流将会很强大，工作流可以处理事件，执行转换并调用服务。它使事件处理可配置而不是编码。
　　使用ESB工作流的好处是：ESB在其内部进行事件处理，因此它通常执行性能的比自己编写监听器要好。这需要权衡，如果你使用ESB这种方式，你会失去可移植性；因为应用程序业务逻辑被包含在ESB中，所以如果你需要将应用程序移动到另一个环境中，需要将ESB一起移动。如果另一个网站是使用不同的ESB，或者他们不想采用ESB，那么所有的业务逻辑需要重写。
　　另一种选择是在代码中手工编写监听器。这些侦听器订阅适当的主题和独立于ESB执行业务逻辑。在这种情况下，您可能不需要一个完整的ESB，只要message
broker即可，通常更便宜。但这种可移植性会以牺牲性能为代价。
　　作为DevOps工程师，您需要知道开发人员是选择自己手工编写函数，如果他们使用工作流，那么你要为ESB需要添加额外的处理能力。如果他们要手工编写监听器，那么你需要考虑esb和听众之间的额外网络带宽，你需要添加足够的处理能力来实现侦听器。
　　这取决于你有多少系统集成，您的ESB可能会从分割中受益性能提高。分割基本上意味着你分配资源单独给特定应用程序组件，这样一个系统的负载不影响另一个系统的性能。在我们的大型项目中我们开始没有分割，但负载非常高，我们最终创建了8段不同系统，并且分离不同系统之间的事件。设定应用程序拥有自己的消息资源这样有助于负载隔离。
　　虽然esb是实现EDA主要机制，但它们不是城里唯一的游戏。正如您可能想到的,：esb有复杂的配置和管理，每天传递数十万甚至数百万消息。还有一种方法，我们使用一个。Atom
Syndication Format,下一代的RSS(Really Simple
Syndication),是一个标准的格式发布web提要和遵循一个非常HTTP-centric的方法。SOR通过Atom Feed发布事件，消费者订阅接收事件。这种模型非常简单，会不再需要ESB，但就像所有技术一样都有一个权衡：延迟。EDA应用程序会有一个隐式的延迟。也就是在SOR记录改变和其他系统变化之间有延迟，但延迟会很小，当使用拉取Polling机制时，延迟取决于拉取的间隙时间。
还有其他系统支持处理事件，如和。
| 网站地图 | 设为首页1876人阅读
wso2esb（33）
WSO2的应用服务器
WSO2的应用服务器是基于WSO2 Carbon平台的企业级就绪的应用程序服务器。继承的WSO2
Web服务应用服务器（WSAS），WSO2的应用服务器（AS）支持除了其Web服务管理功能的Web应用程序部署和管理。加上WSO2的Carbon功能，用户现在有能力管理他们的应用程序，范围从Web服务，Web应用程序在一个统一的方式在应用程序服务器管理控制台本身。
Web服务规范的基础上面向服务的架构（SOA）的概念，支持安全，可靠和事务集成基于松散耦合，这是固有的可扩展性的概念。许多厂商已经支持Web服务和XML到他们现有的专有产品解决方案。
WSO2公司创造了一个新的平台，削减不必要的层，支持在一个简单，干净，轻量级模型的完整的WS - *堆栈，从而更容易地开发，部署和运行应用程序。
当涉及到支持Web应用程序，WSO2的应用服务器内部使用Apache
Tomcat和能够承载任何一种Web应用程序，这是部署在Tomcat。此外，这些Web应用程序可以继承像认证/授权，从WSO2的碳平台的用户管理等功能。
WSO2公司AppServer的全力支持XML，SOAP，WSDL，并支持可靠，安全的通信。
WSO2的应用服务器，它简单而有效的创建，使用和管理Web服务。
WSO2支持的协议
&&&&SOAP1.1/1.2
&&&&WSDL 1.1的
&&&&WSDL 2.0的
&&&&JAX- WS2.2
&&&&MTOM，XOP和带附件的SOAP
&&&&WS - Addressing的
&&&&WS - Security的
&&&&WS - Trust中
&&&&WS- SecureConversation
&&&&WS - MetadataExchange的
&&&&的WS - SecurityPolicy
&&&&的WS - ReliableMessaging
&&&&WS - Policy的
&&&&WS- PolicyAttachment
&&&&WS - MetadataExchange的
&&&&的WS - Transfer
&&&&WS发现
WSO2的应用服务器汇集到一个单一，无缝，易于使用提供的开源项目。而不必下载Apache Web服务的不同部分堆栈分开和组装在一起，我们为你做，并为您提供一个单一的从WSO2的碳平台继承了很多附加功能的综合包。
WSO2开源组件
Apache Axis2 (SOAP)
&&& Apache Axiom (High performance XML Object Model)
&&& Apache Rampart/Apache WSS4J (WS-Security, WS-SecureConversation)
&&& Apache Rahas (WS-Trust)
&&& Apache Sandesha2 (WS-ReliableMessaging)
&&& WS-Addressing implementation in Axis2
&&& Apache Neethi (WS-Policy)
&&& WS-SecurityPolicy implementation in Axis2
&&& Apache XML Schema
&&& Embedded Apache Tomcat
&&& Apache Tribes (Group Communications Framework)
WSO2的应用服务器可以使用在多种不同的方案：
&&&&现有的或新的业务应用作为Web服务公开。
&&&&大厦内或跨企业的可靠消息传递链接。
&&&&托管应用程序的webapps
&&&&相结合。NET，J2EE，CICS，SAP和其他平台。
WSO2的应用服务器是一个完全开源的产品。
WSO2的Apache软件基金会的Web服务项目，通过领先的开源组件的组合。加上我们自己的整合代码，WSO2公司提供生产质量的开源软件。我们所有的集成代码，包括统一的管理控制台可根据Apache软件许可证2.0版。
在此版本的新特点
内置的数据服务支持
&&&&服务器角色管理功能
&&&&为便于Cluster配置的部署同步
&&&&改进的JAX - WS支持
&&&&改进的SOAP示踪
&&&&在服务列表页的改进
&&&&&&&&两个服务和服务组列表
&&&&&&&&在服务列表中的安全指标
&&&&改进的样品和文件
&&&&改进Web应用程序和Web服务的类加载
&&&&嵌入式Tomcat7.0.14的支持
&&&&支持的Servlet API3.0
在发行说明提供完整的功能列表。
WSO2的应用服务器是一个轻量级，高性能和高集成的Web服务的中间件平台。如果你还没有安装AppServer的，请在安装指南。了解更多WSO2的AppServer的！
WSO2的应用服务器管理控制台是您的一站式管理WSO2公司的应用服务器。您可以管理/配置模块/服务，以及监测系统，通过这个接口。
管理控制台的功能是在下面详细描述。
一旦WSO2的应用服务器已成功安装（安装的详细信息，请参见安装指南），启动WSO2的AppServer的服务器。然后，启动Web浏览器实例，它指向的URL
https://localhost:9443/carbon/，如果您使用的是默认设置。这将带你到WSO2的应用服务器控制台的欢迎页面
WSO2的AppServer的两个运输听众：HTTP和HTTPS。默认情况下，HTTP侦听器打开9763端口，而HTTPS侦听端口9443打开。管理员功能只通过HTTPS端口暴露。
签署将可在右上角。当用户点击“登录”链接，它会自动将请求重定向到安全HTTPS协议，如果用户已经在HTTP协议。一旦提供正确的凭据，用户将被记录在应用程序服务器管理控制台。
默认的用户名和密码登录到WSO2的应用服务器管理控制台：
用户名：admin
密码：admin
管理控制台可以指向不同的应用服务器节点，在生产系统中。这是可以做到在登录框上使用“服务器URL”项。
要解决任何问题签署，请按一下“登入说明”
管理控制台的主页将包含系统总结
服务组管理
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：504582次
积分：8011
积分：8011
排名：第2510名
原创：314篇
转载：246篇
评论：43条
(16)(45)(90)(256)(133)(10)(8)(2)