구글 번역을 기본으로, 의역을 아주 많이 섞었습니다.
In the Java community there's been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of "Inversion of Control". In this article I dig into how this pattern works, under the more specific name of "Dependency Injection", and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use.
자바 커뮤니티에서는 다른 프로젝트 사이의 컴포넌트를 응집력 있는 앱으로 조합해주는 경량 컨테이너 붐이 일고 있습니다. 이런 컨테이너의 근간은 객체를 엮는 방법에 대한 패턴과, 흔히 ‘제어 역전’이라고 부르는 개념입니다. 이 글에서는 ‘의존성 주입’이라는 조금 더 구체적인 이름 아래, 이 패턴이 어떻게 동작하는지 자세히 살펴보고, 대안인 ‘Service Locator’과 비교합니다. 이 두 개의 대안 중 어떤 것을 선택하느냐는 객체 구성과 사용을 분리한다는 원칙에 비하면 덜 중요합니다.
One of the entertaining things about the enterprise Java world is the huge amount of activity in building alternatives to the mainstream J2EE technologies, much of it happening in open source. A lot of this is a reaction to the heavyweight complexity in the mainstream J2EE world, but much of it is also exploring alternatives and coming up with creative ideas. A common issue to deal with is how to wire together different elements: how do you fit together this web controller architecture with that database interface backing when they were built by different teams with little knowledge of each other. A number of frameworks have taken a stab at this problem, and several are branching out to provide a general capability to assemble components from different layers. These are often referred to as lightweight containers, examples include PicoContainer, and Spring.
엔터프라이즈 자바 세계에 대한 재미있는 점 중 하나는 주류 J2EE 기술에 대한 대안을 구축하기 위해서 아주 많은 일을 하고 있다는 것입니다. 대부분은 오픈소스로부터 발생합니다. 이 중 많은 부분은 주류 J2EE 세계의 엄청난 복잡성에 대한 반응이지만, 또 대부분은 새로운 대안을 모색하고 창의적인 아이디어를 내놓는 것이라고 할 수 있습니다. 이 때 가장 일반적인 문제는 서로 다른 요소를 연결하는 방법입니다. (서로를 잘 모르는)다른 팀에서 구축한 웹 컨트롤러를 데이터베이스 인터페이스에 어떻게 연결해야 할까요? 많은 프레임워크가 이 문제를 해결했으며, 다른 계층의 구성 요소를 조합하는 기능을 제공하기 위해 노력중입니다. 이를 흔히 경량 컨테이너라고 부르는데, PicoContainer 및 Spring이 그 예입니다.
Underlying these containers are a number of interesting design principles, things that go beyond both these specific containers and indeed the Java platform. Here I want to start exploring some of these principles. The examples I use are in Java, but like most of my writing the principles are equally applicable to other OO environments, particularly .NET.
이런 컨테이너의 근간에는 특정 컨테이너와 (자바 플랫폼을 뛰어넘는)여러 가지 흥미로운 설계 원칙이 있습니다. 여기에서 이 원칙들 중 일부를 살펴보고자 합니다. 여기서 사용하는 예제는 자바로 되어 있지만 대부분의 문서와 마찬가지로 다른 OO 환경, 특히 .NET에도 동일하게 적용할 수 있습니다.
The topic of wiring elements together drags me almost immediately into the knotty terminology problems that surround the terms service and component. You find long and contradictory articles on the definition of these things with ease. For my purposes here are my current uses of these overloaded terms.
‘요소 엮기’라는 주제는 ‘서비스’와 ‘컴포넌트’라는 복잡한 용어 문제와 아주 밀접합니다. 어쩌면 이 용어의 정에 대해 길지만 모순적인 글들을 쉽게 찾을 수 있을지도 모르겠습니다. 여기서는 제 기준의 용어 정의를 사용하려고 합니다.
I use component to mean a glob of software that's intended to be used, without change, by an application that is out of the control of the writers of the component. By 'without change' I mean that the using application doesn't change the source code of the components, although they may alter the component's behavior by extending it in ways allowed by the component writers.
저는 ‘컴포넌트’라는 용어를 ‘변경 없이 사용하기 위한 소프트웨어 덩어리’라는 의미로 씁니다. ‘변경 없이’라는 말은 컴포넌트 작성자가 허용하는 방식으로 확장해 동작을 변경할 수는 있지만, 컴포넌트의 소스코드를 변경하지는 않는다는 의미입니다.
A service is similar to a component in that it's used by foreign applications. The main difference is that I expect a component to be used locally (think jar file, assembly, dll, or a source import). A service will be used remotely through some remote interface, either synchronous or asynchronous (eg web service, messaging system, RPC, or socket.)
‘서비스’도 외부에서 사용한다는 측면에서 컴포넌트와 유사합니다. 컴포넌트와의 중요한 차이점은, 컴포넌트는 로컬 안에서 사용한다는 점입니다(jar 파일, 어셈블리, dll, 소스코드 import를 생각해 보세요). 서비스는 동기/비동기의 원격 언터페이스(웹 서비스, 메세징 시스템, RPC, 소켓)를 통해 사용합니다.