Oracle Fusion 11g 미들웨어 : 계획대로 실행

이 게스트 포스트는 Tony Baer의 OnStrategies 블로그를 통해 제공됩니다. Tony는 Ovum의 선임 분석가입니다. 그의 프로필은 여기에있다. 당신은 여기에 도달 할 수 있습니다.

이번 주 Oracle의 Fusion Middleware 11g 롤아웃에 대한 발표는 정확히 1 년 전 나온 계획에 따라 세부 사항이 다소 까다로운 점입니다. Fusion 스택은 내부적으로 개발되고 획득 된 여러 부분으로 구성되어 있지만 BEA 인수의 성과를 나타내는 것이 하이라이트입니다. 오라클은 BEA를 인수하기 전에 Fusion 미들웨어를 보유하고 있었지만 BEA가 주요 사건이었습니다. WebLogic은 Fusion 스택의 중간에있는 도넛 구멍을 Oracle Containers for Java EE (OC4J)보다 훨씬 인기있는 서버로 채웠습니다. 혼자서 BEA는 Oracle Fusion을 미들웨어의 주요 업체로 만들었습니다.

오라클은 이전에 발표 된 BEA 제품 통합 로드맵에 크게 중점을 두었습니다. Oracle은 WebLogic을 전략적 Java 플랫폼으로, JDeveloper를 기본 개발 환경으로, B2B 프로세스를 모델링하는 경로를 마스터 데이터 관리, 데이터 통합 ​​및 신원 관리를 통해 BEA 컨텐트가 추가 된 Oracle 오퍼링을 중심으로 도입했습니다.

오라클 퓨전 제품 포트폴리오는 오라클이 분명히보다 적극적인 인수 업체 였기 때문에 BEA보다 훨씬 다양한 소스에서 나온 것이지만 BEA가 인수 한 모든 것보다 훨씬 통일적입니다. 오라클에 의해 삼켜지기 전에 BEA는 공통된 프레임 워크가없는 여러 포털, 개발 및 통합 기술을 보유하고있었습니다. 이와 비교하여 오라클은 조각을 함께 만드는 일반적인 프레임 워크를 강조했습니다.

이는 Oracle Forms 4GL 및 Oracle 데이터베이스 관리를위한 다양한 유틸리티로 거슬러 올라가는 네이티브 툴 및 유틸리티 개발을위한 오라클의 유산에 기인합니다

도구는 일반적으로 오라클 매장에만 국한되어 있기 때문에 충분히 원산지였습니다. 그러나 원시 툴링에 대한 이러한 접근 방식은 오라클 플랫폼에 최적화 된보다 폭 넓은 프레임 워크 개발과 함께 변천되었습니다. 오라클의 정신력은 자선이 최고의 적이며, 오라클이 구축하고있는 것은 개별 제품이 아닌 플랫폼이라는 점입니다.

오라클의 Fusion에 대한 표준화가 표준 기반으로 이루어 지도록하는 접근법이기도합니다. 예, 퓨전 제품은 다른 공급 업체 제품과 함께 작동하는 오라클의 “핫 플러 거블 (hot pluggable)”동급 최우수 전략을 지원하도록 설계되었지만 퓨전 환경을 설계 및 관리하기 위해 오라클은 원할 경우 기본 툴링으로 포용했습니다. 고객이 오라클 컨텐츠를 추가하도록 권장하기 위해 미묘한 시도라고 할 수 있습니다.

오라클은 6 ~ 7 년 전 JDeveloper Java 도구의 초기 버전에서 이전에 사용했던 Apache Struts 프레임 워크 대신 자체 모델 뷰 컨트롤러로 ADF (Application Development Framework)가 개발되기 시작했습니다. 이러한 접근 방식은 JDeveloper를 통해 오늘날까지 이어져 왔습니다. JDeveloper는 전통적인 Eclipse IDE와는 맞지 않는 개발에 대한 높은 수준의 선언적 접근 방식을 제공합니다. 또한 이러한 접근법은 애플리케이션 관리에서 반드시 BMC, CA, HP 또는 IBM Tivoli와 경쟁하지는 않지만 Oracle Fusion 플랫폼의 선언적 배포, 모니터링 및 성능 테스트 기능을 제공하는 Oracle Enterprise Manager (EM)에 적용됩니다 .

오라클과 BEA 기술을 결합하면 그 가치가 그 부분의 합보다 큰 시너지 효과가 발생했습니다. 좋은 예가 BA의 준 실시간 JRockit JVM과 Java 객체를위한 분산 캐싱 레이어 인 Oracle Coherence 데이터 그리드를 결합한 것입니다. 본질적으로 JRockit은 자주 사용되는 객체로 더 높은 성능이 필요할 때마다 사용되는 Coherence의 성능을 향상시킵니다. Coherence는 JRockit의 우수한 유스 케이스를 제공하는 하이 엔드 엔터프라이즈 클러스터 플랫폼을 제공합니다.

앞서 언급했듯이 Fusion 11g의 광범위한 개요는 거의 신비가 아니지만 그 과정에서 발생하는 흥미로운 출발이 있습니다. 오라클이 Oracle BPM Suite에 대한 런타임 전략에 또 다른 옵션을 추가 한 BPM에 주목할만한 제품이 있습니다.

원래 Oracle BPEL Process Manager는 런타임이었습니다. BPM 사용자는 프로세스 모델을 BPEL에 매핑해야했습니다. BPEL은 본질적으로 프로세스 의미론이없는 XML 기반 순차 프로그래밍 언어입니다. 1 년 후 OMG는 실행 모델에 대한 지원을 추가 한 프로세스 모델링 표기법 인 BPMN 2.0에 마무리 작업을 진행하고 있습니다. 또한 Oracle BPM Suite 사용자는 11g가 출시되어 프로세스가 트랜잭션 적으로 복잡하지 않은 한 BPEL을 우회 할 수있는 옵션을 얻게됩니다.

의심의 여지가 없습니다. Fusion 11g 마이그레이션은 거대한 리엔지니어링 프로젝트였으며 거의 ​​2000 개의 개발 프로젝트와 5000 가지 이상의 제품 개선이있었습니다. 따라서 오라클이 미들웨어 아키텍처를 마이크로 커널 아키텍처로 마이그레이션함으로써 미들웨어 스택을 다시 설계 할 기회를 갖지 않은 것은 오산이 가장 두드러진 사례입니다. Oracle WebLogic Server는 OSGi 기반이지만 BPM / SOA 스택은 그렇지 않습니다. 오라클은 나머지 Fusion 스택 전체에 마이크로 커널 아키텍처를 채택 할 것인지 여부에 관해 여전히 불만을 토로하고 있습니다.

혁신, M2M 시장이 브라질에서 회복, 협업, 오늘날의 디지털 작업장의 구성 원리는 무엇입니까, CXO, CIO는 누구에게 영향을 미칩니 까? CXO, 기술 집행 덱을 뒤섞는 ANZ 은행

그렇다면 우리는 왜이 모든 일에 열중하고 괴롭 힙니까? OSGi 또는 일반적으로 동적 인 모듈 식 마이크로 커널의 원리는 실행에 필요한 Java 모듈 만 포함하는 매우 컴팩트 한 서버의 배치를 통해 Java 발자국을 크게 줄일 수있는 잠재력을 제공합니다. 좋은 소식은 이것이 잠재적으로 경제적이고 에너지 효율적이며 공간 효율적인 친환경 전략이라는 것입니다. 나쁜 소식은 사용자가 선택적으로 동적으로 배포하는 방법을 배워야하기 때문에 공급 업체가 마이크로 커널을 채택하기에 충분하지 않다는 것입니다.

그러나 방금 언급했듯이, OSGi는 늦게 모멘텀을 잃은 것으로 보입니다. 우리가 지적했듯이 작년 Ovum 연구에서 IBM과 SpringSource가 스택을 완전히 마이그레이션하고 경쟁자가 최소한 암묵적 지원을 제공함에 따라 OSGi는 Java 플랫폼의 사실상 표준이 될 것이라고 믿었습니다. 1 년 후, 오라클의 침묵은 귀가 거린다.

지난 주에 오라클이 발표 한 바에 따르면 오라클이 썬의 인수를 계기로 썬은 오픈 소스 글래스 피시 (GlassFish) 자바 플랫폼을위한 OSGi 지원에 무게를 두면서 Java 모듈화를 JSR 294로 다시 정의하는 것을 목표로하는 Project Jigsaw. 불행히도 Fusion 11g 발표는 문제를 해결하지 못했습니다.

이 게스트 포스트는 Tony Baer의 OnStrategies 블로그를 통해 제공됩니다. Tony는 Ovum의 선임 분석가입니다. 그의 프로필은 여기에있다. 당신은 여기에 도달 할 수 있습니다.

? M2M 시장은 브라질에서 다시 반송

오늘날의 디지털 작업장의 조직 원리는 무엇입니까?

CIO는 누가 영향을 미칩니 까? 여기에 상위 20 개가 있습니다.

ANZ 은행, 기술 집행부 데크 섞기