EJB 구성 요소 와 재 활용 가능 한 모순

EJB 기술 은 다른 눈 부신 기술 처럼 한 고비 에 이 르 렀 다.2000 년 이전에 이 기술 은 전설 적 인 색채 로 가득 차 서 많은 기업 들 이 깊이 생각 하지 않 고 받 아 들 였 다.그러나 이상 은 이상 이다.몇 년 의 발전 을 거 쳐 오늘날 이 기술 은 의심 을 받 거나 적어도 기술자 들 을 망 설 이게 하고 있다.현실 적 으로 J2EE 의 상대 가 나 왔 고.NET 은 후발 적 인 기술 장점 을 가 진 것 같다.대부분의 논의 와 논쟁 은 이미 이 두 체계 구조의 대비 로 바 뀌 기 시작 했다.자바 진영 내부 에서 도 회의 적 인 목 소 리 를 냈 다.가장 직접적인 것 은 EJB 에 대한 공격 이다.사람들 은 원래 이 기술 이 한 약속 이 모두 반대 방향 으로 가 는 것 같다 는 것 을 알 게 되 었 기 때문이다.1.대량의 사례 는 이런 기술 을 사용 하여 오히려 시스템 개발 을 복잡 하 게 만 들 었 기 때문에 상상 하 는 간단 한 개발 주기 가 일상 이 되 었 다.수입 과 판매 예금 을 실현 하 는 것 은 많은 사람들 을 곤란 하 게 한다.2.EJB 는 비 싼 대명사 가 되 었 습 니 다.기대 하 는 원가 가 낮 아 지 는 것 이 아니 라 3.한참 동안 힘 을 쓰 지 않 고 메시지 전달 으로 시스템 상호작용 을 하 는 것 이 좋 습 니 다.4.플랫폼 에서 철저히 벗 어 나 는 것 은 불가능 하지만 자바 는 어쨌든 괜 찮 습 니 다.그래서 Spring 등 N 가지 시스템 이 생 겼 습 니 다.EJB 는 사람들 을 곤 혹 스 럽 게 하기 시작 했다.모든 기술 은 인생 과 마찬가지 로 곤 혹 스 러 운 시기 가 있 지만 EJB 가 사람들 에 게 주 는 곤 혹 스 러 움 은 특히 전형 적 이 고 의미 가 있다.J2EE 와 다른 시스템 의 대 비 는 이미 인터넷 에 범람 했 고 실제 응용 경험 도 곳곳에서 볼 수 있 기 때문에 여기 서 소개 할 필요 가 없다.그러나 EJB 는 현재 단독으로 중시 되 지 않 았 다.이것 은 J2EE 발전 사 와 배치 된다.이러한 사실 을 인정 해 야 한다.EJB 는 단독 적 으로 제기 되 고 정의 되 었 다.최초 로 완전히 단독 적 인 규범 이 었 다.이것 은 이른바 체계 구조 와 직접적인 관계 가 없 거나 EJB 의 의미 와 목 표 는 J2EE 에서 상업 논 리 를 포장 하 는 것 이 아니 라 구조 안에서 EJB 를 지나치게 토론 했다.혹은 J2EE 의 약점 이 EJB 에 반드시 퍼 져 야 한다 고 생각 하 는 것 이 적절 한 지 검토 할 필요 가 있다.EJB 가 탄생 한 초기 에 사람들의 흥분 관건 은 이런 모델 이 기 존의 구성 요소 기술 의 정 수 를 흡수 하고 큰 발전 을 하여 사람들 로 하여 금 튼튼한 상업 구성 요소 제조 원가 가 낮 아 지 는 기 대 를 보 게 하 는 것 이다.특히 플랫폼 의 조립 가능성 과 이식 성 을 뛰 어 넘 는 것 은 소프트웨어 공학 계 의 꿈 이다.기업 측 컴 퓨 팅 프로 그래 밍 산업화 와 세밀 한 분업 이 가능 하 다 는 뜻 이기 때문이다.이런 사상 은 현재 인터페이스 1 급 의 응용 에 도 영향 을 주 었 다.예 를 들 어 이른바 Portlet 기술,IBM 회사 의 WebSphere 플랫폼 의 기술 은 무 서운 것 이 아 닐 수도 있 지만 몇 십 명의 합작 파트너 가 사실상 비슷 한 합작 을 제공 했다.이것 이 야 말로 상대방 을 두려워 하 게 하 는 것 이다.따라서 우 리 는 EJB 에 대해 이야기 할 때 그의 가치 와 역할 에 대해 이야기 하고 그의 디자인 목표 에서 벗 어 나 면 더욱 큰 의 미 를 잃 게 된다.다음 과 같은 상업 환경 과 소프트웨어 기술 병목 은 다시 살 펴 봐 야 한다.1.소프트웨어 공학 은 재 활용 분야 에서 구성 요소 시 대 를 뛰 어 넘 었 거나 구성 요소 가 필요 하지 않 은 가?2.소프트웨어 의 재 활용 은 중복 조립 이 필요 하지 않 고 서로 다른 부위 에 조립 해 야 합 니까?3.상업 논 리 는 아직도 포장 을 하고 강건 한 특성 을 유지 하 며 끊임없이 서 비 스 를 해 야 합 니까?4.구성 요소 와 강건 함 과 가용성 은 서로 연 결 된 특수 성능 으로 대 체 됩 니까?5.EJB 를 뛰 어 넘 고 많은 지 지 를 받 는 더 저렴 한 구성 요소 가 있 습 니까?6..NET 의 구성 요소 표준 과 EJB 는 비교 가 가능 합 니까?아니면 어떤 구성 요소 형식 과 EJB 가 비교 가 가능 합 니까?냉정 하 게 생각 할 때 기술 이 스타 로 치 켜 세 워 져 서 는 안 된다 는 것 을 알 지만 쓰 러 지기 쉬 운 소프트웨어 기술 도 없다.EJB 는 성숙 하지 않 지만 쉽게 부정 당 할 수 있 는 것 은 아니다.EJB 로 인해 많은 일반 프로그래머 들 이 원래 귀족 같은 구성 요소 개발 에 개입 할 수 있 게 되 었 고 심지어 간단 한 Windows 에서 UNIX 의 구성 요 소 를 개발 할 수 있 게 되 었 다.EJB 의 역사 문 제 는 대부분 이런 기술 을 잘못 남용 하 는 것 이다.조회 수가 적은 불쌍 한 광고 조회 프로그램 도 구성 요 소 를 사용 해 야 한다.재 고 를 간단하게 계산 하고 싶 은 고객 에 게 N 년 후에 야 필요 한 확장 성 을 설계 했다.마찬가지 로 현실 에서 이 기술 이 잘 하 는 분야 에 서 는 적어도 아직 더 강 한 경쟁 자 를 찾 을 수 없다.기술 선택 은 응용 형 기술자 의 영원한 주제 로 유사 한 곤혹 이 끊임없이 나타 날 것 이다.가장 중요 한 것 은 그들의 이상 과 목 표를 인정 하고 객관 적 이 고 명확 한 인식 을 유지 하 는 것 이다.잘 하 는 분야 에 두 는 기술 이 가장 아름 다운 것 은 인생 이나 다름없다.