SOA와 웹서비스 입문 (한글) - IBM developerworks

developerWorks 웹 서비스 존에는 수 백 개의 기술자료, 튜토리얼, 팁이 포함되어 있으며, 개발자들이 웹 서비스 관련 애플리케이션을 만드는데 일조하고 있습니다. 하지만 이 새로운 주제를 시작하는 사용자들에게는 오히려 이 많은 정보들이 부담스러울 수 있습니다. 이 페이지는 웹 서비스를 시작할 방법을 모색하는 개발자들을 위한 장소입니다. 기본적인 웹 서비스 기술이 포함되어 있으며, developerWorks의 관련 기술자료, 튜토리얼과 팁, IBM 교육 서비스, 웹 캐스트, 워크샵, IBM 제품들로 연결됩니다.

서비스 지향 아키텍쳐(SOA)

Service-Oriented Architecture(SOA(서비스 지향 아키텍쳐))는 정의가 잘된 인터페이스와 서비스들 간 콘트랙트(contracts)를 통해, 서비스라고 하는 애플리케이션의 다양한 기능 단위를 상호 연관시키는 컴포넌트 모델입니다. 인터페이스는 하드웨어 플랫폼, 운영 체계, 프로그래밍 언어에 독립적인 방식으로 정의됩니다. 따라서 다양한 시스템들에 구현된 어떤 서비스라도 일반적이고 통합된 방식으로 인터랙팅 할 수 있습니다. 특정 구현에 얽매이지 않은 중립적인 인터페이스를 가졌기 때문에 서비스들간 약결합(loose coupling)으로 알려져 있다. 약결합 시스템의 장점은 기민성과 각 서비스의 내부 구조 및 구현의 변화에 대응할 수 있는 능력을 꼽을 수 있습니다. 반면 강결합(tight-coupling)은 애플리케이션의 다양한 컴포넌트들이 기능과 형식면에서 밀접하게 연관되어 있어 애플리케이션 일부나 전체를 변경할 때 까다롭습니다. 약결합 시스템의 필요성은 비즈니스 애플리케이션이 변화하는 환경에 빠르게 적응해야 하는 데서 기인했습니다. 정책, 주력 비즈니스, 비즈니스 포커스, 파트너쉽, 산업 표준, 비즈니스의 본질에 영향을 미치는 관련 요소들은 늘 변화하기 마련입니다. 우리는 이러한 환경에 유연하게 대처할 수 있는 비즈니스를 온 디맨드 비즈니스(On demand business)로 명명하고 있습니다. 서비스 지향 아키텍쳐는 새로운 것은 아니고, 다만 지난 십년 동안 출현했던 강결합 객체 지향 모델에 대한 대안 모델이라 할 수 있습니다. SOA 기반 시스템이 개별 서비스가 객체 지향 디자인으로 구현될 수도 있다는 것을 배제하지 않는 반면, 전체 디자인은 서비스 지향입니다. 시스템 내에 객체를 허용하기 때문에 SOA는 객체 기반 이지만 전체가 객체 지향은 아닙니다. 그 차이는 인터페이스에 있습니다. 초기 SOA 시스템의 고전적인 예는 Common Object Request Broker Architecture (CORBA)인데 이는 SOA와 비슷한 개념을 정의하고 있습니다. 하지만, 오늘날 SOA는 eXtensible Markup Language (XML)에 기반하여 진보했다는 점에서 차별됩니다. Web Services Definition Language (WSDL)라고 하는 XML 기반 언어로 된 인터페이스를 설명하게 되면서, 서비스는 CORBA의 Interface Definition Language (IDL)보다 동적이고 유연한 인터페이스 시스템으로 옮겨가게 되었습니다. 웹 서비스가 SOA를 구현할 수 있는 유일한 방법은 아닙니다. 앞서 설명했던 CORBA도 하나의 방법이고, 따라서 IBM의 MQseries 같은 메시지 지향 미들웨어도 마찬가지 입니다. 하지만 아키텍쳐 모델이 되기 위해서는 서비스 디스크립션 그 이상이 필요합니다. 전체 애플리케이션이 서비스들 간 워크플로우를 어떻게 수행하는지에 대한 정의를 내려야 합니다. 뿐만 아니라 비즈니스 연산 대 비즈니스에서 사용되는 소프트웨어 연산 사이의 변형 포인트를 찾아야 합니다. 따라서 SOA는 비즈니스의 상용 프로세스를 기술 프로세스와 연관시킬 수 있어야 하고, 둘 사이에서 워크플로우 관계를 매핑해야 합니다. 예를 들어, 공급자 역할을 하는 것은 비즈니스 프로세스이고 새롭게 공급된 것을 추가하여 부품 데이터베이스를 업데이트 하는 것은 기술 프로세스이다. 따라서 워크플로우는 SOA 디자인에서 중요한 역할을 합니다. 더욱이, 동적 비즈니스의 워크플로우에는 부서들 간 작동 뿐만 아니라, 다른 외부 파트너들의 작동이 포함되어 있어 여러분에게는 제어권이 없습니다. 서비스 레벨 계약과 운영 정책의 형태로, 서비스들 간 관계가 발생하는 방법에 대한 정책을 정의해야 합니다. 마지막으로, 계약 조건에 따라 프로세스를 수행한다는 신뢰 속에서 이 모든 것이 작동되어야 합니다. 따라서, 보안, 신용, 신뢰성 있는 메시징은 어떤 SOA에서든 중요한 역할을 합니다. 참고자료: how SOA expands on the Web services vision 참조 IBM vision of Service Oriented Architectures. New to Web services. An Executive's Guide to Web services.

위로

서비스 지향 아키텍쳐의 활용

SOA의 필요성은 비즈니스 IT 시스템들이 비즈니스 변화에 대해 보다 민첩하게 대처해야 한다는 필요성에서 생겨났습니다. 확정적인 관계를 받아들이지만 융통성 있는 스팩 구현으로 IT 시스템들은 기존 시스템들의 기능을 활용할 수 있고, 앞으로의 변화에 대응할 수 있습니다. 예를 들어, 500개의 국제적인 점포망을 소유하고 있는 의류 소매 조직은 패션에 발맞추기 위해서 디자인을 자주 바꾸어야 합니다. 스타일과 컬러 뿐만 아니라 재질, 제조, 운송 부분 까지도 변경해야 합니다. 소매업체와 제조자 간 시스템이 호환되지 않는다면, 한 공급자에서 또 다른 공급자로의 변경은 매우 복잡한 소프트웨어 프로세스가 될 수 있습니다. WSDL 인터페이스는 융통성이 있기 때문에 각 기업들이 그들의 기존 시스템을 유지하도록 하고, 대신 WSDL 인터페이스에 맞추어 새로운 서비스 레벨 계약을 체결하도록 합니다. 소프트웨어 애플리케이션을 모두 재구현 할 필요가 없습니다. 이것은 비즈니스의 수평적 변화로서 파트너와 모든 비즈니스 작동을 변경하는 것입니다. 비즈니스 인터페이스는 약간 변경되고 내부 작동까지는 변경될 필요가 없기 때문에 외부적으로 협업할 수 있는 것입니다. 또 다른 형태는 내부 변화(internal change)입니다. 소매업체가 체인 소매점 내에 장소를 빌려 부띠크 판매자에게 제공하기로 결정할 수 도 있습니다. 이것은 점포 내 점포(store-in-store) 비즈니스 모델입니다. 이 기업의 대부분의 비즈니스 기능은 같지만 이제는 새로운 내부 소프트웨어로 임대 계약을 맺어야 합니다. 내부적으로 소프트웨어 시스템은 정비중이더라도 기존 공급자의 시스템과의 인터랙팅에 심각한 영향을 주지 않고 이를 수행해야 합니다. 이 경우 SOA 모델은 그대로 보존되는 반면 내부 구현이 변합니다. SOA 모델에 새로운 상(aspect)이 추가되어 임대 계약에 대한 새로운 책임이 추가되지만, 일반적인 소매 관리 시스템은 변화가 없습니다. 내부 변화에 대한 개념을 확대시키기 위해 IT 관리자들은 다른 방식으로 사용될 수 있는 새로운 소프트웨어 구성 방법을 찾을 수 있습니다. 이를 테면, 광고용 임대 포스터 공간이 이에 해당됩니다. 유연한 SOA 모델에서 생성된 새로운 비즈니스 제안은 이 새로운 디자인에 재적용 됩니다. 이것은 SOA 모델의 새로운 결과물이고, 전에는 불가능했던 새로운 기능이라 할 수 있습니다. 수직적 변화 역시 가능합니다. 소매업자가 자신의 옷을 판매하던 방식에서 매장내매장 모델을 통해 독점적인 임대 공간으로 옮길 수 있다. 수직적 변화의 경우 SOA 모델의 중대한 재구성이 수반되어야 합니다. 아마도 새로운 시스템, 소프트웨어, 프로세스, 관계들이 필요합니다. 이 경우 SOA 모델의 장점은 애플리케이션과 프로그램의 관점이 아닌 비즈니스 기능과 프로세스의 관점에서 작용하여 비즈니스 기능에 기반하여 추가되고, 변경되고 제거되어야 할 것이 무엇인지를 명확하게 구분할 수 있게 됩니다. 소프트웨어 시스템은 비즈니스 프로세스에 맞춰 구성될 수 있습니다. 주지하듯이, 변화와, 이 변화를 받아들이는 SOA 시스템의 능력은 가장 중요한 요소입니다. 개발자에게 그와 같은 변화는 그들의 작업 내부 또는 외부에서 발생할 수 있습니다. 인터페이스가 정의되는 방법과 서로 인터랙팅 하는 방법에 관한한 그렇습니다. 오히려 개발자 보다는 SOA 모델에 대부분의 변화를 일으키는 것은 아키텍트의 역할 입니다. 개발자들이 서비스로 정의된 기능 단위를 만드는데 초점을 맞춘다면 아키텍트와 모델러는 그 단위를 조합하는 것과 Universal Modeling Language (UML)를 통해 일반적으로 표현하는 것과 Model-Driven Architecture (MDA)로 기술하는 것에 초점을 맞추고 있습니다. 참고자료: Service-Oriented Architecture. benefits of having SOA. introduction to SOA for managers.

위로

SOA의 컴포넌트 기술

SOA는 그 자체로 소프트웨어가 함께 놓이는 방식에 대한 추상적 개념입니다. 소프트웨어 형태로 존재하기 위해서는 XML과 웹 서비스로 구현된 보다 구체적인 개념과 기술에 의존합니다. 또한, 보안, 정책 관리, 신뢰성 있는 메시징, 계정 시스템 등이 효과적으로 작동해야 합니다. 분산 트랜잭션 프로세싱과 분산 소프트웨어 상태 관리를 통해 이 부분을 향상시킬 수 있습니다. SOA 서비스와 웹 서비스의 차이는 디자인에 있습니다. SOA 개념은 서비스가 특별하게 인터랙팅 하는 방식을 정확하게 정의하지 않습니다. 단지 서비스들이 서로를 인식하고 인터랙팅 하는 방법만 정의합니다. 프로세스가 수행되는 방법 전략을 정의하는 것과 실제로 수행되는 방법 전략에는 차이가 있습니다. 반면 웹 서비스는 서비스들간 메시징이 인터랙팅 되는 방식에 대한 특정 가이드라인을 제시하고 있습니다. SOA 모델의 전략적 구현은 HTTP를 통해 전달되는 SOAP 메시지에서 일반적으로 볼 수 있습니다. 따라서 웹 서비스는 SOA가 구현되는 방식의 일부라고 할 수 있습니다. SOA는 웹 서비스로 제한되어 있습니다. WSDL로 서비스 인터페이스를 직접 구현하고 XML 메시지와 통신하는 다른 프로토콜은 SOA에 포함될 수 있습니다. CORBA와 IBM의 MQ 시스템들은 SOA에 참여하여 WSDL로 작동하는 새로운 기능을 사용하고 있습니다. 두 서비스가 데이터를 교환하려 한다면 같은 메시징 프로토콜을 사용해야 하지만 데이터 인터페이스는 같은 정보 교환을 허용합니다. 모든 메시징을 적절하게 제어하고 보안, 정책, 계정 등을 적용하려면 SOA 아키텍쳐의 그림에 들어갈 새로운 비즈니스 객체가 필요합니다. 이것은 Enterprise Service Bus f(ESB)이고, 제어 서비스들 간 모든 메시지의 흐름과 통역을 맡고 있으며 모든 가능한 메시징 프로토콜을 사용합니다. ESB가 절대적으로 필요한 것은 아니지만 SOA에서 비즈니스 프로세스를 적절하게 관리하는 중요한 컴포넌트입니다. ESB는 그 자체로 하나의 엔진이거나 많은 피어와 하위 피어들로 구성된 분산 시스템일 수도 있습니다. 개념상으로 Message Queue와 분산 트랜잭션 컴퓨팅 같은 이전 컴퓨터 과학 개념에서 나온 store-and-forward 메커니즘에서 진화한 것입니다. 개발자 측면에서 그들이 사용하는 툴은 SOA의 기능에 대해 인지하고 있어야 하고 개발자가 SOA 객체를 사용하여 효과적으로 작업할 수 있도록 해야 합니다. SOA 모델의 디자인 프로세스, 서비스와 서비스 객체의 개발, SOA 애플리케이션의 테스팅이 이에 해당합니다. 따라서 개발자 툴은 Service-Oriented Application Design/Development (SOAD)를 위한 준비를 해야 합니다. 참고자료: New to Web services. The Web Services Conceptual Architecture. Web services Standards database.

위로

SOA와 다른 기술의 연관 방법

SOA는 다양한 많은 기술들과 인터랙팅 할 수 있지만 여기에서는 중요한 역할을 하는 컴포넌트의 캡슐화와 집합에 대해서 이야기 하겠습니다. 앞서 언급했지만, SOA 서비스는 단순한 객체, 복잡한 객체, 객체들의 집합, 많은 객체들을 포함하고 있는 프로세스, 다른 프로세스들을 포함하는 프로세스, 하나의 결과를 내는 애플리케이션의 전체 집합 등 이 모든 것이 될 수 있습니다. 서비스 밖에서는 하나의 엔터티로 보이지만 내부에서는 필요한 만큼의 복합적 레벨을 포함할 수 있습니다. 퍼포먼스의 관점에서 보면 대부분의 SOA 서비스들은 단순한 객체의 세분성으로까지는 내려가지 않고 큰 컴포넌트의 중간 정도에 더 잘 맞습니다. SOA는 XML과 WSDL을 제외하고는 언어 스팩이 아닙니다. WSDL을 생성하고 인터랙팅 할 수 있는 한 어떤 프로그래밍 언어로도 구현될 수 있습니다. SOAP 그 자체는 절대적 필요조건은 아니지만 일반적인 메시징 시스템입니다. 따라서 SOA의 멤버 서비스들은 WSDL을 지원하는 다양한 프로그래밍 언어와 플랫폼에서 구현될 수 있습니다. Common Object Broker Request Architecture (CORBA) 기반 애플리케이션은 SOA에 인터페이싱을 하기위한 많은 필수 컴포넌트들이 있습니다. CORBA의 Interface Description Language (IDL)은 개념적으로는 WSDL과 비슷하지만 정확하지 않기 때문에 WSDL로 우선 매핑되어야 합니다. 게다가 프로세스와 정책 관리 같은 SOA의 고급 프로토콜이 사용되어야 합니다. 서비스로 표현되는 CORBA 컴포넌트가 SOA 서비스와 인터랙팅 해야 할 경우입니다. CORBA 모델 내에서는 모든 개별적인 하위 컴포넌트들은 전과 같이 작동할 수 있습니다. Object Management Group이 제안하고 다양한 IBM Rational 제품들을 사용하여 구현된 Model-Driven Architecture (MDA)는 보다 추상적인 레벨에서는 SOA의 개념과 강력한 상관관계를 갖고 있습니다. MDA는 어떤 소프트웨어 프로세스든 모델과 메타모델로 정의될 수 있다는 개념에 기반합니다. 따라서 MDA는 플랫폼 상에서 실행될 수 있는 실행파일로 컴파일 될 수 있는 소프트웨어 애플리케이션으로 컴파일 된 모델을 만듭니다. MDA는 서비스 개념과 객체 개념을 구별하지 않지만 모델이 다른 모델의 하위세트로 구성되는 것을 허용합니다. SOA의 핵심 컴포넌트인 BPEL 내의 프로세스 집합과 비슷한 개념입니다. SOA와 웹 서비스는 프로그래밍 언어에 독립적이지만 그 중에서도 자바가 많이 쓰이고 있습니다. 정의가 잘 된 자바 인터페이스와 풍부한 자바로 구현된 다양한 프로토콜은 자바 개발자들이 모델을 구현할 때 도움이 됩니다. 여기에서 자바는 각 서비스의 기능 개발에 중요한 역할을 하고 데이터 객체들과, 서비스 내에서 논리적으로 캡슐화 된 다른 객체들의 인터랙션을 조작합니다. SOA와 웹 서비스의 또 다른 핵심 관계는 자율 컴퓨팅과 그리드 컴퓨팅의 개념입니다. 자율 컴퓨팅 개념은 분산 서비스 아키텍쳐의 관리에 적용되고, 특히 정책과 서비스 레벨 계약을 관리하는데 도움이 됩니다. 게다가 SOA 시스템의 전체적 안정성에도 기여합니다. 그리드 컴퓨팅은 두 가지 레벨의 SOA 시스템에 작용합니다. 분산 컴퓨팅 형태로 되어있는 그리드는 분산 특징과 서비스들과의 인터랙션을 활용하여 SOA 애플리케이션을 전산적으로 지원합니다. 이러한 방식으로, 그리드 서비스는 개별 서비스들이 구현될 수 있는 프레임웍이 되는 것입니다. 따라서 SOA 애플리케이션은 그리드 서비스의 소비자가 될 수 있습니다. 그리드 자체는 SOA에서 구현 될 수도 있습니다. 이 경우 각 운영 체계 서비스들은 전체 SOA 애플리케이션을 구성하는 멤버가 되는 것입니다. 따라서 그리드의 개별 컴포넌트들은 웹 서비스를 사용하여 통신하고 SOA의 형태로 인터랙팅 합니다. 요약하면, 그리드 시스템은 SOA 그 자체가 될 수도 있고, 그 상단에 구현된 애플리케이션 레벨의 SOA 모델을 제공합니다. 참고자료: Key components of a Service-Oriented Architecture. developerWorks Rational. developerWorks XML. developerWorks Java technology content area. developerWorks Autonomic Computing content area. A visual tour of OGSA.

위로

애플리케이션에서 SOA 활용하기

SOA를 활용할 부분은 소프트웨어 개발 프로세스 뿐만 아니라 비즈니스 개발 프로세스도 포함됩니다. 특정 소프트웨어 서비스를 구현할 수 있는 네 가지 SOA 채택 레벨이 있습니다. 이 모두가 비즈니스 모델을 온 디맨드 시스템으로 변형하는 것입니다. 자세한 정보는 The Four levels of SOA Adoption 기술자료를 참조하십시오. 첫 번째 레벨은 가장 간단합니다. 개별 서비스를 구현하는 것이 이 레벨에 포함되어 있습니다. New to Web services에 자세한 자료가 소개되어 있습니다. 두 번째 레벨에서, 서비스를 만들 수 있고 비즈니스 기능들을 SOA에 통합할 수 있습니다. 애플리케이션 통합, 정보 통합, 프로세스 통합, 전체 시스템 통합 등의 여러 통합 단계가 있습니다. Migrating to a Service-Oriented Architecture를 참조하시기 바랍니다. 세 번째 레벨은 자신의 엔터프라이즈 IT 인프라를 SOA 모델로 변형하는 것입니다. 네 번째 채택 레벨은 비즈니스 모델을 온 디맨드로 변형하는데 초점을 맞추고 있습니다. IT 실무자 관점에서, SOA 애플리케이션을 구현하기 위해서는 일반적으로 네 가지 단계를 거쳐야 합니다: 구현, 전개, 사용, 관리. 구현 단계에서는 비즈니스 모델 또는 프로세스, 소프트웨어 모델과 SOA 모델을 정의합니다. 그런 다음, 일반적인 인터페이스로 재사용 할 수 있는 서비스를 만듭니다. 전개 단계에서는 구현된 서비스들을 실행 및 관리 환경으로 배치하는 것입니다. 사용 단계에서는 앞서 정의된 SOA와 소프트웨어 모델에 따라 애플리케이션을 조립하고 소프트웨어 품질과 퍼포먼스, 확장성 같은 비 기능적 사항들을 테스트합니다. 이 정도 진행되면 전개되어 사용자들이 사용할 수 있습니다. 마지막 관리 단계에서는 보안과 사용을 감시 및 관리하고 서비스 레벨 계약과 정책과 비교하여 퍼포먼스를 비교합니다. 이상은 SOA의 개념적인 단계입니다. 이 단계와 실제 환경의 단계를 비교하면 SOA 애플리케이션 생성에 개입된 다양한 역할들이 있습니다. 같은 일 또는 여러 팀 멤버, 심지어는 여러 팀들 내에서 역할이 주어집니다. 역할 개념은 Rational Unified Process (RUP)으로 구별되는 역할로 표현됩니다. RUP 역할에는 프로젝트 매니저, 분석가, 아키텍트, 모델러, 개발자, 테스터, 개발 및 운영자 등이 있습니다. SOA는 개념상의 SOA 모델을, SOA 모델과 IT 인프라의 리소스와 비교하여 테스트하는 SOA Modeler 역할을 추가하여 거의 동일하게 매핑하고 있습니다. 개발자는(사용 단계의) 어셈블러로서의 부차적인 역할을 합니다. 개별 서비스들을 이용하여 정의된 모델에 따라 실제 SOA 애플리케이션을 구현하는 것입니다. 이러한 역할들은 SOA를 사용하는 엔터프라이즈 내에 존재하고 있습니다. 참고자료: Four Levels of SOA Adoption. Migrating to a Service-Oriented Architecture, Part 1, Part 2. Rational Unified Process: Best Practices for software development teams. Speed-start Web Services. Business processes and workflow in the Web services world. BPEL4WS column. From UML to BPEL: Model Driven Architecture in a Web services world.

위로

SOA 기술력 개발하기

정보 분석가, 소프트웨어 아키텍트, 소프트웨어 개발자, 소프트웨어 품질 분석가, 시스템 관리자 등 역할에 따라 기술이 다릅니다. SOA의 개념은 이 모든 역할까지 확장됩니다. 따라서 각 역할이 어떻게 작동하는지에 대해서는 이해해야 합니다. 그 다음에는 각 역할이 갖춰야 하는 기술 개념에 익숙해져야 합니다. 정보 분석가와 소프트웨어 아키텍트는 모델 중심 아키텍쳐와 UMM 2.0을 이해해야 합니다. 소프트웨어 개발자와 프로그래머는 웹 서비스와 MQ 그리고 기타 프로토콜의 프로그램 방식의 인터페이스, 보안 인터랙션 방식, 워크플로우 프로세싱 개념을 자세히 알아야 합니다. 품질 분석가와 시스템 관리자는 SOA 프로세스 모델 대 실제 SOA 기능 아키텍쳐 구현에 대한 이해도를 높여야 합니다. 개별 서비스들이 분산 애플리케이션의 전체 퍼포먼스에 미치는 영향에 대해서도 알고 있어야 합니다. 시스템 관리자는 애플리케이션 보안과 신용 모델이 어떻게 작동하는지, 그리고 애플리케이션이 운영 체계와 네트워크 시스템에 영향을 미치는 정책에 어떤 영향을 미치는 지도 알아야 합니다. 참고자료: Web Services project roles. Speed-start Web services. Level 1 SOA Adoption: Implementing Individual Web services. Level 2 SOA Adoption: Service Oriented Integration. An introduction to Model-Driven Architecture. new tutorials. Rational UML Resource. discussion forum, IBM WebSphere SDK for Web services.

위로

SOA에 활용할 수 있는 IBM 툴과 제품들

IBM은 SOA 기반 IT 시스템들을 구현, 전개, 관리하는데 필요한 툴, 교육, 서비스를 제공한 첫 벤더입니다. 서비스의 구현, 전개, 사용 관련한 툴을 포함하여 전체 수명 주기의 모든 측면을 아우르고 있으며 다양한 레벨의 SOA를 채택하고 있습니다. 각 레벨은 하위 채택 레벨과 소프트웨어를 포함하고 있습니다. 모든 수명주기 단계가 모든 채택 레벨에 필요한 것은 아닙니다. 프로세스의 범위가 다르기 때문입니다. 마지막으로 On Demand Business Transformation의 네 번째 레벨은 비즈니스 지향이며, 하위 레벨에 소프트웨어가 포함되어 있습니다. 웹 서비스 구현의 첫 번째 SOA 채택 레벨에서 그림 1에 나타난 툴은 간단한 웹 서비스의 생성과 운영에 도움이 됩니다. 그림 1. 개별 웹 서비스 구현하기 vs 핵심 컴포넌트 두 번째 레벨인 서비스 지향 통합에서 툴은 다중의 서비스들을 발견하고 이들과 인터랙팅하고, SOA 모델의 기초를 만드는 수단을 제공하는 것으로 옮겨가고 있습니다. 그림 2a는 레벨 2 채택의 핵심 컴포넌트이지만, 그림 2b는 레벨 2에 도움이 되는 추가 컴포넌트 입니다. 그림 2a. 서비스 지향 통합 vs 핵심 컴포넌트 그림 2b. 서비스 지향 통합 vs 추가 컴포넌트 레벨 2인 엔터프라이즈 중심의 IT 변형에서 IBM은 광범위한 SOA와 웹 서비스 제품을 제공하여 모든 IT 시스템 기능들을 사용할 수 있도록 하고, SOA 시스템의 엔터프라이즈 중심의 관리용 프레임웍을 제공합니다. 그림 3a는 레벨 2 채택의 핵심 컴포넌트와 그림 3b의 추가 컴포넌트입니다. 그림 3a. 엔터프라이즈 중심의 IT 변형 vs 핵심 컴포넌트 그림 3b. 엔터프라이즈 중심의 IT 변형 vs 추가 컴포넌트 참고자료: benefits of having an SOA. IBM Web services site: Implementing Web services. IBM Web services site: Service Oriented Integration. IBM Web services site: Enterprise Wide IT Transformation.