LovelyStory.com

J2EE code to lookup UserTransaction in client side for each app. server.

[Weblogic 8.1 & 9.0]
UserTransaction ut = ut = (javax.transaction.UserTransaction)ic.lookup("javax.transaction.UserTransaction");

[Websphere 6.0] : Requires two step lookup
Context comp = (Context)ic.lookup("jta");
UserTransaction ut = (UserTransaction)comp.lookup("usertransaction");

[JBoss]
UserTransaction ut = (UserTransaction)ic.lookup("UserTransaction");

한 시스템이 안전하다고 말하기위해서 충족되어야 할, 트랜잭션의 4가지 요구사항이
ACID, Atomic, Consistent, Isolated, Durable 이다.

Atomic
트랜잭션이 완전히 실행되거나 아니면 하나도 실행되지 않거나다. 예를 들어, 하나의 트랜잭션에서 1,2,3,4의 네개의 task를 실행해야 한다면,
1. 1,2,3,4가 모두 실행되거나
2. 중간에 실패하면 1,2,3,4 중의 어느 것하나도 실행되면 안된다는 것이다.

Consistent
비지니스 시스템이 트랜잭션이 끝난후의 상태와 이치가 맞아야 한다는 것으로, 다시 말해서 비지니스 시스템의 상태가 진짜 비지니스 상황과 같아야 한다는 말이다.
예를 들어, 비행기표를 예약하는 시스템에서 고객한테 티켓을 발급하면서 돈을 지불하는 과정을 빠트린다면, 실제의 비지니스 상황과 트랜잭션 시스템이 일치하지 않는 것이다.
또 데이터베이스에서도 비지니스와 일치하는 constraint을 가져야 하는데, 예를 들어, 고객이 좌석을 예약할때, 비행기, 좌석, 고객정보가 모두 constraint을 가져야지 안그러면 좌석만 배정받고 실제 타야하는 비행기는 모르는 경우가 생길 수도 있다.
Consistent는 atomic, isolated, durable이 모두 만족되야 만족될 수 있는 사항이다.

Isolated
트랜잭션이 실행되는 중간에 방해를 받지 말아야한다는 것으로, 트랜잭션이 액세스하고 있는 데이터가 중간에 다른 프로세스나 다른 트랜잭션으로 인해 변하는 걸 방지하기 위해 필요한 성질이다.

Durable
트랜잭션이 성공하면 트랙잭션으로 인해 생긴 데이터를 물리적인 저장장소에 기록해야 한다는 것으로, 시스템이 크래쉬되더라도 데이터를 잃지 않도록 하기 위한 것이다.

Service Locator 패턴은 클라이언트가 엔터프라이즈 비지니스 서비스를 액세스하는 과정을 간단하게 만들어준다. (Simplify client access to enterprise business services.)
(이구...가끔은 그냥 영어를 갖다부치는 게 훨씬 명료하고 짧다는 생각이 든다. 아마도 나의 번역실력이 부족한 탓이겠지만...ㅜㅜ)

내식대로 설명해보자면,,,
EJB API를 이용하기 위해서는 먼저 클라이언트 사이드에서 JNDI로 Lookup을 해서 EJB Home Interface를 얻어야 한다. 그런데 이 lookup 과정을 필요할때마다 클라이언트 프로그램에 하드코드하는 건 코드를 유지보수하기 힘들게 한다, 더구나 불필요한 JNDI initial context를 생성하고 lookup을 하는건 성능을 떨어트리게도 된다. 그래서,,,,Service Locator 패턴을 이용하자는 건데!

이 Service Locator는 JNDI 이름을 받아서 그 이름에 맞는 서버사이드 컴포넌트를 찾아서, 그 레퍼런스를 건네준다. 이건 EJB를 찾을때뿐만이 아니라 JDBC같은 다른 리소스를 찾는데도 유용하다.

다음 다이어그램은 선의 Java Pet Project을 Service Locator에 응용한 것이다.


1. AdminReqestBD라는 클라이언트가 Service Locator한테 OPCAdminFacade 빈을 찾아달라고 요청하면,
2. Service Locator는 캐쉬된 OPCAdminFacade home interface나 혹은 IntitalContext를 이용해서 OPCAdminFacade home interface를 클라이언트에 리턴하고,
3. AdminReqeustBD 클라이언트는 OPCAdminFacade을 이용한다.

Service Locator 패턴은 Business Delegate 패턴과 같이 혼합해서 사용되는데,
(예제의 AdminRequestBD가 Business Delegate임)
Business Delegate는 다음 편에...

좀더 자세한 설명이나 소스코드가 필요하면 밑의 출처를 참고하도록.

참고: http://java.sun.com/blueprints/patterns/ServiceLocator.html

Overview
도서관에서 책을 찾을 때,, 그냥 책장으로 가서 책장들 쭉 살피면서 책을 찾는다는 건,,,
다리도 아플뿐 더러 시간도 많이 걸린다.
그럴때.....도서관 입구에 있는 카드 카탈로그를 살펴보면,
책 이름과 그 책이 있는 곳의 위치가 담겨있어서,
별로 시간낭비하지 않고 바로 그곳에가서 책을 찾아보면 된다.
요즘은 이 정보가 컴터에 담겨 있어서 컴터로 검색 후에 찾아보면 되구..

암튼...이렇게 책과 그 위치를 매핑해놓는 것처럼,
이름과 object를 매핑해주는 자바기술을
JNDI (Java Naming and Directory Interface)라고 한다.

Other Naming Services

Name과 Object을 연결(binding)해주는 다른 naming service들에는 다음과 같은 것들이 있다.

COS (Common Object Service) Naming : CORBA를 위한 서비스
DNS (Domain Name System) : 인터넷 Name service like www.lovelystory.com
LDAP (Lightweight Directory Access Protocol) : 가벼운 버전의 DAP
NIS (Network Information System) and NIS+ : Sun이 개발한 네트웍 네이밍 서비스

위의 시스템들의 공통점은 name과 object를 바인딩한다는 거고,
틀린 점은 naming convention이 각각 다른다는 거다.

예를 들어 DNS의 www.lovelystory.com은 com이란 최상위 도메인이 있고, 그밑에 lovelystory 도메인이 있고, www라는 machine이 있다는 의미이다.

LDAP의 경우 콤마로 각각의 컴포넌트가 나눠지고 이름/값 형태의 쌍으로 구성되어 있다. 예를 들어 "cn=Todd Sundsted, o=ComFrame, cs=US"라면 US라는 국가에 ComFrame이라는 조직이 있고, 개인의 이름은 Todd Sundsted라는 의미이다.

그래서...JNDI naming은?

JNDI는 구현(Implementation)이 아니라 인터페이스(Interface)다.
따라서 원래 존재하는 서비스를 액세스할 수 있어야 하고, 그 시스템이 어떻게 작동하는지 알아야 JNDI를 적용할 수 있다. 이건,,,단점이라고 볼 수 있는데....이게 다시 장점이 되는데,,,
무슨 말이냐면, 이미 존재하는 어떤 Naming service에도 JNDI를 융합(integration)할 수 있다는 거지.

What about Context and InitialContext?

Context interface는 JNDI에서 중심역할을 하는데, naming service랑 연결된 바인딩을 표현하고, name과 object를 연결해주고, 연결을 풀어주고, object를 rename하고, 바인딩 리스트를 볼 수 있게해준다. Context의 메쏘드에는...

void bind(String stringName, Object object)
void rebind(String stringName, Object object)
Object lookup(String stringName)
void unbind(String stringNAme)
void rename(String stringOldName, String stringNewName)
NamingEnumeration listBindings(String stringName)
NamingEnumeration list(String stringName)

이 있다. 메쏘드 이름만봐도 대충 뭐하는 애들인지 짐작이 가니,
자세한 설명은 피하고....참, 위의 메쏘드들은 String object대신에 Name object를 받는 똑같은 메쏘드들이 또 있는데...Name object를 사용함으로써 특정네임서비스에 대해 알필요가 없어진다.

JNDI의 InitialContext라는 클래스는 어디서부터 찾기 시작해야될 지를 도와준다.



Reference: www.javaworld.com

Jar, War, Ear 파일들의 차이점은?

세 파일은 모두 압축 파일이고, 구조적인 차이는 없으므로 확장자를 서로 바꿔도 문제는 없지만,,,,,
만들어진 목적은 서로 틀리다.

Jar: 자바클래스 파일들이 주이며, EJB 파일들을 포함.
War: 웹 애플래케이션에 관련된 파일들을 포함한다. 주로 JSP, Servlet 파일들.
Ear: 엔터프라이즈 애플리케이션에 필요한 모든 파일들을 포함한다. Jar 파일과 War 파일들을 포함.

---

Differences .jar, .war and .ear files ???

There are no structural differences between the files; they are all archived using zip/jar compression. However, they are intended for different purposes.

Jar files (files with a .jar extension) are intended to hold generic libraries of Java classes, resources, auxiliary files, etc.

War files (files with a .war extension) are intended to contain complete Web applications. In this context, a Web application is defined as a single group of files, classes, resources, .jar files that can be packaged and accessed as one servlet context.

Ear files (files with a .ear extension) are intended to contain complete enterprise applications. In this context, an enterprise application is defined as a collection of .jar files, resources, classes, and multiple Web applications.

Each type of file (.jar, .war, .ear) is processed uniquely by application servers, servlet containers, EJB containers, etc.

Reference: http://expertanswercenter.techtarget.com/eac/knowledgebaseAnswer/0,295199,sid63_gci1105646,00.html

---

An EAR file contains all the JARs and WARs belonging to an application. JAR files contain the EJB classes and WAR files contain the web components (JSPs, static pages, servlets, gifs, etc.). The J2EE application client's class files are also stored in a JAR file. EARs, JARs, and WARs all contain an XML-based Deployment Descriptor

Reference: http://www-1.ibm.com/support/docview.wss?uid=swg21066338