SOA는 비지니스 로직과 데이터를 서비스 중심으로 전환함으로써 소프트웨어 아키텍처의 패러다임을 이동시킨다. SOA는 다음과 같은 4가지 원칙을 반영하는데, 이것이 바로 전통적인 소프트웨어 아키텍처 접근방법과의 차이점이다. 따라서, 기존의 아키텍처를 SOA를 기반으로 한 아키텍처로 바꾸어 디자인하기 위해서는 다음 4가지 사항을 유의하여 고려해야 한다.
프로세스 중심
서비스 혹은 애플리케이션 통합에 대한 요구는 결국 비즈니스 프로세스 자동화라는 필요에 의해서 발생된다. 실제로 비즈니스 서비스는 타인에게 자신의 서비스를 제공하는 반면 프로세스 서비스는 이들 간의 통합을 위한 공통 인프라를 제공한다. 비즈니스 서비스가 실제 비즈니스 로직을 제공한다면, 프로세스 서비스는 프로세스 오케스트레이션(Orchestration). 즉, 언제, 어디서, 누구를, 어떻게 통합해야 하는 지 같은 제어 역할을 담당하게 된다.
이렇게 비즈니스 서비스와 프로세스 서비스의 역할을 분리하지 않은 상태에서는 여러 가지 문제점이 나타난다. 이는 비즈니스 프로세스의 진행 상태를 추적하거나, 프로세스 상에서 발생하는 비즈니스 적인 예외 사항 처리를 힘들게 만든다. 또 프로세스 변경 시 각 애플리케이션들을 함께 변경해야 한다는 문제를 발생시키며, 서비스 내부로의 진입이 필요하기 때문에 보안의 문제까지 유발한다. 이러한 문제점들을 해결하기 위해 SOA에서는 프로세스 서비스를 별도의 구성 요소로 두어 통합에 필요한 메시지 처리와 서비스 오케스트레이션을 담당하게 하고 있다. 그렇게 함으로써 통합에 참여하는 애플리케이션이 자신의 고유 기능에만 집중할 수 있도록 한다. 이런 구조는 각 애플리케이션들의 서비스 진입 지점을 프로세스 서비스로 단일화하고, 업무 프로세스 추적을 가능하게 해준다. 이를 통해 비즈니스 외적인 예외 사항을 보다 쉽게 처리하게 할 수도 있고, 각 애플리케이션들은 업무 프로세스 변경에 독립적일 수 있게 된다. 물론 프로세스 서비스는 메시지 처리, 메시지 연계(Correlation), 비즈니스 트랜잭션 처리, 영속적(Persistent) 프로세스 관리 기능 등을 기본적으로 제공해야 하는데, 이 역시 결코 쉬운 일은 아니다. 이를 위해 몇 가지 솔루션을 사용할 수 있는데 이들은 BPEL4WS(Business Process Execution Language For Web Services)와 같은 표준 언어로 기술된 비즈니스 프로세스의 복잡한 과정을 자동화한다.
플랫폼 독립적 애플리케이션 통합
일반적으로 기업 내의 애플리케이션은 비즈니스 단위별로 작성되고 있으며 그 플랫폼 또한 다양하다. 이에 따라 각 애플리케이션의 통합을 위해 별도의 통합 계층을 두는 것이 일반적이었다. 물론 서로 다른 플랫폼일 경우에만 이러한 통합 계층이 나타나는 것은 아니다. 동일한 플랫폼이라 할지라도 서로 다른 버전을 사용하거나, 공급 벤더가 다를 경우 역시 이러한 통합 계층이 필요했다. 그런데 기업 비즈니스의 경우 기술이나 제품의 변화가 매우 빠르다고 해서, 연결된 애플리케이션들을 동시에 업그레이드하거나 재작성하는 것은 현실적으로 불가능하다. 결과적으로 기업 내 시스템들은 필연적으로 이질적인 환경을 가질 수밖에 없게 되는데, 이는 통합 계층을 점점 더 넓어지게 만든다. 또 이것은 성능, 신뢰성, 보안 등과 같은 문제들까지 더욱 복잡한 양상을 띄게 한다. 애플리케이션들은 서로 연결될수록 더 많은 요구를 처리해야 하기 때문에 더 높은 성능을 필요로 하게 되며, 다른 보안 수준의 기술을 사용하고 있는 애플리케이션들이 연결될 경우, 서로의 보안 수준에 영향을 끼치게 되어 연결된 시스템의 신뢰성이 자신의 신뢰성에 직접 영향을 끼치게 되는 경우도 발생한다. SOA에서 지원하는 플랫폼 독립적인 통합이라는 의미는 단순히 모두가 합의할 수 있는 공통의 프로토콜을 규정함으로써 구현 기술에 관계없는 연결을 보장한다는 것만을 의미하는 것이 아니다. 통합에 따른 성능 요구에 적절하게 대응할 수 있는 스케일 아웃(Scale Out)이 가능해야 하며, 구현 기술에 관계없는 보안 수준을 제공하거나 이를 명시적으로 관리할 수 있어야 한다. 또한 애플리케이션 수준의 신뢰성을 보장할 수 있는 여러 가지 장치들도 모두 포함하고 있어야 한다.
느슨한 연결(Loosely Coupled) 지향
프로세스 설계를 용이하게 하기 위해서는 프로세스 자체를 단순화시켜야 하며, 이것은 서비스 사이에 발생하는 상호 작용을 단순화 시켜야 한다는 것을 의미한다. 실제로 각 서비스들은 기본적으로 독자적인 시스템이기 때문에, 기존 서비스의 비즈니스 로직은 얼마든지 추가, 변경 확장 될 수 있다. 또 이런 변화는 서비스의 인터페이스에 반영이 되기 마련이다. 하지만 일반적으로 비즈니스 컴포넌트를 작성하기 위해 주로 사용되는 기술들(COM+, EJB, CORBA 등)은 객체지향언어를 기반으로 하고 있다. 객체지향언어 기반의 기술들은 인터페이스의 변화에 대응하기 힘들며, 서비스 내부 구현에 사용되는 인터페이스와 외부로 노출되는 비즈니스 인터페이스를 구분하기가 힘들었다. 이런 문제를 해결하기 위해서는 서비스가 느슨하게 연결된 인터페이스를 제공해야 한다.
위 그림은 캠코더를 구입 혹은 판매하는 두 가지 방식에 대한 것이다. 전자는 판매상을 직접 방문하거나 전화를 통해 구입하는 방식인 반면, 후자는 팩스를 이용해 구입하는 방식이다. 위의 두 가지 경우 모두 판매업자와 소비자가 서로 상호 작용을 하게 되며, 이러한 상호 작용은 적절한 절차 즉, 프로세스를 따라 진행된다. 그리고 상호 작용이 적절한 순서대로 진행되었을 때 실제 구매 혹은 판매가 발생한다. 여기서는 후자의 방식이 전자의 방식에 비해 보다 느슨하게 연결되어 있는 것이다. 전자의 경우 손님과 점원 사이의 첫 인사와 마지막 인사 사이에 발생하는 모든 상호 작용이 동일한 상점, 비교적 짧은 시간 내에 모두 발생하는 관계로 각 상호 작용들이 순서, 시간, 장소에 매우 밀접하게 결합되어 있다. 반면, 후자의 경우, 각 상호 작용들은 순서, 시간, 장소에 비교적 느슨하게 결합되어 있다. 즉, 구매자가 어떤 경로를 통해 카탈로그를 구했든 구매자는 정확하게 그 카탈로그가 무엇을 의미하는 지 알 수 있으며, 카탈로그를 입수했다고 해서 바로 물건을 구매할 필요도 없다. 판매자의 입장에서도 이전 카탈로그 전송 여부에 상관없이 자신의 팩스로 들어온 정보가 무엇을 의미하는 지 이해할 수 있으면 그만이다. 또 다른 중요한 점은 전자에 비해 후자는 복잡한 상호 작용이 발생하지 않으며, 절차는 훨씬 단순해졌다는 점과 전자에 비해 비교적 적은 수의 종업원으로도 많은 주문을 처리할 수 있다는 점이다. 이런 차이가 발생하는 이유는 카탈로그가 전달하는 정보의 양이 훨씬 더 완전하기 때문이다. 결국 느슨한 인터페이스라는 것은 보다 완전한 정보를 포함하고 있어 시간, 장소, 순서 등에 독립적인 인터페이스를 의미한다. 주의할 점은 느슨함과 밀접함은 서로 선택적인 것이 아니라 연속적인 개념이라는 점이다. 그러므로 여러 가지 현실적인 고려 사항을 생각해 적당한 수준의 느슨함을 유지하는 것이 중요하다. 정리하자면, 느슨하게 연결된 인터페이스는 보다 완전한 정보를 기술하며, 서비스간의 종속성을 줄여주고 프로세스를 단순화시켜준다.
메시지 및 프로세스 상태 관리
SOA 도입시 주의를 기울여야 할 원칙 중 하나는 상태 관리 측면이다. 일반적으로 컴포넌트는 메소드(method) 호출을 통해 비즈니스 로직을 구동한 후, 컴포넌트를 호출한 애플리케이션의 데이터 저장소에 영속적(persistent) 데이터를 저장하게 된다. 여기서 영속적 데이터란 '고객의 주문 내역'과 같이 일반적으로 관계형 데이터베이스에 저장되는 정보를 의미하는데, 서비스는 각각이 독립된 시스템이기 때문에 연속적 데이터를 각 서비스에서 관리하게 된다. SOA에서의 서비스는 프로세스 및 메시지 상태의 관리를 요구한다. 메시지 상태의 관리란 중복된 메시지, 비동기 메시지 등을 효과적으로 다루기 위해 필요하다. 즉 물건에 대한 주문서를 상점에 보냈음에도 불구하고 응답이 없어 다시 주문서를 보냈다고 하자. 이때 상점에서 주문서를 두부 받았지만, 이 주문은 한차례의 것으로 처리해야 한다. 프로세스 상태 관리는 전체 비즈니스 프로세스 상에서 서비스 자신이 어떤 순서에 도달해 있는 지 관리하기 위해 필요하다. 전체 프로세스 중, 어떤 작업까지를 완수했는지, 앞으로 어떤 작업을 계속 해야 하는지, 프로세스 도중 발생한 예외나 오류를 어떤 방식으로 보정할 것인지 등을 관리하기 위해 필요하다.
