ALSB의 설계 철학은 서비스 구현으로부터 관리 기능을 분리하자라는 것. 그래서 서비스 제공자와 사용자간의 Req-Resp 메시지 흐름을 관리자적인 측면에서 중재할 수 있다. 이는 ALSB의 관리자가 서비스 사용자와 제공자간의 흐름을 제어하고 모니터링할 수 있으며 서비스 공개에 대한 Lifecycle을 관리할 수 있음을 의미한다. 또한 이 서비스 흐름에는 단지 서비스 제공자와 사용자간의 연계만 포함되는 것이 아니라 서비스에 대한 등록과 삭제, 동적인 Routing, 변환, 보안적인 이슈, 비즈니스 프로세스등이 포함된다. 즉, ALSB는 보다 지능화된 서비스에 대한 메타 프록시서비스이고 ALSB에서 강조되거나 독특한 점은 이러한 것을 관리자 수준에서 제어하도록 유도한다는 점일 것이며 따라서 이것은 개발이나 구현등의 이슈가 아닌 정책(Policy)이라는 이슈로 끌어올렸다는 점에서 다른 ESB와의 차별성이 있다고 할 수 있다.

그 외 기능 부분에서 다른 ESB와 차별화될만한 요소들은 다음과 같다.

XQuery 사용: XQuery를 관리자 수준에서 사용함으로써 보다 복잡한 XML 제어가 가능해졌다. 이는 어쨌든간에 장점으로 볼 수 있겠는데, 아무래도 XPath보다는 Xquery를 사용했을 때 보다 복잡하고도 세밀한 XML 제어가 가능해지며 관리자나 개발자의 역량에 따라 다양한 기법을 적용해볼 수 있다는 측면에서 적절한 선택이 아닌가 생각한다. 그 반면에 XQuery 역시 과도한 XML 처리를 불러오므로 속도의 저하는 피할 수 없는 게 아닌가 한다. XSLT보다는 처리 속도에 있어서 나은 성능을 보여줄 지는 모르겠으나 XQuery 역시 성능을 크게 낮출 요인이 될 것이다.

로깅 및 모니터링의 강화: SLA를 만족시키기 위해 할 수 있는 최대한의 것을 제공하겠다는 의도로 다양한 인프라스트럭쳐가 제공된다. 일단 기본적인 수준의 대쉬보드는 관리자 콘솔에서 확인할 수 있고 그 외 세밀한 것들에 대해서는 여러 API등을 통해서도 확인이 가능하다. 게다가 뭔가 문제가 생기거나 자신이 원하는 SLA를 만족시키지 못하였을 경우에는 Altert 기능도 사용할 수 있다. 또한 이러한 SLA에 따라 서비스를 종료하거나 실행하는 것이 가능하다. 일단 이 부분에 대한 보다 자세한 검증은 필요하겠으나 기본적으로 이 정도면 ESB에서 필요한 관리 요건을 어느 정도 충족했다고 보여진다.

(to be continue…)