1. 서론
오늘날 모든 기업은 생산 효율성을 향상시킬 수 있는 방법을 모색하고 있으며, IT 자산의 재구성도 적극적으로 모색하고 있습니다. IT 조직은 서비스 지향 아키텍처(SOA) 기술의 도움으로 이러한 문제를 극복하는 데 어느 정도 진전을 이루었지만 대부분의 경우 전체 IT 서비스 포트폴리오의 일부만 구현됩니다. 현재 이 분야의 대부분의 노력은 단순히 SOA 채택의 "충분한" 상태, 즉 애플리케이션 구축 능력을 향상하고 이를 시장과 더 빠르고, 더 좋고, 더 저렴하게 통합하는 것입니다. 그리고 우리가 배운 것처럼 이러한 목표를 달성하는 것은 말처럼 쉽지 않습니다.
2. 전통적인 미들웨어 기반 복합 애플리케이션
기존 사실은 SOA가 일종의 미들웨어라는 것입니다. 전통적인 경우 미들웨어는 데이터를 소비자 친화적인 상태로 변환하기 위해 더 많은 미들웨어에 의존하는 경우가 많습니다. SOA 기술을 통합한 복합 애플리케이션을 구축하려면 포털(미들웨어)을 사용해야 할 뿐만 아니라 이를 조정하기 위해 BPEL 엔진(또는 미들웨어)도 사용해야 할 수도 있다는 점을 마침내 파악하게 되면, 당연히 다음과 같은 결과를 얻게 됩니다. 매우 실망했습니다. 더 나쁜 것은 UDDI 레지스트리를 게시하고 수많은 웹 서비스를 등록하는 조직 내에서 일할 수도 있다는 것입니다. 불행하게도 대부분의 경우 실제로 이러한 서비스를 사용하는 애플리케이션은 거의 없습니다.
이러한 SOA 서비스를 사용하는 애플리케이션을 구축할 수
없다면 비즈니스 콘텐츠 개발자가 SOA 서비스를 직접 사용하는 애플리케이션을 구축하기가 너무 어렵기 때문일까요? 우리를 위해 그러한 애플리케이션을 만들기 위해 다른 IT 조직에 의존하는 것이 SOA 거버넌스 구조의 부족 때문에 위의 모든 질문에 대한 대답은 "예"라고 생각합니다. 그리고 매우 중요한 이유가 있습니다. IT 조직에서 제공하는 이러한 SOA 서비스를 비즈니스 개발자만이 소비하고 활용하는 것은 너무 어렵습니다. 실제로 진짜 문제는 SOA에 인터페이스를 추가할 수 있는 쉬운 방법이 없다는 것입니다. 이것이 AJAX 기술과 SOA를 결합할 때의 장점입니다.
일반적으로 SOA 서비스는 비즈니스 기능을 캡슐화하고 노출하는 느슨하게 연결된 웹 서비스로 구현됩니다. 이는 매우 간단해 보이지만 구현하기가 매우 복잡하고 어렵습니다. 개발자들은 SOA 서비스의 개발 세분성에 대해 종종 논쟁을 벌입니다. 그러나 이제 대부분의 개발자는 "비즈니스 수준" 개발 세분성이 가장 적절하다는 데 동의합니다. 그러나 이를 위해서는 여전히 많은 수의 관련 도메인 전문가가 참여하여 비즈니스 콘텐츠와 협력하여 이러한 서비스의 규모를 확정해야 합니다.
3. SOA의 르네상스
다행히도 최근에는 SOA에 대한 관심이 높아졌습니다. 아마도 기업들은 마침내 SOA가 실제로 엄청난 도움이 될 수 있다는 것을 깨닫고 있을 것입니다. 아마도 이는 Amazon, Yahoo 및 eBay가 홍보하는 더 나은 개발 도구와 웹 서비스 때문일 것입니다. 어쩌면 AJAX일까요? 그렇습니다. 이것이 제가 이 글을 쓰는 이유입니다. AJAX는 특히 오늘날 다양한 신기술의 하이브리드 애플리케이션 분야에서 SOA에 대한 사람들의 이해를 새롭게 하는 데 중요한 원동력이 되었다고 생각합니다. 그러나 더 큰 힘을 발휘하기 위해 서로 매우 다른 두 기술을 어떻게 결합하고 연결해야 할까요? 먼저 현재 AJAX 기술에 대한 Wikipedia의 정의를 살펴보겠습니다. 웹 페이지가 관련되어 있지만 SOA는 전혀 언급되지 않습니다. 설명은 다음과 같습니다.
"Asynchronous JavaScript+XML'의 약자인 AJAX는 대화형 웹 애플리케이션을 만들기 위한 웹 개발 기술입니다. 서버와 소량의 데이터를 교환하여 프런트 엔드 웹 페이지를 보다 쉽게 만드는 것이 그 목적입니다. 따라서 사용자가 변경할 때마다 전체 웹 페이지를 다시 로드할 필요가 없습니다. 궁극적인 목표는 웹 페이지의 상호 작용성, 응답성 및 유용성을 더욱 향상시키는 것입니다.
SOA는 이 정의에서 언급되지 않습니다. 초기 AJAX 애플리케이션은 페이지의 기능과 유용성을 향상시키는 데 중점을 두었기 때문입니다. 이는 Google Maps, Flickr 및 Yahoo Mail과 같은 수많은 애플리케이션에서 입증되었습니다. 그러나 AJAX의 잠재력에 대해 나를 흥분시키는 것은 이러한 소비자 지향 애플리케이션이 아니라 AJAX의 장점을 실제로 활용하는 회사 방화벽 뒤에서 실행되는 비즈니스 애플리케이션입니다. 두 가지 주요 특성을 보여주기 때문입니다. 하나는 클라이언트입니다. -측 프로그래밍 모델과 다른 하나는 서버에 대한 비동기 호출을 쉽게 구현하는 것입니다. 클라이언트(브라우저)에 논리를 적용하는 기능과 웹 페이지를 중단하지 않고 서버 데이터에 액세스하는 기능이라는 두 가지 주요 기능은 새롭고 풍부한 Web 2.0 엔터프라이즈 응용 프로그램을 구축할 수 있는 문을 열어줍니다. .
앞서 SOA에는 인터페이스가 부족하다고 언급했습니다. 이것이 AJAX가 등장하는 곳입니다. SOA에 괜찮은 모양을 추가합니다. 여기서 조금 더 설명을 부탁드리겠습니다. SOA 서비스가 온라인에 등장한다면 어떤 일이 일어날지 생각해 보는 것이 어떨까요? 이러한 서비스는 일반적으로 등록소나 창고에 등록된 다음(운이 좋다면) 소비에 사용될 수 있습니다. 예를 들어 StrikeIron 웹사이트( www.StrikeIron.com )에서 제공되는 내용을 살펴보겠습니다. StrikeIron은 일반 대중을 위한 "웹 서비스 마켓플레이스"를 성공적으로 만들었습니다. 언뜻 보면 StrikeIron의 디렉토리 메커니즘은 소규모 비즈니스 애플리케이션에서 제공되는 목록과 매우 비슷해 보입니다. 그러나 나중에는 이것이 단순한 애플리케이션이 아니라 실제로는 웹 서비스라는 것을 깨닫게 될 것입니다. 단일 회사가 다양한 소비자에게 WSDL/REST 웹 서비스를 제공한다는 개념은 많은 의미를 갖습니다. 하지만 지금은 이 회사가 무엇을 판매하는지 살펴보겠습니다. StrikeIron(이러한 서비스에 대한 액세스를 제공)에서 제공한 정보에 따르면 제공되는 가장 인기 있는 웹 서비스는 다음과 같습니다.
· 미국 주소 확인
· 글로벌 SMS 서비스
· 판매 및 사용세
· 이메일 확인
· 전화 역방향 조회
의심의 여지가 없습니다. 이러한 웹 서비스는 매우 유용하며 다양한 분야에서 사용될 수 있습니다. 그러나 동시에 그들은 너무 "상품"이기도 합니다. 즉, 누가 이러한 서비스를 제공하는지 관심이 없고 단지 내가 원하는 정보만 얻고 싶을 수도 있습니다. 반면에 웹 서비스를 사용하여 당좌 계좌에서 저축 계좌로 현금을 이체할 수 있습니까? 먼저 이 서비스에 대한 신뢰를 구축해야 하므로 이를 제공하는 업체와 일정한 관계를 구축해야 합니다. 나(소비자)와 서비스 제공자 사이에 존재하는 이러한 "신뢰의 고리"는 기업과 파트너 간의 관계를 나타내기도 합니다.
4. AJAX + SOA 기술 결합
위와 동일한 방법은 기업이 더 넓은 사용자 기반에 웹 서비스를 제공하기 위해 채택할 수도 있습니다. 웹 서비스 시장을 통해 기업은 다양한 웹 서비스를 등록할 수 있으며, 이러한 웹 서비스는 일반적으로 기업 내부 또는 파트너에게만 제공됩니다. 시장 벤더들은 분명히 이것이 일어나기를 원하지만 더 중요한 것은 AJAX+SOA 기술을 적용하여 새로운 종류의 Web 2.0 비즈니스 애플리케이션을 구동할 수 있는 기회가 있다는 것입니다.
처음으로 사람들은 애플리케이션 개발과 SOA가 마침내 합쳐졌다고 느끼기 시작했습니다. 우리는 재사용 가능한 형태로 설명된 비즈니스 기능, 즉 SOA 서비스를 보유하고 있습니다. 우리는 웹이라는 유비쿼터스 연결성을 갖고 있습니다. 우리는 새로운 애플리케이션 컨테이너임이 입증된 브라우저를 보유하고 있습니다. 이러한 유형의 애플리케이션 컨테이너/브라우저에는 JavaScript라는 프로그래밍 모델이 있습니다. 그리고 그들은 모두 개방형 표준을 사용합니다. 실제로 다른 것이 있습니까?
나는 특히 위의 모든 기술을 기반으로 애플리케이션을 개발하는 더 빠른 방법, 즉 SOA 서비스와 통합된 미들웨어에 의존하지 않고도 애플리케이션을 구축할 수 있는 방법을 보고 싶습니다. 이것이 바로 제가 웹 애플리케이션에서 "SOA에 직접 연결"할 수 있기를 바라는 것입니다. 이 "SOA에 대한 직접 연결"은 전통적인 포털 장벽과 무거운 프로세스 엔진을 우회하여 SOA 서비스에 직접(적어도 개념적으로는 나중에 자세히 알아볼 것임) 액세스할 수 있어야 합니다. 이는 단순히 웹 서비스를 의미하는 것이 아니라 BPEL 오케스트레이션 서비스, 대략적인 POJO 서비스, RSS 피드 또는 "서비스"로 노출될 수 있는 기타 모든 것일 수도 있습니다. 물론 인터페이스는 개방형 표준을 사용하여 노출되어야 합니다.
이 새로운 개발 및 런타임 모델은 애플리케이션 중심 복합 애플리케이션을 구축하는 새로운 방법을 제시합니다. 기존의 무거운 클라이언트/서버의 무거운 짐이 없는 클라이언트/서버 유형의 매력이 있습니다. 이는 브라우저 측에서 실행되며 특정 요구 사항에 따라 구현될 수 있습니다.
5. 사용자 기반 복합 애플리케이션
지난 몇 년 동안 우리는 모두 "복합 애플리케이션"이라는 개념을 들어왔습니다. 그러나 대부분의 공급업체는 호스트 서비스를 보다 유용한 다른 서비스나 포털 애플리케이션으로 재구성하는 방법으로 "복합 서비스"에 대해 이야기해 왔습니다. 더 자세히 설명하기 위해 비유를 해보겠습니다.
이 기사에 나오는 가상의 그리드 컴퓨팅 공급업체인 AcmeGrid는 애플리케이션이 서비스로 실행될 수 있도록 하는 서비스, 즉 그리드 컴퓨팅을 제공합니다. 이 회사의 고객들은 많은 서비스를 하나의 대략적인 서비스로 결합하는 방법을 원한다고 말했습니다. 그래서 자연스럽게 AcmeGrid는 Eclipse 기반 AcmeGrid Composite Application Builder(CAB)를 출시했습니다. 흥미롭게도 CAB는 BPEL 디자이너와 매우 비슷해 보이지만 AcmeGrid에서 게시한 서비스와 더 긴밀하게 통합되어 있습니다. 그러나 매우 아름답기는 하지만 실제 응용 프로그램은 아니며 기껏해야 서비스일 뿐입니다. 본질적으로 CAB는 서비스 빌더와 비슷합니다. 하지만 애플리케이션을 구축하려고 할 때 누가 서비스 빌더가 필요합니까? 곧 또 다른 가상 공급업체인 AcmePortal이 PCAB(Portal Composite Application Builder)를 발표했습니다. 또한 Eclipse 기반 디자이너와 함께 제공됩니다. 비록 BPEL 디자이너처럼 보이고 느껴지지만 이 프로그램은 포털 구축 방법을 "알고 있습니다". 많은 경우 포털은 애플리케이션과 마찬가지로 작동합니다. 그러나 포털을 애플리케이션으로 전환하려고 하면 소용이 없습니다.
사실 저는 미들웨어 기반의 복합 애플리케이션보다는 사용자 기반의 복합 애플리케이션을 구현하고 싶습니다. 이를 위해서는 AJAX와 SOA를 사용할 수 있을 뿐만 아니라 둘 다 관리할 수 있는 개발 및 런타임 플랫폼이 필요했습니다. 일부 공급업체에서는 AJAX 애플리케이션 개념을 한 단계 더 발전시켜 브라우저에서 직접 WSDL 기반 웹 서비스를 호출합니다. 이는 기본적으로 SOAP 호출입니다. 이 접근 방식에는 "클라이언트/SOA"라는 이름도 있습니다. 단순한 비기업용 또는 소비자 애플리케이션에는 적합할 수 있지만 진정한 기업용 프로그램에는 적합하지 않습니다. 그 이유는 브라우저에서 직접 웹 서비스를 호출할 때 감독 기능이 브라우저에 넘겨지는 것과 같기 때문입니다. 이는 단순히 감독 문제가 전혀 없음을 의미합니다. 그림 1은 비지도 웹 서비스 소비의 블록 다이어그램을 보여줍니다. 나는 서비스를 감시하지 않는 회사를 본 적이 없으며, 우리가 기술적으로 매우 효율적이라는 이유만으로 회사가 이런 일이 발생하도록 허용할 것이라고 믿지 않습니다. 내 말을 믿을 수 없다면 기업에서는 HTTP와 SSL 이외의 애플리케이션에 방화벽을 절대 개방하지 않는다는 점을 기억하십시오. 시스템 관리자를 아무리 설득해도 그들은 다른 포트를 열지 않을 것입니다.
6.
위에서 볼 수 있듯이 우리가 논의하고 있는 것은 단지 AJAX와 SOA 기술에 관한 것이 아닙니다. 실제로 우리에게 정말로 필요한 것은 AJAX와 SOA가 기업에서 공존하는 데 필요한 감독 기능을 제공할 수 있는 플랫폼입니다. 또한 이 플랫폼은 클라이언트 관점에서 SOA 서비스를 소비하는 기능을 제공하고 서비스 소비를 모니터링할 수도 있습니다. 그림 2는 서비스 게이트웨이를 통해 웹 서비스를 관리하는 방법을 보여줍니다. 서비스 게이트웨이는 실제로 클라이언트를 대신하여 서비스 액세스를 모니터링하고 규제하는 서버 측 추상화입니다. 방금 논의한 경우는 브라우저 기반 AJAX 애플리케이션입니다. 서비스 게이트웨이 사용의 장점은 기업 내에서 실행되는 서비스에만 액세스하도록 제한되지 않는다는 것입니다. 이 서비스 게이트웨이는 기업 내에 등록된 모든 서비스를 감독할 수 있습니다. WSDL 기반 웹 서비스에서 기업은 WSDL을 등록하고 WSDL은 런타임 시 서비스에 대한 바인딩을 제공합니다. 이는 기업의 데이터 센터에서 실행되는 서비스일 수도 있지만 파트너십의 데이터 센터에서 실행되는 서비스일 수도 있습니다. 기업이 규정을 통해 애플리케이션이 서비스에 액세스하도록 허용하는 경우 해당 서비스가 실행되는 위치는 중요하지 않습니다.
7. 결론
이 기사를 읽은 후 AJAX와 SOA를 함께 사용하는 것의 힘, 특히 두 가지가 어떻게 공존하고 기업 서비스 애플리케이션에 필요한 규제 기능을 갖춘 새로운 유형의 웹 기반 애플리케이션을 활성화할 수 있는지 이해하기 시작하셨기를 바랍니다. . 저는 우리가 놀라운 기회의 새로운 시대를 맞이하고 있다고 굳게 믿습니다. Web 2.0 시대에는 소셜 네트워크, 이미지 공유, 다양한 주석 기술도 훌륭하지만, 정말 영향력 있는 것은 기업에 대한 Web 2.0의 반응입니다.