이곳 클릭!! -> Real SOA - Web Services and Service Oriented Architecture
참고로 저자는 Tuscany 팀의 3명의 IBMer 다.
Brian Schaffner (ZDNet Korea)
이전 글에서 각 비즈니스 프로세스에 적합한 서비스 지향 아키텍처(SOA)를 구축하는 방법에 대해 논의한 바 있다. 이번 글에서는 SOA 아키텍처를 보다 세심하게 살펴보고 컴포넌트를 실행하는 방법에 대해 알아보자.
아울러 웹서비스 기술을 이용해 서비스 에이전시, 서비스 제공자, 그리고 서비스 요청자 등을 실행하기 위한 설계를 구축하는 방법 등에 대해 설명하도록 하겠다.
웹 기술로 서비스 실행하기
웹 기술은 상당히 풍부한 수준으로 서비스 실행 도구를 제공할 만큼 성숙해 왔다. 웹서비스 기술은 대체로 다른 기술을 기반으로 구축되며 특히 XML과 HTTP에 근거를 두고 있다.
각 서비스들은 흔히 현존하는 애플리케이션을 포장한 형태로 제공되고 있다. 그림 A는 다양한 웹서비스 컴포넌트와 이들이 하나의 서비스 아키텍처를 수행하기 위해 어떻게 공조를 이루는지 그 연관 관계에 대해 설명하고 있다.
그림 A : SOA의 웹서비스 구현 |
위 그림에서 UDDI가 서비스 발견 에이전시를 제공하며 웹·애플리케이션 서버는 서비스 제공자를 전달하고 애플리케이션은 서비스 제공자의 역할을 하는 것을 발견할 수 있다. 이런 모습이 바로 SOA 모델의 충족 요건이 된다.
서비스 제공자에서 애플리케이션 기능성 요약하기
웹 서비스는 하나 또는 그 이상의 애플리케이션 전반에 걸쳐 실행된다는 기능성을 갖춘 서비스의 ‘포장’을 반드시 제공해야 한다. 일부 웹서비스는 아마 다른 웹서비스들이 다중 애플리케이션에 대한 통합 인터페이스를 제공하는 반면에 단일 애플리케이션을 대상으로 한 기능성을 제공하고 있는지도 모른다.
애플리케이션을 서비스 측면에서 면밀히 계획해 보면 애플리케이션과 기술이 비즈니스 프로세스에 적합한지 살펴볼 수 있다. 그림 B는 애플리케이션의 기능성이 서비스 실행으로 면밀하게 계획되는 방법에 대한 사례를 보여준다.
그림 B : 애플리케이션 기능성이 서비스에 매핑되는 예 |
EJB와 같은 컴포넌트 아키텍처는 애플리케이션 서버 환경에서 수행될 수 있는 서비스를 요약해 보여준다.
웹 서버는 서비스 접근에 대해 HTTP 네트워크 전송 방법을 제시하며 애플리케이션 서버는 SOAP 인터페이스와 서비스를 구성하는 객체 컴포넌트를 주관한다. 객체 컴포넌트는 애플리케이션들에 대해 비즈니스 서비스 계층을 제공한다.
결과적으로 웹서비스는 기초적인 애플리케이션들에서 풍부하게 정의된 서비스들을 이끌어 낸다. 이러한 서비스는 이후 개념 정의가 잘 된 비즈니스 프로세스로 연결된다.
애플리케이션 전반에 걸친 개념적 계층을 구성하면 각 애플리케이션의 기능성을 비즈니스 서비스로 정의된, 보다 의미 있는 방법으로 전달할 수 있다.
WDSL 환경의 서비스 규약 정의
서비스 제공자는 WSDL 문서 형태로 해당 인터페이스 규약을 출판한다. WSDL 문서는 서비스 위치 지정, 그리고 해당 서비스에 대한 접근 방법까지 포함하는 서비스의 특징을 정의한다. 개발적 관점에서 볼 때 WSDL은 서비스 요청자와 서비스 공급자가 모두 동의하는 규약을 제공한다.
일단 비즈니스 프로세스를 정의하고 해당 프로세스를 실행할 서비스를 조직하고 나면 그 다음 단계는 서비스와 서비스 내부의 특정 방법론을 결정하는 것이다.
WSDL은 세부 서비스의 XML 포맷이다. WSDL 문서 내에서 서비스 접근법, 가능한 방법에 대한 판단, 방법에 대한 접근, 방법까지 나아가는 동안 거쳐야 하는 매개변수, 기타 여러 요소에 대한 세부 작업을 수행할 수 있다.
서비스 요청자들은 서비스 레지스트리를 이용해 서비스를 위치시킨다. 웹서비스의 실행에서 서비스 레지스트리는 UDDI를 이용해 실행된다. UDDI 서버는 서비스 내역에 대한 데이터베이스를 갖고 있으며 이들을 서비스 요청 애플리케이션에 제공한다.
서비스 요청자는 웹서비스와의 인터페이스 규약을 납득하기 위해 WSDL 문서를 활용한다.
일반적으로 WSDL 문서는 물리적으로 UDDI 서버에 저장되는 것은 아니다. 오히려 UDDI 서버는 서비스 요청자에게 WSDL 문서를 어디서 발견할 수 있는지 위치를 확인할 수 있는 URL들을 제공한다.
프로그래머의 측면에서 WSDL 문서는 서비스에 접속하기 위해 사용하는 개념 인터페이스를 정의한다. 설계 측면에서 WSDL은 서비스 요청자와 제공자 사이의 규약을 규정하기 때문에 반드시 이 2가지 앞에 위치해야 한다.
일단 WSDL이 설계돼 합의되면 서비스 제공자의 개발자와 서비스 요청자의 개발자는 다소 평행적으로 작업하게 된다.
서비스 발견
서비스는 UDDI 서버에 질의하고 관련된 WSDL 문서에 접근함으로써 발견된다. 중심 레지스트리를 사용함으로써 클라이언트 애플리케이션은 역동적으로 서비스를 발견하고 이에 결합될 수 있다.
UDDI 서버 및 프로토콜은 상당히 포괄적이다. 하나의 서비스 아키텍처로서 UDDI 컴포넌트는 자신의 도메인 내에 위치한 모든 서비스에 대해 잘 알고 있는 중앙 에이전시 역할을 수행한다. 언제든 서비스 요청자가 서비스에 접근하거나 서비스를 위치시켜야 할 때마다 UDDI 서버는 정보 요청을 받는다.
UDDI는 레지스트리를 검색하는데 있어 다양한 방법을 제공한다. 일단 하나의 조직과 서비스가 위치되고 나면 서비스 요청자는 WSDL 위치를 요약한다.
WSDL 은 대개 서비스 그 자체와 함께 위치한다. 그 다음 서비스 요청자는 서비스의 세부 사항을 알기 위해 WSDL 문서에 접근한다. WSDL 문서 내의 정보를 활용해 서비스 요청자는 서비스에 접근하는 방법, 그리고 어떤 방법론이 있는지, 어떤 매개변수가 보내져야만 하는지 등을 다른 것보다 먼저 이해하게 된다.
그림 C는 이러한 프로세스가 작동하는 것을 묘사한 것이다.
그림 C : 서비스 요청자로부터 WSDL에 접근하기 |
향후 과제
SOA를 구현하는 것은 정말 하나의 도전과도 같다. 구현을 통해 SOA를 구성하는 컴포넌트와 웹서비스 이면의 기술들을 이해함으로써 풍부한 전략적 솔루션을 제공함과 동시에 각 비즈니스의 필요 부분과 도전과제 등을 충족시키는 실속있는 아키텍처를 만들어 낼 수 있을 것이다.
떠돌아다니는 내용인데.. 괜찮은거 같아서.. 퍼봅니다.
=============================================
# SOA(Service Oriented Architecture; 서비스 지향 아키텍처)
기본 배경 - J2EE 5.0
J2EE 1.4가 나온 지도 이제 1년이 지났고 예정대로라면 올해 하반기에 위용을 드러낼 J2EE 5.0(J2SE 5.0처럼 1.5가 아닌 5.0으로 버전이 고쳐졌다)을 벌써부터 다루는 것이 무척 성급하게 비칠 수도 있지만 이미 필자가 작년 11월에 J2EE 5.0의 핵심 기술 중 하나인 JBoss의 EJB 3.0 조기 구현체로 과제를 무사히 마쳤을 정도로 상황이 빠르게 진행되고 있다. 웹 쪽은 JSP 2.1, JSTL 1.1, 그리고 JSF 1.2로 EL 공유와 통합이 한창이고, 웹 서비스도 J2EE 1.4에서 보여준 초기적 기술 상태를 벗어나기 위해 JAX-RPC 2.0과 JAXB 2.0, 그리고 WSM(Web Services Metadata) 1.1로 재무장되어 가고 있다.
웹 서비스 개발에서도 누누이 강조하는 개념 중의 하나로 coarse-grained가 있다. 필자가 처음 이 용어의 번역을 시도했을 때(O'Reilly의 Java Web Services, 2002년), 오로지 생각하는 것이라고는 스타벅스에서 원두를 샀을 때 “어떻게 갈아드릴까요?”라는 질문에 “굵게 갈아주세요”하는 바로 그 ‘굵게 갈음(coarse-grained)’이었다. 웹 서비스에서는 반대말인 fine-grained를 하지 말라는 뜻이기도 한데 도대체 뭘 잘게 갈지 말고 굵게 갈라는 뜻일까?
대답은 의외로 간단하다. 사용자가 사용할 인터페이스에 개발자의 잣대를 들이대지 말라는 말이다. 사용자는 장소와 시간을 주고 예약 가능한 택시 목록을 보고 싶다. 개발자는 ‘음··· 일단 xx1 메쏘드를 호출하는 식으로 장소와 시간을 받아온 뒤 xx2 메쏘드를 불러 DB 연결을 얻어 온 후 xx3 메쏘드로 사용자 인증을 한 후 xx4에서 장소를 정규화하고···’ 이렇게 머릿속에는 이미 아스트랄한 메쏘드 세상이 펼쳐지는 것도 모자라서 ‘이렇게 해놓으면 나중에 또 쓸 수 있겠지?’하며 흐믓한 미소마저 짓는다. 재사용을 위한다면 메쏘드를 public으로 할 것이고, 이러다 보면 메쏘드의 공개는 파죽지세로 이어진다.이러한 public 메쏘드와는 별도로 공개된(published) 메쏘드라는 개념이 나와 관심을 끈다. 물론 공개된 메쏘드는 자바 문법으로는 나타낼 수 없지만 단순히 접근 수준을 정하는 정도가 아니라 이 메쏘드를 외부의 클라이언트가 호출할 수 있게 하겠느냐는 뜻에서 공개되었다는 표현을 쓴 것이다(Erich Gamma와 Kent Beck이 쓴 『Contributing to Eclipse』에서 발췌). WSM에서는 공개된 메쏘드에 대한 표식을 가능하게 하는 메타데이터가 제공되고 있으니 정리하면 사용자에게 쓰도록 내비칠 오퍼레이션(웹 서비스에서는 메쏘드라는 프로그래밍 언어적 용어 대신 오퍼레이션을 대응하여 쓴다)은 최대한 굵게, 그리고 프로그래밍 언어의 public과는 차별화해야함이 coarse-grained의 현실적 취지이다.
SOA 베스트 프랙티스: BPEL Cookbook 실제 애플리케이션 개발 경험을 보유한 설계 전문가들로부터 개발, 구축, 운영에 관련한 고급 BPEL 개념과 베스트 프랙티스를 배워 봅시다. 기존 애플리케이션을 컴포지트 애플리케이션(composite application)으로 통합하기 위한 보다 개방적이고 유연한 대안으로 SOA(service-oriented architecture)가 각광받고 있습니다. SOA의 구현 작업은 크게 두 단계로 나뉘어집니다. 먼저, 기존 애플리케이션을 재활용 가능한 서비스로 분할해야 합니다. 두 번째로, 이 서비스들을 유연한 비즈니스 프로세스 내에 “통합(orchestrate)”해야 합니다. Edwin Khodabakchian, VP, BPEL Development |
촐시된 아티클 * |
제 1부 : 비즈니스 룰 개발을 위한 서비스 지향적 접근법 비즈니스 룰 개발 및 관리를 위한 서비스 지향적 접근법을 통해 유지보수 비용을 절감하고 조직의 유연성을 개선하는 방법을 배워 봅니다. 저자 - Kevin Geminiuc, Senior Software Architect, Policy Studies Inc. |
제 2 부: BPEL을 이용한 웹 서비스 네트워크의 구축 European Space Agency가 BPEL 스코프, BPEL 도메인, Oracle BPEL Process Manager API 등을 이용하여 파트너 친화적인 웹 서비스 네트워크를 구축한 사례를 소개합니다. 저자 - Yves Coene, Project Manager, Spacebel s.a. |
제 3 부: 다이내믹 BPEL 프로세스의 구현 런타임에 엔드포인트 레퍼런스를 조작하여 다이내믹 바인딩을 구현하는 방법을 설명합니다. 저자 - Sean Carey, Architect, SPS Commerce |
제 4 부: WSIF를 이용한 통합 WSIF를 이용하여 BPEL 프로세스가 Java 클래스, EJB 등의 J2EE 리소스에 네이티브한 방법으로 액세스하도록 하는 방법을 배워 봅니다. 저자 - Matjaz B. Juric, University of Maribor |
제 6 부: 워크플로우/프로세스 모니터링을 위한 리치 인터넷 애플리케이션(RIA)의 구현 Oracle BPEL Manager API를 확장하여 실시간 워크플로우/프로세스 모니터링 대시보드를 구현하는 방법을 설명합니다. 저자 - Doug Todd, CTO, Enterra Solutions |
제 7 부: BPEL 프로세스의 “즉석” 구현 XQuery를 이용하여 데이터베이스에 저장된 매개변수를 BPEL XML 정의 파일로 변환하고, BPEL 프로세스를 즉석에서 생성하는 방법을 설명합니다. 저자 - Jerry Thomas, Chief Architect, Centerstone Soft |
출시 예정인 아티클... 제 5 부: BPEL을 EAI 환경에 추가하기 제 8 부: BPEL 운영자를 위한 가이드 BPEL 프로세스의 구축 및 운영을 위한 커스텀 프로세스 운영 툴을 생성하는 사례 연구입니다. 저자 - Stany Blanvalet 제 9 부: JMS 메시징 버스를 이용한 BPEL의 통합 제 10 부: 포터블 SOA 통합 프레임워크의 구현 * 게시 일정은 상황에 따라 변경될 수 있습니다. |
SummaryBy J. Jeffrey Hanson
Integrating old and new components and services using a service-oriented architecture requires an infrastructure that can connect any component or service, regardless of location, messaging protocol, and message format. To orchestrate existing services and components to meet the needs of today's dynamic business climate, this infrastructure must be highly customizable. The enterprise service bus (ESB) infrastructure fulfills these requirements. In this article, Jeff Hanson introduces the concepts behind an ESB and discusses the mechanisms it uses to facilitate cross-protocol messaging, message transformation, message security, service invocation, and other requirements of a service-oriented messaging infrastructure. (2,800 words; December 12, 2005)
Printer-friendly version | Mail this to a friend
n enterprise service bus (ESB) is a centralized, logical, architectural component that operates in a distributed, heterogeneous environment to facilitate the requirements of a highly scalable, fault-tolerant, service-messaging framework. An ESB acts as an open and implementation-independent service messaging and interfacing model that isolates application code from the specifics of routing services and transport protocols, and allows substitution of service implementations as needed.
An ESB acts as a shared messaging layer for connecting applications and other services throughout an enterprise computing infrastructure. It supplements its core asynchronous messaging backbone with intelligent transformation and routing to ensure messages are passed reliably. Services participate in the ESB using either Web services messaging standards or Java Message Service (JMS). Originally defined by analysts at Gartner, ESB is increasingly seen as a core component in a service-oriented infrastructure.
In this article, I discuss the open source ESB ServiceMix and its relationship to the Java Business Integration specification.
Minimum requirements of ESB message delivery
The minimum requirements of an ESB, as a message delivery system, are often referred to by the acronym TRANS, which defines an ESB as a software entity that does the following:
Introducing Java Business Integration (JBI)
The Java Business Integration (JBI) specification and API defines a platform for building enterprise-class ESBs using a pluggable, service-based design. JBI builds on the TRANS foundation with normalized messages and component-based interactions.
JBI is a specification and an API for a normalized messaging service along with a component framework and management model for deploying integration services such as routing engines, rule engines, and transformation services. A JBI-based design specifies a standards-based pluggable architecture with a JVM-based runtime component called the normalized message router (NMR).
The high-level interactions of JBI can be seen in Figure 1 below.
Figure 1. High-level view of JBI. Click on thumbnail to view full-sized image. |
JBI embodies a messaging model based on Web Services Description Language (WSDL) for easy mapping to Web services, HTTP, email, and JMS. JBI integrates with legacy systems, binary transports, document-oriented transports, and RPC (remote procedure call) systems.
Figure 1's binding components deal with protocol-oriented relationships and components. And service-engine components in JBI support content-based routing, orchestration, rules, transformations, custom augmentation, etc.
Normalized messages
JBI uses a "normalized" message—consisting of a payload, optional attachments, and metadata—for interaction between consumers and providers. Message normalization is the process of mapping context-specific data to a context-neutral abstraction to transport data in a standard format. All messages handled by the NMR are normalized.
A normalized message consists of three main parts:
Normalized message router
The JBI message exchange depends on the NMR to route message exchange objects between service consumers and providers. The NMR performs such message delivery with varying qualities of service, depending on application needs and the nature of the messages being delivered.
An NMR is not embodied by any concrete object. It is abstracted as a set of APIs, SPIs (service provider interfaces), and components. The NMR APIs include:
Delivery channels
A JBI delivery channel represents a bidirectional communication pipe used by binding components and service engines to transport messages across the NMR. The javax.jbi.messaging.DeliveryChannel
interface forms the API contract between service consumers, service providers, and the NMR.
A service consumer uses its delivery channel to initiate service invocations, while a service provider uses its delivery channel to receive invocations. A component that functions as both consumer and provider uses the same delivery channel for both roles. Therefore implementations of DeliveryChannel
must support concurrent use of a given instance from multiple threads.
Components
The JBI component framework provides a pluggable interface that allows binding components and service engines to interact with the JBI environment. The framework provides the interface to all of the JBI services.
JBI supports two kinds of components, service engines and binding components. Components interact with JBI in two ways:
Service engines
Service engines are the business-logic components in a JBI system and can serve as service providers/consumers. Service engines orchestrate service consumption and requirements. Service engines can also provide services such as data transformation, sophisticated routing, and message coordination facilities.
Binding components
Binding components are used to send and receive messages across specific protocols and transports. They uncouple the JBI environment from protocol specifics by marshalling and unmarshalling messages to and from protocol-specific data formats, allowing the JBI environment to process only normalized messages.
Normalized message exchange
JBI's principal purpose is to route normalized message exchanges from one component to another. Messages are delivered in a normalized form.
Binding components must convert protocol/transport-specific messages to a normalized form. Binding components and service engines interact with the NMR via a delivery channel, which provides a bidirectional delivery mechanism for messages.
An external service consumer sends a service request across a specific protocol and transport to a binding component. The binding component converts the request to a normalized message. The binding component then creates a message packet called a message exchange (ME) and sends it across the binding component's delivery channel to the NMR for delivery to a service provider.
After receiving a message, the consuming service engine or binding component creates a normalized message, putting it into a new MessageExchange
instance, and sends it to the target ServiceEndpoint
instance. After accepting the ME, the ServiceEndpoint
component de-normalizes the message into protocol and transport format, and sends the message along to the external service provider.
Service units
Component-specific artifacts deployed to an installed engine or binding are referred to as service units. Service units are grouped into an aggregate deployment file called a service assembly. This file includes a deployment descriptor that indicates the component into which each service unit is to be deployed.
Service units contain:
The industry has witnessed the evolution of a wide range of solutions addressing the problem space of B2B and enterprise application integration (EAI). These solutions varied from proprietary message oriented middleware to standard JMS based solutions and web services. This paper provides a brief introduction to the upcoming JBI (Java Business Integration) standard in relation to SOA (service-oriented architecture) principles and the ESB (Enterprise Service Bus) infrastructure.
SOA (service-oriented architecture) is one of the latest developments that have made a huge leap in the area of application and business integration. SOA defines a set of well-defined architectural principles, paradigms and best practices to enable loosely coupled interaction between applications.
SOA promotes loosely coupled interaction between participating applications based on well-defined interfaces. Service implementations are self-contained and dont depend on the contextual information and state of other services. Service interactions are mainly based on exchanging document-style data, defined using a standards-based messaging model. The services themselves are agnostic to the transport level interactions required to enable the communication between the service provider and service consumer.
Even though not a mandatory requirement, most of the modern SOA based systems utilise web services and related technologies for providing the required plumbing for the interactions between services. WSDL (Web Services Definition Language) is used as the main artefact for representing messaging models; SOAP as the message representation protocol and HTTP as the wire-level transport protocol. This doesnt mean you always need to use the aforementioned technologies for implementing systems based on service-oriented architecture. Lot of enterprises have used similar architectures for realising loosely coupled systems, well before any of these buzzwords came into existence. However, the key difference is that now we have standards-based protocols, toolsets and software for enabling service oriented architecture.
SOA principles are significantly different from object-oriented paradigms and principles. The key difference is that the interactions between services are defined using interfaces that are oriented more towards data than behaviour. A service in isolation may be realised using object-oriented principles and techniques, however, the interactions between the services seldom use any of these techniques. Rather, these interfaces are geared more towards document-based interchanges. Where object-orientation binds behaviour closer to data, service-orientation decouples data from behaviour.
An ESB (Enterprise Service Bus) provides the infrastructure for realising service-oriented architecture. ESBs provide a runtime environment for deploying and enabling your services augmented with design-tools for defining the interaction and orchestration of the services.
In the ESB world the services dont directly interact with each other. Rather, the ESB runtime acts as a mediator between the services to loosely couple them. The ESB runtime would implement protocol bindings, message translation, message handling etc.
The key services provided by an SB would include:
Most of the ESB vendors base their SOA proposition on open standards and technologies including the various web services standards and protocols. They provide a variety of transport bindings for invoking the services including HTTP, FTP, and JMS etc. Most ESBs use WS-BPEL (Business Process Execution Language for Web Services) for realising orchestration between the deployed services for implementing business processes. ESB vendors also provide quality of service features including fault-tolerance, failover, load balancing, message buffering etc.
JBI (Java Business Integration) is a Java-based standard addressing the EAI and B2B issues based on the paradigms and principles advocated by service-oriented architecture. The current version (1.0) is finalized through the JSR (Java Specification Request) 208 in August 2005. Both commercial and open source worlds have already started embracing JBI as an integration standard in their ESB products.
JBI defines a plug-in based architecture where services can be plugged into the JBI runtime environment. JBI provides well-defined interfaces for services to interact with the JBI runtime environment. The services need to expose interfaces to the JBI runtime environment for the JBI runtime environment to route messages to the services. The JBI runtime environment acts as a mediator between the services that are deployed in the environment.
The JBI runtime core mainly comprises of the following components within the same JVM:
JBI defines two types of components in the JBI runtime environment,
The key aspect of JBI is the decoupling of the service engine and binding components so that business logic is not infested with the infrastructure details required for invoking and consuming services. This promotes a flexible and extensible architecture. Both BC and SE components within JBI can be service providers and/or service consumers.
Both BC and SE components provide interfaces to the JBI runtime for accepting messages from the JBI runtime. Similarly, they use interfaces provided by JBI for communicating with the JBI runtime.
JBI uses a messaging model that decouples the service consumers from the service providers. The messaging model is defined using WSDL. WSDL is used to describe the operations exposed by both SE and BC components. WSDL is also used to define transport level bindings for the abstract service operations.
One of the key components used in the JBI architecture is NMR (Normalized Message Router). NMR provides the main messaging spine built around WSDL, which provides the loosely coupled message exchange between the SE and BC components deployed within the JBI runtime. Services are required to have interfaces, which are an aggregation of operations. Each operation is composed of zero or more messages. An interface can have one or more transport level bindings.
JBI uses a normalized format for representing messages within the runtime. A normalized message is composed of the following parts,
The JBI specification provides standard interfaces for the service consumers and providers for exchanging messages with the NMR. NMR supports both one-way and request-response semantics for service invocation between consumers and providers.
JBI uses JMX for the runtime installation, configuration and monitoring of services. The services are required to implement a set of JBI interfaces to make them manageable in the JBI environment. The JBI environment is required to provide a set of JMX MBeans to enable the management of the JBI runtime.
The JBI runtime environment allows the following operation related to the SE and BC components,
JBI defines standard deployment descriptors and packaging models for both components and component artefacts.
JBI identifies the following roles for providing an end-to-end JBI based EAI solution,
With the whole industry aligning more and more towards open standards and specifications, JBI takes a great leap in enabling Java technologists adopting a standards-based approach in addressing integration issues using service oriented architecture and ESB infrastructure. Both commercial vendors like Oracle and open source software like ServiceMix have already started adopting JBI as part of their ESB offerings.
Meeraj Kinnumpurath works as a Java architect with VOCA Ltd (formerly BACS), who are the largest clearing house in Europe. He has been using Java for the past eight years, developing enterprise applications. He has also published a few books on Java, J2EE and Web Services.
Web Services + EA = SOA | ||
.최근 정보기술의 방향에서 중요한 키워드 중 하나가 바로 서비스(Service)이다. 서비스는 정보기술이 현실에서 지향하는 바를 한 마디로 설명할 수 있는 중요한 단어이다. 서비스 지향 아키텍쳐(Services-Oriented Architecture; 이하 SOA) 역시 서비스의 관점에서 소프트웨어 아키텍쳐를 조망하는 기술로 최근 많은 각광을 받고 있으며, 시장조사업체인 가트너 그룹은 2006년까지 전 세계 비즈니스 애플리케이션의 80% 이상이 SOA를 기반으로 개발될 것이라고 전망하고 있다. SOA 개 ..SOA는 소프트웨어 아키텍처의 일종이다. 따라서, SOA를 이해하기 위해서는 이를 구성하고 있는 요소들을 파악할 필요가 있는데, 본 절에서는 먼저 SOA와 서비스를 정의하고 이를 기반으로 구성요소들을 살펴보도록 한다. 1) SOA의 정의 2) SOA의 구성요소
| ||
| ||
위의 그림으로부터 우리는 SOA를 이해하기 위한 세가지 주요 요소를 추출할 수 있다. 서비스, 메시지 그리고 서비스 발견 등이 그것이다. 이들 각각에 대한 이해를 통해, 우리는 SOA의 본질에 보다 가까이 갈 수 있다. | ||
| ||
| ||
| ||
| ||
| ||
SOA vs. Web Services ..SOA와 웹 서비스의 관계는 많은 자료에서 언급하고 있다. 일반적으로 그 내용은 거의 유사하지만 제시하는 기관마다 약간의 시각차이가 존재하고, 특히 SOA를 정의하는 관점에 따라서도 차이가 존재한다. 여기서는 여러 자료를 토대로 SOA와 웹 서비스의 관계를 도출하고 구체적으로 웹 서비스를 통해 SOA를 구현하는 방법까지 정리하였다.
| ||
| ||
| ||
| ||
| ||
| ||
| ||
SOA vs. EA ..SOA와 EA의 관계는 다양한 시각에서 논의되고 있다. 이 둘의 관계는 바라보는 관점이나 적용 범위에 따라 차이가 있을 수 있으나 SOA가 EA의 하위 아키텍처를 구성한다는 관점과 SOA와 EA가 상호보완적 개념이라는 관점이 언급되고 있다. 여기서는 이러한 SOA와 EA의 관계에 대한 몇 가지 관점들에 대해 설명해 보고자 한다.
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
..이처럼 SOA는 기업의 최종 목표 시스템 아키텍쳐를 구현하기 위한 방안으로서 가장 적절한 대안이라고 할 수 있다. | ||
| ||
Web Services + EA = SOA ?? ..지금까지 SOA, 웹 서비스, EA에 관한 개념과 이들 상호간의 관계에 관하여 다각적인 측면에서 조망해 보았다. 아직은 초기 단계이기 때문인지 대다수가 정답으로 받아들이는 내용은 아직 없다. | ||
| ||
..SOA의 구현을 위한 가장 최적의 기술이 웹 서비스라고 한다면 웹 서비스 성공의 1차 관건은 SOA라는 철학을 기업의 EA에 반영하는 것이다. EA에 반영된 SOA는 EA의 활용/진화 과정을 통해, 웹 서비스 형태로 기업에 내재화 될 것이며 이를 통해 기업은 정보기술분야의 효용성을 증대 시킬 수 있을 것이다. |
I also would like to add some precisions on the differences between ESB (Enterprise Service Bus)
and SOA. There
is a fundamental difference between EAI (and the web service enabled EAI, a.k.a.
ESB) and SOA. EAI relies on a "common information model", with a
central EAI manager, onto which enterprise systems are bolted via
connectors (be it web services, JCA or anything else). The bus represents both
the common information model and the EAI manager. In an ESB, connected systems are not in control, the EAI manager is.
ESB is not SOA. SOA requires a registry onto
which peers registers and find other peers. In a SOA, every peer is at the same
level, there is no center of control, nothing in the middle, therefore no need
for a common
information model. Peers are not defined by their "contract" but
rather by how they interact with each other (i.e. collaborate via a message
choreography). To answer Collaxa's question, IMHO, Indigo is not an ESB, it
is a true SOA framework, just like TME's GAIA or SUN's
JXTA project. (Please
take a look at figure 7 of the BCM introduction). ESB can be viewed as a very
particular case of SOA, a special kind of fabric if you will, but it is
certainly not the only fabric possible.
Another aspect that few people seem to be grasping at the moment is that for building SOAs
we need the
notion of "service domains" (no, this is not the same thing as
Scopes, since scopes have always a context associated to them). This notion is natural as soon as we
think of a company boundary (which will be its own service domain), but the
concept is also useful at a lower level of granularity. It greatly simplifies
problems like management, security, ... but also offer an extra level of
decoupling. WS-CAF is going a bit in this direction with the concept of
coordination, but it stops short of providing "domain level" logic, it
rather relies on well defined composition of web services packaged in a
"composite application".
Summary
Responding to real-time changes and events in a timely manner is becoming one of the most important requirements for an enterprise framework. This article discusses technologies and mechanisms that enable a service-oriented framework to effectively respond to real-time stimuli and, therefore, send and receive synchronous and asynchronous events across layers of an architectural stack without knowing the details of the underlying event system. (2,800 words; January 31, 2005)
nternet transactions, business-to-business systems, peer-to-peer processes, and real-time workflows are too dynamic and too complex to be modeled by traditional sequential-processing methods. Therefore, the need for more sophisticated asynchronous processing techniques is quickly becoming apparent. To address these unpredictable environments, the current trend in systems architecture is service-oriented design and event-driven programming.
A service-oriented architecture (SOA) presents a dynamic runtime environment, where loose couplings between service providers and/or service consumers enable powerful and flexible component interactions. Building a communication model to exploit this power and flexibility is a high priority for competitive software development. An event-driven communication model is able to respond better to real-time changes and stimuli than conventional request/reply mechanisms.
Service-oriented and event-driven architectures are natural fits for distributed systems since they share many of the same characteristics, such as modularity, loose-couplings, and adaptability.
In this article, I discuss the details of designing an effective event-driven and service-oriented platform using Mule, a lightweight event-messaging framework designed around an enterprise service bus (ESB) pattern. Components and applications can use Mule to communicate through a common messaging framework implemented transparently using Java Message Service (JMS) or another messaging technology.
Overview of service-oriented architecture
The term "service-oriented" has evolved to define an architecture where a service is a software component that embodies a core piece of an enterprise's business logic and features the following characteristics:
Services typically focus exclusively on solving business-domain problems.
Generally, service clients rely on configuration data, registries, and software factories to determine the location, protocol, and public interface for each service.
Applications are typically described by what they do, not necessarily by what they are or what they contain. For this reason, it's much more straightforward to describe an application publicly using verbs (services) as opposed to nouns (objects). Since objects define a thing and not an action, an impedance mismatch can occur when attempting to encapsulate what a component does as opposed to what a component is. In SOA, an application is described naturally, since each logical business operation of the application that can be verbalized is a likely candidate for a service. Therefore, SOA solves the impedance mismatch by allowing applications and components to access the functionality of services based on what the services do, i.e., what actions they perform. In turn, application developers can more easily match their needs with the appropriate services, since the interfaces for the services describe more completely the problems they solve.
Overview of event-driven architecture
An event-driven architecture (EDA) defines a methodology for designing and implementing applications and systems in which events transmit between loosely coupled software components and services. An event-driven system is typically comprised of event consumers and event producers. Event consumers subscribe to an intermediary event manager, and event producers publish to this manager. When the event manager receives an event from a producer, the manager forwards the event to the consumer. If the consumer is unavailable, the manager can store the event and try to forward it later. This method of event transmission is referred to in message-based systems as store and forward.
Building applications and systems around an event-driven architecture allows these applications and systems to be constructed in a manner that facilitates more responsiveness, since event-driven systems are, by design, more normalized to unpredictable and asynchronous environments.
Benefits of event-driven design and development
Event-driven design and development provide the following benefits:
EDA and SOA together
Unlike a request/reply system, where callers must explicitly request information, an event-driven architecture (EDA) provides a mechanism for systems to respond dynamically as events occur. In an EDA, events are published by event producers, and event consumers receive events as they happen.
Business systems benefit from the features of both an SOA and an EDA, since an EDA can trigger event consumers as events happen and loosely coupled services can be quickly accessed and queried from those same consumers.
For systems to be most responsive, they must be able to quickly determine the necessary actions when events are triggered. To this end, events should be published and consumed across all boundaries of the SOA, including the layers of the architectural stack and across physical tiers.
Figure 1 illustrates possible events that can be triggered across layers of an architectural stack:
|
In the context of Figure 1, an event can be defined as any published change in a system, platform, component, business, or application process. Events can be high-level and business-oriented, or low-level and technical in character. Because events can be transmitted and received, event-aware applications and services can respond to the underlying changes as needed.
Event taxonomies and causality
The secret to understanding a given event is to know its cause at the time the event occurred, knowledge often referred to as event causality. Event causality is typically divided into two basic categories:
Vertical causality implies an event taxonomy that remains somewhat constant across different layers of a system, as illustrated by the following list:
Horizontal causality implies an event taxonomy that also remains somewhat constant across different layers of a system, as illustrated by the following list:
The benefits of event-driven communication within an SOA are currently being realized by a number of ESB frameworks and platforms. One of the most promising of these within the Java development realm is Mule.
Introducing Mule
Mule is an open source ESB-messaging framework and message broker, loosely based on the staged event-driven architecture (SEDA). SEDA defines a highly concurrent enterprise platform in terms of stages (self-contained application components) connected by queues. Mule uses concepts from SEDA to increase the performance of processing events.
Mule provides support for asynchronous, synchronous, and request-response event processing using disparate technologies and transports such as JMS, HTTP, email, and XML-based Remote Procedure Call. Mule can be easily embedded into any application framework and explicitly supports the Spring framework. Mule also supports dynamic, declarative, content-based, and rule-based message routing. Mule facilitates declarative and programmatic transaction support, including XA transaction support. Mule provides a representational state transfer (REST) API to provide Web-based access to events.
The Mule ESB model drives all services in a system over a decoupled, message-communication backbone. Services registered with the bus have no knowledge of other registered services; therefore, each service is concerned with processing only the events it receives. Mule also decouples container, transport, and transformation details from the services, allowing any kind of object to be registered as a service on the bus.
I use the Mule framework to demonstrate the concepts and ideas discussed in this article.
The Mule architecture
The Mule architecture consists primarily of the following elements:
The Universal Message Object (UMO) API
The UMO API defines the services and interactions of objects to be managed by Mule.
UMO components
UMO components can be any component in the Mule system that receives, processes, and sends data as event messages.
Mule server
The Mule server component is a server application launched to bootstrap the Mule environment.
Descriptors
The descriptor components describe a Mule UMO's attributes. New Mule UMOs can be initialized as needed from their associated descriptor. A descriptor consists of:
Connectors
Connectors are components that provide the implementation for connecting to an external system or protocol and managing the session for that system or protocol. A connector is responsible for sending data to an external message receiver and for managing the registration and deregistration of message receivers.
Providers
Providers are components that manage the sending, receiving, and transformation of event data to and from external systems. They enable connections to external systems or other components in Mule. A provider acts as a bridge from the external system into Mule and vice versa. It is, in fact, a composite of a set of objects used to connect to and communicate with the underlying system. The elements of a provider are:
Endpoint resolvers
Endpoint resolvers determine what method to invoke on a UMO component when the component receives an event.
Transformers
Transformer components transform message or event payloads to and from different data formats. Transformers can be chained together to perform successive transforms on an event before an object receives it.
Message adapters
Message adapters provide a common manner in which to read disparate data from external systems.
Message receivers
Message receivers are listener-endpoint threads that receive data from an external system.
Message dispatchers
Message dispatchers send (synchronous) or dispatch (asynchronous) events to the underlying technology.
Message routers
Message routers are components that can be configured for a UMO component to route a message to deferent providers based on the message or other configuration.
Agents
Agents are components that bind to external services such as Java Management Extension servers.
Mule model
A Mule model encapsulates and manages the runtime behavior of a Mule server instance. A model consists of:
Mule manager
The Mule manager maintains and provides the following services:
The diagram in Figure 2 illustrates a high-level view of the message flow for the Mule architecture.
|
Mule events
Mule events contain event data and properties examined and manipulated by event-aware components. The properties are arbitrary and can be set at any time after an event is created.
The org.mule.umo.UMOEvent
class represents an event occurring in the Mule environment. All data sent or received within the Mule environment is passed between components as an instance of UMOEvent
. The data in a Mule event can be accessed in its original format or in a transformed format. A Mule event uses a transformer associated with the provider that received the event to transform the event's payload into a format the receiving component understands.
The payload for a Mule event is contained within an instance of the org.mule.umo.UMOMessage
interface. A UMOMessage
instance is composed of the payload itself and its associated properties. This interface also acts as a common abstraction of different message implementations provided by different underlying technologies.
The org.mule.extras.client.MuleClient
class defines a simple API that allows Mule clients to send and receive events to and from a Mule server. In most Mule applications, events are triggered by some external occurrence, such as a message received on a topic or a file being deleted from a directory.
The following illustrates how to send an event synchronously to another Mule component:
String componentName = "MyReceiver"; // The name of the receiving component.
String transformers = null; // A comma-separated list of transformers
// to apply to the result message.
String payload = "A test event"; // The payload of the event.
java.util.Map messageProperties = null; // Any properties to be associated
// with the payload.
MuleClient client = new MuleClient();
UMOMessage message = client.sendDirect(componentName,
transformers,
payload,
messageProperties);
System.out.println("Event result: " + message.getPayloadAsString());
An instance of MuleClient
requires a server URL to define the endpoint for the remote Mule server to which the MuleClient
instance will connect. The URL defines the protocol, the message's endpoint destination, and, optionally, the provider to use when dispatching the event. Endpoint examples are:
Mule event processing
Mule can send and receive events in three different ways:
The org.mule.impl.MuleComponent
implementation class provides a concrete component class that includes all the functionality needed to send and receive data and create events.
Objects that execute synchronously are encouraged to implement the org.mule.umo.lifecycle.Callable
interface, which defines a single method, Object onCall(UMOEventContext eventContext)
. The Callable
interface provides UMOs with an interface that supports event calls. Although not mandatory, the interface provides a lifecycle method that executes when the implementing component receives an event. The following illustrates a simple implementation of this interface:
import org.mule.umo.lifecycle.Callable;
public class EchoComponent
implements Callable
{
public Object onCall(UMOEventContext context) throws Exception
{
String msg = context.getMessageAsString();
// Print message to System.out
System.out.println("Received synchronous message: " + msg);
// Echo transformed message back to sender
return context.getTransformedMessage();
}
}
The object returned from the onCall()
method can be anything. When the UMOLifecycleAdapter
for the component receives this object, it will first see if the object is a UMOMessage
; if the object is neither a UMOMessage
nor null, a new message will be created using the returned object as the payload. This new event will then publish via the configured outbound router, if one has been configured for the UMO and the setStopFurtherProcessing(true)
method wasn't called on the UMOEventContext
instance.
A simple event framework using Mule
Let's put the pieces of Mule together to construct a simple event framework. The framework consists of an event manager responsible for registering and deregistering services that can receive events, and for synchronously and asynchronously routing messages to these services.
The Mule "vm" protocol requires that a configuration file be located at a directory named META-INF/services/org/mule/providers/vm
, relative to the event manager's working directory. This file defines numerous components for the protocol, such as the connector and dispatcher factory. The file's contents are as follows:
connector=org.mule.providers.vm.VMConnector
dispatcher.factory=org.mule.providers.vm.VMMessageDispatcherFactory
message.receiver=org.mule.providers.vm.VMMessageReceiver
message.adapter=org.mule.providers.vm.VMMessageAdapter
endpoint.builder=org.mule.impl.endpoint.ResourceNameEndpointBuilder
A simple interface defines the event manager's public view:
package com.jeffhanson.mule;
import org.mule.umo.FutureMessageResult;
public interface EventManager
{
/**
* Sends an event message synchronously to a given service.
*
* @param serviceName The name of the service to which the event
* message is to be sent.
* @param payload The content of the event message.
* @return Object The result, if any.
* @throws EventException on error
*/
public Object sendSynchronousEvent(String serviceName,
Object payload)
throws EventException;
/**
* Sends an event message asynchronously to a given service.
*
* @param serviceName The name of the service to which the event
* message is to be sent.
* @param payload The content of the event message.
* @return FutureMessageResult The result, if any.
* @throws EventException on error
*/
public FutureMessageResult sendAsynchronousEvent(String serviceName,
Object payload)
throws EventException;
/**
* Starts this event manager.
*/
public void start();
/**
* Stops this event manager.
*/
public void stop();
/**
* Retrieves the protocol this event manager uses.
* @return
*/
public String getProtocol();
/**
* Registers a service to receive event messages.
*
* @param serviceName The name to associate with the service.
* @param implementation Either a container reference to the service
* or a fully-qualified class name.
*/
public void registerService(String serviceName,
String implementation)
throws EventException;
/**
* Unregisters a service from receiving event messages.
*
* @param serviceName The name associated with the service to unregister.
*/
public void unregisterService(String serviceName)
throws EventException;
}
The event-manager implementation class is encapsulated within a factory class, thereby allowing the implementation to change as needed without affecting the event manager's clients. The event-manager implementation is shown below:
package com.jeffhanson.mule;
import org.mule.umo.*;
import org.mule.extras.client.MuleClient;
import org.mule.impl.endpoint.MuleEndpoint;
import org.mule.config.QuickConfigurationBuilder;
import java.util.HashMap;
import java.util.Map;
public class EventManagerFactory
{
private static HashMap instances = new HashMap();
/**
* Retrieves the event manager instance for a given protocol.
*
* @param protocol The protocol to use.
* @return EventManager The event manager instance.
*/
public static EventManager getInstance(String protocol)
{
EventManager instance = (EventManager)instances.get(protocol);
if (instance == null)
{
instance = new EventManagerImpl(protocol);
instances.put(protocol, instance);
}
return instance;
}
/**
* A concrete implementation for a simple event manager.
*/
private static class EventManagerImpl
implements EventManager
{
private UMOManager manager = null;
private QuickConfigurationBuilder builder = null;
private MuleClient eventClient = null;
private String protocol = null;
private MuleEndpoint receiveEndpoint = null;
private MuleEndpoint sendEndpoint = null;
private EventManagerImpl(String protocol)
{
this.protocol = protocol;
}
/**
* Starts this event manager.
*/
public void start()
{
try
{
builder = new QuickConfigurationBuilder();
manager = builder.createStartedManager(true,
protocol + "tmp/events");
eventClient = new MuleClient();
receiveEndpoint = new MuleEndpoint(protocol
+ "tmp/events/receive");
sendEndpoint = new MuleEndpoint(protocol + "tmp/events/send");
}
catch (UMOException e)
{
System.err.println(e);
}
}
/**
* Stops this event manager.
*/
public void stop()
{
try
{
manager.stop();
}
catch (UMOException e)
{
System.err.println(e);
}
}
/**
* Retrieves the protocol this event manager uses.
* @return
*/
public String getProtocol()
{
return protocol;
}
/**
* Registers a service to receive event messages.
*
* @param serviceName The name to associate with the service.
* @param implementation Either a container reference to the service
* or a fully-qualified class name
* to use as the component implementation.
*/
public void registerService(String serviceName,
String implementation)
throws EventException
{
if (!manager.getModel().isComponentRegistered(serviceName))
{
try
{
builder.registerComponent(implementation,
serviceName,
receiveEndpoint,
sendEndpoint);
}
catch (UMOException e)
{
throw new EventException(e.toString());
}
}
}
/**
* Unregisters a service from receiving event messages.
*
* @param serviceName The name associated with the service to unregister.
*/
public void unregisterService(String serviceName)
throws EventException
{
try
{
builder.unregisterComponent(serviceName);
}
catch (UMOException e)
{
throw new EventException(e.toString());
}
}
/**
* Sends an event message synchronously to a given service.
*
* @param serviceName The name of the service to which the event
* message is to be sent.
* @param payload The content of the event message
* @return Object The result, if any.
* @throws EventException on error
*/
public Object sendSynchronousEvent(String serviceName,
Object payload)
throws EventException
{
try
{
if (!manager.getModel().isComponentRegistered(serviceName))
{
throw new EventException("Service: " + serviceName
+ " is not registered.");
}
String transformers = null;
Map messageProperties = null;
UMOMessage result = eventClient.sendDirect(serviceName,
transformers,
payload,
messageProperties);
if (result == null)
{
return null;
}
return result.getPayload();
}
catch (UMOException e)
{
throw new EventException(e.toString());
}
catch (Exception e)
{
throw new EventException(e.toString());
}
}
/**
* Sends an event message asynchronously.
*
* @param serviceName The name of the service to which the event
* message is to be sent.
* @param payload The content of the event message.
* @return FutureMessageResult The result, if any
* @throws EventException on error
*/
public FutureMessageResult sendAsynchronousEvent(String serviceName,
Object payload)
throws EventException
{
FutureMessageResult result = null;
try
{
if (!manager.getModel().isComponentRegistered(serviceName))
{
throw new EventException("Service: " + serviceName
+ " is not registered.");
}
String transformers = null;
Map messageProperties = null;
result = eventClient.sendDirectAsync(serviceName,
transformers,
payload,
messageProperties);
}
catch (UMOException e)
{
throw new EventException(e.toString());
}
return result;
}
}
}
The Mule framework dispatches messages by the payload's data type. The event framework can exploit this payload-based dispatching mechanism by defining generic event methods to act as event receivers in the services registered with the event manager. The following class defines one of these services with three overloaded event methods named receiveEvent()
:
package com.jeffhanson.mule;
import java.util.Date;
public class TestService
{
public void receiveEvent(String eventMessage)
{
System.out.println("\n\nTestService.receiveEvent(String) received "
+ "event message: " + eventMessage + "\n\n");
}
public void receiveEvent(Integer eventMessage)
{
System.out.println("\n\nTestService.receiveEvent(Integer) received "
+"event message: " + eventMessage + "\n\n");
}
public void receiveEvent(Date eventMessage)
{
System.out.println("\n\nTestService.receiveEvent(Date) received "
+ "event message: " + eventMessage + "\n\n");
}
}
The event manager's client application sends three events to the test service to test each receiveEvent()
method. The client application follows:
package com.jeffhanson.mule;
import org.apache.log4j.Logger;
import org.apache.log4j.Level;
import org.apache.log4j.BasicConfigurator;
import java.util.Date;
public class EventClient
{
static Logger logger = Logger.getLogger(EventClient.class);
public static void main(String[] args)
{
// Set up a simple configuration that logs on the console.
BasicConfigurator.configure();
logger.setLevel(Level.ALL);
try
{
EventManager eventManager =
EventManagerFactory.getInstance("vm://");
eventManager.start();
String serviceName = TestService.class.getName();
String implementation = serviceName;
eventManager.registerService(serviceName, implementation);
Object result =
eventManager.sendSynchronousEvent(serviceName, "A test message");
if (result != null)
{
System.out.println("Event result: " + result.toString());
}
result =
eventManager.sendSynchronousEvent(serviceName, new Integer(23456));
if (result != null)
{
System.out.println("Event result: " + result.toString());
}
result =
eventManager.sendSynchronousEvent(serviceName, new Date());
if (result != null)
{
System.out.println("Event result: " + result.toString());
}
eventManager.stop();
}
catch (EventException e)
{
System.err.println(e.toString());
}
}
}
The Mule platform's simplifications and abstractions that the preceding framework provides enable you to send and receive synchronous and asynchronous events across layers of an architectural stack without knowing the details of the underlying event system. The use of the Factory pattern and SOA principles are exploited to facilitate a loosely-coupled and extensible design.
Summary
Designing an effective event-driven software system can grow complex when services and processes need to interact across multiple tiers and protocols. However, a service-oriented architecture built around a properly designed event-management layer using standard industry patterns can reduce or even eliminate these problems.
The Mule platform provides APIs, components, and abstractions that can be used to build a powerful, robust, event-driven system that is scalable and highly-maintainable.
About the author
Jeff Hanson has more than 18 years of experience in the software industry. He has worked as a senior engineer for the Windows OpenDoc project and as lead architect for the Route 66 framework at Novell. He is currently the chief architect for eReinsure.com, building Web services frameworks and platforms for J2EE-based reinsurance systems. Hanson has also authored numerous articles and books including Pro JMX: Java Management Extensions (Apress, November 2003; ISBN: 1590591011) and Web Services Business Strategies and Architectures (Wrox Press, August 2002; ISBN: 1904284132).