요즈음 나는 ....

Posted 2007. 5. 4. 20:02
1. 몸이 더 안좋아짐. 오늘은 회사를 쉬었음. 토비형을 보고 싶기도 했지만 도무지 보기가 힘든 상황
2. 최근엔 SOA의 SCA대해서 좀더 깊이 연구 하였음.
3. 스프링의 IoC에 대한 좀더 깊은 생각
4. 스프링의 컨트롤러에 대한 여러가지 생각을 하게 됨. - 내부 구조를 뜯다가 서블릿의 그 ( ? ) 구조가 생각나기도 했음. 그러나 스프링은 여전히 국내에서는 무력한 상태임. 참고로 스프링의 컨트롤러는 Servlet Controller는 아님.
5. 아침 스터디중 - TDD에 대한 또 다른 생각중
6. SQL Map - Abator 괘얀음. 그러나 유동성 없음. 조금 하다 보니 DAO를 생성해주는데 "SPRING" 으로 바꾸자 Spring의 JDBC Template를 이용해서 코딩이 Gen 되어 나옴 그런데 코드를 보고 약간 실망...T.T 자동 Gen의 한계가 아닐까라는 생각이 듬.
7. 제품에 대한 의존도및 이것들에 대한 유지보수에 대한 생각중 - 제품자체의 건강함을 위해서 코드는 간결하고 철학을 가져야 함. 내부적인 품질이 지켜지지 않은 모 회사의 제품은 철학도 없고... 사람힘들게 만드는 쓰레기 코드임이 틀림 없음. 이상...


걍 생각없이 읽어볼만한 pdf 임

잠이 안온다.

Posted 2007. 1. 17. 01:48
오늘 빡센 하루 보내고 내일은 일어날 수 있을지 모르겠다. 지금 집에와서 컴터 앞에 앉은지..5시간째....막 가트너와 포레스트리서치의 자료를 뒤지고... 자려고 하는데
도통 잠이 안온다. 두 회사의 리서치 자료중 그래도 맘에 드는건 가트너...
공통점은 둘다 최근들어 ESB관련 자료를 토해낸다..... 토해낸다는 의미는....^^;;;;

최근에 본 자료의 양은 태어나서 가장 많이 본듯.... 정말 끔찍하게 많은 양이다. 머리속에서 자료들이 둥둥 떠다니는듯.... 이 많은 양의 자료를 함축하고 추상화 하느냐가 지금은 중요하다....

포레스트리서치의 자료는 CIO나 혹은 CEO전용인듯...그래서 몇번 좌절.... 그러나 나에게는 너무나 좋은 자료들....그들의 레벨에서 많은것을 생각해야하니...
다행히 엔지니어링 자료는 여기저기 뒤지면 많이 있어 다행...

얼마전 쓴 블로그에서 마이크로커널이 왜 훌륭하다고 하는지... 아는 사람은 알겠지만
JBoss의 마이크로 커널이야 말로...SOA의 실체라는 생각이 들어서 이다.
너에게만 TRUE SOA라는 말을 내가 붙여준다. ^^

그거와 관계없이...여기저기 레포트를 뒤지다 레드헷의 이야기를 보게 된다.
오라클이 탐냈던 JBoss결국은...레드헷이...가졌다.
결국 레드헷은 SOA플레폼을 원했던 것이다.

엄청난 자료속에 내가 필요한 것은 별로 없던데...한숨이 핑핑 나온다.
내일은 또 무슨 일이 있을랑가.... 토요일만 기다려진다.

이번주에 알아야 했던 사실은 이전에 알았던 그 무엇보다 광범위 했다.
특히 기업이 오픈소스를 도입할때 얼마나 신중하여야 하는지...
또 경영자, 그 중간, 개발자들간의 갭등에 대해서 다시 생각해보는 좋은 시간이 되었다.
다시 한번 부끄러워지는 하루였다. 그래서 더 힘이 빠졌나....
아래 그림은 오늘을 생각하며 넣은 뽀나스 T.T


사용자 삽입 이미지























사용자 삽입 이미지





JBI VS SCA

Posted 2006. 11. 22. 17:51

http://www.chwlund.com/?p=60

After the release of the Service Component Architecture (SCA) specification last month there have been a lot of discussion related to how SCA relates to Java Business Integration (JBI) (JSR-208). I will try to clear thinks up, all in all (if you dont have time to read more): SCA is a specification to make developers make services (in a SOA) in a standard, consistent and technology-independent way and JBI is a specification that defines how integration products should look like and how vendors could actually choose to design an integration product or component (standardization between integration technology vendors)

I have written about Java Business Integration in another post. Read this to learn more about JBI. To sum it up, JBI is all about the standardization of integration products (mainly ESBs). JBI specifies an architecture and an API that should be used when developing integration products. So, in our everyday consultant lifes, we do not have to care so much about this standard, but I think its a really important standard for the integration market, because it opens up integration solutions and makes it possible for different vendors to collaborate. I have written a lot more about this in my older post.

SCA, on the other hand, will maybe influence our everyday life much more than JBI. SCA is a specification that defines how we as developers should write services in a service -oriented architecture. Its like a general WSDL, but also much more. It defines how a service should be described and how it relates to other services. In this way we can define services independent of the technology used to implement it.
A white paper from IBM shows a specific example of how SCA will change how we develop services:

A EJB represents a reservation service for a airline-company and the service is loaded by the application like this:

// Get the initial context as shown in a previous example
...
// Look up the home interface using the JNDI name
try {
java.lang.Object ejbHome =
initialContext.lookup(
"java:comp/env/com/ejb/CarReservation");
carHome =
(CarReservationHome)javax.rmi.PortableRemoteObject.narrow(
(org.omg.CORBA.Object) ejbHome, CarReservationHome.class);
}

catch (NamingException e) { // Error getting the home interface
...

This is fine if you only use EJBs and your future services only will be EJBs. But what if you have to implement the reservation service using a different kind of java component or even another technology platform (like .Net). Then its better to refer to your services in a more neutral and transparent way, like this:

ModuleContext moduleContext=CurrentModuleContext.getContext();
AirReservation airReservation= (AirReservation)moduleContext.locateService(“AirReservation?);
airReservation.bookFlight(flight);

Dave Schaffer says this about the relation between JBI and SCA:

One of the beauty of SCA is that it is focusing only on things that a SOA developer sees and touches. SCA does not care about how the runtime that is going to execute a SCA module is architected.

SCA defines services and a way to create them, but it does not say anything about how the runtime enviroments should be like. A SCA service could be executed by an integration product like an ESB. And this ESB could be designed according to JBI. So, summed up, there may not be any relation between SCA and JBI, but they are two very important standard that may function complementary in a service-oriented architecture and you may end up running your SCA services in a JBI-compatible integraton suite. Please correct me if I am wrong, because I havent got a deep understanding of SCA yet…

Links:
Dave Schaffer: SCA, JBI and more..
The serverside: Discussion
Servicemix.org: How does ServiceMix compare to Tuscany or SCA

Entry Filed under: Uncategorized

Comparing SCA, Java EE and JBI

Posted 2006. 11. 22. 17:44

https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2824

Blogs

Jean-Jacques Dubray

Comparing SCA, Java EE and JBI
Jean-Jacques Dubray SAP Employee
Business Card
Company: SAP Labs, LLC
Posted on Dec. 12, 2005 02:25 PM in
Java Programming, SAP NetWeaver Platform, Technologies

Java EE is one of the most successful application model and rightfully so. It greatly simplifies the development of stand alone, scalable, available, secure and transacted web applications. Everything in its application model is designed to process an arbitrary number of simultaneous requests and create a response synchronously as fast as possible. JSPs/Servlets, Session beans, Entity beans (as an in memory data cache), the security model, the transaction model, ... are all assisting the developer in creating these responses, in the richest and fastest possible way.

In fact, JEE has been so successful it has imposed itself as the main and preferred way of accessing back-end data, not just as a way to write new and cool stand alone web applications. Back-end integration is not easy, technologies are varied and often rustic to say the least, and most back-end systems were not designed  with the requirements of web applications in mind. There are three approaches to develop back-end integration solutions: invocation, mediation and activation.

image

Invocation has been the most commonly used approach used to date through technologies such as JCA, JAX-WS or WS-IF which are well aligned to support the request/response model but fail to support complex long running integration scenarios associated to particular application states. This is precisely one of the problems in JEE today because back-end integration does not always fit well the synchronous request/response model.

Mediation, is not new, and has been applied through proprietary products and frameworks for a decade. Last summer the JCP published an API to build standardized mediation infrastructure: the JBI specification. JBI is based on the "mediated message exchange" pattern: when a component sends a message to another component, this interchange is mediated by the JBI infrastructure, namely the NMR or Normalized Message Router. The NMR functionality can be augmented by Service Engines (such as transformation or orchestration engines) to facilitate the mediation with back-end systems. However, centrally coordinated architectures, such as JBI, have historically always struggled with the problem of "who manages the central infrastructure". The problem is most acute in B2B scenarios where most companies don't want to incur the cost of "mediating" message interchanges unless there is some value add. Actually, the JBI specification explicitly excludes from its scope the normalization of the interactions between two JBI instances. These type of interactions happen behind binding components in a completely proprietary way. This restriction greatly compromises the composition capabilities of JBI instances. Hence, JBI is well suited to solve small and local integration problems.

Activation is a relatively new approach to the problem. It consists of producing components which can be accessed via different middleware, synchronously or asynchronously. Activation maximizes the autonomy of the components themselves and their ability to be composed with other components. In particular, this means that the business logic implemented by a component cannot depend or rely on any specific middleware facilities. This is the component model proposed by SCA. In SCA, activation applies either at the component level or at the module level. A module is an assembly of components running in the same process. 

SCA enables arbitrary topologies of systems, supporting synchronous and asynchronous, client/server, peer-to-peer, long running or short lived interactions. SCA does not make any assumption about company boundaries and enables exposing a system as a component participating in another system, each of which having different managing authorities, i.e. company boundaries may be defined or shifted arbitrarily across an SCA system. SCA is well suited to solve any integration problem in particular the most complex ones, including the ones solved by mediation and invocation infrastructures. In many ways, SCA can be viewed as a decentralized mediation infrastructure where mediation happens either at the provider or the consumer side, without necessarily involving an intermediary.

To further understand the differences between the 3 approaches, let's look at how a "connected system" is assembled, i.e. how the wiring is defined and enacted in each approach. In an invocation based infrastructure, the wiring is usually defined via a "connection string containing the end point reference and some credential. In a mediation based infrastructure, the connected system is defined via a configuration file that contains the specification of a particular assembly of components, routing rules, ... This specification is consumed by the JBI infrastructure (NMR, Binding Components and Service Components). However each binding component retains its own proprietary mechanism to specify wiring to the service provider or consumer behind the binding component. In SCA, there is no central coordinator and an assembly of components is deployed to each component type, which activate components (instances of component types) for each unit of work being performed.

I do not want to end this note just by saying that SCA offers a new integration model because, SCA is also and above all a new application model, i.e a new way to build applications as an assembly of autonomous software agents, exposing service interfaces. SCA is innovative because it offers a unified application and integration model.

We can expect that Java EE and SCA will coexist offering a complementary application model while JBI will be used in traditional Enterprise Application Integration scenario. 

Jean-Jacques Dubray is a Standards Architect at SAP Labs, Palo Alto.


둘이 공존하는 방법을 잘 설명해 뒀다. 두개의 스팩....

많은 사람들이 궁금해 한다.
이전부터 무엇이 다를까 하고 ....

EAI는 Hub/Spoke 패턴이고 ESB는 말그대로 BUS패턴이라고 생각을 하고 있다.
그런데 이렇게 혼란 스러운 이유는 많은 벤더들이 자신들의 입장에서 제품을 만들기에
이런 이야기까지 나온다.
BPM 을 근간으로 하는 SOA, EAI를 근간으로 하는 SOA등등...
실제 그들의 아키텍처를 보더라고 제품을 부각하기 위해 많은 노력을 하는 것이 보인다.

아래에 좋은 참고가 될만한 자료를 올림 ^^

PS : EAI, ESB, BPM 모두 자신이 하는 일이 다르며
간단하게 내 생각을 말하자면 휴먼 프로세스는 BPM이...IT프로세스는 ESB가...
EAI는 기간계시스템의 연동정도로 생각하고 정의 하고 싶다.
EAI는 인프라에 바탕을 두고..ESB는 서비스의 조합및 서비스 컨트롤등을 근간으로 하며
BPM은 인간의 프로세스를 제어하기.....
결국 IT는 또다시 경영으로 넘어가는 구나...

참고자료 :




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

링크

http://incubator.apache.org/tuscany/

오랫동안 지켜보았다.
그리고 할말도 많다.
아파치 투스카니... SDO땜에 얼마나 힘들었나... 결국 OpenAdapter를 쓰려고 노력하게 되었다.

SCA... 이번엔 정말 잘해보고 잡다. 어찌나 표준도 없고 답답한지...

DAS SDO .... 애타게 찾던.... ㅋㅋㅋ 아키텍처야 SDO나온지는 좀 되는데...
앞으로 Sun과 IBM BEA의 SOA 전략이 상당히 궁금하다.
JBI와 함께 동반할까...아니면 서로 또다른 표준을 만들면서 나아갈까...
매우 궁금하면서 재미있다.
IBM은 이미 Eclipse등의 플레폼을 만들면서 여러가지 데이타 교환구조를 이미 Eclipse에 옮기고 있다. 실제 EMF패키지를 뜯어보면 이미 쓰이고 있었다.



BEA 에 나온 SCA글
http://dev2dev.bea.com/pub/a/2005/11/sca.html
http://www.dev2dev.co.kr/pub/a/2005/11/sca.jsp