실제 애플리케이션 개발 경험을 보유한 설계 전문가들로부터 개발, 구축, 운영에 관련한 고급 BPEL 개념과 베스트 프랙티스를 배워 봅시다.

기존 애플리케이션을 컴포지트 애플리케이션(composite application)으로 통합하기 위한 보다 개방적이고 유연한 대안으로 SOA(service-oriented architecture)가 각광받고 있습니다. SOA의 구현 작업은 크게 두 단계로 나뉘어집니다. 먼저, 기존 애플리케이션을 재활용 가능한 서비스로 분할해야 합니다. 두 번째로, 이 서비스들을 유연한 비즈니스 프로세스 내에 “통합(orchestrate)”해야 합니다.

업계의 SOA 구현 노력을 지원하기 위한 목적에서, OTN은 SOA 및 BPEL 분야의 전문가들이 집필진으로 참여하는 새로운 시리즈 “SOA 베스트 프랙티스: BPEL Cookbook”을 기획하였습니다. 비즈니스 룰의 관리, BPEL 프로세스의 다이내믹한 생성, BPEL과 고전적 EAI 미들웨어의 통합 등을 주제로, 필자들이 실제 IT 환경에서 BPEL을 성공적으로 적용할 수 있었던 비결을 알려 드리게 될 것입니다.

이 연재에 관련한 의견 및 질문은 BPEL 사용자 포럼에 올려 주시기 바랍니다. BPEL에 관련한 개인적인 경험을 OTN 커뮤니티에서 공유하고자 하는 경우에도, 포럼을 통해 의견을 전달해 주시면 감사하겠습니다.
Oracle BPEL Process Manager를 직접 테스트해 보고자 하시는 경우, 제품 다운로드 페이지를 참고하시기 바랍니다. (15분 안에 설치를 완료하실 수 있습니다!)

Edwin Khodabakchian, VP, BPEL Development
Dave Shaffer, Director Product Management, Oracle BPEL Process Manager
Harish Gaur, Principal Product Manager and "BPEL Cookbook" Editor
Markus Zirn, Director, Strategic Customer Program

.최근 정보기술의 방향에서 중요한 키워드 중 하나가 바로 서비스(Service)이다. 서비스는 정보기술이 현실에서 지향하는 바를 한 마디로 설명할 수 있는 중요한 단어이다. 서비스 지향 아키텍쳐(Services-Oriented Architecture; 이하 SOA) 역시 서비스의 관점에서 소프트웨어 아키텍쳐를 조망하는 기술로 최근 많은 각광을 받고 있으며, 시장조사업체인 가트너 그룹은 2006년까지 전 세계 비즈니스 애플리케이션의 80% 이상이 SOA를 기반으로 개발될 것이라고 전망하고 있다.
..SOA의 설명을 위해 자연스럽게 떠올리게 되는 두 가지 키워드가 웹 서비스(Web Services)와 전사적 아키텍처(Enterprise Architecture; 이하 EA)이다. 웹 서비스와 EA는 기업 및 공공기관에서 가장 관심을 높게 보이는 기술 이슈이다. 국내의 모든 공공기관들은 EA를 필히 구축해야 하고 전자정부 애플리케이션의 통합 및 연계를 위해서는 기업에 종속적인 EAI 메카니즘이 아닌 표준화된 기술 즉, 웹 서비스를 반드시 적용하도록 규정하고 있다.
..본 고에서 다루고자 하는 내용은 국가적 필수 적용 기술인 웹 서비스, EA와 새로이 떠오르고 있는 기술인 SOA의 관계를 도출하는 것이다. 그렇게 함으로써 SOA의 적용에 Web Services와 EA가 어떤 역할을 할 수 있는 지를 파악하고자 한다.
..이를 위해 먼저 SOA의 개념에 대해 간단히 설명한 후 Web Services, EA와의 관련성을 각각 분석한 후 결론 부문에서 이들 세 기술간의 관계를 도출하였다.

SOA 개

..SOA는 소프트웨어 아키텍처의 일종이다. 따라서, SOA를 이해하기 위해서는 이를 구성하고 있는 요소들을 파악할 필요가 있는데, 본 절에서는 먼저 SOA와 서비스를 정의하고 이를 기반으로 구성요소들을 살펴보도록 한다.

1) SOA의 정의
..사실 SOA는 이미 CORBA나 DCOM등의 분산 객체 기술에서 그 기본 개념이 사용되었으나, 기술적인 문제(기술적인 미성숙 및 공개 표준의 부재)와 비즈니스 문제들(주요 소프트웨어 벤더들 간 협력의 부재)로 인하여 그리 큰 주목을 받지 못했다. 하지만 XML 기반의 웹 서비스 기술이 등장하면서 SOA는 새롭게 조명을 받고 있다.
..W3C는 SOA를 "호출 가능한 컴포넌트의 집합"으로 정의 하고 있다. 여기서 컴포넌트는 그 인터페이스의 정의 내용이 공개(publish)?발견(discovery) 가능한 것을 의미한다.
..하지만 CBDI는 이 정의에 대해 두 가지 문제점을 지적하고 있다. SOA가 단순한 컴포넌트의 집합이 아니라는 점과, 정의 자체가 아키텍처의 구성 방법 보다는 이미 정의되어 있는 컴포넌트만을 염두 해두고 있다는 점이다. 따라서 CBDI는 SOA를 "애플리케이션의 기능들을 사용자(consumer)에 적합한 크기(granularity)로 공개한 서비스들의 집합으로 제공하고 사용되게 하는 정책(policy), 적용(practice), 또는 프레임워크(framework)"로 정의하고, 이 때 서비스는 "단일한 표준기반의 인터페이스 형태를 사용하여 구현과 독립적으로 추상화되며, 호출(invoke)되고, 공개(publish)되며, 발견(discover)할 수 있는 것"이라 정의하였다.
..즉, SOA란 서비스라 불리는 분할(decomposition)된 애플리케이션 조각들을 단위로 느슨하게 연결해 하나의 완성된 애플리케이션으로 만드는 아키텍처이다.


2) SOA의 구성요소
..<그림 2>는 SOA의 기본 구성요소를 도시하고 있는데, 각 요소는 다음과 같다.








- 서비스 사용자(Service Consumer) : '서비스 제공자'에 의해 제공되고 있는 하나 이상의 서비스를 사용한다.
- 서비스 제공자(Service Provider) : '서비스 사용자'가 호출시 입력하는 값을 가공하여, 그에 해당하는 결과를 제공한다. 경우에 따라 '서비스 제공자'는 또 다른 - - '서비스 제공자'의 서비스를 사용하는 '서비스 사용자'가 될 수도 있다.
- 서비스 레지스트리(Service Registry) : 서비스에 대한 설명 정보(descriptions)를 저장하고 있다. '서비스 제공자'는 자신이 제공하고 있는 서비스를 등록하고, '서비스 사용자'는 자신의 원하는 서비스를 발견하여 사용한다.

위의 그림으로부터 우리는 SOA를 이해하기 위한 세가지 주요 요소를 추출할 수 있다. 서비스, 메시지 그리고 서비스 발견 등이 그것이다. 이들 각각에 대한 이해를 통해, 우리는 SOA의 본질에 보다 가까이 갈 수 있다.

가. 서비스(Services)
..SOA의 관점에서 서비스는 인터페이스를 통해 자신이 가진 비즈니스 프로세스를 처리할 수 있는 컴포넌트로 정의된다. <그림 3>과 같이 서비스는 인터페이스와 구현 부분으로 구성된다. 서비스가 가지는 특징을 다음과 같이 3가지로 요약할 수 있다.
..- 서비스의 인터페이스는 플랫폼에 독립적이다
..- 서비스는 동적으로 검색될 수 있으며, 호출될 수 있다.
..- 서비스는 self-contained하다. 즉, 자신의 상태를 스스로 유지한다.
..서비스의 탄생으로 인해 자체적으로 소프트웨어를 만드는 기업은 점차 사라지고, 향후에는 만들어져 있는 소프트웨어를 서비스 단위로 구입하여 사용하는 패러다임이 대세를 이룰 것으로 예상된다.
나. 메시지 (Messages)
..SOA를 이루는 두 번째 중요한 개념은 메시지이다. 서비스 제공자와 서비스 사용자는 메시지를 통해 서로 통신한다. 서비스 제공자는 서비스 명세를 통해 자신이 가진 서비스의 인터페이스를 공개하는데, 이 명세 내에는 서비스가 제공하는 기능과 이를 이용하기 위해 사용자와 주고 받아야 하는 메시지의 형식이 정의되어 있다. SOA 관점에서 서비스는 플랫폼 독립적이어야 하므로, SOA에서 정의되는 메시지는 특정 기술에 독립적이어야 한다. <그림 4>는 서비스 제공자와 서비스 사용자가 메시지를 통해 통신하는 모습을 보여준다.

..이러한 SOA 메시지를 체계를 응용하면 <그림 5>와 같이 보다 복잡한 아키텍처를 구성할 수 있다. 그림과 같이 서비스 제공자는 동시에 서비스 사용자가 될 수 있다. 서비스 제공자는 다른 서비스 제공자로부터 비즈니스 프로세스나 컨텐츠 등을 제공 받아 보다 가치 있는 서비스를 제공할 수 있다.

다. 서비스 발견(Discovery)
..서비스 발견이란 서비스 사용자가 서비스 레지스트리로부터 자신의 원하는 서비스 제공자를 찾는 작업을 말한다. 이를 위해서는 서비스 레지스트리는 서비스를 등록하고 발견하는 기능을 제공해야 한다. SOA의 관점에서 서비스 레지스트리는 다음과 같은 요구사항을 만족해야 한다.
..- 서비스의 확장성(scalability) 보장
..- 서비스 사용자와 제공자의 분리 (decoupling)
..- 서비스의 동적인 변경 기능 제공 (hot update)
..- 서비스 사용자를 위한 검색 기능 제공 (동적인 검색 기능 포함)

3) SOA의 특징
..SOA가 가지고 있는 중요한 특징을 정리하면 다음과 같다.

- 서비스는 발견이 가능하고 동적으로 바인딩 된다.
- 서비스는 컴포넌트와 같이 독립된 모듈이다.
- 서비스의 플랫폼간 상호 운용이 가능하다.
- 서비스는 느슨하게 연결된다.
- 서비스는 네트워크 주소로 접근 가능한 인터페이스를 갖는다.
- 서비스는 위치 투명성을 제공한다.
- 서비스의 조립이 가능하다.
- 서비스는 자기 치유(self-healing)를 지원한다.

4) SOA의 이점
..SOA는 기업 내의 어플리케이션 아키텍처를 보다 유연하고 확장 가능하도록 구성할 수 있게 하는 패러다임이다. 이러한 특징으로 인해 기업은 SOA를 통해 다음과 같은 이점을 얻을 수 있다.

- 기존 자산을 최대한 이용할 수 있게 한다.
- 빠른 시장 접근이 가능케 한다.
- 전반적인 IT 비용을 절감해준다.
- 위험관리를 용이케 한다.
- 끊임없는 비즈니스 프로세스의 진보를 이루게 한다.
- 프로세스 중심의 아키텍처를 유지할 수 있게 한다.

SOA vs. Web Services

..SOA와 웹 서비스의 관계는 많은 자료에서 언급하고 있다. 일반적으로 그 내용은 거의 유사하지만 제시하는 기관마다 약간의 시각차이가 존재하고, 특히 SOA를 정의하는 관점에 따라서도 차이가 존재한다. 여기서는 여러 자료를 토대로 SOA와 웹 서비스의 관계를 도출하고 구체적으로 웹 서비스를 통해 SOA를 구현하는 방법까지 정리하였다.

1) SOA와 웹 서비스의 관계
..SOA는 웹 서비스 개념보다 먼저 출현하였으며, 웹 서비스 보다 포괄적인 개념이다. SOA는 소프트웨어 개발 패러다임에 가깝고, 웹 서비스는 이러한 SOA의 패러다임을 실현하기 위한 다양한 기술 구현 사례라고 할 수 있다. 이름에서 알 수 있듯이 SOA는 아키텍처이다. 웹 서비스와 달리 특정 기술의 집합이 아니다. SOA는 기술적인 것을 초월할 뿐만 아니라 기술로부터 독립적이다. 비즈니스 환경에서 SOA의 순수한 아키텍처적인 정의는 "호출 가능한 잘 정의된 인터페이스를 갖는 독립된 기능의 서비스로 정의한 애플리케이션 아키텍처"이다. 반면, 웹 서비스는 기술의 집합이며 SOA의 개념을 보다 구체화한 것이다. <그림 6>은 이들 간의 관계를 개념화한 것이다.

..웹 서비스는 단순히 SOA를 구현한 것만은 아니다. 웹 서비스는 SOA 구현의 Best Practice라고 할 수 있다. 왜냐하면 SOA의 근본적인 철학을 고스란히 실현할 수 있도록 플랫폼 독립적인 프로토콜과 기술을 채택했기 때문이다. 앞에서도 밝혔듯이 웹 서비스가 HTTP, XML, SOAP, WSDL, UDDI 등의 프로토콜을 채택한 것은 SOA의 기본적인 요구사항을 만족하기 위해서라고 할 수 있다. 이들 기술은 특정 컴퓨팅 기술에 중립적이며, de-facto 표준에 가깝다.
..웹 서비스는 SOA를 개념 수준에서 구현이 가능한 현실로 끌어올리는데 중요한 역할을 한다. 현재도 웹 서비스를 이루는 기술표준들은 진화하고 있으며, 이들이 보다 견고해짐에 따라 SOA를 채택하기 위한 위험요소도 점차 제거될 것으로 기대된다.

2) 웹 서비스를 이용한 SOA의 구현
..SOA에서 기본적으로 요구하는 컴퓨팅 관련 사항과 웹 서비스의 대응 기술은 다음과 같다.

- SOA는 플랫폼 독립적인 방식으로 호출될 수 있는 서비스로 구성된다 - XML, SOAP
- 서비스는 플랫폼, 프로그래밍 언어에 독립적인 인터페이스를 갖는다. - WSDL
- 서비스는 표준체계에 의해 등록이 가능하며, 동적으로 발견 가능하다. - UDDI

..웹 서비스는 W3C SOAP 1.2 표준을 통해 서비스 사용자와 제공자 사이의 통신을 구현한다. <그림 7>은 이를 표현한 것이다.

..웹 서비스에서 사용하는 서비스 기술의 표준은 WSDL이다. WSDL은 서비스 사용자와 제공자가 주고 받을 메시지를 XML로 정의하며, 모든 프로그래밍 언어에 독립적으로 작동한다.

SOA vs. EA

..SOA와 EA의 관계는 다양한 시각에서 논의되고 있다. 이 둘의 관계는 바라보는 관점이나 적용 범위에 따라 차이가 있을 수 있으나 SOA가 EA의 하위 아키텍처를 구성한다는 관점과 SOA와 EA가 상호보완적 개념이라는 관점이 언급되고 있다. 여기서는 이러한 SOA와 EA의 관계에 대한 몇 가지 관점들에 대해 설명해 보고자 한다.

1) SOA를 EA의 하위 아키텍처로 보는 관점
..<그림 10>처럼 SOA를 EA의 하위 아키텍처의 구현 방안으로 보는 시각으로서 SOA가 EA의 기술 부문 (데이터/애플리케이션/기술)의 아키텍처라는 시각과 EA의 애플리케이션/기술 아키텍처의 일부라는 시각으로 나뉘어 진다. 이들은 SOA를 비즈니스 관점에서는 배제하고 주로 기술 관점, 특히 기업 애플리케이션을 구현하기 위한 기술 아키텍쳐 관점에서 주로 SOA를 바라보고 있다.

가. SOA는 EA의 기술부문(데이터/애플리케이션/기술)에 해당한다.
..SOA가 EA의 기술부문, 즉 데이터/애플리케이션/기술 아키텍처에 해당한다는 관점으로 비즈니스 프로세스 구현에 필요한 기술적인 사항들을 SOA로 구성할 수 있으며 이를 통해 EA가 추구하는 유연하고 민첩한 구조를 달성한다는 관점이다.

SOA를 통한 조직의 데이터 아키텍처 변화를 <그림 11>에서 표현하고 있다. 이처럼 각각의 서비스가 관련된 데이터를 직접 관리하는 분산 데이터 환경으로 변화하게 된다.

나. SOA는 EA 기술아키텍처를 구성하는 패턴(Pattern)의 하나이다.
..이 관점은 가트너 그룹에서 주장하는 EA와 SOA의 관계로 SOA는 EA를 구성하는 하나의 기술 패턴이라는 관점이다. 패턴이란 '정해진 문제점에 대하여 여러 사람들이 공감하는 해결책'이라고 할 수 있다. 이는 <그림 12>의 가트너 EA 프레임워크를 통해 이해할 수 있다. 여기서는 일반적인 매트릭스 형태의 EA 프레임워크와 달리 EA 구성요소들의 수직적이고 계층적인 관계에 중점을 두고 있다.

..가트너의 EA 프레임워크에서 SOA의 위치를 살펴보면 비즈니스 프로세스/스타일 하부의 기술 패턴에 위치하고 있으며 SOA의 구현과 관련된 기술들은 패턴의 하부를 구성하는 기술 단위체인 벽돌(Brick) 레벨에 위치하고 있는 것을 알 수 있다.

2) To-Be 아키텍쳐의 구현 방안으로서의 SOA
..EA는 그 정의에서 알 수 있듯이 As-Is 아키텍처와 To-Be 아키텍처 그리고 To-Be 아키텍처의 구현계획과 관련된 표준/가이드로 구성 되어 있다. To-Be 아키텍처의 구현 방법으로는 신규 개발, 외부도입, 기존 시스템의 전환(migration) 등의 방안이 있으며, 이중 기존 시스템의 전환 방안에 SOA가 적용 될 수 있다. 이는 CBDi에서 제시하는 방안으로 <그림 13> 과 같이 기존 시스템을 전환할 수 있다. 초기에는 획일적인 형태의 레가시 시스템을 웹 서비스와 같은 SOA에 적합한 기술을 적용하여 래핑을 실시하여 외부와의 인터페이스를 정형화한 후 최종적으로는 래핑한 내부의 레가시 시스템을 컴포넌트로 재정립함으로써 완전한 형태의 SOA 구조로 변환할 수 있다.

..이처럼 SOA는 기업의 최종 목표 시스템 아키텍쳐를 구현하기 위한 방안으로서 가장 적절한 대안이라고 할 수 있다.

3) SOA와 EA의 관계
..앞에서 언급된 여러 가지 SOA와 EA의 관계를 분석해 보면, SOA는 EA와 매우 밀접한 관계를 가지고 있다는 것을 알 수 있다. 이들을 다시 정리해 보면, SOA를 단순히 EA의 하위 아키텍쳐로 바라봄으로써 단순히 기술 아키텍쳐를 표현할 수 있는 패턴으로 보는 관점과 보다 넓은 관점에서 미래 지향형 EA를 구축하기 위한 방안으로 볼 수 있다.
..두 가지 관점 모두 의미가 있지만, 후자의 관점이 보다 설득력이 있다. 결론적으로, SOA는 EA가 추구하는 목표들은 명확하게 달성할 수 있게 해주며, EA가 제공하는 조직의 전사적 구조는 SOA의 적용을 용이하게 해주는 상호보완적 관계라고도 할 수 있다.

..이를 그림으로 표현해보면 <그림 14>와 같다. 즉, 'SOA 개념이 EA에 반영되어 내재화됨으로서 조직의 정보기술구조를 보다 유연하고 민첩하게 할 수 있다'라고 정의하는 것이 바람직하다.

Web Services + EA = SOA ??

..지금까지 SOA, 웹 서비스, EA에 관한 개념과 이들 상호간의 관계에 관하여 다각적인 측면에서 조망해 보았다. 아직은 초기 단계이기 때문인지 대다수가 정답으로 받아들이는 내용은 아직 없다.
그래서 본 고에서는 이들 간의 관계를 주관적이긴 하지만 앞선 연구결과들의 객관성을 반영하면서 전체가 지향하는 방향에 맞게 이들의 관계를 정립해 보았으며, 최종 SOA 방정식의 결과로 아래의 두 가지 명제를 도출하였다.
.."웹 서비스는 SOA의 구현을 위한 현존하는 최적의 기술 대안이다."
.."SOA는 차세대(To-Be) EA 구현을 위한 최적의 아키텍쳐이다."
..이를 그림으로 표현하면 <그림 15>와 같다. SOA는 EA의 모든 부분을 구현할 수 있는 차세대 아키텍쳐이며, 웹 서비스는 SOA의 기술 도메인과 EA의 기술 아키텍쳐, 비즈니스 프로세스 영역을 담당하고 있으며, SOA 구현을 위한 최적의 기술이라고 할 수 있다.

..SOA의 구현을 위한 가장 최적의 기술이 웹 서비스라고 한다면 웹 서비스 성공의 1차 관건은 SOA라는 철학을 기업의 EA에 반영하는 것이다. EA에 반영된 SOA는 EA의 활용/진화 과정을 통해, 웹 서비스 형태로 기업에 내재화 될 것이며 이를 통해 기업은 정보기술분야의 효용성을 증대 시킬 수 있을 것이다.
..이러한 구조는 기업의 정보시스템 구조를 느슨하게 연결된(Loosely Coupled) 형태로 만들어 변화하는 비즈니스 환경에 보다 유연하고 신속하게 대응할 수 있는 능력을 제공한다. 즉, 비즈니스 환경이 변하여 그에 대한 정보기술부문의 요구사항이 발생하면 EA에 정의되어 있는 SOA에 관련된 기술, 표준 등을 통해 자체적으로 서비스를 개발하거나 표준화된 인터페이스에 적합한 외부 서비스를 서비스 중개자(Service Broker)를 통해 조달 하여 비즈니스 부문의 요구사항에 보다 신속하게 대응 할 수 있는 것이다.
..긍극적으로 SOA, 웹 서비스, EA는 미래지향적인 기업의 정보기술구조를 구현하고 관리하기 위해 꼭 필요하며, 이들은 서로가 독립적으로 위치하기도 하지만 상호간에 연결도가 높은 철학, 기술, 개념이라고 할 수 있다

Java generics support in Eclipse V3.1

Document options Print this page E-mail this page Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Intermediate

Neal Ford (nealford@nealford.com), Application Architect, ThoughtWorks

18 Oct 2005

Java™ 5 offers generics support, a feature developers requested for years. It represents a significant upgrade to the Java programming language. With something as complex as generics also comes challenges, both for tool vendors and developers. This article highlights how Eclipse has responded and the changes wrought by generics to the Java language. It shows how to take full advantage of generics within Eclipse, including support in Quick Assist, Quick Fix, refactoring, and project preferences. It also shows some subtle and important aspects of a fully generic language.

Generics in Java

The creators of Java technology have talked about adding generics support to the language almost since the first version. C++ supports generics through the Standard Template Library, but the implementation is hampered by the lack of a single unified parent class for all other classes (embodied in the Object class in Java). The generics support in the Java programming language is the most significant syntax change in its history. Tools support has proceeded more slowly than for other SDK upgrades for obvious reasons. Now, though, you have excellent support for these new language features in Eclipse V3.1. This article highlights some of these new features.

Back to top

Java 5 Projects

To turn on generics support in Eclipse V3.1, you need Java 5 on your machine, which you can download from the usual places. The generics support comes along with project properties in the compiler settings pages. That means you can have separate SDK settings per project, just as in the past. To create a project that uses generics, you have to specify the language level during the creation of the project or through the project properties of an existing project.

Two specific property pages pertain to Java 5 settings. The first specifies compiler settings.

Unless you have set the default project settings in Eclipse for Java 5, you will need to override those settings for this project. The JDK compliance section allows you to determine the settings for source and class files. When setting level 5.0 for source files, you get a slew of new Content Assist and refactoring options.

The other pertinent properties dialog is the Errors/Warnings section in the tree view.

The wealth of J2SE 5 options control what kinds of errors and warnings (see Table 1) Eclipse will generate for your Java 5 code.

Once you have all your project options set to your liking, you can start using generics in Eclipse.

Back to top

Porting from Specific to Generic

Consider this simple class in Listing 1, which creates a list of Employee and Manager objects (Manager extends Employee), prints them, gives them a raise, then prints them again.

package com.nealford.devworks.generics.generics;



import java.util.ArrayList;

import java.util.Collections;

import java.util.List;



public class HR {



    public HR() {

        List empList = new ArrayList(5);

        empList.add(new Employee("Homer", 200.0, 1995));

        empList.add(new Employee("Lenny", 300.0, 2000));

        empList.add(new Employee("Waylon", 700.0, 1965));

        empList.add(new Manager("Monty", 2000.0, 1933, 

                (Employee) empList.get(2)));

        

        printEmployees(empList);

        

        System.out.println("----- Give everyone a raise -----");

        for (int i = 0; i < empList.size(); i++)

            ((Employee) empList.get(i)).applyRaise(5);

        

        printEmployees(empList);

        

        System.out.println("The maximum salary for any employee is "+

                Employee.MAX_SALARY);

        

        System.out.println("Sort employees by salary");

        Collections.sort(empList);

        printEmployees(empList);

        

        System.out.println("Sort employees by name");

        Collections.sort(empList, new Employee.NameComparer());

        printEmployees(empList);

        

        System.out.println("Sort employees by hire year");

        Collections.sort(empList, Employee.getHireYearComparator());

        printEmployees(empList);



    }

    

    public void printEmployees(List emps) {

        for (int i = 0; i < emps.size(); i++) 

            System.out.println(emps.get(i));

    }

    

    public static void main(String[] args) {

        new HR();

    }

}

If you turn on Java 5 support, a variety of warnings will light up for this code.

Back to top

Quick Fix features

The Quick Fix feature in Eclipse appears as a lightbulb in the editor gutter anytime Eclipse wants to suggest an improvement to your code. In the code from Listing 1, you will see a variety of Quick Fixes.

Quick Fix provides a lightbulb and a wavy yellow line indicating improvements. If you roll over the wavy yellow line, you will see the suggestion that appears in Figure 4.

The Quick Fix suggestion listed here is just that -- a suggestion. The lightbulbs in the gutter are offered to add a local variable for the return of the add() method of List, which returns a boolean, which is ignored, in this case.

To address the Quick Fix suggestion, move to the refactoring menu. A few refactorings in Eclipse directly relate to generics in Java 5. The "Infer Generic Type Arguments" refactoring will add generics support to the list. The first dialog allows you to pick options.

The first option relates to the inference that the clone() method will return the receiver type, not another (related class). Well-behaved classes generally observe this rule; uncheck this box if you know that your class doesn't. The second option, when unchecked, will leave the "raw" (nongeneric) parameter in place, rather than infer the correct generic parameter type.

As in most refactorings in Eclipse, you can preview what changes will occur in your class. The Preview button on this dialog yields the dialog shown in Figure 6.

The updated code looks like this:

List<Employee> empList = new ArrayList<Employee>(5);

empList.add(new Employee("Homer", 200.0, 1995));

empList.add(new Employee("Lenny", 300.0, 2000));

empList.add(new Employee("Waylon", 700.0, 1965));

empList.add(new Manager("Monty", 2000.0, 1933, 

        empList.get(2)));

Two interesting changes have occurred to the code. First -- and most obvious -- the List and ArrayList declarations are now generic for Employee types. The second -- more subtle -- change is in the last line. If you look at the original empList addition of the Manager class, it requires a typecast to an Employee for the Assistant field in the last parameter. The Infer refactoring was smart enough to remove the now unnecessary type cast.

Before leaving Quick Fix, there is one other aspect that is interesting in the Java 5 support added by Eclipse: You can now receive suggestions for supplying annotations for methods, such as @Override. You also have Content Assist for annotations.

Back to top

Quick Assist features

Eclipse V3.1 has added a Quick Assist to facilitate generics support in Java 5. Consider this mundane for() loop, found in the printEmployees() method shown in Listing 3.

public void printEmployees(List<Employee> emps) {

    for (int i = 0; i < emps.size(); i++) 

        System.out.println(emps.get(i));

}

Along with support for generics, Java 5 now supports a for...each loop. Quick Assist offers to change this for loop into a for...each, which yields the code shown in Listing 4.

public void printEmployees(List<Employee> emps) {

    for (Employee emp : emps) 

        System.out.println(emp);

}

This version is much cleaner because it eliminates the i variable and the call to get() entirely.

Back to top

Generic types

Eclipse V3.1 has also expanded its support for type operations to extend to generic types. This means:

• Generic types can be safely renamed.
  
• Type variables can be safely renamed.
  
• Generic methods can be extracted from or inlined into generic code.
  
• Code Assist can automatically insert appropriate type parameters in parameterized types.

The search facilities in Eclipse have also gotten more intelligent with generic types. Consider this:

public void doEmployeeAnalysis() {

    List<Employee> empList = new ArrayList<Employee>(5);

    List<Date> hireDates = new ArrayList<Date>(5);

    List<Integer> departments = new ArrayList<Integer>(10);

    List<? extends Employee> allMgrs = new ArrayList<Manager>(5);

    . . .

If you highlight the first List<Employee> declaration and select Search > References > Project, Eclipse will show you all the list declarations.

You can also filter these results via a well-hidden feature of the Search window. If you access the Search window menu (in the right-hand corner, beside the minimize and maximize buttons), you get generics-aware filtering options.

If you filter the results using Filter Incompatible, it eliminates the two entries that are not Employee-based. The results are shown in Figure 10.

Back to top

Digging deeper in generics

Unfortunately, Eclipse cannot solve all your generics problems. In fact, sometimes refactorings yield syntactically correct code that is not semantically correct for the problem you are trying to solve. Ironically, life was easier in the pre-generics days because you had to pass everything as generic collections of objects. Now you must be careful to pass the right type of collection.

Consider this example. In the HR application, you add a method that determines retirement age for employees. However, the age of the Employee comes from the Employee super class: Person. Writing a method that takes just employees would work in this one instance, but you do not want to restrict the application to work only with employees. What if you need to trace former employees (as Persons) in the future?

The solution to this problem lies with flexible generic parameters. Consider the code in Listing 6, which accepts any class that extends Person.

public List<Person> empsOverRetirementAge(

                        List<? extends Person> people) {

    List<Person> retirees = new ArrayList<Person>(1);

    for (Person e : people) 

        if (e.getAge() > 65) 

            retirees.add(e);

    return retirees;

}

This method accepts any subclass of Person and is, therefore, more flexible. You should keep this in mind when using generics. In this case, the generic is actually more specific (they should have called this language feature "specifics," anyway). Carefully identifying your parameter types allows you to achieve the same level of flexibility in your code that you had prior to generics, but with the added type security that generics provide.

Back to top

Summary

Generics support is a huge enhancement to the Java programming language, necessitating a long time for tool vendors to catch up. Now that you have good tool support, you should start taking advantage of this advanced language feature. It makes code more readable -- because you eliminate type casts -- and allows the compiler to do more work on your behalf. Anytime you can get compilers and other tools (like IDEs) to perform more work, it means less work for you.

Back to top

Resources

• Start here to find Eclipse project resources.
  
  
  
• Read "Getting started with the Eclipse Platform" to get an overview of Eclipse, including its origin and architecture.
  
  
  
• "AOP@Work: AOP tools comparison, Part 1" delves into AOP frameworks that support generics in the Java programming language.
  
  
  
• developerWorks has published myriad Eclipse articles and tutorials.
  
  
  
• If you are new to generics, read Generics in the Java Programming Language, which provides an overview to the changes in Java 5.
  
  
  
• For a good overview article on generics from Java Pro Magazine, read Language Features of Java Generics.
  
  
  
• Read Quiz: Java 1.5 Generics. It will test your knowledge of generics support in Java 5 -- and it's a good way to kill a few minutes.
  
  
  
• Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
  
  

• Innovate your next open source development project with IBM trial software, available for download or on DVD.
  
  

• Get involved in the developerWorks community by participating in developerWorks blogs.

Back to top

About the author

Neal Ford is an application architect at ThoughtWorks, an IT professional services company. Neal designs and develops applications, instructional materials, magazine articles, courseware, video/DVD presentations, and wrote the books Developing with Delphi: Object-Oriented Techniques, JBuilder 3 Unleashed, and Art of Java Web Development. His primary consulting focus is the building of large-scale enterprise applications. He has also been a speaker at developer conferences.

Get a better handle on Struts actions, with Spring

Three ways to integrate Struts applications with Spring

Document options Print this page E-mail this page Document options requiring JavaScript are not displayed Discuss Sample code Rate this page Help us improve this content

Level: Intermediate

George Franciscus (george.franciscus@nexcel.ca), Principal, Nexcel

11 Oct 2005

Struts Recipes co-author George Franciscus is back with another great Struts integration recipe -- this time for importing Struts applications into the Spring framework. Follow along as George shows you how to revamp Struts actions so they can be managed just like Spring beans. The result is a boosted web framework that easily reaps the benefits of Spring AOP.

The Inversion of Control (IOC) design pattern has been generating buzz for long enough now that you've surely heard of it. If you've used the Spring framework in any capacity, then you've seen its principles in action. In this article, you'll learn about the power of the IOC pattern first-hand as I use its principles to inject a Struts application into the Spring framework.

The advantages of integrating a Struts application into the Spring framework are manifold. First off, Spring was explicitly designed to resolve some of the real-world problems of JEE, such as complexity, poor performance, testability, and much more. Second, the Spring framework includes an AOP implementation that lets you apply aspect-oriented techniques to normal object-oriented code. Third, some might say that the Spring framework just handles Struts better than Struts handles itself. But that's a matter of opinion, so follow along as I demonstrate three approaches to integrating Struts applications into the Spring framework, and then decide for yourself.

The approaches I demonstrate are all relatively simple to execute but they offer distinctly different advantages. So that you can fully understand each approach, I've created a separate working example for each one. See the Download section for the complete example source code. See Resources to download Struts MVC and the Spring framework.

What's so great about Spring?

Spring creator Rod Johnson took a critical eye to Java™ Enterprise software development and suggested that many enterprise issues could be resolved by the strategic use of the IOC pattern, also known as dependency injection. When Rod and a dedicated team of open-source developers put his theories into practice, the result was the Spring framework. In a nutshell, Spring is a lightweight container that makes it easy to wire objects together using an external XML configuration file. Each object can receive a reference to a dependent object by exposing a JavaBean property, leaving you with the simple task of "wiring them up" in an XML configuration file.

IOC and Spring IOC is a design pattern that externalizes application logic so that it can be injected into client code rather than written into it. Combining IOC with the use of programming to interfaces, as the Spring framework does, yields an architecture that reduces the client's dependency on implementation-specific logic. See Resources for more on IOC and Spring.

Dependency injection is a powerful feature, but the Spring framework offers much more. Spring supports pluggable transaction managers to give you a broader range of choices for transaction handling. It integrates leading persistence frameworks while also offering a consistent exception hierarchy. Spring also provides a simple mechanism for applying aspect-oriented code against normal, object-oriented code.

Spring AOP lets you use interceptors to intercept application logic at one or more execution points. Interceptors are widely used for for logging because consolidating an application's logging logic in interceptors results in a more readable, functional code base. As you'll soon see, Spring AOP ships with its own interceptors for addressing cross-cutting concerns and also lets you write your own.

Back to top

Integrating Struts and Spring

Like Struts, Spring can also function as an MVC implementation. Both frameworks have their merits and drawbacks, although most would agree that Struts is still king when it comes to MVC. Many development teams have learned to rely on Struts as the foundation for building quality software under strict deadlines. With so much momentum behind Struts, even development teams that would like to integrate features of the Spring framework don't want to switch to Spring MVC. The good news is that you don't have to. The Spring architecture allows you to connect Struts as your Web framework to Spring-based business and persistence layers. The end result is that you can have your cake and eat it too!

In the recipes that follow, you'll learn three ways to integrate Struts MVC into the Spring framework. I'll expose the cons of each recipe as well as its comparative advantages. Once you've seen all three in action, I'll show you an exciting application of the approach I like best.

Back to top

Three little recipes

Each of the following integration techniques (or recipes) has its merits, as well as its own particular quirks. I'm partial to only one of them, but knowing them all will deepen your understanding of both Struts and Spring. It will also provide you with a broad range of options for dealing with various scenarios. The recipes are as follows:

• Use Spring's ActionSupport class to integrate Struts
  
• Override the Struts RequestProcessor with Spring's DelegatingRequestProcessor
  
• Delegate Struts Action management to the Spring framework

Loading the application context

No matter which technique you use, you will need to use the Spring ContextLoaderPlugin to load the Spring application context for the Struts ActionServlet. Simply add the plug-in to your struts-config.xml file as you would any other plug-in, as shown here:

<plug-in className=

  "org.springframework.web.struts.ContextLoaderPlugIn">

    <set-property property=

      "contextConfigLocation" value="/WEB-INF/beans.xml"/>

 </plug-in>

As previously mentioned, you'll find the complete source for the three fully functional example applications in the Download section. Each example presents a different approach to combining Struts and Spring for a book-search application. You can follow the basics of the examples here, but download the applications to see all the nitty-gritty details!

Back to top

Recipe 1. Use Spring's ActionSupport

Creating a Spring context manually is the most intuitive way to integrate Struts with Spring. To make it even easier, Spring offers a little help. The org.springframework.web.struts.ActionSupport class provides a getWebApplicationContext() method to easily obtain a Spring context. All you need to do is extend your action from Spring's ActionSupport instead of the Struts Action class, as shown in Listing 1:

package ca.nexcel.books.actions;



import java.io.IOException;



import javax.servlet.ServletException;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;



import org.apache.struts.action.ActionError;

import org.apache.struts.action.ActionErrors;

import org.apache.struts.action.ActionForm;

import org.apache.struts.action.ActionForward;

import org.apache.struts.action.ActionMapping;

import org.apache.struts.action.DynaActionForm;

import org.springframework.context.ApplicationContext;

import org.springframework.web.struts.ActionSupport;



import ca.nexcel.books.beans.Book;

import ca.nexcel.books.business.BookService;



public class SearchSubmit extends ActionSupport {   |(1)





  public ActionForward execute(

    ActionMapping mapping,

    ActionForm form,

    HttpServletRequest request,

    HttpServletResponse response)

    throws IOException, ServletException {



    DynaActionForm searchForm = (DynaActionForm) form;

    String isbn = (String) searchForm.get("isbn");

		

    //the old fashion way

    //BookService bookService = new BookServiceImpl();

		

    ApplicationContext ctx = 

      getWebApplicationContext();    |(2)

    BookService bookService = 

      (BookService) ctx.getBean("bookService");   |(3)

        

  Book book = bookService.read(isbn.trim());



    if (null == book) {

      ActionErrors errors = new ActionErrors();

      errors.add(ActionErrors.GLOBAL_ERROR,new ActionError

        ("message.notfound"));

      saveErrors(request, errors);

      return mapping.findForward("failure") ;

  }



    request.setAttribute("book", book);

    return mapping.findForward("success");

  }

}

Let's quickly consider what's happening here. At (1), I create an Action by extending from the Spring ActionSupport class rather than the Struts Action class. At (2), I use the getWebApplicationContext() method to obtain an ApplicationContext. To obtain the business service, I use the context obtained at (2) to look up a Spring bean at (3).

This technique is simple and easy to understand. Unfortunately, it couples the Struts action to the Spring framework. If you ever decide to replace Spring, you would have to rewrite the code. Moreover, because the Struts action isn't under Spring's control, it can't reap the benefits of Spring AOP. This technique may be useful when using multiple independent Spring contexts, but for the most part it's not as desirable a solution as the other two choices.

Back to top

Recipe 2. Override the RequestProcessor

Decoupling Spring from the Struts action is a much smarter design choice. One way to do this is to override the Struts RequestProcessor processor with the org.springframework.web.struts.DelegatingRequestProcessor class, as shown in Listing 2:

<?xml version="1.0" encoding="ISO-8859-1" ?>



<!DOCTYPE struts-config PUBLIC

          "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"

          "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">



<struts-config>

 <form-beans>

    <form-bean name="searchForm" 

      type="org.apache.struts.validator.DynaValidatorForm">

               <form-property name="isbn"    type="java.lang.String"/>

    </form-bean>

  

  </form-beans>



 <global-forwards type="org.apache.struts.action.ActionForward">

     <forward   name="welcome"                path="/welcome.do"/>

     <forward   name="searchEntry"            path="/searchEntry.do"/>

     <forward   name="searchSubmit"           path="/searchSubmit.do"/>

 </global-forwards>



 <action-mappings>

    <action    path="/welcome" forward="/WEB-INF/pages/welcome.htm"/>

    <action    path="/searchEntry" forward="/WEB-INF/pages/search.jsp"/>

    <action    path="/searchSubmit" 

               type="ca.nexcel.books.actions.SearchSubmit"

               input="/searchEntry.do"

               validate="true"

               name="searchForm">

              <forward name="success" path="/WEB-INF/pages/detail.jsp"/>

              <forward name="failure" path="/WEB-INF/pages/search.jsp"/>

    </action>  



 </action-mappings>



 <message-resources parameter="ApplicationResources"/>



 <controller processorClass="org.springframework.web.struts.

   DelegatingRequestProcessor"/> |(1)



 <plug-in className="org.apache.struts.validator.ValidatorPlugIn">

    <set-property property="pathnames" 

      value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/>

 </plug-in>





 <plug-in className="org.springframework.web.struts.ContextLoaderPlugIn">

    <set-property property="csntextConfigLocation" value="/WEB-INF/beans.xml"/>

 </plug-in>

 

</struts-config>

Here, I've used the <controller> tag to override the default Struts RequestProcessor with the DelegatingRequestProcessor. My next step is to register the action in my Spring config file, as shown in Listing 3:

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

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 

  "http://www.springframework.org/dtd/spring-beans.dtd">



<beans>

  <bean id="bookService" class="ca.nexcel.books.business.BookServiceImpl"/>



  <bean name="/searchSubmit" 

    class="ca.nexcel.books.actions.SearchSubmit"> |(1)

     <property name="bookService">

        <ref bean="bookService"/>

     </property>

  </bean>

</beans>

Note that at (1), I've registered a bean using the name attribute to match the struts-config action mapping name. The SearchSubmit action exposes a JavaBean property, allowing Spring to populate the property at run time, as shown in Listing 4:

package ca.nexcel.books.actions;



import java.io.IOException;



import javax.servlet.ServletException;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;



import org.apache.struts.action.Action;

import org.apache.struts.action.ActionError;

import org.apache.struts.action.ActionErrors;

import org.apache.struts.action.ActionForm;

import org.apache.struts.action.ActionForward;

import org.apache.struts.action.ActionMapping;

import org.apache.struts.action.DynaActionForm;



import ca.nexcel.books.beans.Book;

import ca.nexcel.books.business.BookService;



public class SearchSubmit extends Action {

	

  private BookService bookService;

  public BookService getBookService() {

    return bookService;

  }



  public void setBookService(BookService bookService) { | (1)

    this.bookService = bookService; 

  } 



  public ActionForward execute(

    ActionMapping mapping,

    ActionForm form,

    HttpServletRequest request,

    HttpServletResponse response)

    throws IOException, ServletException {



    DynaActionForm searchForm = (DynaActionForm) form;

    String isbn = (String) searchForm.get("isbn");

		

  Book book = getBookService().read(isbn.trim());  |(2)



    if (null == book) {

      ActionErrors errors = new ActionErrors();

      errors.add(ActionErrors.GLOBAL_ERROR,new ActionError("message.notfound"));

      saveErrors(request, errors);

      return mapping.findForward("failure") ;

  }



      request.setAttribute("book", book);

      return mapping.findForward("success");

  }



}

In Listing 4, you can see how to build the Struts action. At (1), I create a JavaBean property. This property is automatically populated by the DelegatingRequestProcessor. This design protects the Struts action from knowing it's being managed by Spring while giving you all the benefits of Spring's action management framework. Because your Struts actions are oblivious to the existence of Spring, you can swap out Spring for some other inversion of control container without refactoring your Struts code.

While the DelegatingRequestProcessor approach is definitely better than the first one, it does have some problems. If you were using a different RequestProcessor, then you would need to integrate the Spring DelegatingRequestProcessor manually. The added code would become a maintenance hassle and would also reduce your application's flexibility going forward. Moreover, there has been some talk of replacing the Struts RequestProcessor with a chain of command. Such a change would negatively impact the longevity of this solution.

Back to top

Recipe 3. Delegate action management to Spring

A much better solution is to delegate Struts action management to the Spring framework. You can do this by registering a proxy in the struts-config action mapping. The proxy is responsible for looking up the Struts action in the Spring context. Because the action is under Spring's control, it populates the action's JavaBean properties and leaves the door open to applying features such as Spring's AOP interceptors.

In Listing 5, the Action class is the same as it was in Listing 4. However, the struts-config is a little different:

<?xml version="1.0" encoding="ISO-8859-1" ?>



<!DOCTYPE struts-config PUBLIC

          "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN"

          "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">



<struts-config>

 <form-beans>

    <form-bean name="searchForm" 

      type="org.apache.struts.validator.DynaValidatorForm">

               <form-property name="isbn"    type="java.lang.String"/>

    </form-bean>

  

  </form-beans>



 <global-forwards type="org.apache.struts.action.ActionForward">

     <forward   name="welcome"                path="/welcome.do"/>

     <forward   name="searchEntry"            path="/searchEntry.do"/>

     <forward   name="searchSubmit"           path="/searchSubmit.do"/>

 </global-forwards>



 <action-mappings>

    <action    path="/welcome" forward="/WEB-INF/pages/welcome.htm"/>

    <action    path="/searchEntry" forward="/WEB-INF/pages/search.jsp"/>

    <action    path="/searchSubmit" 

             type="org.springframework.web.struts.DelegatingActionProxy" |(1)

             input="/searchEntry.do"

             validate="true"

             name="searchForm">

             <forward name="success" path="/WEB-INF/pages/detail.jsp"/>

             <forward name="failure" path="/WEB-INF/pages/search.jsp"/>

    </action>  



 </action-mappings>



 <message-resources parameter="ApplicationResources"/>





 <plug-in className="org.apache.struts.validator.ValidatorPlugIn">

    <set-property 

    property="pathnames" 

    value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/>

 </plug-in>





 <plug-in 

    className="org.springframework.web.struts.ContextLoaderPlugIn">

    <set-property property="contextConfigLocation" value="/WEB-INF/beans.xml"/>

 </plug-in>



 

</struts-config>

Listing 5 is a typical struts-config.xml file, except for one small difference. Instead of declaring the action's class name, it registers the name of Spring's proxy class, as shown at (1). The DelegatingActionProxy class uses the action mapping name to look up the action in the Spring context. This is the context that was declared with ContextLoaderPlugIn.

Registering a Struts action as a Spring bean is very straightforward, as shown in Listing 6. I simply create a bean using the name of the action mapping using the <bean> tag's name attribute (in this case, "/searchSubmit"). The action's JavaBean properties are populated like any Spring bean:

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

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 

 "http://www.springframework.org/dtd/spring-beans.dtd">



<beans>

  <bean id="bookService" class="ca.nexcel.books.business.BookServiceImpl"/>



  <bean name="/searchSubmit"   

        class="ca.nexcel.books.actions.SearchSubmit">

     <property name="bookService">

        <ref bean="bookService"/>

     </property>

  </bean>



</beans>

Back to top

The benefits of action delegation

The action-delegation solution is the best of the three. The Struts action has no knowledge of Spring and could be used in non-Spring applications without changing a single line of code. It's not at the mercy of a change to the RequestProcessor, and it can take advantage of Spring's AOP features.

The benefits of action delegation don't stop there, either. Once you have your Struts action under Spring's control, you can leverage Spring to give them more pizzazz. For example, without Spring, all Struts actions must be threadsafe. If you set the <bean> tag's singleton attribute to "false," however, your application will have a newly minted action object on every request. You might not need this feature, but it's nice to know you have it in your back pocket. You can also take advantage of Spring's lifecycle methods. For example, the <bean> tag's init-method attribute is used to run a method when the Struts action is instantiated. Similarly, the destroy-method attribute executes a method just before the bean is removed from the container. These methods are a great way to manage expensive objects in much the same way as the Servlet lifecycle does.

Back to top

Intercepting Struts

As previously mentioned, one of the chief advantages of combining Struts and Spring, and doing it by delegating Struts actions to the Spring framework, is that you can apply Spring's AOP interceptors to your Struts actions. By applying Spring interceptors to Struts actions, you can tackle cross-cutting concerns with minimal effort.

Spring offers a few built-in interceptors, but I'll show you how to create your own and apply it to a Struts action. To use an interceptor, you need to do three things:

1. Create the interceptor.
   
2. Register it.
   
3. Declare where it will intersect the code.

This is pretty simple stuff but also very powerful. For example, in Listing 7, I create a logging interceptor for a Struts action. This interceptor prints out a statement before every method call:

package ca.nexcel.books.interceptors;



import org.springframework.aop.MethodBeforeAdvice;



import java.lang.reflect.Method;



public class LoggingInterceptor implements MethodBeforeAdvice {



   public void before(Method method, Object[] objects, Object o) throws Throwable {

        System.out.println("logging before!");

    }

}

This interceptor is very simple. The before() method is executed before every method in its intersection. In this case, it prints out a statement, but it could do anything you like. The next step is to register the interceptor in the Spring configuration file, shown in Listing 8:

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

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 

  "http://www.springframework.org/dtd/spring-beans.dtd">



<beans>

  <bean id="bookService" class="ca.nexcel.books.business.BookServiceImpl"/>



  <bean name="/searchSubmit" 

        class="ca.nexcel.books.actions.SearchSubmit">

     <property name="bookService">

        <ref bean="bookService"/>

     </property>

  </bean>



  <!--  Interceptors --> 

  <bean name="logger"    

    class="ca.nexcel.books.interceptors.LoggingInterceptor"/> |(1)



  <!-- AutoProxies -->

  <bean name="loggingAutoProxy" 

        class="org.springframework.aop.framework.autoproxy.

          BeanNameAutoProxyCreator"> |(2)

    <property name="beanNames">

          <value>/searchSubmit</valuesgt; |(3)

    </property>

    <property name="interceptorNames">

        <list>

          <value>logger</value> |(4)

        </list>

    </property>

   </bean>



</beans>

As you've probably noticed, Listing 8 extends the application shown in Listing 6 to include an interceptor. Details are as follows:

• At (1), I register the interceptor.
  
• At (2), I create a bean name autoproxy describing how the interceptor is applied. There are other ways to define intersections, but this approach is common and easy to do.
  
• At (3), I register the Struts action as the bean that will be intercepted. If you wanted to intersect other Struts actions, then you could simply create additional <value> tags under "beanNames."
  
• At (4), when the interception occurs, I execute the name of the interceptor bean created at (1). All the interceptors listed here are applied against the "beanNames."

That's it! As this example shows, putting your Struts actions under control of the Spring framework opens up a whole new set of options for handling your Struts applications. In the case of this example, action delegation makes it easy to utilize Spring interceptors for better logging in Struts applications.

Back to top

In conclusion

In this article, you learned three recipes for integrating Struts actions into the Spring framework. Using Spring's ActionSupport to integrate Struts (as I did in the first recipe) is quick and easy but couples your Struts actions to the Spring framework. If you ever needed to port the application to a different framework you would need to rewrite the code. The second solution of delegating the RequestProcessor cleverly decouples your code, but it doesn't necessarily scale well and may not last long if the Struts RequestProcessor is revised to a chain of command. The third approach is the best of the three: delegating Struts actions to the Spring framework results in decoupled code that lets you utilize Spring's features (such as logging interceptors) in your Struts applications.

Each of the three Struts-Spring integration recipes is realized as a complete working application. See the Download section to study them in detail.

Back to top

Downloads

	Information about download methods			Get Adobe® Reader®

Back to top

Resources

• The Spring series (Naveen Balani, developerWorks, June-September 2005): A four-part introduction to the Spring framework's components and features, including Spring AOP.
  
  
  
• Best practices in Struts development (Palaniyappan Thiagarajan and Pagadala Suresh, developerWorks, June 2004): Includes an overview of the Struts Action component.
  
  
  
• Inversion of Control Containers and the Dependency Injection pattern (Martin Fowler, January 2004): An introduction to IOC containers.
  
  
  
• Introduction to the Spring Framework (Rod Johnson, The ServerSide, May 2005): Spring's creator explains why the Spring framework is important.
  
  
  
• Struts Recipes (George Franciscus and Danilo Gurovich; Manning, 2004): A popular compendium of Struts recipes and best practices.
  
  
  
• Struts In Action (Ted Husted, Cedric Dumoulin, George Franciscus, David Winterfeldt; Manning, 2002): A comprehensive resource for professional Struts developers.
  
  
  
• Spring In Action (Craig Walls and Ryan Breidenbach; Manning, 2005): A Spring resource book for developers by developers.
  
  
  
• The Java technology zone: Find articles about every aspect of Java programming.
  
  

• The Struts framework: A project of the Apache Software Foundation.
  
  
  
• The Spring framework: A layered Java enterprise application framework.
  
  

• Participate in the discussion forum.
  
  
  
• developerWorks blogs: Get involved in the developerWorks community.

Back to top

About the author

	George Franciscus is a Java Enterprise consultant and Struts authority. He is a coauthor of Manning's Struts Recipes and Struts in Action. George offers technical and management consulting services through nexcel.ca.

Document options Print this page E-mail this page Document options requiring JavaScript are not displayed Rate this page Help us improve this co

evel: Introductory

Bobby Woolf , WebSphere J2EE Consultant, IBM Software Services for WebSphere

26 Aug 2005

It's not just for architects: Using an Enterprise Service Bus, the foundation of a Service-Oriented Architecture (SOA), makes life easier for developers, too.

Introduction

Interesting applications rarely live in isolation; an application can't do much that is very useful without working with other applications. Service-Oriented Architecture takes the trend of integrating applications so that they can work together and accelerates it, breaking each application into parts that then must be integrated with each other. The SOA model -- service consumers invoking service providers -- may seem simple, but it introduces two significant problems:

1. How does a consumer find the providers of the service it wants to invoke?
   
2. How can a consumer invoke a service quickly and reliably, because the network is actually slow and unreliable?

It turns out there's a fairly straightforward answer to both these problems, an approach called the Enterprise Service Bus (ESB). An ESB makes service invocation simpler for both the consumer and the provider by handling all of the complexity in between. Not only does an ESB make it simpler for applications (or their parts) to invoke services, it also helps them transfer data and broadcast event notifications. An ESB's design embodies a number of established design patterns and standard specifications.

I wrote this article to help you, the developer, understand why an ESB is a useful and necessary part of application integration, including SOA. The article doesn't focus on definitions or products, but on the functions and capabilities an ESB implements for you so that you don't have to. It shows what an ESB does for you.

Back to top

Invoking services

To help you understand application integration and SOA, I'll start with how Web services work. Web services are only one approach you can use to implement a service invocation. They may not even be the best approach, but they are the most standardized approach available today, and they do help frame the design of what I'm trying to accomplish.

To begin, I must explain the terminology. A Web service is a lot like a function in procedural programming: it has a name, parameters, and a result. The name is a Uniform Resource Identifier (URI), which the Web services provider uses to make the Web service available as an endpoint. The Web services consumer uses the endpoint URI as the address for locating and invoking the Web service. The specific operation and parameters are contained in a request, which the consumer passes into the Web service when it invokes the endpoint. After performing the service, the endpoint passes a response back to the consumer, which indicates success (or an error) and contains the result of the service. So, a consumer invokes a provider's endpoint, passing in a request, and getting back a response.

The current definition of how to implement a Web service is the WS-I Basic Profile 1.1, which consists of SOAP 1.1 over HTTP 1.1 described by Web Services Description Language (WSDL) 1.1. (See Resources for a link to the specification itself.) With SOAP over HTTP, the consumer invokes a service using a SOAP request transported over HTTP in an HTTP request. The consumer blocks synchronously on the HTTP socket waiting for the HTTP response containing the SOAP response. The endpoint's API is described by its WSDL, a contract between the consumer and the provider.

Now that you understand the terminology, let's look at the communication choices a consumer has for invoking a service: synchronous or asynchronous.

Synchronous vs. asynchronous invocation

A consumer can implement a service invocation synchronously or asynchronously. From the consumer's point of view, the difference is this:

• Synchronous – The consumer uses a single thread to invoke the service; the thread sends the request, blocks while the service is running, and waits for the response.
  
• Asynchronous – The consumer uses a pair of threads to invoke the service; one thread sends the request, then a separate thread receives the response.

The terms synchronous and asynchronous are often confused with the terms sequential and concurrent. These latter terms have to do with the order that separate tasks must be performed, whereas synchronous and asynchronous have to do with the way a thread performs a single task, such as invoking a single service. A good way to understand the difference between synchronous and asynchronous invocation is to consider the consequences for crash recovery:

• Synchronous – If the consumer crashes while blocking as the service runs, when it restarts it has no way of reconnecting to the invocation in progress, so the response is lost. The consumer must repeat the invocation and hope it doesn't crash this time.
  
• Asynchronous – If the consumer crashes while waiting for the response after sending the request, when it restarts it can continue waiting for the response, so the response is not lost.

Crash recovery is not the only difference between synchronous and asynchronous invocation, but if you're trying to decide which style a particular invocation uses, looking at the way each handles crash recovery is usually a good way to tell.

Now that you understand the consumer's choices for service invocation communication style, take a look at the consumer's connectivity style choices for connecting to a provider. The consumer may choose from among the following communication styles:

1. Synchronous direct invocation
   
2. Synchronous brokered invocation
   
3. Asynchronous brokered invocation

I will explain each style separately.

Synchronous direct invocation

The SOAP over HTTP style of invoking a Web service is said to be direct: Much like performing a function call, the consumer knows the address of the endpoint and invokes it directly. For the invocation to succeed, the Web service must be operational when the consumer invokes the endpoint and must respond before the consumer times out. If a Web service is deployed to a new location (such as a different Internet domain), the consumer must be made aware of the new URI for the endpoint. To deploy several providers of the same type of service, each provider's endpoint must be deployed to a different URI. To choose between the different service providers, the consumer must know each of their URIs.

For example, consider a simple Web service for getting a stock quote: The consumer passes in a stock symbol and gets back the stock's current price. This service might be provided by several different brokerage companies, each under a different Internet URL. Getting the URL for a Web service is a chicken-and-egg problem. If the consumer knew the location of the endpoint, it could ask the service what its address is, but that's the address the consumer would need so that it could ask for the address.

To get around this problem, the Universal Description Discovery and Integration (UDDI) specification describes a Web service that is a directory, like a phonebook, for locating other Web services. The idea is that the UDDI service is deployed to a well-known address the consumer will already know; then the consumer can use UDDI to find other Web services.

In the case of the stock quote service, the consumer knows the UDDI service's address, which in turn knows the stock quote services' addresses, as shown in Figure 1.

Figure 2 shows how the consumer uses the UDDI service to find the stock quote providers' endpoints and invoke one of them. The process works as follows:

1. The consumer asks UDDI for a list of providers for a service.
   
2. The consumer selects a provider's endpoint from the list returned by UDDI.
   
3. The consumer invokes that endpoint.

Note that the algorithm for selecting a provider is completely up to the consumer; in this example, the consumer just chooses the first one in the list. A real implementation might be more sophisticated.

Notice also that because the service endpoints can change, every time the consumer wants to invoke the service, it should re-query UDDI to see if the providers' details have changed. Having to query UDDI for every service invocation greatly adds to the overhead of invoking the service, especially in the usual case where the providers' details haven't changed.

Synchronous brokered invocation

A shortcoming of the direct invocation approach is that the consumer must know the URI of the provider's endpoint to invoke the service. It uses UDDI as a directory to find that URI. If there are multiple providers, UDDI specifies multiple URIs, and the consumer must select from among them. If a provider changes its endpoint's URI, it must reregister with the UDDI server so that UDDI has the new URI, and then the consumer must re-query UDDI to get the new URI. In effect, this means that every time the consumer wants to invoke a service, it must query UDDI for the endpoint URIs and select from among them. This causes the consumer to waste a lot of effort repeatedly making UDDI lookups and selecting a provider. This approach also forces the consumer to somehow choose a provider from among a seemingly indistinguishable list.

One approach to simplify this problem is to introduce a broker to act as an intermediary for invoking the Web service. The consumer no longer invokes the service provider directly, but rather invokes a service proxy in the broker, which in turn invokes the service provider. The consumer needs to know the URI for the proxy's endpoint and so uses UDDI to find the address, but in this case, UDDI only returns a single URI, so the consumer doesn't have to choose. The consumer probably doesn't even realize that the endpoint is in a proxy; it just knows that it can use this URI for invoking the Web service. The broker coordinates the consumer with the service providers, as shown in Figure 3.

The proxy's URI should be stable: After the consumer uses UDDI to get the proxy's URI the first time it invokes the service, the consumer can reuse that URI for subsequent invocations (at least until the proxy stops working). Meanwhile, the proxy keeps track of the providers, their URIs (which may change between invocations), whether they're available (did the last invocation fail?), their load (how long did the last invocation take?), and so on. The proxy then takes the responsibility for choosing the best provider for each invocation, relieving the consumer of this responsibility. The consumer simply invokes the same proxy at the same address every time, and the proxy takes care of coordinating with the various providers.

Figure 4 shows how the consumer uses the broker to invoke the service, which works in the following way:

1. The consumer asks UDDI for a list of providers for a service. The URI returned by UDDI is actually for the service proxy. UDDI will only return one URI, not several, because the broker only has one proxy for a particular service.
   
2. The consumer invokes the service using the proxy's URI.
   
3. The service proxy selects a service provider from its list of available providers.
   
4. The service proxy invokes the selected provider's endpoint.

Notice that the effort of selecting the provider has moved from the consumer and is now encapsulated in the broker's proxy. This simplifies life for the consumer. Ultimately, the selection process the proxy uses may be no different than the process the consumer would have used. However, because the UDDI server and proxy are encapsulated within the broker, certain efficiencies can be more easily introduced, such as caching UDDI information in the proxy and having the UDDI server notify the proxy when the cached information becomes stale.

Note too that because the proxy's address is stable, the consumer doesn't have to query UDDI repeatedly, once per service invocation. Rather, the consumer only needs to query UDDI once and then can safely cache the proxy's address and use it to invoke the service repeatedly. This greatly lowers the overhead of invoking a service.

Asynchronous brokered invocation

A shortcoming of the synchronous approach is that the consumer must wait while the service is performed -- the consumer's thread must block while the service runs. If the service takes a long time to perform, the consumer may give up before it receives the response. When the consumer makes the request, if none of the service providers are running or if they're all overloaded, the consumer will not be able to wait. And as explained earlier, if the consumer crashes while blocking, even if it restarts the response will be lost and the invocation must be repeated.

A common solution to this problem is for the consumer to invoke the service asynchronously. With this approach, the consumer uses one thread to send the request and another to receive the response. This way the consumer doesn't have to block waiting for the response and can perform other work in the meantime. The consumer is therefore much less sensitive to how long it takes the provider to perform the service.

A broker that enables a consumer to invoke a Web service asynchronously is implemented using a messaging system that uses message queues for sending the request and receiving the response. Like a synchronous service proxy, the pair of message queues acts as a single address the consumer uses to invoke the service, regardless of how many providers may be listening, as shown in Figure 5.

This approach uses the Request-Reply pattern to invoke a Web service. Instead of HTTP as specified in WS-I BP 1.1, message queues now perform the transport. The SOAP request and response are the same as with WS-I BP, but they are now enclosed in messaging system messages.

Figure 6 shows how the consumer invokes the service asynchronously using a broker, which proceeds according to the following steps:

1. The consumer sends the SOAP request as a message on the request queue. The consumer is now finished and can use that thread to perform other work.
   
2. Each of the providers is a consumer on the request queue, which makes them competing consumers. The messaging system determines which provider is able to receive the message and ensures that only one provider receives the message. How this works specifically depends on the implementation of the messaging system.
   
3. The winning provider receives the message from the request queue.
   
4. The provider performs the service.
   
5. The provider sends the SOAP response as a message on the reply queue. The provider is now finished and can use its thread to perform other work (such as waiting for another request).
   
6. The consumer's listener thread receives the message containing the SOAP response.

Notice that the effort of selecting a provider is now encapsulated within the messaging system, simplifying life for the consumer. Notice also that if the consumer crashes after making the request, even if the response comes back in the meantime, the messaging system will save the response on the reply queue until the consumer starts up again.

Note as well that the consumer does not use UDDI to find the request and reply queues. Currently, there is no standard service for returning a pair of queue addresses, so the consumer must just know the addresses. The consumer is either hardcoded with the addresses or reads them from an external configuration file. In the future, either UDDI needs to be extended or a similar service specified that a consumer can query to discover the pair of queues for invoking a particular service.

Now you understand the connectivity style choices for service invocation. Let's look at additional integration capabilities that can also be helpful, then at how you develop an ESB that gives us these abilities.

Back to top

Other integration capabilities

An ESB also gives you the opportunity to go beyond service invocation and integrate applications and parts of an SOA using other techniques. A service invocation is almost always a two-way operation, meaning that a request is sent from the consumer to the provider and a response is sent back in the other direction. Other integration techniques work as one-way operations, where a sender pushes information to the receiver but does not wait for a response; the receiver simply consumes the information without responding.

Data transfer

Sometimes an application simply wants to transfer data to another application without necessarily invoking a procedure in the receiver, and definitely without waiting for a result. This is a classic integration problem: One application has data that another one needs. The sender doesn't need to tell the receiver what to do with the data; it is just making the data available.

A service invocation can be used to transfer data, which is equivalent to invoking a setter method, but that's forcing the data transfer into the RPC paradigm. The data transfer is actually more like a file transfer: data is exported from the sender and imported to the receiver without the sender overtly directing the receiver as to what to do with the data. This is more akin to a document-style SOAP message than an RPC-style message.

Using an ESB for data transfer leverages its abilities to locate the receiver and transfer data reliably. The sender doesn't have to know how to find the receiver, it just has to know how to find the ESB and trust that it will find the receiver. The ESB is also responsible for transferring the data reliably. The sender can simply push the data into the ESB and know that it will be delivered.

For more information about the data transfer technique, see the Document Message pattern. (For more about this, see the book Enterprise Integration Patterns listed in Resources.)

Event notification

Sometimes a change occurs in one application that needs to be announced to other applications. For example, if a customer edits his address in an application, other applications with their own databases should be notified so they can update their records.

Again, one application can invoke a service on another application to inform it of a change, but there are three problems with this approach. The first two problems are the same as those with data transfer. First, a service invocation is too specific about what the receiver should do with the information, and second it tends to be two-way, forcing the sender to wait for a reply (even asynchronously) it doesn't really want.

The third and most significant problem with invoking a service for event notification is that service invocation is inherently one-to-one, consumer-to-provider, whereas event notification is inherently broadcast, one-to-many, to all interested receivers. Using service invocation, the sender would have to keep track of all interested receivers and invoke the service separately on each of them. This broadcasting of the notification is better left to the broker between the sender and the receivers.

Using an ESB for event notification leverages its abilities to keep a list of interested receivers and make sure the notification gets delivered to each one. It enables the sender to issue the notification just once and be assured that the notification will be delivered to all interested receivers, whoever those are. Because the operation is one-way, the sender can go about doing other work while the notifications are being delivered, and the notifications can be delivered concurrently.

For more information about the data transfer technique, see the Event Message pattern. (Again, see the book Enterprise Integration Patterns listed in Resources.)

Back to top

Developing an Enterprise Service Bus

Now you know the difference between invoking a Web service in a provider directly as compared with doing so using a broker. You've also seen how the broker can enable the consumer to invoke the service synchronously or asynchronously.

The broker is often what has come to be called an ESB. So how does an ESB compare to already established designs and patterns?

Self-describing and discoverable

What distinguishes Web services from previous integration approaches is that a consumer can dynamically bind to the provider of a service. This works because of the following two main capabilities:

• Self-describing – A Web service describes itself in a machine-readable way. Two or more providers of the same service are immediately recognizable, even though they may have very different implementations, because their declarative interfaces fit the same description.
  
• Discoverable – Web services providers can be organized into machine-executable directories. A consumer can search such a directory to find a provider of a desired service.

These self-describing and discoverable capabilities of Web services are very different from previous integration approaches. With other approaches, interfaces were enforced at compile-time, which is also when consumers were bound to providers. Message formats were not expressed declaratively. They were implied by mutual agreement and not enforceable until a receiver failed to parse the structure created by the sender.

Self-describing services simplified integration by declaring interfaces that could be enforced. Dynamic discovery of services freed the consumer from being bound to a particular provider at a particular address, but the opportunity for run time discovery created its own problems. Should a consumer perform discovery of providers of a service once or repeatedly?

It has been difficult to resolve the tension between binding a consumer to a provider once-and-for-all at compile time versus potentially discovering a new provider with every invocation during run time. An ESB offers a third choice, a compromise enabling a consumer to dynamically bind to a service proxy just once and yet still be able to use multiple and future providers using the proxy.

Thus, an ESB not only makes services available so that consumers can invoke them, but it also offers consumers the ability to find the services programmatically.

Services gateway

The foundation for a synchronous ESB is what's known as a services gateway, which acts as a middleman between service consumers and providers to facilitate synchronous brokered invocations. It provides access to all known services and the service proxy for each of them. In this way, a gateway provides one-stop shopping for a consumer that wants to invoke any of the services in any of the providers the gateway brokers.

When the services the gateway coordinates are Web services, the services are self-describing. Each service declares its interface using WSDL, which consists of the following four parts:

1. Port types -- The sets of operations performed by the Web service. A port type might be stockBrokerServices, with ports/operations like getQuote.
   
2. Messages – The format of the requests and responses, such as getQuoteRequest (which contains a stock symbol) and getQuoteResponse (which contains a price).
   
3. Types – The data types used by the Web service, such as symbol and price (or simply xs:string and xs:decimal).
   
4. Bindings – The address for invoking the operation, such as http://stockbroker.example.com/getQuote.

Such a gateway's Web services -- or more specifically, its proxies for the services -- are also discoverable. The gateway provides this capability as a UDDI service, as illustrated earlier. To discover the address for invoking a service, a consumer queries the gateway's UDDI service for providers of the desired WSDL operation and gets back the binding for the gateway's proxy for that operation.

Message bus

At the foundation of an asynchronous enterprise service bus is an established pattern called a Message Bus, described in the book Enterprise Integration Patterns listed in Resources. A message bus is a collection of message channels (also known as a queue or topic) usually configured as request-reply channel pairs. Each pair represents a service that can be invoked by a consumer using the bus. The caller puts a request message on the request queue for the service and then (asynchronously) listens for the result on the reply queue. (The caller knows which result is the right one for its particular request because it has the right correlation identifier.)

The consumer invoking the service doesn't actually know who's providing the service. The service providers also connect to the message bus and listen for request messages. If there are multiple service providers, they actually compete with each other as competing consumers to be the one to consume a particular request. The messaging system that implements the message bus acts as a message dispatcher and distributes the request messages to the service providers, ideally optimizing this distribution somehow based on load balancing, network latency, and so forth. After a service provider receives a request, it performs the service and then puts the result in a message on the agreed-upon reply channel. So the provider and the consumer never directly know about each other's locations; they just know about the message bus and how to address the appropriate channels, and by sharing the same channels they can communicate.

This message bus is the gist of an ESB, and this is nothing new. Application integrators have been doing this for more than a decade using message queuing products like WebSphere® MQ and TIBCO Enterprise Message Service. Indeed, it's often said that if you are using enterprise messaging products, you have an ESB. IBM customers have been doing this for quite some time with WebSphere Business Integration Message Broker and WebSphere MQ.

So, is an ESB just a message bus? No, a message bus is definitely the foundation of an asynchronous ESB, but a full ESB is something more. An ESB has abilities message buses have always lacked: The aforementioned describing and discovery abilities.

A better message bus

So if a message bus is not a full ESB, then what else does an ESB do?

A shortcoming of the traditional message bus approach is that it's not self-describing. From the consumer's perspective, there are a whole lot of channels for invoking a whole lot of services. But which one is the right channel for invoking the service the consumer needs? The consumer can't just put a request on any request channel; it has to know the right channel to use to invoke the particular service it needs. Otherwise, it might end up buying an airline ticket when it wanted a book. Likewise, even after the consumer knows (somehow) which channel to use (and which channel to listen to for the reply), it then needs to know what format the data in the request needs to be (and what data format to expect for the reply).

As described earlier, WSDL solves this problem for synchronous Web services, and for the time being is the standard of choice for describing asynchronous services as well. The WSDL associated with a request channel would describe what service that channel provides as well as the format of the request message the consumer must provide. The WSDL would probably also specify the reply channel the caller should listen to for the reply and the format to expect for the reply message. In this way, a caller application can programmatically look at the pair of channels for invoking a service and know that they provide the desired service using the desired request and reply message formats.

Self-describing services channels lead to another issue, namely discovery, which synchronous Web services solve with UDDI. As shown earlier, a consumer asks a UDDI server for the address of a Web service provider, and the server replies with the URL for that provider. The consumer uses the URL to invoke the service.

An ESB needs a similar directory service, one with a UDDI-like API that a consumer can invoke to ask for the address of a service that implements the desired WSDL operation. The ESB replies with the address of the appropriate pair of request-reply channels. So an ESB consumer, like a UDDI consumer, needs to know nothing more than the following:

1. The WSDL describing the service it wants to invoke
   
2. The address of the ESB's directory service (which can probably be derived from the ESB's root address)

This is enough to locate a service's request and reply channels and start invoking the service. Furthermore, this directory service is just another service that the ESB provides, a master service for locating other services.

Synchronous or asynchronous?

Service consumers face an artificial choice between communication styles: synchronous or asynchronous. To solve this dilemma, many ESBs will support both synchronous and asynchronous services, and in fact may offer both invocation models for the same service. In this case, when a consumer asks for the address of a service, it can get two matches: one synchronous, the other asynchronous. The consumer can then choose the invocation model it likes best. Either way, the service performed is the same although the specific service provider instance may differ.

So an ESB is better than a traditional message bus because it also makes a service self-describing and provides a directory service for finding the other services. This is what the vendors of products for building ESBs are striving to deliver.

Back to top

Conclusion

As you've seen, a service can be invoked in any of following three ways:

1. Directly and synchronously
   
2. Synchronously through a broker
   
3. Asynchronously through a broker

An Enterprise Service Bus is a broker that supports synchronous and asynchronous service invocation. It also enables data transfer and event notification between applications. It helps consumers find providers and handles the details of communication between them.

A synchronous ESB is a services gateway that acts as a central coordinator of a variety of services. An asynchronous ESB is a message bus whose services also support the Web service capabilities of being self-describing and discoverable. Standards and patterns exist today for implementing a synchronous ESB and a message bus that is a simplified asynchronous ESB. Additional standards are needed for asynchronous ESBs to reach their full potential.

Back to top

Resources

• New to SOA and Web services provides an overview for readers who would like to learn about Web services but don't know where to start.
  
  
• WS-I Basic Profile Version 1.1 (WS-I) defines the WS-I Basic Profile 1.1.
  
• Simple Object Access Protocol (SOAP) 1.1 discusses the SOAP 1.1.
  
  
• Find out more about Hypertext Transfer Protocol (HTTP) 1.1.
  
  
• Web Services Description Language (WSDL) 1.1 is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.
  
  
• Universal Description, Discovery and Integration (UDDI) 2.04 specification describes the programming interface and expected behaviors of all instances of the UDDI registry.
  
  
• "Simplify integration architectures with an Enterprise Service Bus" (developerWorks, August 2005) dispells the myths of an Enterprise Service Bus and shows how you can apply this architectural style to the implementation of Service-Oriented Architecture-based applications.
  
  
• Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf (Addison Wesley ISBN 0321200683; October 2003) provides a catalog of patterns and real-world solutions that demonstrate the power of messaging and helps you design effective messaging solutions for your enterprise.
  
  
• "Building a JMS Web service using SOAP over JMS and WebSphere Studio" (developerWorks, February 2004) describes the basics of JMS Web services and shows you how to develop a two-way request and response JMS Web service using WebSphere Studio V5.1.
  
  
• Find out more about WSDL JMS Extension at the Apache Web site.
  
  
• Calling an Asynchronous Web Service Sample shows the use of a Web service control.

Back to top

About the author

Bobby Woolf is a WebSphere J2EE Consultant for IBM Software Services for WebSphere (ISSW). Bobby assists clients in developing applications for WebSphere Application Server using WebSphere Studio Application Developer. He is a co-author of Enterprise Integration Patterns and The Design Patterns Smalltalk Companion. He also has a blog on the IBM developerWorks Web site called J2EE in Practice. Bobby is a frequent conference speaker.