Search Results for 'EJB 3.0'

2 POSTS

  1. 2006.11.03 SDO vs EJB 3.0
  2. 2006.09.07 EJB 링크관리

SDO vs EJB 3.0

Posted 2006. 11. 3. 22:34
앞으로 SDO가 많이 쓰일듯 하다. 이유는 아래와 같다.
아래글 참고 ^^

바로 이전 프로젝트에서 FireStorm SDO를 사용해봤다. 아직까지는 익숙치 않은 개념이지만 조금씩 몸에 체감되어 감을 느낀다.

최근 "서비스는 무엇이며 컴포넌트와의 관계는 무얼까" " 라는 대주제 때문에 머리가 아프다.

많은 사람들이 SOA에  많은 의구심을 가진다. SOA라는 아키텍처는 가트너 그룹이 10년쯔음 말한 개념들이다. 많은 의심속에 나는 의심을 많이 하지 않기로 했다.
달에 로켓을 쏘아 올리기전 많은 사람들이 로켓의 모양을 상상하고 그 모양이 달로 가는 진짜 로켓의 모양이 된것 처럼 SOA도 점처 구체성을 가지지 않을까 하는게 내 생각이다.

SDO versus EJB 3.0
The purpose and objectives of the SDO 2.0 and EJB 3.0 (sometimes referred to as Java Persistence API - JPA) specifications are so different that it is possible to say that they are complementary rather than competing.

SDO is a very ambitious attempt to provide a single, highly flexible API for all types of data in Service Oriented Architectures. EJB 3.0 is aimed making EJB more simple, with the new data persistence support based on Object Relational Mapping (ORM), with strong contributions from the Hibernate and Oracle ORM tool developers.

Language Support
-EJB 3.0 is Java-only
-The SDO API is published in both Java and C++, but also possible to implement in other programming languages (there's a PHP implementation). SDO defines a set of SDO data types to ensure portability between different data source types and for compatibility between languages. To date, SDO implementations exist for Java, C++, and PHP. EJB 3.0 is Java only does not address multi-language data compatibility.

Data Types and Formats
-EJB 3.0 data persistence is aimed at relational data held in databases
-SDO is for any type of data, with relational data only one example. When developers learn the SDO API, they can access any type of data supported by the SDO implementation they are using. As well as providing a standardized API for accessing data across multiple data sources, SDO also provides a common API for accessing metadata about the data source. While the SDO data access API provides DataGraph and DataObject interfaces for accessing and updating data, the SDO metadata API provides Type and Property interfaces.

EJB 3.0 is Based on ORM, Whereas SDO is Focused on Data
-EJB 3.0 is strongly based on ORM technology, which is designed for persisting data in an Java objects to a relational database (known as the 'logic first' approach) or mapping between the Java objects and an existing relational database (known as the spaghetti junction approach).
-SDO takes a 'data first' approach, where it is assumed that the database will be optimized (and normalized) and may last longer than the actual business application. Assuming that the database is the focus point for the data, FireStorm/SDO reverse engineers the database schema to produce the persistence code.

SDO is for Service-Oriented Architectures
-EJB 3.0 is for traditional stand-alone (monolithic) Java applications, typically with client-server architecture
-SDO supports the concept of disconnected programming model, making it ideal for service-oriented architectures. The disconnected DataGraph means that databases are not locked because data is modified offline.

SCA and J2EE Specifications
-EJB 3.0 is part of JEE (the rebranded J2EE), which has been the dominant application development platform for the past several years
-The latest version of the SDO specification was released in conjunction with the Service Component Architecture (SCA) specification. SCA enables peer-to-peer interactions between services in a distributed SOA architecture. SCA is the industry response to Microsoft's Indigo/WCF strategy and is probably the most important development in SOA/Web Services in the past couple of years.

Tightly versus Loosely Coupled
-EJB 3.0 is embedded and tightly coupled within an application
-SDO implementations can be designed for a lightweight and distributed architecture. The SDO specification enables both a static (or strongly typed) programming model and a dynamic (or loosely typed) programming model.

With such different objectives and characteristics, it's not possible to say if EJB 3.0 or SDO are 'better' data persistence specifications. However, that does make it possible to produce some broad guidelines:

If you are developing a traditional (non SOA) application and only have relational data and are only developing in Java, then EJB 3.0 is a good choice.

If you are developing using a SOA, if you need to access multiple types of data, then SDO is a good choice.

PJ Murray
CodeFutures Software

링크

EJB 링크관리

Posted 2006. 9. 7. 18:11

퍼시스턴스와 분리해서 관리 할것

http://www.dev2dev.co.kr/pub/a/2006/03/ejb-3.jsp

EJB 3.0 소개