基于JMS的SOA实现机制和JBoss ESB 4.6程序开发指南

JbossESB

JBoss

需积分: 5 71 浏览量更新于2024-08-02 收藏 1.22MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

JBossESB4.6 程序开发指南本资源是 JBoss SOA 开发指南，涵盖 SOA 平台配置、协议转换和基于 JMS 的 SOA 实现机制等内容。本指南适合程序开发者、系统集成商和 SOA 架构师等，旨在帮助他们快速掌握 JBossESB4.6 的开发和实现。一、SOA 平台配置 SOA（Service Oriented Architecture）是一种软件架构风格，旨在将应用程序分解为多个服务，通过服务之间的交互实现业务逻辑。JBossESB 是基于 Java 的 SOA 平台，提供了一个统一的框架来实现服务的集成和编排。在 JBossESB 中，配置 SOA 平台是一个关键步骤，包括配置服务总线、设置服务 registry、定义服务契约等。服务总线是 SOA 平台的核心组件，负责服务之间的交互和通信。服务 registry 是一个存储服务信息的仓库，用于服务发现和路由。服务契约是服务之间的接口定义，用于确保服务之间的交互正确。二、协议转换协议转换是 JBossESB 的一个重要特性，允许不同的服务使用不同的通信协议进行交互。JBossESB 支持多种协议，包括 HTTP、JMS、FTP 等。在协议转换中，JBossESB 提供了多种转换器，例如 HTTP 转换器、JMS 转换器等。三、基于 JMS 的 SOA 实现机制 JMS（Java Message Service）是 Java 平台上的一种消息服务标准，用于实现异步消息传递。JBossESB 使用 JMS 实现基于消息的服务集成，允许不同的服务使用 JMS 进行异步通信。在 JBossESB 中，基于 JMS 的 SOA 实现机制包括三个主要步骤：服务注册、服务发现和服务调用。在服务注册中，服务提供者将服务信息注册到服务 registry 中。在服务发现中，服务消费者从服务 registry 中获取服务信息。在服务调用中，服务消费者使用 JMS 将消息发送到服务提供者。四、程序开发指南本指南还提供了详细的程序开发指南，包括如何使用 JBossESB 的 API 来开发服务、如何使用 JBossESB 的工具来实现服务集成等。五、结论 JBossESB4.6 是一个功能强大且灵活的 SOA 平台，提供了多种协议转换和基于 JMS 的 SOA 实现机制。通过本指南，开发者可以快速掌握 JBossESB 的开发和实现，提高开发效率和质量。

资源详情

资源推荐

for the toolset), and to trigger their own ‘action classes’ that can be unaware of transport and

triggering mechanisms.

Note: Within JBossESB source we have two trees: org.jboss.internal.soa.esb and

org.jboss.soa.esb. You should limit your use of anything within the

org.jboss.internal.soa.esb package because the contents are subject to change without

notice. Alternatively anything within the org.jboss.soa.esb is covered by our deprecation

policy.

The core of JBossESB in a nutshell

Rosetta is built on four core architectural components:

• Message Listener and Message Filtering code. Message Listeners act as “inbound”

message routers that listen for messages (e.g. on a JMS Queue/Topic, or on the file

system) and present the message to a message processing pipeline that filters the

message and routes it (“outbound” router) to another message endpoint.

• Data transformation via the SmooksAction action processor. See the “Message

Transformation” chapter in the ServicesGuide for further details.

• A Content Based Routing Service. See the “What is Content-Based Routing” chapter

in the ServicesGuide for further information.

• A Message Repository, for saving messages/events exchanged within the ESB. See

the “What is the Registry” chapter in the ServicesGuide for further details.

These capabilities are offered through a set of business classes, adapters and processors,

which will be described in detail later. Interactions between clients and services are supported

via a range of different approaches, including JMS, flat-file system and email.

A typical JBossESB deployment is shown below. We shall return to this diagram in

subsequent sections.

Note: Some of the components in the diagram (e.g., LDAP server) are configuration choices

and may not be provided out-of-the-box. Furthermore, the Processor and Action

distinction shown in the above diagram is merely an illustrative convenience to show the

concepts involved when an incoming event (message) triggers the underlying ESB to

invoke higher-level services.

JBESB-PG-7/17/09 16

Action ClassProcessor

JMS / MQ

Web

Services

Processor Action Class

Processor

Action Class

CONTROLLER

For each LDAP chapter

creates a listener

Passive Listeners

Asynch Messages

Current implementation

is a JMS listener

listens

File Drop

Subdirectories

Subdirectory_1

Subdirectory_2

Subdirectory_n

Active Listeners

Action Class

Invokes

HTTP

Monitors

Current

implementation in a

Directory Poller

LDAP

Passive

Active

Notificatio

n on

failure

Notificatio

n on

success

Notification

Framework

through:

SMTP:eMail

JMS

FTP

Notificatio

n on

success

Invokes

Invokes Invokes

Invokes

Post

Processing

Object Store

Persistence Handler

Post Processing

Stores

(optional)

Reads

(optional)

Reads

(optional)

Relational

Database

SMTP

Web

Services

Async MQ

Messaging

Others

As required

Transformatio

n Library

Relational

Database

ITER8

XSLT

transformation

library

Resource

Layer

Chapter 1

Services and Messages

Introduction

In keeping with SOA principles, everything within JBossESB is considered to be either a

service or a message. Services encapsulate the business logic or points of integration with

legacy systems. Messages are the way in which clients and services communicate with each

other.

In the following sections we shall look at how Services and Messages are supported within

JBossESB.

The Service

A “Service” in JBossESB is defined as a list of “Action” classes that process an ESB Message

in a sequential manner (see below). This list of Action classes is referred to as an “Action

Pipeline”. A Service can define a list of “Listeners”, which act as inbound routers for the

Service, routing messages to the Action Pipeline.

The following is a very simple JBossESB configuration that defines a single Service that

simply prints the contents of the ESB Message to the console.

<?xml version = "1.0" encoding = "UTF-8"?>

<jbossesb

xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-

1.0.1.xsd" invmScope=”GLOBAL”>

</actions>

</service>

</services>

</jbossesb>

As you can see from the above example, a Service has “category” and “name” attributes.

When JBossESB deploys the Service, it uses these attributes to register the Service endpoints

(listeners) in the Service Registry (see Registry Guide). Clients can invoke the Service using

the ServiceInvoker as follows.

ServiceInvoker invoker = new ServiceInvoker(“Retail”, “ShoeStore”);

Message message = MessageFactory.getInstance().getMessage();

message.getBody().add(“Hi there!”);

invoker.deliverAsync(message);

The ServiceInvoker uses the Service Registry (see ServicesGuide) to lookup the available

Endpoint addresses for the “Retail:ShoeStore” Service. It takes care of all the transport details

of getting the message from the Client to one of the available Service Endpoints (JMS, FTP,

HTTP etc), hiding all of the lower level details from the Client.

The Endpoint addresses made available to the ServiceInvoker will depend on the list of

listeners configured on the Service such as JMS, FTP or HTTP. No listeners are configured

on the Service in the above example, but its InVM listener has been enabled using

JBESB-PG-7/17/09 18

invmScope="GLOBAL"

. To add additional Endpoints for the Service, we need to explicitly

add listener configurations on the Service. JBossESB supports two forms of listener

configuration:

1. Gateway Listeners: These listener configurations configure a “Gateway” Endpoint.

These Endpoint types can be used to get messages onto an ESB bus. It is responsible

for “normalizing” the message payload by wrapping it into an ESB Message (see

below) before shipping it to the Service's Action Pipeline.

2. ESB Aware Listeners: These listener configurations configure an “ESB Aware”

Endpoint. These Endpoint types are used to exchange ESB Messages (see below)

between ESB Aware components e.g. exchanging messages on the bus.

The following is an example of how a JMS Gateway listener can be added to the above

ShoeStore Service.

<?xml version = "1.0" encoding = "UTF-8"?>

<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/

trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd">

<jms-provider name="JBossMQ" connection-factory="ConnectionFactory">

<jms-bus busid="shoeStoreJMSGateway">

<jms-message-filter dest-type="QUEUE" dest-name="queue/shoeStoreJMSGateway"/>

</jms-bus>

</jms-provider>

</providers>

<service category="Retail" name="ShoeStore" description="Acme Shoe Store Service"

invmScope=”GLOBAL”>

<jms-listener name="shoeStoreJMSGateway" busidref="shoeStoreJMSGateway"

is-gateway="true"/>

</listeners>

</actions>

</service>

</services>

</jbossesb>

In the above configuration, we added a bus <providers> section to the configuration. This is

where we configure the transport level details for Endpoints. In this case we added a <jms-

provider> section that defines a single <jms-bus> for the Shoe Store JMS Queue. This bus is

then referenced in the <jms-listener> defined on the Shoe Store Service. The Shoe Store is

now invocable via two Endpoints – the InVM Endpoint and the JMS Gateway Endpoint. The

ServiceInvoker will always use a Service's local InVM Endpoint, if available, in preference to

other Endpoint types.

The Message

All interactions between clients and services within JBossESB occur through the exchange of

Messages. In order to encourage loose coupling we recommend a message-exchange pattern

based on one-way messages, i.e., requests and responses are independent messages, correlated

where necessary by the infrastructure or application. Applications constructed in this way are

less brittle and can be more tolerant of failures, giving developers more flexibility in their

deployment and message delivery requirements.

To ensure loose coupling of services and develop SOA applications, it is necessary to:

The InVM transport is a new feature since JBossESB 4.3 that provides communication

between services running on the same JVM. Section 4.3.3, "InVM Transport" contains more

information about this feature.

JBESB-PG-7/17/09 19

剩余154页未读，继续阅读

jinhuah

粉丝: 3
资源: 6

基于JMS的SOA实现机制和JBoss ESB 4.6程序开发指南

JBoss ESB 开发指南

JBOSS ESB程序员指南

net framework 4.6 (脱机安装程序

C:\Program Files\dotnet\sdk\7.0.306\Microsoft.Common.CurrentVersion.targets(1229,5): Error: 找不到 .NETFramework,Version=v4.6 的引用程序集。要解决此问题，请为此框架版本安装开发人员工具包(SDK/目标包)或者重新定向应用程序。

.net framework4.6的证书

.net4.6anzhuangbao

.net 4.6.exe

.net framework 4.6

.net framework 4.6 安装

net framework v4.6

win10下载opengl4.6教程

st-link utility4.6

用vs2017 开发mfc程序 使用 版本号为4.6的 opencv 在调试过程中非常卡顿 怎么解决

android studio 4.6下载

net framework4.6安装 win7

gpdk090v4.6

eclipse4.6版本下载

graphon go global 4.6

opengl4.6 glsl

最新资源

用vs2017 开发mfc程序使用版本号为4.6的 opencv 在调试过程中非常卡顿怎么解决