Ace-T's Blog 내 검색 [네이버 커넥트 이웃 합니다~^-^/ 요청 大 환영~~]

메시지큐에 대해 알아보자.

Architecture/AA 2017.06.27 14:30
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T
모델 종류 
  • 발행/구독(publish - and - subscribe) 모델
          1: 다 - 모든 클라이언트에게 모든 메시지의 사본을 전달.
           publisher -> topic -> subscriber
                                         -> subscriber
                                         -> subscriber


  • 지점간 연결(point -  to - point) 모델 
          1:1 - 하나의 메시지는 하나의 클라이언트에만 전송(큐는 공유 가능)
          sender -> queue -> receiver 

위의 모델 중에 publish - and - subscribe(pub - sub) 모델에 대해서 알아보자!

pub/sub 구조
보통의 message queue들은 publisher - message broker(topic) - subscriber 구조를 사용한다.
publisher(message data)를 하면 가운데 있는 message broker가 메시지를 선택하고 처리하는 즉, 내부적으로 구독하고 있는
subscriber들을 찾아서 메시지를 보낸다. 

opensource message queue중에 nats라는 녀석이 있다. (http://nats.io/)
lib는 https://github.com/nats-io/go-nats 참고!


pub/sub 구현(w/go lang)
그러면 pub/sub 모델을 구현한다고 생각해보자.
우선은 메시지큐 server가 필요하겠다. 그리고 그 서버를 붙는 client도 필요하다.
보통 jms, nats, amazon sqs 등등이 서버가 되겠다. client는 제공되어지는 publish()등의 함수가 있는 lib 정도.

ex)  메시지 큐 동작 과정
  1. 클라이언트가 NATS 서버와의 TCP / IP 소켓 연결을 설정.
    1. nc, _ := nats.Connect(nats.DefaultURL)
  2. 발행
    1. nc.Publish("foo", []byte("Hello World"))
  3. 구독 (subject가 구독대상 : foo)
          // Simple Async Subscriber
    nc.Subscribe("foo", func(m *nats.Msg) {
                      fmt.Printf("Received a message: %s\n", string(m.Data))
     })

    // Simple Sync Subscriber
    sub, err := nc.SubscribeSync("foo")
    m, err := sub.NextMsg(timeout)
  1. 구독 해제(Sync Subscriber 일 경우에만)
    // Unsubscribe
          sub.Unsubscribe()    
     5. defer nc.Close()    

func TestNatsWorking(t *testing.T) {
   nc, _ := nats.Connect(nats.DefaultURL)
   defer nc.Close()
   // Simple Publisher
   nc.Publish("foo", []byte("Hello World"))

   // Simple Async Subscriber
   nc.Subscribe("foo", func(m *nats.Msg) {
      fmt.Printf("Received a message: %s\n", string(m.Data))
   })

}



           


저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

SOLID (object-oriented design)

Architecture/AA 2014.02.26 21:24
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T

객체지향적으로 개발 할 때 OOD를 따져서 설계하고 개발한다면 더욱 더 좋은 소스가 될 수 있다.

한번 알아보도록 하자!

 

출처 : http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

 

추억의 솔리드..ㅋㅋㅋㅋㅋ 이밤에 끝을 잡고~

 

Initial Stands for
(acronym)
Concept
S SRP
Single responsibility principle - 단일 책임의 원칙
a class should have only a single responsibility.
하나의 클래스에 오직 하나의 책임이어야 한다는 원칙.
예를 들어 MVC 패턴이 나오기까지...jsp에 모든 것을 다 때려 넣었던 그런
시절이 있었다...단일 페이지에 모든 것을....와우! 그런 것처럼 하나의 클래스에 하나의 책임을 주어서 유지보수와 소스의 가독성, 재사용성을 높일 수 있다.

 ex) Class에 오직 하나의 책임..그렇다면! 메소드도 있는데???

그렇다! 하나의 Class에 여러가지 메소드가 있을 것이다.

그 메소드들이 Class들 마다 하는 역할을 구분하여 오직 하나의 역할(책임)을 줘야 한다는 뜻이다.

 

즉, public class acetData{

          public void load(){

             .........................

           }

 

          public void save(){

             .........................

           }

 

          public void del(){

             .........................

           }

 

           public void displayToUi(AcetVo acetVo){

             .........................

           }       

     }

 

위의 클래스에서 Data와 관련 된 메소드는

데이터를 load

데이터를 save

데이터를 del

이렇게 3가지이며, 데이터 관련 책임이라고 볼 수 있으며,

displayToUi는 UI 화면에 데이터를 뿌려주는 것! 즉, 화면에 보여주는 책임이라고

볼 수 있다.  displayToUi는 UI Class로 빼줘야 한다.

 

 

O OCP
Open/closed principle - 개방 폐쇄의 원칙
“software entities … should be open for extension, but closed for modification.”
요녀석은 확장에 대한 open~!!!!! closed는 수정에 대한 내용이다. 라고 대부분
나와있다..ㅋㅋㅋㅋ 여기에서 중요한 것은!!! 확장이다! 영어로 extension~!!
수정에 대한 closed 즉, 수정이 되면 안된다는 것이다. 어떨때??? 확장 땜시롱!
확장을 위해! open! 확장이 매우 용이하게!! 그렇다고 본 소스를 마구마구 수정하면 No!! 즉, 수정에 대한 것은 closed!! 결론적으로 확장을 잘하기 위한 원칙이다.
바로 상속의 개념인 것이다. 즉, 공통적인 부분을 추상하여 SubClass나 SubType으로 표현한다. 자세히 말하면 바로 SubClass(extends), SubType(implements) 인 것이다.
L LSP
Liskov substitution principle - 리스코프 치환 원칙
“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.

너무나도 헷깔렸던 개념이다..-_-;;
그 이유가 SubClass와 SubType 차이를 몰랐었고...OCP나 LSP는 요 2가지로 표현이 된다는 것이다..
특히 위에 나오는 영어에서도 보면 subType의 인스턴스가 교체된다는 것인데...
여기에서 교체된다는 말이 code로 표현을 어떻게 해줘야하는건지...잘 떠오르지 않았다..주변 동료에게 이런저런 이야기를 같이 해보다가...알게 되었다^-^
우선 정의를 보도록 하자.
정의 : 
1) SuperClass(상위타입)을 SubClass(하위타입)로 교체(치환)해도 정상 작동 해야 한다.       
또는 2) SuperType(상위타입)을 SubType(하위타입)로 교체(치환)해도 정상 작동 해야 한다.      

        1)은 Class기반의 상속을 생각하면 된다.

        2)는 Interface 기반의 상속(구현)을 생각하면 된다.

 

        1)은 말그대로 객체를 치환하여도 같은 동작을 하면 OK!!

        2) 객체를 치환한다는 개념으로 접근하기보다 SubType의 기능 수행으로

            생각하면 된다. ex) dataSave()면 데이터 저장인데 그 안에서 modify기능을

            하면 안된다.

 

         이 원칙은 OCP를 잘 구현하기 위해 체크하는 스펙 같은거라고 보면 될 것 같다.

         반대로 말하면 리스코프 치환 원칙을 지키지 않으면 OCP를 지키지 않을

         가능성이 커진다는 것이다.

 

         특히 2번, 인터페이스 기반에서는 치환이라는 개념 자체가 이해가 가질 않았을

         것이다..그러므로 기능, 리턴, 예외 등 올바른 작동을 하는지 봐야 한다.


참고 사이트
1)http://www.cs.princeton.edu/courses/archive/fall98/cs441/mainus/node12.html
2) http://vandbt.tistory.com/41
3) http://hyukmini.tistory.com/16    

I ISP
Interface segregation principle - 인터페이스 분리 원칙
“many client-specific interfaces are better than one general-purpose interface.”[4]
 
많은 뚜렷한 인터페이스들은 하나의 일반적인 취지의 인터페이스보다 낫다.
옹마~앙대요~~왜이리 말이 어려운지.....OTL =3=3
 
인터페이스 분리 원칙은..클라이언트를 기준으로 인터페이스를 분리하는 원칙.
이 말을 다시 풀어보면..
 
각 클라이언트가 사용하는 기능을 중심으로 인터페이스를 분리함으로써,
클라이언트로부터 발생하는 인터페이스 변경의 여파가 다른 클라이언트에 미치는 영향을 최소화 할 수 있게 된다.

        생각해보자! 기능 중심?????? 인터페이스를 분리해??? Why??

        인터페이스를 하나 만들려고 한다. 그 안에는 여러가지 메소드들이

        많이 있을 것이다.

        즉, ISP의 원칙을 잘모른다면..동작의 역할 인 메소드들이 뒤죽박죽

        하나의 인터페이스에 얽혀있을 것이다.

        하지만 ISP를 잘~~알고 인터페이스를 만든다고 하면! 바로 기능중심!!! 으로

        나눠서 이쁘게 잘~~~쓰게 될 것이다.

 

    참고문헌 : 개발자가 반드시 정복해야 할 객체지향과 디자인 패턴(최범균 저)

 

D DIP
Dependency inversion principle - 의존관계 역전의 법칙
one should “Depend upon Abstractions. Do not depend upon concretions.”[4]
Dependency injection is one method of following this principle.

       DI(Dependency Injection)이라고 보면 된다. springframework의 특징

      중인 IoC/DI 이다. 커플링을 최소화시키며(외부주입을 해주니깐!)

 

      특히, 생성자 또는 setter로 주입을 시키는 특징이 있다.

 

 

 

 

 

 

                 - END -

저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

[소프트웨어 아키텍처 이론과 실체] 아키텍트로 가기 위한 필독서!!

Architecture/AA 2013.11.24 22:59
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T

 

소프트웨어 아키텍처 이론과 실체

라는 책을 산지..올해 2월에 산것 같은데..제대로 보지를 못했다..ㅠ_ㅠ 채수원님 책은 술술 읽혀서 보았다 다행히..

2013/03/05 - [Life of AceT/Good book] - 소프트웨어 아키텍처 이론과 실제, TDD(채수원)

 

아직 기초 지식이 부족하여 할 것이 너무나도 많다..(아~내 잃어버린 시간들이여~~진작에 공부를 했어야..쿨럭~)

조금 정리를 하여 조금씩 이라도 볼 생각이다.

사실 잊고 있었는데..홍K(前팀장)님이..자극을 주셨다+ㅁ+~고오오오오오~

좋은 자료도 주시고..흐흐+ㅁ+흐흐흐~나만 봐야디~

 

자!~ 책의 구성은 총 4부로 되어있다. 혼자보기에는 엄청 힘들 것 같기도 하다..ㄷㄷㄷ

1부. 아키텍처의 개요

   1장) 아키텍처 비즈니스 사이클

   2장) 소프트웨어 아키텍처 정의

   3장) A-7E 항공 전자 시스템

 

2부. 아키텍처 수립

   4장) 품질속성 이해

   5장) 품질 목표 달성

   6장)항공관제 시스템

   7장) 아키텍처 설계

   8장) 비행 모의실험

   9장) 아키텍처 문서화

   10장) 아키텍처 재건

 

3부. 아키턱처 분석

   11장) ATAM

   12장) CBAM

   13장) 월드와이드웹

 

 4부. 아키텍처 확산

   14장) 소프트웨어 프로덕트 라인

   15장) 셀시우스테크

   16장) J2EE/EJB

   17장) 루더 아키텍처

   18장) 기성 컴포넌트를 활용한 시스템 구축

   19장) 소프트웨어 아키텍처의 미래

 

 

 

 

 

 

저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

DTP(Distribution Transaction Processing) 관련 자료

Architecture/AA 2013.06.08 00:44
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T




DTP(Distribution Transaction Processing) 에 대해서 알 수 있는 The open group의 자료 이다. 


자료 링크(영어) : 2.1 X/Open DTP Model을 보면 됩니다. :D

http://pubs.opengroup.org/onlinepubs/009680699/toc.pdf



toc.pdf



IBM에서 번역한 내용(한글) :

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0004558.htm



저작자 표시 비영리 변경 금지
신고

acet 박태하가 추천하는 readtrend 추천글!

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

ACE-T의 아키텍트 이야기

Architecture/AA 2013.01.28 10:46
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T



- 시작
아키텍처 직군에 있으면서 일반적인 개발보다 더 큰 그림을 봐야 겠다고 생각이 든다.

개발을 할 때 마다 찾아보고 처리하고 했던 방식에서 이제는 모든 것을 아울러야 하는 역할을 해야 한다.

결론은!

공부하자~! 2013년이 밝아 벌써 1월이 지나가고 있다.
다시 한번 내 마음의 열정을 불태워보자^-^ 화이링!
저작자 표시 비영리 변경 금지
신고

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

AA란?

Architecture/AA 2012.11.12 13:08
[Good Comment!!, Good Discussion!!, Good Contens!!]
[ If you think that is useful, please click the finger on the bottom~^-^good~ ]
by ace-T


Architecture?

Architecture의 사전적 의미는 ‘건축 혹은 건축 양식’ , 그리고 ‘컴퓨터 시스템의 구성’ 으로 나와 있습니다. 컴퓨터에서 말하는 아키텍처란, 프로세스와 전체적인 구조나, 컴퓨터와 운영체제, 네트워크 및 기타 개념들 간의 논리적 상호관계 등을 생각하고 정의하는 등, 컴퓨터 구조의 모든 곳에 적용되는 용어입니다.
Architecture는 OSI 7 Layer같은 참조 모델처럼 하나의 참조 모델이 될 수도 있지만, 특정 제품의 구조를 위한 모델을 의미하거나, 펜티엄 프로세서 같은 특정 제품의 구조가 될 수도 있습니다. 이 문서에서의 Architecture의 가장 가까운 뜻은 “특정 제품의 구조를 위한 모델을 의미” 가 될 듯 싶습니다.

Application Architecture란

Application Architecture는 Enterprise Architecture의 구조를 묘사한 EA 정보의 종류 중 하나로써, 엔터프라이즈의 Business Model의 원활한 수행을 위하여 필요한 기능이나 업무 구조, 활동들이 정보기술에 의하여 구체적으로 구현되기 위한 모습입니다.
쉽게 말하면 하나의 솔루션을 지칭하는 말이 될 수도 있고, 솔루션의 구조를 지칭하는 말이 될 수도 있습니다.
(주로, Application Architecture는 비즈니스 요구 사항에 근거하여 지정됩니다.)

요런 거였구나! ㅋㅋ
저작자 표시 비영리 변경 금지
신고

설정

트랙백

댓글

:::: facebook을 이용하시는 분들은 로그인 후 아래에 코멘트를 남겨주세요 ::::

티스토리 툴바