몇몇 기술적 링크들.

composite message pattern강의
-정리하자면, DVM 분산 가상 머신,위에서 메세징 패스 및 처리를 어떻게 구현해야하는가에 대한 설명이다. 고려해야할 background지식을 생각해보면 왜 저러한 구조가 나올지 알수있다. 마지막 패킷문제는 아마 구현상 오버헤드를 어디에 두느냐에 대한 문제인듯.

Patterns for Successful Framework Development
(BOOK : Framework Design Guidelines)

-framework에서 고려해야할 tradeoff항목들
framework의 유무에 따른 tradeoff
1.프레임워크를 개발하는데 드는 비용은 일반 어플리케이션을 개발시보다 보통 3배 이상이 들어간다. 따라서 반드시 최소 3개 이상의 어플리케이션에서 이 프레임워크를 이용한다는 보장이 있을때에만 개발에 착수하라.

domain에 종속된 프레임워크의 tradeoff
2.세상의 모든 문제를 해결할 수 있는 프레임워크는 존재할 수 없다. 높은 추상화를 통해 제네릭한 알고리즘과 데이터 스트럭처를 제공하는 프레임워크는 그만큼 효율성의 손해를 가져온다. 따라서 적은 수의 핵심 기능에만 촛점을 맞추는 프레임워크를 설계하라.

기능과 obeject 의 크기에 따른 tradeoff
3.프레임워크의 전체 기능을 분할할 때는 강력하고 광범위한 기능을 가지는 적은 수의 큰 오브젝트로 나누는 것보다, 덜 강력하지만 유연한 많은 수의 작은 오브젝트로 나누어라. 이럴 경우 비록 오브젝트의 수는 많아지지만 개개의 오브젝트들을 이해하는 것이 쉬워진다. 또한, 작은 오브젝트들은 여러 상황에서 보다 다양한 방식으로 조합될 수 있다.

framework의 교육비용과 개선비용의 tradeoff
4.프레임워크를 쉽게 이용하도록 만들기 위해서는 사용자들에게 프레임워크의 실질적인 필요성을 각인시킬 필요가 있다. 이를 위해 사용자들을 지속적으로 참여시키는 방법이 필요하다. 이런 방법으로는 모두가 함께 참여하는 워크샵이 될 수도 있고, 프레임워크 사용을 돕는 툴을 제공하는 것도 생각할 수 있다. 하지만 이런 행위들이 비용과 시간을 상승시킨다는 점을 감안해서 적절히 조절할 필요가 있다.

p.s 이 글은 tradeoff의 관점(view)에서 쓴 글이다. 실제 글의 내용은 전혀 다른 방향임^^;

웹 기반 시스템 하에서의 성능이론 (제니퍼 소프트, 이원영님)
-웹 기반 시스템 하에서의 성능적 특성에 대한 수학적인 접근