2.1 Event Service

The Event Service is a publish/subscribe multipoint-to-multipoint communication

mechanism that is based on the concept of event channels. One or more publishers

communicate asynchronously with one or more subscribers by means of events over

a cluster-wide entity named event channel.

Events consist of a standard header and zero or more bytes of publisher event data.

Multiple publishers and multiple subscribers can communicate over the same event

channel. Individual publishers and individual subscribers can communicate over multiple

event channels. Subscribers are anonymous, which means that they may join

and leave an event channel at any time without involving the publisher(s).

반응형

'기타' 카테고리의 다른 글

잠금 기능 요약  (6) 2013.06.12
체크 포인트 기능 요약  (6) 2013.06.12
알림 기능 요약  (6) 2013.06.11
메시지 기능 요약  (6) 2013.06.11
[EDW519] 실제 공개되는 오픈소스중 코드의 양은 얼마나 되는가?  (6) 2012.10.31

2.1 Users of the Notification Service Library

Users of the Notification Service library run on cluster nodes as defined by the Cluster

Membership Service (see [4]).

2.1.1 Producer

A notification producer generates notifications (using the Producer API of the Notification

Service).

2.1.2 Consumer

A consumer consumes notifications that were generated by producers. If a consumer

is not interested in all notifications, it can specify filter criteria. A consumer can also

be a producer. A consumer can be one of the types described in the following subsections

or both:

2.1.2.1 Subscriber

A subscriber for notifications gets notifications forwarded as they occur (push interface).

2.1.2.2 Reader

A reader retrieves historical notification entries from the persistent notification log

(pull interface).


2.2 Notification Service

Similar to the AIS Services, the Notification Service mainly consists of a client library

and a server. No assumptions are made as to how server instances are distributed

across the nodes of an SA Forum cluster. In an implementation, the server could

even be part of the library.

2.2.1 Notification Service Library

The Notification Service library provides the following public C APIs:

• Producer API

• Subscriber API

• Reader API

2.2.2 Notification Server

The notification server applies the filtering criteria on notifications for delivery to subscribed

consumers and performs the logging into persistent storage.


2.2.3 Transport Service

The transport service links the Notification Service library and the notification server.

It is currently not specified.


2.3 Log Service

Alarm notifications and security alarm notifications are logged persistently. An implementation

may also support persistent logging for the other notification types (object

creation / deletion, attribute value change, state change notifications). It is recommended

that the Notification Service use the API of the SA Forum Log Service to

write notifications into persistent storage. Likewise, the Notification Reader API may

also use the log files of the Log Service.

반응형





2 Overview

This specification defines the Message Service within the Application Interface Specification

(AIS).


2.1 Message Service

The Message Service specifies a buffered message-passing system based on the

concept of a message queue for processes on the same or on different nodes1. Messages

are written to message queues and read from them. A single message queue

permits a multipoint-to-point communication. Message queues are persistent or nonpersistent.

The Message Service must preserve messages that have not yet been

consumed when the message queue is closed.

Processes sending messages to a message queue are unaware that the process

which was originally processing these messages, has been replaced by another process

acting as a standby in case the original process fails or switches over.

Message queues can be grouped together to form message queue groups. Message

queue groups permit multipoint-to-multipoint communication. They are identified by

logical names, so that a process is unaware of the number of message queues and of

the physical location of the message queues to which it is communicating. The

sender addresses message queue groups by using the same mechanisms that it

uses to address single message queues. The message queue groups can be used to

distribute messages among message queues pertaining to the message queue

group. Regardless of the number of message queues to which messages are distributed,

the message queue group remains accessible under the same name.

Message queue groups can be used to maintain transparency of the sender process

to faults in the receiver processes, represented by the message queues in the message

queue groups. The sender process communicates with the message queue

group. If a receiver process fails, the sender process continues to communicate with

the message queue group and is unaware of the fault, because it continues to obtain

service from the other receiver processes.

With message queues, the Message Service uses the model of n senders to 1

receiver whereas with message

반응형

본 페이지는 HACKER NEW의 TOP CONTIRBUTOR

Ed Weissman의 기고문을 바탕으로 작성되었습니다.

출처 : The Best of edw519

 

소프트웨어를 빙산처럼 나타내서

소프트웨어에서 소스코드중에

오픈소스가 얼마만큼 공개되어 있는지를

나타내면 아래와 같다.

 

빙산의 일각이라고 보면 되겠네,,,

 

반응형

본 페이지는 HACKER NEW의 TOP CONTIRBUTOR

Ed Weissman의 기고문을 바탕으로 작성되었습니다.

출처 : The Best of edw519



# 막장해석

50. 나의 업무 가이드라인

1. 해결책과 함께 시작하고 다시 일한다.

2. 변수는 그것들이 무엇인지 알도록 이름짓는다.

3. 함수는 그것들이 무엇을 하는지 알도록 이름짓는다.

4. 동일한 라인의 코드를 2번이상 절대 쓰지말고 함수를 써라.

5. 고객은 그들이 원하는게 뭔지 모른다고 가정해라.

6. 만약 고객이 그들이 뭘 원하는지 안다고 해도, 말로 설명할수 없다고 가정해라.

7. 고객들은 그들이 싫어하는것이 뭔지 알고있다. 프로토타입을 자주해라.

8. 이해할수 있을떄까지 함수를 타고 들어갈 준비를 해라.

9. 하던일이 막히면 컴퓨터를 꺼라.

10. 막힌것에 대한 정확한 해결책을 가질때까지 컴퓨터를 키지말라.

11. 아름다운 코드는 중요한데, 그보다 납기일 지키는게 더 중요하다.

12. 어떤 변수는 완전히 다른 변수에 포함되면 안된다. (? 이해가 안됨...)

13. 모든 변수는 3단어 이하여야 한다. (test_code_example)

14. 정확한 일을 위해서 올바른 툴을 써라.

15. 거의 모든 툴(언어(?))을 가지고 업무를 할 수 있다. 다른 툴이 더 나을 수도 있다.

16. 발생했던 문제들에 대해서 깊이 배우기 위해 자주 밴치마킹해라

17. 한번도 안해봤던걸 시도해봐라, 생각보다 쉽다.

18. 당신이 이전에 사용했던 'pattern'들을 기억해둬라. 나중에 다시 사용하게 될테니.

19. 일단은 가장 간결하게 구현하도록 해라. 복잡하게 하지말고.

20. 맨날 코딩해라. 



# 원문

50. My Working Guidelines

1. Start with the answer, then work back.

2. Name your variables so that anyone will know what they are.

3. Name your functions so that anyone will know what they do.

4. Never write the same line of code twice. Use functions.

5. Assume the user doesn't know what they want.

6. Even if the user knows what they want, assume they can't verbalize it.

7. The user always knows what they don't like. Prototype often.

8. Be prepared to dig down as many levels of detail as needed to understand.

9. When you're stuck, turn off your computer.

10. Don't turn your computer on until you have a specific task.

11. Beauty is important, but delivery is more important.

12. No variable should be fully contained within another variable.

13. All variables should be at least 3 characters long.

14. Use the right tool for the right job.

15. Almost any tool can do the job. Some are better than others.

16. Benchmark often in order to learn what happens under the hood.

17. Try something that's never been done. It may be easier than you thought.

18. Remember the patterns you've used before. You'll use them again.

19. Keep it extremely simple at first. Complexify as you go.

20. Code every day.


반응형

본 페이지는 HACKER NEW의 TOP CONTIRBUTOR

Ed Weissman의 기고문을 바탕으로 작성되었습니다.

출처 : The Best of edw519

 

< 맘대로 해석>

 

누가 최고의 개발자인가?

이에 대한 대답은 항상, '그런거 알아서 뭐하려고?'일지 모르지만

구지 정하자면 이렇다.

 

프로젝트 매니저에게는 고품질의 제품과 납기일을 항상 지키는 개발자가 슈퍼스타.

고객에게는 그들의 문제점을 가장 빠르게 해결해주는 개발자가 슈퍼스타.

사업주에게는 가장많은 돈을 그들에게 벌어다주는 개발자가 슈퍼스타.

PHB(학부생)에게는 그들을 최고로 보이게해주는 개발자가 슈퍼스타.

언론인에게는 최고의 이야기를 들려주는 개발자가 슈퍼스타.

신입 프로그래머에게는 최고의 멘토가 되어주는 개발자가 슈퍼스타.

다른 프로그래머에게는 꼭한번쯤 경쟁해보고 싶은 개발자가 슈퍼스타.

 

 

<원문>

 

Who is a superstar developer?
The answer to “Who is a superstar developer?” is always, “Who wants to know?”
To a project manager, the programmer who hits every deadline (regardless of quality) is a superstar.
To a customer, the programmer who solves their problem quickest is a superstar.
To a business owner, the programmer who makes them the most money is a superstar.
To a PHB, the programmer who makes them look the best is the superstar.
To a journalist, the programmer who tells the best stories is the superstar.
To a junior programmer, the best mentor is the superstar.
To another programmer, the programmer they are most likely to want to go into battle with is the superstar.
January 28, 2010

 

<결론>

 

결국은 무의미한 질문이다.

최고의 개발자란 마주하고 있는이에 따라

그 기준도 다르고

결론적으로는 능력있는 개발자를 의미하기 때문에..

반응형

본 페이지는 HACKER NEW의 TOP CONTIRBUTOR

Ed Weissman의 기고문을 바탕으로 작성되었습니다.

출처 : The Best of edw519

 

어디에서부터 내 직업에서 필요로 하는 것들을 배워왔는가?

 

 

Where did you learn what you need to know?
Where did the things I need to know to do my job come from?


October 1, 2009

 

1. 혼자 해온거 : 30 %

2. 두번째 멘토, 수년에 걸친 나의 사용자, 나의 고용주와 고객들, 가족들 : 40 %

3. 유치원, 대학동아리(연구실), 첫번째 멘토, 다른 프로그래머들, 독서 : 25% 

4. 초등학교, 중학교, 고등학교, 대학교, MBA 비지니스 스쿨 : 5%

 

[결론]

일단 본인 스스로 해보는게 가장 빠른길이다.

책을 보거나 멘토를 만나거나 회사에서 일하면서 배우는게 그 다음 빠른길이다.

학교 수업 만으로는... 평생해도 안되겠네..

 

 

반응형

본 페이지는 HACKER NEW의 TOP CONTIRBUTOR

Ed Weissman의 기고문을 바탕으로 작성되었습니다.

출처 : The Best of edw519

 

[ 맘대로 번역 ]

[ 에드의 일반적인 하루 ]

나는 단거리 경주가 아닌 마라톤의 삶을 살고 있기에,

건강한 스케줄 안에서 나의 긴 업무 시간의 틀을 만들었다.

나의 전형적인 하루일과는 다음과 같다.

 

----------------------------------------------------------------------

7:00 am - 지난밤의 계획에 대해서 즉시 코딩을 시작한다.

             그리고 이메일, 뉴스 해드라인확인
8 to 9 - 운동
9 - 아침식사 및 인터넷
9:30 to 12 - 코딩
12 - 점심식사 및 인터넷
12:30 to 6 - 코딩
6 - 가족과의 저녁식사(집이나 식당)
7 to 9 - 코딩

9 to 11 - 컴퓨터는 끄고 종이와 연필을 가지고 분석/설계/내일의 상세 계획을 한다.

 ----------------------------------------------------------------------

 

[예외들]

일주일에 한두번은 카운셀링을한다.(저녁 스케줄은 유지한다.)

일주일에 하루는 가족과 함께하는데 주로 TV로 스포츠를 본다.

난 이 생활을 평생 지속할 것 같다.

 

[원문]

96. My Typical Day
I am running a marathon, not a sprint, so I frame my long working hours within a “healthy schedule”. My
typical day:
7:00 am - immediately start coding last night's plan, then email, headlines
8 to 9 - exercise
9 - breakfast & internet
9:30 to 12 - code
12 - lunch & internet
12:30 to 6 - code
6 - dinner with family (home or restaurant)
7 to 9 - code
9 to 11 - computer off, pencil/paper, analysis, design, detail plan for tomorrow
Exceptions: one to two days per week consulting (still keep my night schedule), one day per week with
family, occasional sports on TV. I could keep this up forever.
June 4, 2008

 

 

하루에 10시간이 코딩이다.

식사시간에 인터넷을 이용해서 뭘 하는지 모르지만...

잠자기전 2시간은 컴퓨터가 아닌 종이/연필 가지고 구상하고..

운동은 아침에하고..

아.. 근데 주말에는 뭐하는지 안적혀있었다.. 설마 주말에도....???

 

 

 

 

반응형

+ Recent posts