어쨌건간에 흘러가는 者

컴포넌트(component)
- COM이나 Java Beans같은 특정 명세(specification)에 따라 구현된 개체(object). component의 명세는 보통 다음과 같은 사항을 정의한다(defined by Clements Szyperski, David Messerschmitt).

1. 재사용이 가능(Multiple-use)해야 한다.
2. 컨텍스트(문맥)에 특화되지 않아야 한다(Non-context-specific)
3. 타 컴포넌트와 함께 운용될 수 있으며 타 컴포넌트로 교체가 가능해야 한다(Composable with other components)
4. 캡슐화되어 있어야 한다(encapsulated : 예를 들어 인터페이스를 통해 내부를 바라볼 수 없도록)
5. 독립적인 배포 및 버전 관리의 단위가 되어야 한다.

또한, 다음과 같이 정의하기도 한다(by Carlos E. Perez).
1. 동적 확장(dynamic extension)이 가능한 메커니즘이어야 한다. 동적 확장에는 위임(delegation), 이벤트 핸들러(event handler)뿐 아니라 상속 역시 포함된다.
2. 인트로스펙션이 가능한 캡슐화 메커니즘을 지원해야 한다. 자신의 실제 인터페이스가 어떠한 모습인지를 외부로 표현하여야.
3. (컴포넌트를 사용하는) 컨테이너의 요구에 따르는 정의된 라이프사이클을 따를 수 있어야 한다.
4. 컨테이너와의 상호작용을 위한 프로토콜이 마련되어야 한다. 여기에는 다른 컴포넌트나 다른 컴포넌트의 팩토리를 찾는 방법, 다른 컴포넌트를 참조하고 호출(invoke)하는 방법 등이 포함된다.

* introspection, type introspection : 동적 개체 타입 결정
* component의 상속은 .NET이나 SOM(System Object Model: IBM의 object oriented shared library)에서 지원.


서비스(service) : SOA, EA, ESB 등의 문맥 내에서 정의
- 하나 또는 그 이상의 가능성(capability)에 대해, 미리 정의된 인터페이스를 통하여 서비스 기술(description)에 의해 명세된 제약(constraint)와 정책에 따라 액세스 가능한 메커니즘(defined by OASIS: Organization for the Advancement of Structured Information Standards)

- 다음와 같은 특징을 갖는 소프트웨어 메커니즘(by Carlos E. Perez) :기본적으로 느슨한 결합(loosely coupled) 원칙에 따르고 있음.
1. 분산 환경하에서 실행(invocation)이 가능한 메커니즘.
2. 인터페이스 인트로스펙션이 가능해야 한다: 클라이언트는 해당 서비스가 노출하는 설명(description)을 통해 제공되는 기능이 무엇인지를 알 수 있어야 한다. 이는 컴포넌트의 특징과 중복되지만 QoS 보장이라던가 상호운용성 정보를 포함한다는 점에서 다르다.
3. 서비스 간에는 암시적인 상태 공유가 없어야 한다. 이는 메시지 전달(message passing)과 같이 좀더 정제된 호출(granular invocation)이 필요하다는 것을 내포한다.
4. 비동기적 호출(asyncronous invocation). RPC에서와 같은 동기적 호출은 유비쿼터스 환경에서는 알맞지 않다.
5. 표준화된 프로토콜 인벨롭(편지 봉투: envolope): 메세지 페이로드에 대한 메타 정보를 제공해야 한다.