블로그 이미지
윤영식
Full Stacker, Application Architecter, KnowHow Dispenser and Bike Rider

Publication

06-21 10:30

Category

Recent Comment

2012. 11. 10. 20:19 Middleware, Cloud/OSGi

위키북스의 OSGi & Spring DM을 읽으면서 Spring DM쪽의 내용을 요약해 본다 



▶ 동영상 자료

  - IBM DeveloperWorks : 안영회/이일민 개념 및 개발하기 (맨 하단의 Next 클릭해서 봄)



▶ 간단 요약 (Ch. 11)

  - 서비스 레지스트리를 사용하는 OSGi의 서비스 룩업 메커니즘을 스프링에서 제공하는 의존성 주입 형태로 사용할 수 있게 해준다. (그림 참조)

  - SpringDM은 OSGi상에서 Extender 개념을 이용하여 POJO(Plain Old Java Object) 형태의 일반 스프링 빈을 OSGi번들로 동적으로 바꾸는 작업을 지원한다 (Extender : 동적으로 설치되는 번들/서비스의 설치/삭제 시 이벤트를 받아서 특정 동작을 수행함)

    + SpringDM OSGi Extender : META-INF/spring/*.xml 파일을 읽어서 스피링 빈으로 초기화 한다

    + SpringDM Web Extender : war 확장자 배포하거나 WEB-INF 폴더를 가지고 있으면 웹컨테이너에 등록시킴 


  - POJO A가 BundleActivator -> BundleContext로 Service Registry에 Service A등록이 되고 ServiceTracker -> BundleActivator를 통해 Service A를 찾아 POJO B가 사용한다 (참조)

  - OSGi 번들은 BundleActivator, ServiceTracker Interface에 의존하나 SpringDM은 spring.xml 과 POJO 만을 필요로 한다 

    + POJO기반으로 번들을 만들어 테스트가 용이하다

    + 번들, 라이프사이클, 버젼닝, 동적 추가/수정/삭제 등의 기능을 엔터프라이즈급 애플리케이션을 개발할 때 사용할 수 있게 됨


  - SpringDM 개발 = Eclipse STS(Spring Tool Suite) + Maven Plugin(v 3.0.4) 설치

  - Eclipse에 Target Platform을 설정한다 (T.P = 번들을 개발하고 실행하는 환경을 의미함. 사용자 Target Platform 만들기 참조)

  - OSGi로 관련 Bundle을 별도의 Plug-In Project로 만들다 보면 Working set으로 묶어서 관리하고 싶어진다. 이를 위한 설정은    WhiteShip 브로깅을 참조한다

  - SpringDM은 Spring Application Context : Bundle = 1:1 관계이다 



▶ Eclipse에서 SpringDM 간단히 만들고 등록하기 

1. Plug-in Project를 생성한다 (이클립스 플러그인 프로젝트는 기본적으로 이클립스 Equinox OSGi를 이용한다)


2. 적절한 이름을 입력하고 하단 Options에서 Activator를 상속받지 않은 POJO로 개발을 할 것이다 


3. 생성하면 자동으로 MANIFEST.MF 파일이 생성된다


4. META-INF/spring.xml 파일을 생성한다 


5. spring.xml 스프링 프레임워크 빈등록 환경설정 이전에 프로젝트를 선택하고 Spring Tools에서 "Add Spring Project Nature"를 선택한다 


6. 프로젝트 폴더 우측 상단에 S 자가 표현된다


7. spring 폴더에 "Spring Bean Configuration File"을 생성한다 


8. 명칭은 spring.xml 로 생성한다


9. spring.xml에 osgi 관련 xsd 내역이 없으니 코딩하고, 인식하고자 하는 bean을 등록한다 


10. Run Configuration... 에서 해당 프로젝트의 실행 환경을 새로 생성한다 


11. Bundle로 HelloSpringDM을 선택한다 (Target Platform을 적절히 선택해 주어야 한다. 여기선 오류가 있다. Spring이 선택되어야 한다)



12. Active한 bundle을 확인하고 HelloSpringDM의 RESOLVED 상태를 start 시켜주어 Active 상태로 만든다 

posted by peter yun 윤영식
2012. 11. 3. 18:19 Middleware, Cloud/Cloud

Node.js로 개발한 간단한 애플리케이션을 CloudFoundry로 배포해 보자. 현재 클파(CloudFoundry)는 무료이지만 조만간 유료로 가지 않을까 생각된다. 특징을 보자 


▶ 클파 설치하기

  - 우선  http://www.cloudfoundry.com/  으로 가서 Sign Up 한다 (신청한 메일계정으로 비밀번호가 온다)

  - http://www.rubyinstaller.org/ 사이트로 가서 ruby를 설치한다. (설치시 path 설정여부에 check를 한다. ruby의 gem을 사용하기 위함으로 node.js의 npm와 같은 package 설치 관리자로 보면 된다)


  - d:>gem install vmc  (클파 관리 유틸 vmc를 설치 한다. 한참을 설치하니 그냥 기다리자)

  - vmc의 target을 클파로 지정을 한다 (api.cloudfoundry.com) 그런후 신청한 계정으로 로그인을 한다


  - 하단에 첨부된 파일 적절한 위치에 푼다음 해당 디렉토리로 이동한다

  - 클파에 애플리케이션을 Push 한다 (vmc push <URL해드> 예) vmc push nulpulum 으로 하면 웹 호출 주소가 http://nulpulum.cloudfoundry.com 이 된다. 자세한 사항은 vmc help 로 살펴보자. 최초에는 사용하려는 service에 대하여 물어본다 이때 mongoDB 1개만을 만든다.)



  - 배포된 애플리케이션의 정보를 보자

  - 브라우저에서 호출하여 보자 


  - 간단하게 자신의 애플리케이션을 배포하여 바로 확인해 볼 수가 있다. 등록가능한 애플리케이션에 대해 보려면 vmc services 명령으로 확인해 보면 된다. 


* 첨부파일 : Node.js + Express + MongoDB를 사용한 간단한 CRUD 애플리케이션 

cloudFoundry mongodb.zip



<참조>

  - Open Source Cloud PaaS

  - Spring쪽에서 만든거라 Spring Framework을 지원하고, Node.js등 최신 기술을 지원한다 

  - 클파 이해하기

  - 클파 VMC 사용

'Middleware, Cloud > Cloud' 카테고리의 다른 글

Cloud9IDE 사용하기  (0) 2012.11.15
Ubuntu 에 JDK 1.7 설치하기  (0) 2012.11.15
[CloudFoundry] 개발한 Node.js 프로그램 배포하기  (0) 2012.11.03
posted by peter yun 윤영식
2012. 11. 3. 12:11 Middleware, Cloud/OSGi

예전 프로젝트할 때 WAS를 재기동하지 않고 애플리케이션과 SQL을 관리툴을 통하여 reloading 하는 프레임워크를 만든적이 있다. 또는 솔루션에서 액션을 수행하는 어뎁터 Java 코드를 관리툴을 통하여 입력하면 WAS의 재기동없이 신규 및 업데이트가 가능하게 한적이 있다. 그때 마다 사용했던 것이 ClassLoader 이다. 


좀 더 발전적이게 Plugin처럼 만들고 싶다는 생각을 했지만 게으름으로 미루다 OSGi에 관심을 갖게 되었다. 솔루션을 만들때 통신, 데이터 관리, 어드민 관리, 서비스등을 별도의 버전으로 관리하고 싶었다. OSGi 이면서 J2EE와 같은 Enterprise급 또는 솔루션 개발을 진행할 수 없을까 고민하던 중 찾은 Eclipse Virgo!  


  - 이일민씨의 기고글 : Virg 들어가기

  - Ted Won씨의 블로그 : Virgo 이해

  - 공식 Virgo Wiki


딱 내가 찾던 미들웨어 기능을 고스란히 가지고 있는 Eclipse Virgo를 사용해 보자 

Virgo는 두가지 종류의 버전을 제공한다 


  - Virgo Kernel : Runtime Platform for OSGi based java applications

  - Virgo Web Server : Virgo Kernel + Tomcat Server, OSGi based Web Application 배포 가능 



▶ Virgo 설치 


  1) 다운로드 :  http://www.eclipse.org/virgo/download/ (현재 v3.5.0)

  2) Virgo Server for Apache Tomcat 으로 시작해 보자

  3) bin/startup.bat 를 수행하면 OSGi bundle를 로딩하고 tomcat이 시작된다

  4) 웹 admin console을 들어가 보자 (https://localhost:8080,  id: admin pwd: springsource)

  5) 상단의 메뉴를 클릭하면 반영된 bundle내용 및 기타 상태정보와 deploy등을 수행할 수 있다

  6) Virgo에서 제공하는 모니터링 툴을 실행해 보자 (<Virgo_Home>/bin/jconsole.bat 실행)

  7) jconsole 로그인 (admin / springsource)

  8) JVM에 대한 기본적인 모니터링 항목(memory, thread info, loaded classes, tomcat JMX info) 등을 다양하게 모니터링 할 수 있다 

[Overview] 탭에서 Memory, CPU, Thread수, 로딩된 Class수 등을 볼 수 있다. 



[Threads] 탭에서 각 스레드의 정보를 볼 수 있다. 하단 왼쪽의 스레드를 클릭하면 하단 오른쪽에 정보가 나온다. 


[MBeans]탭에서 Tomcat의 JMX 뿐만 아니라 Virgo 관련 JMX 정보도 볼 수 있다 


  9) Virgo가 사용하는 기본 Library Path(repository/ext)와 유저 Library Path (repository/usr). 기본 OSGi Bundling만 인식한다 

  10) Log는 configuration/serviceability.xml 안에 설정을 하면 serviceability 디렉토리에 로그가 쌓인다 (logback 사용)

  11) OSGi telnet console을 사용하고 싶다면 configuration/osgi.console.properties 중 telnet.enabled=true 로 수정 그리고 Virgo를 재기동한다


  12) OSGi CLI 기반 연결 기본 port 는 2401 변경하고 싶다면 위의 properties파일에서 포트 번호를 변경하고 접속한다

  13) osgi> lb 명령을 수행하면 현재 번들의 상태를 알 수 있다

  14) 번들을 보면 OSGi Kernel, Apache Felix, Apache MINA등이 Active이고 Spring, SLF4J 등이 Resolved 상태이다


Virgo는 OSGi개념위에 J2EE 플랫폼기반 애플리케이션을 만들 수 있게 해준다. 


posted by peter yun 윤영식
2012. 10. 30. 15:25 Middleware, Cloud/OSGi

OSGi Layer에서 최상위에 있는 서비스 Layer는 번들이 서로 동적으로 협동하여 작업할 수 있도록 하는 방법을 제공한다. OSGi의 서비스는 SOA 처럼 구동된다 


  - Repository에 서비스를 Publish 한다

  - 클라이언트는 서비스를 Find 한다

  - 서비스가 찾아지면 클라이언트는 Repository와 Bind 된다


서비스의 사용 단계는 Publish -> Find -> Bind 되어 서비스 인터페이스를 통하여 수행된다 
 


▶ OSGi 서비스 등록 및 해지 

BundleContext를 통한 등록 API
public ServiceRegistration registerService(String clazz, Object Service, Dictionary properties);
public ServiceRegistration registerService(String[] clazz, Object Service, Dictionary properties);

인자값 의미

  - clazz : 해당 서비스 객체의 패키지명 + 인터페이스명, <Interface>.class.getName()  으로 얻어온다 

  - Service : 인터페이스 구현체, new 로 생성한다 

  - properties : 서비스 속성, SERVICE_VENDOR (같은 인터페이스 상속시 구분 명칭), SERVICE_RANKING (서비스 호출 우선순위)


서비스 해지
등록시 return 되는 ServiceRegistration 객체의 unregister()를 호출한다. 즉 BundleContext에는 등록된 서비스를 해지하는 API가 없고 return된 ServiceRegistration 객체를 통하여 해지한다



▶ OSGi 서비스 사용하기 

BundleContext를 통하여 서비스 찾는 API
public ServiceReference getServiceReference(String interfaceName); 
public Object getService(ServiceReference reference);

서비스 객체 얻는 순서 

  - BundleContext.getServiceReference(<interface>.class.getName())으로 호출하여 ServiceReference 객체를 얻는다

  - 다음 BundleContext.getService() 인자값으로 얻어도 ServiceReference 객체를 넘기면 실제 서비스 객체를 얻을 수 있다.


서비스 돌려주기
public void ungetService(ServiceReference reference);


* 동일한 인터페이스를 상속받은 서비스가 있고, 해당 인터페이스를 사용하는 클라이언트가 있다면 서비스 등록시 설정한 properties의 SERVICE_RANKING의 우선순위값에 따라 순서가 정해진다. 우선순위 RANKING이 동일 하다면 OSGi 에 등록된 번들 번호가 작은 것이 먼저 호출된다. 

* 클라이언트가 서비스 번들이 등록되었는지 찾기 위해서 Util 성격의 ServiceTracker를 사용하는 것이 좋다. 번들들은 동적으로 운영되므로 클라이언트가 호출하였어도 서비스가 등록되기 전일 수 있으므로 waiting하여 얻어오는 과정을 tracker에 위임한다 


* BundleContext API 참조 : http://kickjava.com/src/org/osgi/framework/BundleContext.java.htm


* 참조 샘플 : http://xguru.net/446

posted by peter yun 윤영식
TAG OSGi
2012. 10. 30. 14:20 Middleware, Cloud/OSGi

Bundle은 BundleContext에 의한 생명주기 관리가 이루어진다. 기본적으로 BundleContext 객체는 Bundle이 생성될 때 인자로 전달이 된다. 또한 OSGi 프레임워크와의 연결 통로이다. BundleContext는 OSGi Layer에서 LifeCycle Layer를 담당한다.



▶ BundleContext의 하는 일


  - OSGi에 새로운 번들 설치

  - OSGi에 설치된 다른 번들 리스트 및 정보 읽어오기

  - OSGi에 등록된 서비스 리스트 및 서비스 객체 가져오기

  - 서비스나 번들의 변경에 대한 이벤트 Listening  


결국 BundleContext가 번들에 대한 LifeCycle 관리 및 번들의 의존관계 설정에 따른 타 번들의 참조값을 BundleContext끼리 공유하여 가져온다


▶ Bundle의 LifeCycle

  1) OSGi 를 구동하여 shell 환경으로 들어가면 번들 jar 파일을 설치->시작->활성->정지->삭제등의 작업을 할 수 있다. 



  2) install file:c:/temp/testbundle.jar 파일 명령 : INSTALLED 상태가 된다
번들의 manifest 오류들을 점검 한다 

  3) resolve <bundle number> : RESOLVED 상태가 된다 
번들의 Export / Import를 연결해 주는 단계,  resolving 상태에서 문제가 발생하면 diag 명령을 내려서 원인을 찾는다

  4) start <bundle number> : STARTING->ACTIVE 상태가 된다
BundleActivator.start(BundleContext)가 호출된다. 문제 발생시 다시 RESOLVED 상태로 돌아 간다
start 안에는 많은 시간이 소요되는 작업을 해서는 안되고 있다면 별도의 스레드로 진행한다 

  5) stop <bundle number> : STOPPING->RESOLVED 상태가 된다
BundleActivator.stop(BundleContext)가 호출된다. stop()을 호출하면 만들어 놓은 스레드나 서비스를 종료 해지해야 한다. 따라서 stop 호출시 사용한 스레드, 서비스들을 종료하는 코드를 넣는다.   

  6) uninstall <bundle number> : RESOLVED-> UNINSTALLED 상태가 되고 ss(Equinox 기준) 또는 lb (felix 기준) 명령으로 보면 bundle 명칭이 나오지 않는다. 번들이 삭제된 것임 
번들이 완전 제거 되는 것임. OSGi 목록에서 나타나지 않는다 


LifeCycel의 상태 변이 흐름에 따라 명령어도 동일함을 알 수 있다.  OSGi 미들웨어의 재구동없이 번들을 만들고 적용시키는 것이 가능함을 알 수 있다.


'Middleware, Cloud > OSGi' 카테고리의 다른 글

[Eclipse Virgo] 사용하기  (0) 2012.11.03
[OSGi] 서비스 Layer 만들기  (0) 2012.10.30
[OSGi] BundleContext에 의한 LifeCycle 관리  (0) 2012.10.30
[OSGi] manifest.mf 파일 설정  (0) 2012.10.30
[OSGi] Felix 설치 사용하기  (0) 2012.10.29
[OSGi] 이론-1  (0) 2012.10.27
posted by peter yun 윤영식
TAG OSGi
2012. 10. 30. 13:51 Middleware, Cloud/OSGi

OSGi 번들은 jar 파일로 패키징이 되고 안에 META-INF/manifest.mf 파일이 존재해야 한다. 해당 파일에는 번들의 명칭, 버전, 의존관계, 정책등이 기술된다. manifest.mf 파일 만들기는 OSGi Layer에서 Module Layer의 모듈 즉, 번들을 만들기 위한 중요 부분이다.


Name: Value 방식으로 서술이 된다. 

일반적인 기술 방법은 http://blog.naver.com/PostView.nhn?blogId=kittenjun&logNo=10126086035 사이트를 참조한다. 


중요하게 생각되는 항목은


  - BundleActivator를 상속받아 구현한 클래스 지정하는 Bundle-Activator

  - OSGi에 노출되는 외부명칭 Bundle-Name, 내부 키명칭 Bundle-SymbolicName

  - 번들 버전 Bundle-Version 

  - 외부 Bundle을 사용한다면 Import-Package


정도는 기본적으로 알아두어야 겠다

주의 : manifest.mf 파일 맨뒤에는 CR(Carriage Return)과 같이 Line Break 종료되어야 한다. 따라서 파일 맨 마지막에 빈 공백의 라인을 의무적으로 넣는다. 작성하고 Enter키 두번 누른다. 맨 마지막 줄에 빈 공백 라인이 없으면 Activator 인식 오류가 발생할 수도 있다. 


'Middleware, Cloud > OSGi' 카테고리의 다른 글

[Eclipse Virgo] 사용하기  (0) 2012.11.03
[OSGi] 서비스 Layer 만들기  (0) 2012.10.30
[OSGi] BundleContext에 의한 LifeCycle 관리  (0) 2012.10.30
[OSGi] manifest.mf 파일 설정  (0) 2012.10.30
[OSGi] Felix 설치 사용하기  (0) 2012.10.29
[OSGi] 이론-1  (0) 2012.10.27
posted by peter yun 윤영식
TAG OSGi
2012. 10. 29. 16:15 Middleware, Cloud/OSGi

OSGi 프레임워크중 r4를 구현한 Felix를 설치하고 간단히 구현한 번들을 어떻게 올려서 사용할 수 있는지 보자. 


▶ 테스트 환경


  - Felix를 local PC에 설치하고 구동한다  (Felix가 OSGi 프레임워크라고 하지만 사실은 기능이 아무것도 없고 필요한 기능을 구현한 번들을 운영 관리해 주는 미들웨어-Middelware-라고 보면 된다)

  - Jetty 엔진 번들을 Felix 프레임워크에 올린다(start). 

  - Test용 Http Servlet 호출 프로그램을 짜고 번들로 만든다 (TestServlet 번들)

  - TestServlet 번들을 Felix에 올린다(start)

  - 브라우져에서 TestServlet을 호출해 본다. 


결국 아무 기능이 없는 Felix OSGi 미들웨어 위에 HTTP Servlet Engine인 Jetty를 올리고, Servlet을 개발하여 올리면 Client에게 서비스를 제공할 수 있게된다. 


▶ 환경 구축하고 테스트


  1) Felix (http://felix.apache.org/site/downloads.cgi) 에서 main framework 을 다운로드 한다

  2) 다운로드 zip 파일을 적당 위치에 푼다 (이전에 JDK 설치는 필수)
   

  3) 디렉토리 위치에 felix.bat 파일을 만든다  (bat 내용 :  java -classpath ./bin/felix.jar org.apache.felix.main.Main )    

    

  4) cmd 창을 띄워서 felix.bat 을 실행하고, lb 명령을 수행하면 현재 기본 Activate된 번들 정보가 나온다 (help 다른명령보기)

   

  5) felix에는 shell과 repository 번들이 bundle 디렉토리에 존재한다.

    

  6) 다른 번들을 auto deploy하기 위하여 conf/config.properties에서 #felix.auto.deploy.dir=bundle 로 되어있는 주석 #을 제거한다. 그리고 bundle디렉토리에 다운로드 받은 번들 jar 파일을 놓고 felix를 재시작하면 자동 activate된다.


  7) 수동 active 방법 : install xxx.jar   -->  start <번들No.> 

   

  8) felix를 일단 시작하면 기존 active된 상태 정보들은 felix-cache디렉토리에 영구저장된다. (번들 activate 상태정보를 완전 제거하고, felix를 초기화 하고 싶다면 해당 디렉토리를 삭제하면 된다)

  

  9) http://felix.apache.org/site/downloads.cgi 사이트에서 HTTP 관련 subproject 번들을 다운로드 받아서 로컬의 <felix 홈>/bundle 디렉토리에 copy한다


  

  10) felix를 재시작하면 jetty가 8080 port로 Listening을 한다 (포트 변경은 jetty bundle 압축을 풀고, metatype.xml 에 정의된 port 수정후 재 배포한다

 

  11) http://localhost:8080/ 을 호출해 보면 jetty 404 에러가 보이면 정상이다. (왜? 아무런 서비스도 올리지 않고 단지 jetty servlet engine만 기동 되었기 때문이다)
 

  12) 테스트 번들 만들기는 다음 블로그에서 소개하기로 하고 첨부된 httptest.jar 를 특정 디렉토리에 복사한다. 

  

  13) felix 위에 activate 시켜보자. 여기선 bundle 디렉토리에 파일을 놓고 felix를 restart함으로써 auto deploy 말고 수동으로 바로 activate 시켜본다 ( felix:install file:<directory> , 주의 : 윈도우 구분자는 \\ 두개 삽입하고 전체경로 지정 )

  

  14) http://localhost:8080/servlet1/MyMusicCollection  을 호출한다

  

  15) counting crows 입력값을 넣고 submit 하면 jetty가 해당 요청을 받아서 test servlet으로 요청처리를 보내고 결과를 반환한다

 


결국 OSGi 프레임워크는 필요한 기능이나 서비스를 번들로 만들어서 각 기능을 이용할 수 있게 해주는 미들웨어라고 볼 수 있다.


'Middleware, Cloud > OSGi' 카테고리의 다른 글

[Eclipse Virgo] 사용하기  (0) 2012.11.03
[OSGi] 서비스 Layer 만들기  (0) 2012.10.30
[OSGi] BundleContext에 의한 LifeCycle 관리  (0) 2012.10.30
[OSGi] manifest.mf 파일 설정  (0) 2012.10.30
[OSGi] Felix 설치 사용하기  (0) 2012.10.29
[OSGi] 이론-1  (0) 2012.10.27
posted by peter yun 윤영식
TAG OSGi
2012. 10. 27. 14:10 Middleware, Cloud/OSGi

▶ OSGi (Open Services Gateway Initiative)


OSGi 기술은 java에서 동적 컴포넌트 시스템을 정의한 스펙이다. 

The OSGi technology is a set of specifications that define a dynamic component system for Java. 


컴포넌트 모듈을 만들고 이들을 추가하면 동적으로 반영되고 상호 모듈끼리 통신하여 대화할 수 있도록 만들어 주는 부분이 필요하다. 이를 위하여 OSGi는 어떤 Layer를 가지고 있나 보자 



참조 http://www.osgi.org/Technology/WhatIsOSGi


위의 관계를 간단히 보면 다음과 같다


  - 자바 인터페이스와 실제 구현 개체를 Service로 만든다 - Services Layer

  - 서비스를 제공하기 위한 기능적 배포단위로 Bundle을 만든다 (Jar 파일롤 묶음. MANIFEST 파일 포함) - Module Layer

  - 번들의 생명주기 관리는 Bundle Context가 해준다 (번들의 설치, 실행, 정지, 삭제 생명주기관리) - Life Cycle Layer

  - Installed -> Resolved -> Start -> Active -> Stop -> Resolved -> Uninstalled 

  - OSGi 프레임워크는 소량의 메모리로 효율적인 통합된 컴포넌트 개발환경을 제공하고, 애플리케이션 실행 중에도 동적 다운로드 
    및 업그레이드가 가능하게 해준다. 이는 OSGi가 애플리케이션간의 의존성을 관리하고 확장성(Scalable)를 제공한다. 

OSGi 프레임워크는 Bundle을 관리하는 Bundle Context를 가지고 있고 Bundle이 가지고 있는 Service를 등록하여 Bundle끼리 상호 대화할 수 있도록 해준다. 결국 Service를 등록하는 Registry가 OSGi Framework안에 존재하고 해당 Registry가 Service들을 상호 연결시켜주는 방식이다. 해당 방식은 Spring Framework의 DI (Denpendency Injecttion)가 같고, 결국 SOLID의 DIP 원리를 구현하여 서비스끼리의 Loosed Coupling을 지원한다는 말씀되시 겠다. 




* OSGi 사용 장점

  - 개발자입장에서 큰규모의 분산환경 구현 및 배포를 컴포넌트 기반으로 하기 때문에 이에대한 복잡성을 제거하여 단순화 해준다. (Eclipse, JBoss, Spring등에 쓰이고 있다)

  - 사업면에서는 운영비용을 줄여주고 네트워크환경의 멀티디바이스 통합을 손쉽게 해준다 

  - 또다른 이점은  http://www.osgi.org/Technology/WhyOSGi 여길 참조하자. 좋은 점은 다가졌다는 이야기


* OSGi 이론 다시 정리 참조http://blog.secmem.org/107


'Middleware, Cloud > OSGi' 카테고리의 다른 글

[Eclipse Virgo] 사용하기  (0) 2012.11.03
[OSGi] 서비스 Layer 만들기  (0) 2012.10.30
[OSGi] BundleContext에 의한 LifeCycle 관리  (0) 2012.10.30
[OSGi] manifest.mf 파일 설정  (0) 2012.10.30
[OSGi] Felix 설치 사용하기  (0) 2012.10.29
[OSGi] 이론-1  (0) 2012.10.27
posted by peter yun 윤영식
TAG OSGi
2012. 10. 25. 16:31 Middleware, Cloud/WAS

하이퍼소닉은 애플리케이션 테스트용으로 사용하는 것으로 실 운영시에는 적은 메모리라도 아끼기 위하여 삭제하는 것이 좋다. 하이퍼소닉은 외부 접근이 안되므로 보안에 대한  설정은 없지만 운영들어 가기전에 삭제한다


  • deploy> 밑에서 ls *ds.xml 검색하면 hsqldb-ds.xml 파일이 나온다 
  • hsqldb-ds.xml 파일을 삭제한다 

하이퍼소닉을 제거한후 oracle을 사용한다면 다음과 같은 서비스에 설정을 변경하여 준다. 

  • deploy 밑에 oracle-ds.xml 파일을 만든다 
  • DefaultDS를 사용하고 있는 ejb2-timer-service.xml의 설정을 oracle로 변경한다
  • JMS를 사용하면 deploy/messaging/hsqldb-persistence-service.xml 파일을 지우고 동일한 oracle-persistence-service.xml 파일을 만든다
  • uuid-key-generator.sar에서 UUID 키 생성을 한다면 META-INF/jboss-service.xml 에서 DefaultDS를 변경한다 
만일 새로운 데이터베이스로 서비스를 전환했다면 

show tables in jbossdb; 로 사용하는 테이블들을 점검 한다 


posted by peter yun 윤영식
2012. 10. 25. 16:12 Middleware, Cloud/WAS

Java Messaging Service를 사용하지 않는 다면 다음의 파일 또는 내용을 제거 하여 자원(메모리, CPU) 소모를 예방한다


  • deploy/messaging 디렉토리 삭제
  • deploy/jms-ra.rar 파일 삭제
  • deployers/messaging-definitions-jboss-beans.xml 파일 삭제
  • conf/standardjboss.xml 파일에서 jms 관련 내용 제거 

메시징을 이용한다면 

  • deploy/messaging/destinations-service.xml 안에 <security>를 설정한다
  • conf/login-config.xml 파일에 <application-policy name="JMSRealm"> 이라는 새로운 application 정책을 만든다 
  • 마지막으로 deploy/messaging/messaging-jboss-beans.xml 안에 <bean name="SecurityStore">를 설정한다 


posted by peter yun 윤영식
2012. 10. 25. 16:02 Middleware, Cloud/WAS

▶ shutdown이나 twiddle이 JBoss의 내부 마이크로 커널과 통신하려면 JMX invoker를 사용한다.


  • deploy/jmx-invoker-service.xml 구성에서 org.jboss.invocation.Invocation 에 대한 인증 인터셉터를 추가한다
         <operation>
            <description>The detached invoker entry point</description>
            <name>invoke</name>
            <parameter>
               <description>The method invocation context</description>
               <name>invocation</name>
               <type>org.jboss.invocation.Invocation</type>
            </parameter>
            <return-type>java.lang.Object</return-type>
            <descriptors>
               <interceptors>
                  <!-- Interceptor to require authenticated users -->
                  <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
                     securityDomain="java:/jaas/jmx-console"/>
                  <!-- Interceptor that deals with non-serializable results -->
                  <interceptor code="org.jboss.jmx.connector.invoker.SerializableInterceptor"
                     policyClass="StripModelMBeanInfoPolicy"/>
               </interceptors>
            </descriptors>
         </operation>

해당 조건을 적용하면 단순 shutdown 명령이 내리지 않고 하기와 같이 한다

 bin> shutdown -S -s jnp://<IP> -u admin -p <admin 패스워드>

  • jnp 프로토콜 접속하는 JBoss 설치 IP (옵션)
  • -u 인증 admin 아이디 
  • -p admin 계정의 패스워드 



▶ HTTP Invoker 는 80 포트를 통해서 외부세계에서 JBoss의 JNDI, JMX invocation, EJB invocation등의 원격 접속을 허용한다. 


  • 80 포트는 애플리케이션을 요청하는 포트 이므로 HTTP Invoker는 아예 삭제를 한다
  • deploy/http-invoker.sar라는 단일 서비스를 디렉토리 몽땅 제거하면 서비스가 삭제된다





posted by peter yun 윤영식
2012. 10. 25. 15:40 Middleware, Cloud/WAS

JBoss 5.x에 대한 관리화면 폴더는 각 도메인안의 

  • deploy/jmx-console.war : JMX 콘솔
  • deploy/management : 웹 콘솔
두 디렉토리를 삭제하면 JMX 관리가 안됨. 보고 싶다면 보안을 설정한다

  • jmx-console.war/WEB-INF/web.xml에서 하기 security 테그의 주석을 제거한다 
<security-constraint>
     <web-resource-collection>
       <web-resource-name>HtmlAdaptor</web-resource-name>
       <description>An example security config that only allows users with the
         role JBossAdmin to access the HTML JMX console web application
       </description>
       <url-pattern>/*</url-pattern>
     </web-resource-collection>
     <auth-constraint>
       <role-name>JBossAdmin</role-name>
     </auth-constraint>
   </security-constraint>


  • JBossAdmin 권한을 가진 사용자만이 JMX 콘솔 사용이 가능하다 
  • 사전에 WEB-INF/jboss-web.xml 의 보안 도메인 링크가 하기와 같이 설정되어 있어야 한다
<jboss-web>
      <security-domain>java:/jaas/jmx-console</security-domain>
</jboss-web>

  • security domain에 대한 부분은 conf/login-config.xml에 하기와 같이 설정되어 있다
 <application-policy name="jmx-console">
    <authentication>
      <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
        flag="required">
        <module-option name="usersProperties">props/jmx-console-users.properties</module-option>
        <module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
      </login-module>
    </authentication>
  </application-policy>

  • conf/props 디렉토리 밑에 jmx-console-users.properties에 key=value로 admin을 정의 한다
  • conf/props 디렉토리 밑에 jmx-console-roles.propertiess에 하기와 같이 역할을 정의 한다
admin=JBossAdmin,HttpInvoker

  • management/console-mgr.sar/web-console.war/WEB-INF 디렉토리에서 web.xml 의 security 태그 주석을 제거하고 jboss-web.xml에서 java:/jaas/web-console를 java:/jaas/jmx-console 로 변경하면 똑같은 보안설정을 따르게 된다. 



posted by peter yun 윤영식
2012. 10. 21. 21:13 Middleware, Cloud/DBMS

org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Listener refused the connection with the following error:

ORA-12505, TNS:listener does not currently know of SID given in connect descriptor

 )

        at org.apache.commons.dbcp.BasicDataSource.createPoolableConnectionFactory(BasicDataSource.java:1549)

        at org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1388)

        at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)



위와 같은 메세지가 나오면 다음과 같이 수정하여 Listener를 restart 시킨다. 


  • ORA-12505, TNS:listener does not currently know of SID given in connect descriptor 이 메세지 구글링 해보면 lsnrctl services 수행해서 SID가 잘 나오는지 확인해 보라고 하는데 백날 해봐야 SID 안나오고 UNKNOWN 이라고 나온다. 
  • 그럼 listener.ora 파일을 열어보자. 하기와 같이 나올 것이다. 

SID_LIST_LISTENER =

  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = C:\oraclexe\app\oracle\product\11.2.0\server)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (SID_NAME = CLRExtProc)
      (ORACLE_HOME = C:\oraclexe\app\oracle\product\11.2.0\server)
      (PROGRAM = extproc)
    )
  )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
    )
  )

DEFAULT_SERVICE_LISTENER = (XE)

  • 위의 문구를 하기와 같이 수정한다. 
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = C:\oraclexe\app\oracle\product\11.2.0\server)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = XE)
      (ORACLE_HOME = C:\oraclexe\app\oracle\product\11.2.0\server)
      (SID_NAME  = XE)
    )
  )

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
    )
  )

DEFAULT_SERVICE_LISTENER = (XE)

  • 서비스에서 Listener를 restart 해보고, lsnrctl services 명령어 날려보자. 하기 빨간색 문구가 새롭게 나온다. 
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:0 refused:0
         LOCAL SERVER
Service "XE" has 1 instance(s).
  Instance "XE", status UNKNOWN, has 1 handler(s) for this service...
    Handler(s):
      "DEDICATED" established:3 refused:0
         LOCAL SERVER
The command completed successfully

기술적인 부분은 구글링해 보자.

posted by peter yun 윤영식
2012. 9. 3. 18:06 Middleware, Cloud/WAS

JBoss의 사용하는 port를 변경하거나, 서비스 추가/삭제 및 환경설정에 대한 관리를 알아보자. 이런 관리를 위해서는 먼저 JBoss의 아키텍쳐를 아는 것이 중요하다. 

  • 4.0.3 이전 JMX를 이용하여 service 추가/삭제
  • 4.0.3 이후 microcontainer 상에서 service를 POJO(Plain Old Java Objects) 로 만들어 추가/삭제 가능
  • 5.x 버전부터 JBoss는 microcontainer-based 아키텍쳐를 사용하고 있다. 

▶ microcontainer란 무엇인가?
  • Spring framework와 유사하게 dependency injection framework 이다 
  • DI에는 다음과 같은 설정을 한다
    • instantiated할 오브젝트 설정
    • 인스턴스 오브젝트의 constructor 파라미터 제공
    • set 프로퍼티에 값 설정
    • 오브젝트끼리 의존관계 설정
  • microcontainer는 이전의 JMX kernel 아키텍쳐보다  훨씬 가볍다, 환경설정이 적다, 서비스들을 standalone올 디플로이 할 수 있다. 
  • microcontainer위에 모든 서비스가 올라간다 (단, v5.0에는 JMX kernel위에 JMX, JNDI등이 올라가지만 이후는 microcontainer위에 전분 올라가도록 변경됨)
  • 환경파일의 이해
    • server/xxx/conf/bootstrap.xml : primary beans configuration 파일이다 

▶ JMX  이해하기 
  • Client는 JMX Server를 통해서 xxxMBean 인터페이스를 상속받은 MBean 클래스의 내역을 서비스 받는다
  • JMX Server가 xxxMBean을 lookup해서 찾고 client는 바로 xxxMBean을 접근할 수 없다. 
  • jboss-service.xml 파일 설정을 기반으로 service deployer가 MBean을 인스턴스화 한다. 또한 *-service.xml 설정도 같이 엮어서 인스터스화 한다.
  • jboss-service.xml 파일이 MBean 설정을 위한 primary descriptor 파일이다. 주 설정내역은 다음과 같다.
    • logging service 
    • thread pool : 다양한 서비스의 thread pool을 제공한다
    • JNDI
    • MBean 관리를 위한 security 
    • MBean과 관련된 JMX 서비스들
    • MBean과 관련된 remoting 서비스

▶ MBean 명칭 이해하기
  • MBean 명칭안는 여러부분이 내포된다.
  • domain : 자바의 패키지 명칭
  • key-value : 콤마로 구분

예) jboss.jca:service=ManagedConnectionPool,name=DefaultDS

  • jboss.jca = domain 이고 콜론앞의 값
  • service=ManagedConnectionPool,name=DefaultDS = key properties들이고 콤마로 구분된다. (순서완 상관없음)

▶ Application Server 환경설정하기
server/xxx/conf/ 디렉토리 밑에 있는 config 파일들을 알아보자 
  • bootstrap.xml : POJO를 초기화 하기위하여 microcontainer가 사용함
  • jax-ws-catalog.xml : JAX-WS를 위한 맵핑에 사용함
  • jbossjta-properties.xml : Java Transaction API (JTA) 서비스에서 사용함
  • jboss-log4j.xml : 로깅 설정
  • jboss-service.xml : JMX kernel에서 사용
  • jndi.properties : JNDI 서비스에서 사용하는 디폴트 설정값
  • login-config.xml : security 서비스에서 사용
  • standardjboss.xml : EJB 서비스에서 사용
  • standardjbosscmp-jdbc.cmp : Container Managed Persistence(CMP) EJB를 위한 다양한 DB 설정에 사용 
  • 다른 환경 파일들 설명



posted by peter yun 윤영식
2012. 8. 16. 17:43 Middleware, Cloud/WAS

JBoss는 메모리의 효율적 사용을 위하여 몇가지 종류의 서버 타입을 나누어 놓았다. 한번 들여다 보자 


▶ microcontainer 

  • 메모리를 적게 사용한다
  • 시작이 빠르다
  • microcontainer 위에 필요한 서비스들이 plug-in 된다 
  • server configureation은 같이 올라간다. 3종류 환경 : default, minimal, all

마이크로 컨테이너에 Plug-in 되어 올라가는 서비스들 

    • default : clustering은 없고 대부분의 필요한 서비스가 함께 올라감
    • minimal : deploy, JNDI, microcontainer등 최소한의 요소만 올라감
    • all : clustergin 포함해서 모든 서비스가 다 올라감 (server/all/deploy/cluster/cluster-jboss-beans.xml 환경참조)

▶ server/default 폴더 
  • conf, deploy, deployers, lib 이 기본 디렉토리로 존재
  • 기동된 이후 여러개의 temp 디렉토리가 생성됨 : data, log, tmp, work 등 
    • conf : 서버 기동시에 최초에 한번만 스캔된다. 즉, 재시작해야만 다시 인식됨 (자동 reloading 있음 좋겠다)
      • bootstrap.xml : microcontainer 코어 서비스들 정의
      • jboss-services.xml : 시작시 기동할 코어 JMX 서비스들 정의 
      • standardjboss.xml : EJB container 정의
      • jboss-log4j.xml : 로깅 설정
      • login-config.xml : authentication(자격-권한) 과 authorization(권한 범위-인증) 설정 
    • deploy : JAR, WAR, EAR 파일이 놓이면 시작시 자동으로 인식하여 배포함 
    • deployers : JBoss AS 서비스들을 가진다
    • lib : 어플리케이션 공유 라이브러리 디렉토리 
    • 기동시 생성되는 디렉토리들
      • data : write to file temp data ex) HSQL 이용시
      • log : boot.log, server.log, audit.log 쌓임
      • tmp : stores temp data
      • work : compile jsp files

▶ 자신의 서버환경 만들기 
  • default, minimal, all중 자신이 원하는 것을 하나 선택한다 
  • Copy & Paste하고 디렉토리 명칭을 원하는 것으로 변경한다 


▶ Start / Stop 

다른곳에서 너무 잘 정리해서 그냥 참조 : http://www.allsoft.co.kr/bbs/board.php?bo_table=study97_1&wr_id=4

  • 8080 가 default port로 사용
  • 맨 끝에 Started in 시간 나오면 성공
  • run.bat -c default -b <ip-address>
▶ 애플리케이션 Deploy
server/XXX/deploy/ 폴더 안에 파일 copy하면 deploy되고 delete하면 undeploy 된다 
예로 web01.war 파일을 deploy 폴더에 copy하면 jboss 콘솔창에 하기와 같은 메세지가 출력된다. 
17:06:07,823 INFO  [TomcatDeployment] deploy, ctxPath=/web01
역으로 delete하면 하기와 같은 메세지가 출력된다.
17:07:11,849 INFO  [TomcatDeployment] undeploy, ctxPath=/web01




posted by peter yun 윤영식
2012. 8. 16. 16:51 Middleware, Cloud/WAS

Mining 출판사에서 나온 내용을 읽으며 중요한 사항 및 참고할 만한 글을 올려 본다

  • JBoss의 의미가 처음에는 Enterprise Java Beans Open Source Software 라는 뜻으로 EJBoss 였다가 E 자가 맘에 안들어서 JBoss가 되었단다
  • JBoss 5 버전을 다운로드 받는 곳 :  http://www.jboss.org/jbossas/downloads
    • 적당한 위치에 푼다 (5.1버전은 JDK6 사전설치)
    • top level 디렉토리는 : bin, client, docs, lib, server 
      • bin : run, shutdown, probe(discovering JBoss AS clusters)
      • client : 클라이언트 어플리케이션과 통신을 위한 라이브러리들 존재
      • docs : 메뉴얼, 샘플
      • lib : core AS 라이브러리들 
      • server : 특성에 맞는 운영을 위한 디렉토리로 구분  (conf / lib / deploy 는 공통으로 존재)


posted by peter yun 윤영식
prev 1 2 next