 | |
|
난이도 : 초급 Mark Colan, e-business evangelist, IBM Corporation
2007 년 8 월 21 일 오늘날의 웹 서비스 구현은 대게는 단순하고, 클라이언트-서버 모델을 따르고 있습니다. 플랫폼 중립적인 교환도 지원되어 다양한 클라이언트 구현들이 새로운 코드 또는 기존의 코드와 상호 작동 할 수 있습니다. 이 같은 애플리케이션들을 간단히 구현하는 방법을 다룬 글들이 많이 있습니다. 이제는, 이것을 토대로 무엇을 할 수 있는지에 대한 더 큰 그림을 봐야 할 때입니다. 필자는 단순한 모델에서 복잡성까지 내포하고 있는 실제 비즈니스 모델로 이동하는 문제를 설명합니다.
기원전 221년에, Qin 황제는 전쟁 중이던 여러 나라들을 지금 현재 우리가 중국이라고 부르는 하나의 새로운 나라로 통일했다. 중국이 하나의 국가로서 지속되었던 한 가지 이유는 Qin이 표준이라는 것을 도입했기 때문일 것이다. 도로에서 마차가 효율적으로 이동할 수 있는 바퀴의 표준 길이, 모든 사람들이 메시지를 전달할 수 있는 공통 언어, 외부 공격으로부터 대응할 수 있는 강력한 방어 장치(만리장성) 등이 대표적이다. 이것은 마치 표준화된 전송, 메시지 교환, 방화벽의 모델과도 같다.
같은 맥락으로, 요즘의 비즈니스 통합은 이종의 컴퓨터 시스템들이 효율적으로 상호 작동할 수 있게 해주는 표준을 통해 많은 혜택을 누리고 있다. 이러한 기술들은 집합적으로 웹 서비스라고 일컬어 진다. 웹 서비스의 여명 시대는 SOAP 1.1로 대표되는데, 이는 분산 시스템에서의 인터랙션에 XML 콘텐트 사용에 대해 정의하면서, 구현 상세를 숨겼다. 4년 후에, 많은 기업들은 웹 서비스를 사용하고 있고, 업계는 웹 서비스 시대를 살아가고 있다고 볼 수 있다.
IBM은 서비스 지향 아키텍처(SOA)를 온 디맨드 비즈니스라는 비전에서 상호 운용성과 유연성 요구 사항의 열쇠로 간주하고 있다. SOA는 엔터프라이즈와 비즈니스 파트너들간 엔드투엔드 통합을 지원한다. 고객들이 새로운 요구 사항, 새로운 비즈니스 기회, 위협에 빠르게 대처할 수 있도록 하는 유연한 비즈니스 프로세스 모델을 제공하는 것이다.
SOA란 무엇인가?
SOA는 여러분이 웹 서비스로 수행할 수 있는 것에 대한 큰 그림을 나타낸다. 웹 서비스 스팩은 서비스를 구현하고 이들과 인터랙팅 하는데 필요한 상세들을 정의한다. 하지만, SOA는 애플리케이션 기능을 서비스로서 엔드 유저 애플리케이션에 제공하는 분산 시스템을 구현하거나 다른 서비스를 구현하는 방식이다. SOA는 웹 서비스에 기반하고 있지만, 다른 기술도 사용할 수 있다. SOA를 사용하여 분산 애플리케이션들을 디자인 할 때, 간단한 클라이언트-서버 모델에서 복잡한 시스템까지 웹 서비스를 확장하여 사용할 수 있다.
따라서, 개별 소프트웨어 에셋들은 다른 애플리케이션들을 개발하는 구현 블록이 된다. 여러분은 새로운 코드와 레거시 코드에서 모두 가능한 공통의 인터랙션 스타일을 사용함으로써 시스템 복잡성을 줄일 수 있다. (Lawrence Wilkes(CBDi)는 SOA가 "Save Our Assets(에셋을 절약하자)"의 약자라고 농담을 한 바 있다.) 이러한 소프트웨어 에셋들을 표현하고 인터랙팅 하는 표준 방식이 있다. 이제 초점은 그러한 구현 블록에 의존하는 애플리케이션 어셈블리로 옮겨간다.
비즈니스 애플리케이션을 위한 SOA이기도 하지만, SOA는 그리드 컴퓨팅과 고급 웹 서비스 스팩(WS-DistributedManagement, WS-Trust, UDDI) 같은 분산 시스템에 사용될 수도 있다.
서비스란 무엇인가?
SOA에서 서비스란 비즈니스 프로세스에서 사용되기 위해 재사용 가능한 컴포넌트로서 패키징 된 애플리케이션 기능이다. 정보를 제공하거나 하나의 상태에서 또 다른 상태로 비즈니스 데이터를 변화시킨다. 여러분이 필요로 하는 서비스의 품질을 제공한다면 특정 서비스를 구현하는데 사용되는 프로세스는 문제가 되지 않는다.
정의된 통신 프로토콜을 통해서, 상호 운용성과 위치 투명성을 강조하는 서비스들이 호출될 수 있다. 서비스는 소프트웨어 컴포넌트의 모습을 취하고 있다. 서비스 요청자의 관점에서 볼 때 독립된 기능을 갖고 있는 것으로 보인다. 하지만, 서비스 구현에는 실제로 하나의 엔터프라이즈 내의 다른 컴퓨터와 많은 비즈니스 파트너들이 소유한 컴퓨터 상에서 실행되는 많은 단계들이 포함되어 있다. 서비스는 캡슐화 된 소프트웨어 관점에서 볼 때 컴포넌트가 될 수도 있고 되지 않을 수도 있다. 클래스 객체와 마찬가지로, 요청자 애플리케이션은 서비스를 하나로 취급할 수 있다.
웹 서비스 호출은 HTTP 같은 표준 프로토콜을 통해 WSDL을 사용하여 기술된 SOAP 메시지들을 사용하여 이루어진다. 웹 서비스의 사용은 외부 비즈니스 파트너들과 통신할 때 가장 큰 효과를 발휘한다.
약결합(Loose coupling)
서비스 요청자에서 서비스 공급자로의 바인딩은 서비스를 약결합 해야 한다. 서비스 요청자는 프로그래밍 언어, 전개 플랫폼 같은 공급자의 구현에 대한 기술적 상세를 모른다. 서비스 요청자는 API 또는 파일 포맷 대신에 메시지의 형태(요청 메시지와 응답 메시지)로 연산을 호출한다.
약결합으로 양 측의 소프트웨어는 서로에게 영향을 주지 않고 변경될 수 있으며, 메시지 스키마는 그대로 유지된다. 극단적인 경우, 서비스 공급자는 COBOL 같은 레거시 코드에 기반한 조기 구현을 자바에 기반한 완전히 새로운 코드 베이스로 대체할 수 있다. 서비스 요청자에 미치는 영향은 없다. 새로운 코드가 같은 메시지 스키마를 지원하는 한 문제가 없다.
잘 정의된 인터페이스
서비스 인터랙션은 잘 정의되어 있어야 한다. Web services Description Language (WSDL)은 서비스 공급자로 바인딩하기 위해 서비스 요청자가 요구하는 상세를 기술하는 방식이다. 서비스 디스크립션은 다음의 사항들과 상호 작동 하기 위해 사용되는 연산에 초점을 맞춘다.
- 서비스
- 연산을 호출하는 메시지
- 메시지 구현 상세
- 메시지를 구현하는 프로세스에 대한 메시지를 보낼 곳에 대한 정보
WSDL에는 서비스의 구현 상세가 포함되지 않는다. 서비스 요청자는 서비스가 Java code, C#, COBOL 든, 어떤 언어로 작성되었는지 모를 뿐만 아니라 관여하지 않는다. HTTP를 사용하여 SOAP 호출을 기술할 수 있다. 이러한 확장 메커니즘 때문에, JMS, 직접적인 메소드 호출, 레거시 코드를 관리하는 어댑터에 의해 핸들되는 호출(CICS)을 통해 전달된 XML 콘텐트 같은 다른 인터랙션 스타일을 정의할 수도 있다.
WSDL의 공통 정의를 통해 개발 툴들은 다양한 스타일의 인터랙션에 공통의 인터페이스를 만들면서, 애플리케이션 코드에서 서비스를 호출하는 방법의 상세를 숨긴다. 예를 들어, Web Services Invocation Framework (WSIF)은 서비스가 한 개 이상의 인터랙션 스타일로 노출된다면 품질 서비스를 호출하는 최상의 방법을 런타임으로 결정할 수 있도록 함으로써 이 기능을 활용하고 있다.
Stateless 서비스 디자인
서비스는 독립적인 요청들이어야 하는데, 이는 하나의 요청에서 또 다른 요청으로 정보나 상태를 필요로 한다. 서비스는 다른 서비스의 정황이나 상태에 의존해서는 안된다. 의존성이 필요하면 구현 생성물(세션 키)이 아닌 공통의 비즈니스 프로세스, 함수, 데이터 모델의 관점에서 정의된다. 물론, 요청자 애플리케이션은 서비스 호출들 간 영속 상태를 필요로 하지만 이는 서비스 공급자와는 별개다.
다음은 대화를 정의하는 잘못된 방식 예제이다.
Requester: “What is Bruce’s checking account balance?"
Provider: “$x"
Requester: “And what is his credit limit?"
Provider: “$y"
|
공급자는 요청들 사이에 Bruce의 계좌를 기억해야 하는데, 이는 서비스 구현에 복잡성을 가져온다. Stateless 서비스 디자인은 다음과 같이 대화를 재정의 한다.
Requester: “What is Bruce’s checking account balance?"
Provider: “$x"
Requester: “What is Bruce’s credit limit?"
Provider: “$y"
|
서비스 세분성
연산의 세분성은 중요한 디자인 포인트이다. 외부 소비를 위해 대단위 인터페이스를 사용하는 것이 권장되는 반면, 소단위 인터페이스가 엔터프라이즈 내부에서 사용된다. 대단위 인터페이스는 SubmitPurchaseOrder 같이 주어진 서비스에 대해 완전한 프로세싱이 될 수 있고, 메시지에는 구매 주문을 정의하는데 필요한 모든 비즈니스 정보가 포함된다. 소단위 인터페이스는 개별 연산을 갖고 있다: CreateNewPurchaseOrder, SetShippingAddress, AddItem.
소단위 인터페이스는 요청자 애플리케이션에 더욱 많은 유연성을 제공하지만, 인터랙션 패턴은 다양한 서비스 요청자들간 다양하다. 이는 서비스 공급자 지원을 더욱 어렵게 할 수 있다. 대단위 인터페이스는 서비스 요청자들이 일관된 방식으로 서비스를 사용할 수 있도록 보장한다. SOA는 대단위 인터페이스 사용을 요하지 않지만, 외부 통합을 위한 베스트 프랙티스로서 사용할 것을 권장한다. 서비스 구성법은 소단위 연산들로 구성된 비즈니스 프로세스를 실행하는 대단위 인터페이스를 생성하는데 사용될 수 있다.
서비스 품질 고려 사항
SOA 디자인은 컴퓨터 시스템까지도 확장되고 엔터프라이즈 라인까지 확대될 수 있다. 인터넷을 사용할 때 보안 기능과 요구 사항에 대해, 파트너들간 보안 도메인을 연결하는 방법에 대해 생각해야 한다. 인터넷 프로토콜은 신뢰성을 보장하지 않지만, 메시지가 한번에 전달 및 처리되도록 해야 한다. 이것이 불가능 할 때 요청자는 요청이 처리되지 않았다는 것을 알아야 한다.
예를 들어, 여러분이 전개한 서비스의 측정, 가용성, 응답 시간을 고려하여 이들이 정해진 범위에 있는지를 보장해야 한다. 다른 비즈니스 파트너의 서비스를 사용하는 시스템을 디자인 할 때, 서비스 지향 관리를 사용하여 파트너들간 서비스를 집합적으로 관리해야 한다.
맺음말
이 글에서는 소프트웨어 에셋의 가치를 높이는 SOA의 특성에 초점을 맞추어 설명했다. 아울러, 분산 애플리케이션에서 복잡성을 관리하는 부분도 설명했다. 또한 서비스의 본질을 정의했고 특성 및 베스트 프랙티스도 살펴 보았다.
다음 기술자료에서는 SOA의 아키텍처 개념에 대해 검토하려고 한다.
- 서비스 호출과 디스크립션
- 브로커 모델
- 내부 통합
- 서비스 외부화
참고자료
- 기술자료 "서비스 지향 아키텍처 입문 (한글)" SOA (한국 developerWorks, 2004년 4월): SOA에 대한 정보와 참고자료.
- 이 기술자료의 Part 2 보기, "서비스 지향 아키텍처를 통한 웹 서비스 비전 확대, Part 2" (developerWorks, 2004년 6월).
-
서비스 지향 아키텍처 웹사이트 (IBM).
-
"이-비즈니스 서비스 통합", (developerWorks, 2000년 10월).
-
"서비스 지향 아키텍쳐로 전환, Part 1 (한글)" (한국 developerWorks, 2003년 12월) 서비스 지향 아키텍처의 가치를 정확히 이해하기.
-
"서비스 지향 아키텍처로 전환, Part 2 (한글)" (한국 developerWorks, 2003년 12월) 이 글을 다 읽은 후에는 SOA가 미래의 애플리케이션을 빠르고 정확하게 개발할 수 있는 최상의 플랫폼이라는 것을 알 수 있을 것이다.
-
도서 검색: 이 글 또는 다른 기술의 토픽 확인.
필자소개 | | | Mark Colan은 IBM의 이-비즈니스 기술 전도사이다. 웹 서비스와 XML 기술 및 전략 분야에서 일하고 있다. 2000년과 2001년 대부분의 XML 컨퍼런스를 비롯하여 Java One '98과 '99에서 강연도 했다. 최신 프리젠테이션 자료(PDF)는 http://ibm.com/developerworks/speakers/colan에서 제공하고 있다. IBM에 입사하기 전, Lotus Development Corporation에서 12년 동안 근무했으며, 상용 제품들을 개발했다. 상용 소프트웨어 제품과 기술의 디자인 및 구현에 20년 경력을 쌓았으며, 컴포넌트 소프트웨어 전략, 운영 체계, 소프트웨어 툴에도 정통하다. Lotus에서 개발된 자바 표준 확장인 InfoBus Technology의 아키텍트 리더이다. (mcolan@us.ibm.com)
|
기사에 대한 평가
| |
