요즘 SOA라는걸 보고 있는데, 정말 SOA라는거 이것을 봐서는 뭐가 뭔지 감도 안잡히는거 같습니다 =_=

그래서 원천적으로 SOA를 하기전에 OOP의 단점이 무엇일지 생각해 보았습니다.
생각해보니 절차지향 언어로부터 이어져와서 OOP는 LANGUAGE라는 플랫폼에 강결합(tightly-coupled)
라는 생각이 들었습니다. 정확히는 컴파일러 라고 해야할까요?

예를들면 자바에서 OOP을 이용하여 코딩을 하다가 C++에서 만든 클래스를 패키지와 해서
가져다가 그냥 쓸수 있을까요?
같이 OOP 이지만, 자바와 C++은 서로 직접적으로는 호환이 안되겠지요. 서로 문법이 미묘하게 틀리니까요
물론 C#과 JAVA도 그럴거 같구요.

결론적으로 플랫폼에 종속적인것이 OOP의 단점인것 같습니다.

음 그래서, 이제는 언어라는 플랫폼에 약결합(loosely-coupled)으로 하여 언어에 구애받지 않고, 자바와
닷넷, C++ 이라는 언어로 만들어진 객체들을 넘어 컴포넌트들을 언어에 구애받지 않고, 쓸수 있을수는
없을까요?

음 그래서 생각해 보건데, XML을 이용하면 될거 같아요. 서로 컴포넌트들간에 정보 교환을 할때,
XML을 이용한 공통된 형식을 만들어서, 독립적으로 만들어진 컴포넌트들간에 통신을 할수 있을거예요
그럼 XML을 이용해서 주고받고 할수 있겠지요.

따라서 플랫폼이 다른 컴포넌트라도 재사용이 가능할거 같습니다.

음 하지만 여기에서 다시 떠오르는게 일반 어플리케이션에서는 저런것이 힘들거 같기도 하네요.
예를들어 C++에서 만든 .EXE 어플리케이션을 실행하는데 JAVA로 만든 컴포넌트를 활용하기 위해
JVM을 이용한 .CLASS를 동시에 실행하고, 이러면 정작 프로그램을 사용하는 입장에서는 무언가
이상해 지겠죠? 

음 하지만 웹에서는 그냥 수월하게 할수 있을거 같아요.
PHP와 JSP로 만든 컴포넌트들이 존재할때, 각각 서버를 한대씩 만들어놓고 사용자가 하나의
처리를 요청하면 각자의 PHP와 JSP와의 메세지 교환을 통하여 처리후에 그걸 사용자에게
VIEW로 그냥 보여주기만 하면 되지 않을까요.

음 따라서, 이런 Object Oriented라는 관점의 중요성이 점차 줄어들고 서비스중심, 관점중심의 프로그램인
SOA, AOP라는게 나오지 않았나 생각이 되네요.

정말 초짜가 말하는거라, 틀린거나 조언해주실거 있으시는 분이 있으시면 괜찮을것 같습니다.
정말 어려워요 ㅠㅠ 정말 소프트웨어 공학이 어려워요 ㅠㅠ