웹 서비스 개발 방법론 - 모바일 애플리케이션 개발, 웹 서비스, SOA 아키텍처 - 기술
콘텐츠로 건너뛰기

웹 서비스 개발 방법론 - 모바일 애플리케이션 개발, 웹 서비스, SOA 아키텍처

광고

Coulouris는 분산 시스템을 "컴퓨터 네트워크에 존재하는 하드웨어 및/또는 소프트웨어 구성 요소가 메시지 교환을 통해 통신하고 해당 작업을 조정하는 시스템"으로 정의했습니다.

이 개념은 몇 가지 요인으로 인해 최근 몇 년간 대중화되었습니다. 분산 시스템의 발전을 촉진한 첫 번째 요인은 고속 로컬 네트워크의 출현이었습니다. 또 다른 중요한 요소는 개인용 컴퓨터 성능의 기술적 진보와 분산 애플리케이션을 지원하는 소프트웨어 개발이었습니다. 분산 시스템은 웹(Web)과 인터넷(Internet)이라는 개념과 연결되어 있다. 웹이 발전하고 새로운 영역, 상호 작용, 요구 사항 및 애플리케이션이 등장하면서 웹 2.0의 개념이 등장했습니다. 이 용어는 협업과 민첩성을 장려하는 소셜 네트워크, 블로그, 위키, 포크소노미와 같은 특별한 범위의 서비스와 사용자 커뮤니티를 기반으로 하는 웹 역사의 2세대를 지칭하기 위해 2004년 Tim O'Reilly에 의해 만들어졌습니다. 사용자 간의 정보 교환.

서비스 지향(SOA)으로 간주될 수 있는 첫 번째 아키텍처는 아키텍처의 다양한 요소를 상호 연결하고 서비스를 구축하는 추상화 계층 역할을 하는 CORBA(Common Object Request Broker Architecture)를 기반으로 했습니다. 다른 초기 기술로는 DCOM(Distributed Component Object Model) 또는 RPC(Remote Procedure Protocol)가 있습니다. 웹에서 분산 시스템을 효율적으로 설계하고 구현해야 하는 필요성으로 인해 몇 가지 과제가 발생합니다. 일부는 개발 자체(성능, 사용자 경험 등)에 초점을 맞추고 다른 일부는 서비스의 재사용성과 호환성을 기반으로 하는 보완적인 문제에 중점을 둡니다. 이러한 요구에 따라 다양한 사용자를 정보 서버와 상호 연결하는 표준화된 메커니즘을 제공하는 웹 서비스가 탄생합니다.

서비스 지향 아키텍처

SOA(서비스 지향 아키텍처)에 따르면 이는 비즈니스 요구 사항을 지원하기 위해 서비스 사용을 정의하는 소프트웨어 아키텍처이며, 그 목적은 소프트웨어 에이전트 간의 가능한 최소 결합을 달성하는 것입니다. 서비스는 서비스 소비자가 원하는 최종 결과를 달성하기 위해 서비스 제공자가 수행하는 작업 단위입니다. 서비스 제공자와 서비스 소비자는 모두 소유자가 아닌 소프트웨어 에이전트가 수행하는 역할입니다. 일반적인 의미에서 서비스 지향 아키텍처는 회사가 다양한 프로세스를 구성하고 활용할 수 있도록 고안된 소프트웨어 솔루션입니다. SOA를 사용하면 소프트웨어 애플리케이션은 더 이상 기능과 프로세스의 거대한 블록이 아닙니다. 대신 이러한 애플리케이션은 조립된 모듈식 서비스로 구성됩니다. 서비스는 단순한 소프트웨어 기능(예: CD 재생 취소)이라는 점을 기억하십시오. 운영 체제, 플랫폼, 프로그래밍 언어 또는 지리적 위치에 관계없이 모든 시스템에서 요청 시 실행할 수 있습니다.

SOA의 혁명적인 점은 오랫동안 존재해온 개념 자체가 아니라 WWW(World Wide Web)를 통해 구현될 수 있다는 점이다. 모든 플랫폼에서 웹 페이지가 로드되는 것처럼 웹 서비스는 다음을 사용하여 구축되므로 플랫폼에 관계없이 비슷한 방식으로 작동합니다.
보편적인 표준.

사진SOA의 아이디어는 데이터와 처리 사이의 관계를 제안하는 객체 지향 프로그래밍에서 직접 유래합니다. 따라서 기본 플랫폼 및 프로그래밍 언어와 독립적인 인터페이스를 통해 서비스를 공식적으로 정의합니다. 이러한 인터페이스는 구현의 특성을 숨기므로 다른 인터페이스와 독립적입니다. 개발자와 프로그래밍 언어. 이러한 아키텍처를 통해 비즈니스 논리를 반영하는 동시에 다양한 독점 시스템 또는 타사 시스템 간의 상호 작용을 촉진하는 확장성이 뛰어난 시스템을 설계 및 구현하는 것이 가능합니다. 우리가 누군가에게 일을 맡기고 싶은 이유는 그 사람이 전문가이기 때문입니다. 서비스를 이용하는 것은 일반적으로 직접 수행하는 것보다 저렴하고 효과적입니다. 그래서 우리 대부분은 모든 것에 전문가가 될 수 없다는 것을 이해합니다. 소프트웨어 시스템 구축에도 동일한 규칙이 적용될 수 있습니다.

인터페이스는 매우 중요합니다. 잘 정의되지 않거나 작동하지 않으면 시스템이 작동하지 않습니다. 더 많은 인터페이스를 통합하면 비용이 많이 들고 분산 애플리케이션에서 오류가 발생할 가능성도 높아집니다. 원격 인터페이스는 대부분의 분산 애플리케이션에서 가장 느린 부분입니다. 이 모든 것을 통해 각 애플리케이션에 대해 새로운 인터페이스를 구축하는 대신 모든 애플리케이션에 대해 일반 인터페이스를 재사용하는 것이 더 합리적입니다.

따라서 사용할 수 있는 일반 인터페이스는 몇 가지뿐이므로 메시지에 애플리케이션별 의미를 포함해야 합니다. 인터페이스를 통해 모든 유형의 메시지를 보낼 수 있지만 아키텍처가 서비스 지향적이라고 말하려면 따라야 할 몇 가지 규칙이 있습니다.

– 첫째, 메시지는 서비스 제공자가 문제 해결을 담당하므로 교훈적이지 않고 설명적이어야 합니다. 예를 들어, 레스토랑에 가서 웨이터에게 무엇을 마시고 싶은지, 선호하는 음료를 말하는 것과 비슷할 것입니다. 하지만 요리사에게 요리를 준비하는 방법을 단계별로 설명해서는 안 됩니다.

‐ 둘째, 서비스 제공자는 관련된 모든 사람이 이해할 수 있는 형식, 구조 및 어휘로 메시지가 작성되지 않으면 귀하의 요청을 이해할 수 없습니다. 따라서 메시지의 어휘와 구조를 제한하는 것은
효과적인 의사소통을 위해 필요합니다. 메시지를 제한할수록 이해하기가 더 쉽습니다.

‐ 셋째, 확장 가능성이 매우 중요하다. 세상은 끊임없이 변화하는 곳이며, 소프트웨어가 살아가는 환경도 마찬가지입니다. 이러한 변경에는 시스템 소프트웨어, 소비자에 대한 해당 변경이 필요합니다. 서비스, 공급자 및 그들이 교환하는 메시지. 메시지를 확장할 수 없는 경우 소비자와 공급자는 특정 버전의 서비스에 고정됩니다. 제약 조건과 확장성은 깊은 관련이 있으므로 둘 다 필요하며, 하나를 늘리면 다른 하나는 줄어듭니다. 이상적인 것은 올바른 균형을 이루는 것입니다.

– 넷째, SOA에는 소비자가 원하는 서비스의 맥락에서 소비자가 서비스 제공자를 찾을 수 있도록 하는 메커니즘이 있어야 합니다. 메커니즘은 유연해야 하며 중앙 집중식 레지스트리가 아니어야 합니다.

‐ 다섯째, Stateless 서비스: 소비자가 공급자에게 보내는 각 메시지에는 공급자가 이를 처리하는 데 필요한 모든 정보가 포함되어야 합니다. 이러한 제한으로 인해 서비스 공급자는 요청 간에 상태 정보를 저장할 필요가 없으므로 서비스 공급자의 확장성이 향상됩니다. 각 요청을 일반적으로 처리할 수 있으므로 이를 "대량 생산 서비스"라고 부를 수 있습니다. 또한 모든 모니터링 소프트웨어가 독립적인 요청을 검사하고 그 의도를 추출할 수 있으므로 이러한 제한은 더 많은 가시성을 제공합니다. 또한 중간 상태가 없기 때문에 부분 장애로부터 쉽게 복구할 수 있어 서비스의 안정성이 더욱 높아집니다.

‐ 여섯째, 멱등적 요청(변경하지 않음): 소프트웨어 에이전트가 받은 중복 요청은 단일 요청과 동일한 효과를 갖습니다. 이 요구 사항을 통해 공급자와 소비자는 서비스의 전반적인 신뢰성을 높일 수 있습니다. 서비스, 오류가 발생한 경우 요청을 반복하기만 하면 됩니다.

따라서 SOA는 도구가 아니라 새롭고 더욱 동적이고 덜 의존적인 애플리케이션을 구축하기 위한 표준 세트라고 말할 수 있습니다. SOA는 체계적인 방식으로 서로 다른 서비스 간의 비즈니스 논리 및 정보에 대한 액세스를 용이하게 하며, 여러 원격 서비스를 조율하여 단일 서비스를 구성할 수도 있습니다. 다수의 정의는 서비스 지향 아키텍처 구현에서 다음 장에서 살펴보게 될 웹 서비스의 사용을 식별합니다. 그러나 다른 서비스 기반 기술을 사용하여 구현할 수 있습니다.