Oracle Tuxedo 리뷰

# oracle tuxedo 리뷰

 

Online Transanction process성 업무를 다루는 Tuxedo에서 Client가 Server로 서비스를 호출하는 테스트를 진행하다가 tuxedo가 만들어내는 솔루션에 대한 생각을 해보았다.

 

---

 

늘 그렇듯, 

들어가는 문은 한정적이나 인구는 박이 터진다. 

하나의 예를 들어보자면 서울의 지하철은 출퇴근길에 지옥철로 유명하다.

전세계적으로 보아도 대한민국 서울의 지하철 밀집도는 늘 상위권에 머무른다.

 

출퇴근을 위해서 사람들은 지하철을 타기 위해 역으로 몰려든다.

하지만 지하철의 최대 탑승객 인원은 한정적이기 때문에 탑승하지 못한 승객은 다음 지하철을 기다려야한다.

지하철 탑승객들의 이러한 불편함을 한명이라도 줄이기 위해서는 사람들이 많을 수록 더 많은 지하철이 필요하다.

 

서비스업에서는 모두가 마찬가지일 것이다. ( 물론 사업이 잘 나가야한다는 전제조건이 필요하겠지만)

 

Tuxedo 프로세스는 서울의 지하철과 비슷하다.

service(지하철탑승)를 요청하는 Client(탑승객)는 수없이 많을 것이고 Server(지하철)는 한정적일 것이다.

 

server는 강남신세계백화점이라고 생각하면 쉽겠다!

손님(client)들은 강남역으로 가는 원활한 지하철을 이용하여 강남신세계백화점(server)에 도착하고 싶어한다.

신세계백화점(server)에는 모두가 사고 싶어하는 나이키신발(service)가 있다.

 

그런데 신세계백화점의 나이키매장은 한정적인데 나이키신발도 별로 없는거지...

 

---

 

장이 열리고 닫히는 주식시장에서의 매도와 매수가 활발하게 이루어지는 주식을 예를 들어 보자.

 

우리 (클라이언트)는 주식을 매수/매도 하기 위해 웹어플리케이션이나 모바일어플리케이션을 이용할 것이다.

여기서 어느 한 종목의 주식의 트레이딩을 주어진 시간에 나만 사용할 텐가? 절대 아닐 것이다. (물론 그럴 수 있다...)

셀수 없이 많은 나와 같은 Client와 그리고 나와 동시에 트레이딩을 할 수 있는 Client들이 수십명 또는 수천, 수억 명 또는 거래 횟수가 수천 번, 수억 번이 될 수도 있다. (물론 아마도 국내 이용자들은 이정도일 수는 없을 것이다...) 

이렇게 많은 Client들의 service request는 어떻게 처리될까? 서비스를 요청받는 Server에 부하가 이루어지지 않을까?

 

이러한 서비스들을 원할하게 이루어질 수 있도록 하는 것이 미들웨어단이 맡은 역할이라고 나는 생각한다.

 

사업의 특성상... 몰려오는 Client를 어떻게 할 수는 없을 것이다.

우리는 너희가 없어도 돈을 충분히 버니까 오지마라!

이럴 수도 없다. 

장사가 망할 수도 있는데...

 

그렇다면 Server는 어떻게 하면 될까?

간단하게 생각하자.

클라이언트가 원하는 서비스를 가진 어플리케이션서버들을 더 많이 만들면 된다. 

서비스를 사용하는 클라이언트가 많아지면 많아질수록 그 서비스를 가지고 있는 더욱 더 많은 서버를 만들면 되는 것이다.

 

신세계백화점에 나이키매장이 하나였는데 나이키 매장을 10곳을 더 만든다면?

분명히 손님의 밀집도도 나뉘어져서 매장의 service도 원할하게 이루어질 것이다.

 

 

너무 많은 예를 들어서 헷갈릴 수도 있겠다.

---

 

이러한 문제점들을 솔루션으로 제시하는 미들웨어가 Tuxedo라고 할 수 있다.

 

고객이(client)이 원활한 지하철(middleware)을 이용하여 신세계백화점(server)에 가서 원하는 나이키신발(service)을 가지고 나올 수 있도록 도와주는 매개체인 것이다.

 

 

 

즉,

Client와 server 사이에 위치하는 놈이 tuxedo 라고 할 수 있다.

 

즉, Tuxedo는 OS 상에 올라가는 미들웨어이다.