Apache Storm 

스톰은 메세지전달 실패시 바로잡는 능력(fault tolerant) 이 있으며,  다양한 레벨의 메세지 보증 전f략을 가지고 있다. 

1. at-most-once:  이 모드에서는 만약 실패나 타임아웃이 발생했을때 메세지를 버릴수 있으며, 이 모드는 특별한 핸들링을 요구하지 않으며, 메세지들은 스파웃에 의해 생성된 순서대로 처리된다.
2. at-least-once:  이 모드는 각각의 스파웃 튜플이 설정된 타임아웃 안에서 "fully" 진행상태인지 아닌지를 추적한다. 어떤 인풋 튜플이 타임아웃 안에 fully 진행 상황이 아니면 다시 발행(re-emiited) 된다.  이 의미는 동일한 튜플이 한번 더 진행될 수 도 있다는 이야기 이며, 순서가 바뀔 수 도 있다. 
3. exactly-once: Trident 와 함께 사용될때, 스톰은 " exactly-once" 보증을 제공한다. 

읽을꺼리 : Exactly-Once Processing with Trident - The Fake Truth

Apache Kafka 

How do I get exactly-once messaging from Kafka?

Exactly once semantics has two parts: avoiding duplication during data production and avoiding duplicates during data consumption.

There are two approaches to getting exactly once semantics during data production:

1. Use a single-writer per partition and every time you get a network error check the last message in that partition to see if your last write succeeded
2. Include a primary key (UUID or something) in the message and deduplicate on the consumer.

If you do one of these things, the log that Kafka hosts will be duplicate-free. However, reading without duplicates depends on some co-operation from the consumer too. If the consumer is periodically checkpointing its position then if it fails and restarts it will restart from the checkpointed position. Thus if the data output and the checkpoint are not written atomically it will be possible to get duplicates here as well. This problem is particular to your storage system. For example, if you are using a database you could commit these together in a transaction. The HDFS loader Camus that LinkedIn wrote does something like this for Hadoop loads. The other alternative that doesn't require a transaction is to store the offset with the data loaded and deduplicate using the topic/partition/offset combination.

I think there are two improvements that would make this a lot easier:

1. Producer idempotence could be done automatically and much more cheaply by optionally integrating support for this on the server.
2. The existing high-level consumer doesn't expose a lot of the more fine grained control of offsets (e.g. to reset your position). We will be working on that soon

읽을꺼리 :  Kafka Clients (At-most-once, At-least-once, Exactly-once, and Avro Client)

Spark Streaming

Fault-tolerance Semantics

In this section, we will discuss the behavior of Spark Streaming applications in the event of failures.

Background

To understand the semantics provided by Spark Streaming, let us remember the basic fault-tolerance semantics of Spark’s RDDs.

1. An RDD is an immutable, deterministically re-computable, distributed dataset. Each RDD remembers the lineage of deterministic operations that were used on a fault-tolerant input dataset to create it.
2. If any partition of an RDD is lost due to a worker node failure, then that partition can be re-computed from the original fault-tolerant dataset using the lineage of operations.
3. Assuming that all of the RDD transformations are deterministic, the data in the final transformed RDD will always be the same irrespective of failures in the Spark cluster.

Spark operates on data in fault-tolerant file systems like HDFS or S3. Hence, all of the RDDs generated from the fault-tolerant data are also fault-tolerant. However, this is not the case for Spark Streaming as the data in most cases is received over the network (except when fileStreamis used). To achieve the same fault-tolerance properties for all of the generated RDDs, the received data is replicated among multiple Spark executors in worker nodes in the cluster (default replication factor is 2). This leads to two kinds of data in the system that need to recovered in the event of failures:

1. Data received and replicated - This data survives failure of a single worker node as a copy of it exists on one of the other nodes.
2. Data received but buffered for replication - Since this is not replicated, the only way to recover this data is to get it again from the source.

Furthermore, there are two kinds of failures that we should be concerned about:

1. Failure of a Worker Node - Any of the worker nodes running executors can fail, and all in-memory data on those nodes will be lost. If any receivers were running on failed nodes, then their buffered data will be lost.
2. Failure of the Driver Node - If the driver node running the Spark Streaming application fails, then obviously the SparkContext is lost, and all executors with their in-memory data are lost.

With this basic knowledge, let us understand the fault-tolerance semantics of Spark Streaming.

Definitions

The semantics of streaming systems are often captured in terms of how many times each record can be processed by the system. There are three types of guarantees that a system can provide under all possible operating conditions (despite failures, etc.)

1. At most once: Each record will be either processed once or not processed at all.
2. At least once: Each record will be processed one or more times. This is stronger than at-most once as it ensure that no data will be lost. But there may be duplicates.
3. Exactly once: Each record will be processed exactly once - no data will be lost and no data will be processed multiple times. This is obviously the strongest guarantee of the three.

Basic Semantics

In any stream processing system, broadly speaking, there are three steps in processing the data.

1. Receiving the data: The data is received from sources using Receivers or otherwise.

2. Transforming the data: The received data is transformed using DStream and RDD transformations.

3. Pushing out the data: The final transformed data is pushed out to external systems like file systems, databases, dashboards, etc.

If a streaming application has to achieve end-to-end exactly-once guarantees, then each step has to provide an exactly-once guarantee. That is, each record must be received exactly once, transformed exactly once, and pushed to downstream systems exactly once. Let’s understand the semantics of these steps in the context of Spark Streaming.

1. Receiving the data: Different input sources provide different guarantees. This is discussed in detail in the next subsection.

2. Transforming the data: All data that has been received will be processed exactly once, thanks to the guarantees that RDDs provide. Even if there are failures, as long as the received input data is accessible, the final transformed RDDs will always have the same contents.

3. Pushing out the data: Output operations by default ensure at-least once semantics because it depends on the type of output operation (idempotent, or not) and the semantics of the downstream system (supports transactions or not). But users can implement their own transaction mechanisms to achieve exactly-once semantics. This is discussed in more details later in the section.

Semantics of Received Data

Different input sources provide different guarantees, ranging from at-least once to exactly once. Read for more details.

With Files

If all of the input data is already present in a fault-tolerant file system like HDFS, Spark Streaming can always recover from any failure and process all of the data. This gives exactly-once semantics, meaning all of the data will be processed exactly once no matter what fails.

With Receiver-based Sources

For input sources based on receivers, the fault-tolerance semantics depend on both the failure scenario and the type of receiver. As we discussed earlier, there are two types of receivers:

1. Reliable Receiver - These receivers acknowledge reliable sources only after ensuring that the received data has been replicated. If such a receiver fails, the source will not receive acknowledgment for the buffered (unreplicated) data. Therefore, if the receiver is restarted, the source will resend the data, and no data will be lost due to the failure.
2. Unreliable Receiver - Such receivers do not send acknowledgment and therefore can lose data when they fail due to worker or driver failures.

Depending on what type of receivers are used we achieve the following semantics. If a worker node fails, then there is no data loss with reliable receivers. With unreliable receivers, data received but not replicated can get lost. If the driver node fails, then besides these losses, all of the past data that was received and replicated in memory will be lost. This will affect the results of the stateful transformations.

To avoid this loss of past received data, Spark 1.2 introduced write ahead logs which save the received data to fault-tolerant storage. With thewrite ahead logs enabled and reliable receivers, there is zero data loss. In terms of semantics, it provides an at-least once guarantee.

The following table summarizes the semantics under failures:

With Kafka Direct API

In Spark 1.3, we have introduced a new Kafka Direct API, which can ensure that all the Kafka data is received by Spark Streaming exactly once. Along with this, if you implement exactly-once output operation, you can achieve end-to-end exactly-once guarantees. This approach (experimental as of Spark 1.6.1) is further discussed in the Kafka Integration Guide.

Semantics of output operations

Output operations (like foreachRDD) have at-least once semantics, that is, the transformed data may get written to an external entity more than once in the event of a worker failure. While this is acceptable for saving to file systems using the saveAs***Files operations (as the file will simply get overwritten with the same data), additional effort may be necessary to achieve exactly-once semantics. There are two approaches.

• Idempotent updates: Multiple attempts always write the same data. For example, saveAs***Files always writes the same data to the generated files.

Transactional updates: All updates are made transactionally so that updates are made exactly once atomically. One way to do this would be the following.

• Use the batch time (available in foreachRDD) and the partition index of the RDD to create an identifier. This identifier uniquely identifies a blob data in the streaming application.

• Update external system with this blob transactionally (that is, exactly once, atomically) using the identifier. That is, if the identifier is not already committed, commit the partition data and the identifier atomically. Else, if this was already committed, skip the update.

  dstream.foreachRDD { (rdd, time) =>
    rdd.foreachPartition { partitionIterator =>
      val partitionId = TaskContext.get.partitionId()
      val uniqueId = generateUniqueId(time.milliseconds, partitionId)
      // use this uniqueId to transactionally commit the data in partitionIterator
    }
  }

읽을꺼리 :  Spark Streaming vs Storm Trident 

다른 읽을꺼리 
High-throughput, low-latency, and exactly-once stream processing with Apache Flink

1. 생산자 (Sender) 테스트 

   1. 결과 
      
   2. 이유
      1. 카프카 생산자는 브로커로 부터의 ack 를  기다리지 않고 메세지를 보낸다.브로커가 핸들링 할수있는 만큼 빠르게 메세지를 마구 보낸다.
      2. 카프카는 좀더 효율적인 저장소 포맷을 가지고있다. 평균적으로 카프카 각 메세지들은 9byte 의 오버헤드를 가지며, 반면 ActiveMQ 에서는 144 bytes 를 가진다. 이것은 메세지 헤더때문인데  JMS 에 의해 요구되어진것과 다양한 인덱싱구조를 유지하기위한 것이다. LinkedIn 은 관찰하길  ActiveMQ 의 가장 바쁜쓰레드는 메세지 메타데이터와 상태를 유지하기위한 B-Tree 에 접근하기위해 대부분의 시간을 소비하는것을 발견했다.
         
         

소비자 (Receiver) 테스트

1. 결과

   
Reason
1. 카프카는 좀더 효율적인 저장소 포맷을 가지고있다. 브로커로부터 컨슈머로 데이터 이동시 아주 적은 바이트만 소비된다.
2. ActiveMQ 와  RabbitMQ 의 브로커는  모든 메세지에 대한 전달 상태를 유지해야한다. LinkedIn 팀은 ActiveMQ 쓰레드들 중 하나를 관찰했는데  KahaDB 페이지를 디스크에 쓰는데 매우 바쁜걸 발견했다.  대조적으로 카프카 브로커상에서는 디스크 쓰기 행위가 없다. 결론적으로 파일에 쓰는 API 를 사용하는것에 의해 카프카는 데이터이동에 관한 오버헤드를 감소시킬수있던것이다.

레퍼런스)

http://mungeol-heo.blogspot.kr/2015/01/kafka-vs-rabbitmq-vs-activemq.html  
http://prismoskills.appspot.com/lessons/System_Design_and_Big_Data/Chapter_12_-_RabbitMQ_vs_Kafka.jsp
http://prismoskills.appspot.com/lessons/System_Design_and_Big_Data/Chapter_12_-_RabbitMQ_vs_Kafka.jsp
https://suniphrase.wordpress.com/2015/05/07/messaging-system-comparison-kafka-vs-rabbitmq-vs-activemq/

Friday, January 2, 2015

역주: 메세지큐에 대한 글을 적기 전에 왜 메세지큐냐? 를 먼저 생각해봐야한다.

Hello World!

Work Queues

Distributing tasks among workers (the competing consumers pattern) (워커에게 하나씩 균등히 나누어 준다)

Round-robin dispatching

Fair dispatch

* 메세지를 하나의 큐에 보내면 , 소비자들이 나누어갖는데, 시간배분을 해준다. (위처럼 라운드로빈이라면 홀수로 받는 워커에 일이 가중될수도있다. 홀수로 보내지는 일이 항상 많을경우) 

Publish/Subscribe

Sending messages to many consumers at once (모든 소비자에게 다 준다) 

Exchanges

 * Exchanges 를 통해 여러개의 큐에  보낸다.  

 * 워커큐와 다른점은 워커큐는 항상 하나의 메세지는 하나의 컨슈머만 받을수있다는것이고, 

   생산자/소비자 패턴에서는 하나의 메세지를 여러 워커가 받을수있다라는 점. 

Bindings

Putting it all together

Routing

Receiving messages selectively (원하는 것을 가져가게 한다)

Direct exchange

Multiple bindings

Putting it all together

Receiving messages based on a pattern (topics) (특정 패턴에 기반해 나누어 가진다) 

Topic exchange

RPC

Request/reply pattern

레퍼런스: https://www.rabbitmq.com/getstarted.html  

MQTT 시작하기 좋은 글 

https://dzone.com/refcardz/getting-started-with-mqtt

MQTT 란?

(http://www.codejs.co.kr/mqtt-mq-telemetry-transport%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0/ 펌)

Mosquitto (http://mosquitto.org/) 

모스키토는 MQ Telemetry Trasport  프로토콜 버전 3.1 과 3.1.1 을 구현한 오픈소스 메세지브로커이다. MQTT 는 생산자/소비자 모델을 사용한 메세지 이동에 관한 가벼운 메소드를 제공한다. 이것은  저전력 파워센서 나 모바일 디바이스 , 임베디드 컴퓨터나 아두이노 마이크로 컨트롤러  같은 "디바이스 to 디바이스 " 간의 메세징을 처리하기에 적합하다. 

관련 내 블로그 글 

http://brad2014.tistory.com/389

실제 빅데이터 플랫폼 속의 위치 (http://brad2014.tistory.com/185)

저는 최근에 사물인터넷 플랫폼에 대해 살펴보는 중에 OSGi 에 대해서 좀 더 관심을 갖게되었습니다. (예전에 이클립스 플러그인 책에서도 쳐음 접하고..) OSGi 는 얼핏 보기에 JNDI 가 제공하는 리소스투명성 및 컴포넌트 베이스 기반 방법론을 합쳐놓은 느낌입니다. 당연하지만 예전부터 많은 컴포넌트 조립 기술(CORBA, COM+) 들이 난립해 왔기 때문에 각각 기술들의 테두리가 분명할리는 없겠지요.  2008년에 쓰여진글이라 좀 됬지만 OSGi 가 궁금하신분은 아래 번역글을 통해서 첫인사를 해보시길 바랍니다. 딱히 OSGi 가 궁금하지 않더라도 옛날얘기 들려주듯이 작성된 IT 선배의 개발 모델 이야기는 충분히 재미있을것입니다. ( 2020년 현재 업데이트:  참고로 자바 9버전의 모듈리티를 이용하면 좀 더 편하게 모듈화를 할 수 있습니다. 그렇다고 OSGi를 대체하진 못합니다. 가장 큰 부분이 자바9 모듈리티는 컴파일 타임에 적용되며, OSGi는 런타임에 설치/업그레이드/제거 까지 할 수 있습니다. 쓰임새에 따라서 달리 사용되거나, 혼용해서 사용 될 수 있을 것 입니다. )

원글 링크 : https://queue.acm.org/detail.cfm?id=1348594

* 번역에 심각한 오역이 있거나, OSGi 에 대한 정보를 공유해주시면 더욱 이 글을 번역한 보람이 있을것입니다. 감사합니다. 

OSGi 가 어떻게 내 삶을 바꾸어 놓았나  

1980년 초반 나는 OOP (object-oriented programming)  를 알게되었으며  홀딱  빠져서 사랑하게 되었다.보통 이런 종류의 사랑은 이 새로운 기술에 투자하기 위해 경영진을 설득시킨다는걸 의미한다. 그리고 무엇보다 중요한것은 쩌는 컨퍼런스에 가볼수있게 된다는 것이다. ㅎㅎ 그래서 나는 상관에게 이 기술의 장미빛 미래에 대한 썰을 풀었다. 어떻게 하루만에 이미 존재하는 클래스들로부터 어플리케이션을 만들수있는지~ 클래스들을 저장소(repository) 로부터 가져와서 그것들을 조합하고 뚝딱똑딱 거리면 새로운 어플리케이션이 쑴풍쑴풍 생겨난다고...

오늘날 우리는  당연히 객체들을 사용한다. 그러나 솔직히 말하자면 1985년에 내가 상관에게 했던 장미빛 이야기는 실제로 구체화 되지 않은거 같다. 객체의 재사용은 결코 사람들이 예견한 수준을 넘지 못했고 여전히 레고 이론은 추구해야 할 경배의 대상이며 다다를수없는 성배와 같다. (역주: 2020년 현재도 요원하다. 다행이 JSON-HTTP가 대세가 됬는데 역시 쉬운게 먹힌다는 걸 방증한다. COM+, 웹서비스,SOA 다 대중성과는 멀다.) 

우리가 필요한것

늦은 90년대, 에릭슨연구소에서 일하는 동안, 나는 레고이론을 탐구할 기회가 생겼다. 홈 오토매이션에 대한 소프트웨어 표준화 작업에 참여하게되었는데 이 작업은 IBM, 에릭슨, 노텔, 사이베이스, 썬, 프랑스 텔레콤, 모토롤라, 필립스등 여러 회사들의 참여하에 시작되었고 그 회사들은 나중에 OSGi 얼라이언스 (오픈 동적 컴포넌트 플랫폼을 진행하기위한) 가 되었다. 우리가 1999년에 직면한 핵심 문제점은 어떻게 여러 임베디드 컴퓨터들 사이에 여러 밴더들의 어플리케이션들이 신뢰성 있게 리소스를 공유하며 함께 작동 할 수 있는지 였다. 간단한 말처럼 들리지만 , 집에는 여러 디바이스들이 연결된 다양한 종류의 네트워크로 이루어져있다. 고로 어플리케이션이 각각 다른 리소스와 기능을 재사용할수있는 모델이 필요하다는것은 처음부터 자명한 일이었다. 

여러 어플리케이션들이 각각 그것의 드라이버들과 라이브러리를 포함하게 강제하는 모델은 알맞지 않다. (예컨데, 오늘날 자바 폰 소프트웨어가 작동하는 방식)  또한 패쇄적인 API 셋도 마찬가지인데 , 타겟 마켓(역자: 스위치,계량기,수많은 센서들) 의 다양성이 너무 크기 때문이다. 더 중요한점은 우리는 이런 어플리케이션들이 서로에 대한 선행지식 없이 어울려지길 바랬던 것이다. 추가적으로 간편한 플러그인 방식이길 바랬다. 새로운 기능 추가를 위해 홈 서버를 내려야만 하는것은 그닥 매력적이지 않다. 1999년에 OSGi 얼라이언스가 출범한것을 상기시켜보면 윈도우95가 주류였는데 기술그룹에서 우리들은 약간의 설정만 바꿔도 PC 가 재부팅되는것에 질려있었다. "No reboot" 는 일찍부터 우리의 경구(mantra)가 되었다.또 다른 경구는 OSGi 얼라이언스 멤버회사들이 크고 작은 범위에서 그들 자신의 방법대로 스펙을 구현 할 수 있다는 것이다. 즉  여러 공급자들로 부터 온 각각의 부분들이 콜라보레이션이 될 수 있어야 한다는 것이다. 

그런 환경에서 보안은 옵션이 아니다. 시작부터 명확해야한다. 보안은 아키텍쳐안에서 구축되어져야한다. 다른 신뢰레벨을 가진 여러 리소스로 부터 어플리케이션을 실행하는 능력은 중요한 요구항목이다. 우리는  퍠쇄 시스템, 벽으로 둘러쌓인 정원, 완전하게 개방적인 시스템 등을 충분히 지원해야한다.

홈서버를 위한 환경선택은 우리가 해야할 첫번째 결정 사항이었다. 이것은 그렇게 힘들지 않았는데 자바는 경쟁자가 없었으며 선 마이크로시스템즈( Object-Oriented 언어로 유명한 ) 는 OSGi 멤버였다. 그래서 자바는 다른 참가자들의 어떤 반대없이 무난히 선택되었다. 자바의 중요한 특징은 VM (가상머신) 아키텍쳐라는것인데 이것은 여러 다른 디바이스들의 스펙에 대한 지원을 쉽게 해주었다. 오늘날  VM 은  다양한언어 (PHP, Scala, Groovy, Ruby, Python, etc.) 를 선택할수있게 해주며 심지어 다양한 하드웨어에서 실행된다. 

객체 얽김 (Entanglement)

저 시기에 객체들은 사용할 만 은 했었지만 그것들의 재사용성은 객체 얽김 문제 때문에 한계가 있었다. 많은 소프트웨어 개발자들은 절망적인 느낌을 받았는데 어떤 경우냐 하면 class A 를 사용할때 , 그것이 라이브러리 B 를 끌어오고, 그것은 라이브러리C 를 필요로하고..괴롭게도 계속된다. 최근 OOP 에서 우리는 커플링에 대한 주의력 없이 캡슐화에 대해 열광하였다. 흥미롭게도 OO 의  전임자는 구조적 프로그래밍이었는데 , 그것의 경구는 "낮은 커플링" "높은 응집력" 이었다. 내가 예상하길 우리는 상속성, 폴리모피즘, 기타 객체지향 신상품들 때문에 매우 바빠질것이라고 봤다.그러나 1998 년에 홈오토매이션 어플리케이션을 위한 자바프레임워크는 클래스들 특성 보다는 커다란 응집도/조밀도 (granularity) 의 크기를 가진 무언가를 요구했었다. 

우리에게 필요한것은 컴포넌트 프레임워크였다. 강건하고 신뢰성있으며 동적으로 컴포넌트들을 관리할수있는 그런 프레임워크 말이다. 우리는 새로운 컴포넌트를 완전히 동적으로 리부팅없이 인스톨 / 시작,멈추기 /  언인스톨 할수있기를 원했다. 만약 컴포넌트 A 가 컴포넌트 B 를 사용한다면 이런 의존성은 관리되야하며 , 컴포넌트가 시작되었을때 예외와 함께 발견되면 안된다. 컴포넌트간에는 서로를 발견할 필요가 있다. 또한 우리는 리부트를 허용하지 않기때문에 그 컴포넌트들은 의존성이 사라질때 탐지를 해야한다. 이런 동적 작동을 하기위해서 우리는 서비스 모델이란 것을 개발했었다. 하나의 컴포넌트가 서비스 객체를 등록할 수 있게하는 것은 또 다른 컴포넌트가 그 서비스를 발견하고 바인딩 할 수 있다는것을 말한다. 만약 서비스가 사라지면 언바인딩도 되면서 말이다. 각각의 서비스는 반드시 그것의 행위를 기술하는 계약서(contract)를 가져야하며 이 아키텍처는 SOA  (service-oriented architecture) 라 불릴수있을것이다. - 이 용어가 인기를 얻기 전 이야기지만 -  오늘날의 대부분 유명한 SOA 와는 대조적으로 OSGi 모델은 웹서비스나 커뮤니케이션 층의 어떤 다른것을 요구하지 않는다. 

OSGi 서비스는 단지  POJO 이다.     

OSGi 스펙들 

썬은 환경을 제공할뿐만아니라, 우리에게 JES (Java Embeded Server) 라고 불리는 구현품을 제공한다. JES 는 자바 가상머신 실행시에 번들 (ZIP/JAR files)의 인스톨/언인스톨을 허용한다. 저것은 VM 은 여러 다른 어플리케이션들 사이에서 공유된다는 것을 말하며  번들은 좀 그저그렇지만 우리는 찾고있던 컴포넌라고 볼수있다. 그리고 개발자로서 품위를 지키기위해 그것을 발전시켜야 한다는 것을 느꼈고 그렇게 했다. - 광범위하게.  우리는 8년을 해왔으며 시계는 여전히 돌아간다. OSGi 스펙은 , 지금 현재 릴리즈 4,  꽤 성숙해있다. 2000년에 인터넷 광풍을 따라서 홈 오토매이션 마켓이 붕괴되었을때에도 (단지 릴리즈1이 나왔을때) ,OSGi 스펙은 전화,자동차,산업자동화등에 채택되었으며, 최근에는 OSGi 기술이 확대시키거나또는 무거운 J2EE 컨테이너 그리고 다른 어플리케이션 서버를 대체할수있는 엔터프라이즈 컴퓨팅 세계에서 꽤 유명하게 되었다. 

시스템 예시 : Idefix 

산업자동화는 내가 OSGi 테크놀러지에서 좋아하는 분야이다. 나는 자바와 임베디드 프로그래밍을 좋아한다. 운수없게도, 소비자 전자회사들은 BOM(원료구입서,재료사양서) 상에서 극단적인 시각을 가지고있으며, C,C++ 같은 언어들에서 더 높게 나오는 소프트웨어 개발 비용을 무시하는 경향이 있다. 이것은 종종 JAVA 꺼져를 의미하며 VM 라이센스는 비용을 지불해야하며 추가적인 CPU , 메모리 요구사항이 있다는것으로 말을 일삼는다.

소량 제작은 소프트웨어 비용을 더 심각하게 만들기 때문에 산업 자동화 마켓에서는 좀 문제이다. 예를 들어서 한 회사가 50십만 유로로 팔리는  Idéfix  라는 산업용 측정 디바이스를 생산한다고 말해보자.  (그것은 가상의 디바이스이지만 정보는 실제 제품/상황 으로부터 수집됬다. 비공개를 원했을뿐..)

Idéfix 는 많은 하드웨어 익스텐션을 가지고있는데, 그것들은 수송라인의 샘플을 위한것이다. 샘플들의 정확한 위치, 특별한 액체 투입, 정밀한 값이 필요한 복잡한 측정등이 필요하다. 명백히 그런 장치는 많은 수량이 팔리지않는다.  고객은 그들의 환경에 딱 맞추기 위해서 확장 커스터마이징을 요구한다.  소프트웨어 아키텍처는 유연성 및 그런 유지비용, 적응성 비용을 낮추기위해 포커싱을 맞추게 된다. 적응성(adaptations ) 이 이런 종류의 시장에 매우 중요한며 또 다른 중요한 요소는 원격관리 이다.

세계 무역시장은 점점 커지고있으며 Idéfix  같은 디바이스는 세계 어디에서나 필요하다. 이런 작은 규모의 판매량은 기술자가 고객 근처에서 원할한 서비스를 해주는것을 어렵게한다. 만약 어떤 문제가 생겼을때 이런 문제는 신뢰성에 큰 타격을 입히는데. 원격 진단 및 소프트웨어 업데이트는 그래서 매우 중요해진다.

Idéfix  는 과거 수년동안 OSGi 스펙을 가진 자바 기반의 방법론에 대한 아이디어를 가진 컨설턴트들과 협동 작업을 해왔다. OSGi 스펙들은 Idéfix 같은 장치들에 대한 요구사항과 굉장히 매치가 잘되는데. 동적 컴포넌트 모델을 제공함으로써 표준 고객 적응성,  하드웨어 아키텍처 확장, 원격관리, 복잡한 측정알고리즘같은 복잡한문제들을 단순화해준다. 플러그향 형태의 시스템이 필요할때 누구한테나 필요하지 않겠는가? 자바가 실시간형태의 디바이스에 사용될수있지만 Idéfix  아케텍처는 하드 리얼타임 코드를 메인 어플리케이션 코드로 부터 분리시켰다. 이 하드 리얼타임 형태는 보조 프로세서에의해 제공되게 하며 , 하드웨어 확장에 그 스스로 임베디드되던가 혹은 플러그인 카드와 함께 제공되게 했다. 하드 리얼타임 부분을 분리시키는것은 복잡하고 치명적인 문제들을 단순화시킬수있었다.

디바이스 드라이버 로딩 

Idéfix 의 디자이너는 1-wire 디바이스를 익스텐션을 구분하기위해 사용했다. 이 간단한 프로토콜은 파워라인같은 동일한 와이어상에서 작동할수있으며, 매우 쌌고 , 간단한 1-wire 디바이스의 네트워크는 지선(ground wire) 과 파워/프로토콜 와이어와 연결되었다. 각각의 1-wire 디바이스는 유니크한 64비트 주소를 가지고있으며 그 주소는 1-wire 프로토콜을 통해 발견되어질수있었다. 일단 익스텐션이 적절히 연결되면 , 1-wire 디바이스 안의 유니크 코드는 안착된 익스텐션의 타입을 감별하기위해 사용 될 수 있었다. 이런것들은 사실 OSGi  디바이스 엑세스 스펙 디자인에 대한 예인데, 이 스펙은 OSGi 동적 서비스 모델을 명쾌히 설명해준다. 

자 더 자세히 살펴보자.

1-wire 버스는 컨트롤러를 요구한다. 그 컨트롤러는 1-wire 디바이스가 네트워크상에 있는지 감지하는데 OSGi 시스템에서 이런 컨트롤러는 프로그램되었으며 그 자체로 번들인 베이스(base) 드라이버라는 것을 통해 관리된다. 베이스 라이버가 새로운 1-wire 디바이스를 감지하면 그것을 OSGi 서비스 레지스터리와 함께 1-wire 디바이스를 나타내는 서비스로 등록한다.OSGi 서비스는 단지 POJO 이며, 서비스 정보에 대한 속성셋을 가지고 있다. 이 경우 하나의 속성은 1-wire (USB,Firewire,RFID,Ethernet, Zigbee, Z-Wave 같은것도 마찬가지) 인 디바이스 카테고리를 나타내는데 또 다른 속성으로는 unique ID 가 있다. 이 경우 1-wire unique code 는 모든 1-wire 칩안에 임베디드되있다. 디바이스 엑세스 서브시스템은 특별한 디바이스 속성을 가지고있는 서비스가 등록되는것을 감지하며 OSGi 프레임워크로 부터 서비스가 등록되면 바로 고지를 받을것이다.

하나 또는 그 이상의 드라이버 위치 서비스들을 통해 번들들의 데이타베이스를 참고하기 위해 속성들을 사용한다. 그 드라이버 위치 서비스는 매칭된 드라이버 로케이션(URLs) 를 리턴하며, 디바이스 엑세스 서브 시스템은 프레임워크 안의 이런 번들들을 로딩할것이다. 물론 그들이 이미 존재한다면 말이다. 이런 드라이버 번들 각각은 드라이버 서비스를 시작할때 등록된다. 이런 드라이버 서비스는 드라이버의 적합성을 따지기위해 사용된다. 가장 적합한것은 드라이버 셀렉터 서비스에 의해 선택되며 그 드라이

버는 그 후에 디바이스 서비스에 붙여서 사용된다.  그 드라이버는 그리고나서 연결된 디바이스의 실질적인 기능을 반영한 새로운 서비스를 등록하는것을 통해 디바이스 서비스를 재구성(refine) 할것이다.

원형은 번들이고 삼각형은 서비스들 인 아래 그림은 각각의 진행사항을 나타낸다. 숫자는 액션의 순서이다.

예에서 , 다음 1-wire ID 를 갖는 디바이스는 : 

  67.4B.A7.CD.90.AA.1A.01 

5 센티미터 직경을 가진 샘플 트레이로 정재될수있다. 만약 1-wire 베이스 드라이버가 장착되지 않은 
디바이스를 검침하면 적합한 디바이스 서비스는 즉시 등록해제 될것이다. 
디바이스 엑세스 번들은 등록해제되었다고 고지받을것이며 , 셈플 트레이 서비스가 등록해제되게 할것이다.  
이 예제는 어떻게 이런 번들을 실제 디커플(decoupled) 시키는지 보여주며, 1-wire 리시버 베이스 드라이버는 
표준화된 디바이스 엑세스 번들을 인지하지 않거나 어떤 셈플 트레이 서비스에 대한 지식도 가지고있지 
않는다.

디바이스 엑세스 번들은 단지 디바이스 속성(properties )에 대해서만 알고있으며 1-wire 컨트롤러의 
베이스드라이버에 대한 어떠한 단서도 없으며 . 샘플 트레이에 대한 어떠한 특징도 알수없다. 
이런 세가지 컴포넌트가 알고있는 모든것은  단지 서비스들 이다. 
샘플 트레이를 위해 다르게 만들지 않았다. 만약 1-wire 컨트롤러 베이스 드라이버 번들이 
소프트웨어 업데이터나 샘플 트레이가 제거되었다고 해도 멈추지 않는다.

양쪽 이벤트는 동등하게 다루어지며 이러한 서비스레지스트리를 통한 디커플링 패턴은 OSGi 디자인패턴의 핵심이다.디바이스 드라이버번들을 인스톨링하는것은 꽤나 직설화법처럼 들리는데, 실제적으로 OSGi의 많은 부분에서 모듈레이어에 의해 구성된다.  그것은 VM 안에서 번들을 관리하는 책임이 있다. 중요한 문제는 이러한 번들들이 클래스들과 리소스를 공유한다는것이다. 즉 하나의 번들은 다른 번들로부터 클래스들을 임포트 할수있다는것이다. 컴퓨팅 세상에서 공유는 어렵다..

자바 모듈화 

다른 번들들은 다른 클래스 공간에 속할수있다. 그러나 동시적으로 같은 VM 안의 존재하기위해  같은 어플리케이션이나 라이브러리의  다른 버전을 따른다 (허용한다) . OSGi 프레임워크는 자동적으로 다른 클래스 공간들안의 번들들을 분리한다. 그래서 그들은 충돌하지 않게된다. 클래스 공간을 관리하는 동안에 익스포트들을 위해 임포트들을 풀어내는것(Resolving) 은 매우 어려운 문제인데 각 가능한 케이스에서 해결책을 보장할수가 없다. 이 리졸빙 알고리즘은 OSGi 스펙에서  구현자들이  혁신적인 해결책을 찾기위해 자유롭게 연구중인 아주 자그마한 영역중에  하나이다.    운좋게도 번들 개발자들은 완전히 이런 어려운 문제로부터 보호받고있다. 이런 모든 복잡성은 쉽게 사용가능한 API 로부터 감춰져있으며 , 우리의 예제에서는 드라이버 번들은 오직  OSGi 프레임워크이 적합한 번들을 찾을수있게하는  URL 을 제공할뿐이다. 그 번들은 파일 시스템, 웹 서버, 데이타베이스 및 Java URL 을 가진 어떤 위치에나 거주지를 마련할수있게된다. 번들은 ZIP 파일들이고 , 그러므로 자바코드 이상의 것을  포함할수있다. 내포적 (introspective 역주: 스스로를 설명할수있는 )이고 중요한 시간에 이벤트를 발생시키는  잘 정의된 라이프싸이클와 함께 그것을 사용하라. 너는 단지 디바이스를 위한 자바 코드가 아니라 컨텐트를 가져다주기위한 시스템을 가지고있다.  Idéfix 에서 보조프로세서위에서 돌아가기위해 필요한 코드를 예로들어서 갖는다. 이런 코드를 인스톨링하는 일은 어쩌면 디바이스 드라이버의 몫이 될수있는데 그러나 모든 다른 디바이스에게 매우 유사한 코드가 될수있다. 또한 신뢰성의 이유로서 , 또 다른 번들이 모든 보조프로세서들을 위해 이 코드를 관리한다면 더 나을것이다.

그러므로 Idéfix  장치는 인스톨이 필요할때  특별한 디렉토리에서 찾을수있는 번들을 가진다.(고지는 라이프 사이클 이벤트 동안 보내어진다)  만약 이 디렉토리가 보조프로세서를 위해  코드 이미지를 포함한다면, 이 번들은 자동적으로 그것을 인스톨할것이다. 만약 번들이 업데이트되었다면, 그 보조프로세서상의 이미지는 따라서 업데이트 될것이다.  만약 번들이 언인스톨되면, 그 코드는 보조프로세서(auxiliary processor) 로부터 제거될것이다. 또 다른것에 번들의 (관리되는) 라이프 사이클을 매칭하는것은 매우 유명한데 extenders 이라는 이름을 가지고있다. Extenders  는  help resources, install database tables, provide Web services 이런것들을 등록하기위해 사용된다. 

서비스 지향 비지니스 모델 

만약 고객이 counters  를 리셋할수있거나 , 비 인가된  방식으로 장치를 사용할수있다면 , 그 제조회사는 돈을 읽게되겠지..결국 보안 모델은 매우 중요하다. OSGi 보안모델은 번들과 함께 시작한다. 번들은 X.509 증명서를  사용한 인증을 위해 공용키/개인키를 사용하여 서명될수있다. 우리가 작은 별도의 룰을 세팅해야할지라도 , 이것은 자바에 의해 제공되는 기본적인 모델이다. 자바 보안 모델의 중요한 문제는 모델이 높은 복잡도(fine granularity)를 가지고있기때문에 만들어지는 설정관리 문제이다. 

( 역주: Granularity에는 Coarse-Grained와 Fine-Grained라는 개념이 있다. 이는 서로 반대되는 개념으로써 전자는 보다 더 뭉쳐져있는 정도를 말하고 후자는 보다 잘게 잘게 쪼개져있음을 의미한다.) 자바 시큐리티를 관리하기 시도하는것은 매우 어렵다.  

많은 시스템들이 끝내 2가지 정적 레벨을 가지게되었는데 "보안하지 않거나, 모두 허용  ㅡ.ㅡ;; "OSGi 는  보안 매니지먼트를 번들기반의 깔쌈한 모델을 제공하여 간소화한다. 각 번들은 승인(permission) 셋을 가지고있고 그것은 컨디셔널 승인 관리자 서비스가 사뿐사뿐 돌아다니며 바꿀수있다. 게다가 각 번들은 허가설정(permission) 파일을 포함하며 번들이 환경으로부터 얻은 승인설정을 더욱더 제한할수있다. 그 아이디어는 서명자는 그들이 사인하기전에 번들의 보안스코프를 확인할수있게하는것이다. 이 모델은 보안 퍼미션들의 관리가 복잡한 문제일지라도 그것을  다루는것을 꽤 단순화해준다. 

OSGi and Open Source

Another advantage that made Idéfix easy to sell to the software developers is Eclipse, a free open source development environment. The developers at Eclipse had originally created their own plug-in model, but in 2003 they were looking for a more dynamic model. After evaluating several modularity systems, OSGi technology came out on top (OK, it might have helped that I was part of the team). The Eclipse team then did an amazing job of open-heart surgery by removing the old plug-in engine, replacing it with a brand new framework compatible with OSGi, and creating a compatibility layer that made all existing plug-ins compatible with the new system. To top it off, Eclipse provided an excellent environment in which to develop bundles. Though it is not a key requirement, there is definitely synergy if bundles for a device can be developed and tested in the same environment as your desktop. This is a key advantage of OSGi and why we sometimes call it universal middleware. Properly designed bundles run almost anywhere.

Idéfix’s architecture allowed for a lot of use of open source projects. For the OSGi framework, Idéfix chose Apache Felix, one of the key open source OSGi implementations. It also used bundles from Knopflerfish (an open source project with commercial backing) and Equinox (the Eclipse OSGi implementation). These projects implement most of the service specifications of OSGi release 4. Idéfix could also have chosen from one of the commercial implementations available from companies such as Makewave, ProSyst, IBM, and others.

Unfortunately, not all Java-based open source projects provide the right metadata for OSGi frameworks, even though the necessary headers are quite easy to add when a project is built with make, ant, maven, or the bnd tool. These headers do not cause any overhead or problems when the JARs (Java archive files) are used without OSGi. We hope that the increasing adoption rate of OSGi in our industry will help improve this situation dramatically in the next year. In the meantime, there are two projects, one in Eclipse and one in Apache Felix, that provide bundle-ized JARs for many open source software projects.

Application Programming Models

One of the great software insights of the past decade is the concept of a POJO. POJO-style programming means that we write Java code that is coupled to the Java environment but not to a specific container. We have learned the hard way that coupling our application logic to a framework is a bad idea because it locks us in. We always need some code that bridges our container with the POJO, however. This code injects any dependencies into the POJO so it can remain oblivious to where those dependencies come from. Though the OSGi framework is lightweight, it is also some kind of container and the same rules therefore apply.

Several application frameworks based on dependency injection have been developed to allow POJO programming in an OSGi environment. These frameworks hide the complexity of the dynamic dependencies, add extra layers such as transactions and remoting transparently, and simplify programming of the application logic.

The OSGi Alliance specified the declarative services application model for the release 4 service platform. The declarative services model is a small but effective dependency injection model based on the OSGi service model. Apache Felix took an interesting approach with iPOJO. This model reduces many programming chores by analyzing the bytecodes and inferring the intentions for many common tasks.

The best-known application programming model for OSGi is Spring. SpringSource, the Spring guardian, extended the Spring bean configuration model to connect to the dynamic OSGi services. This turned out to work extremely well because Spring and OSGi had little overlap and were extremely complementary. Spring-OSGi is highly popular in the enterprise software market at the moment. In the near future, the SCA (Service Component Architecture), an effort from OASIS with all the major players in the enterprise software market, will map SCA to OSGi, a promising combination.

Five different programming models, and counting, is quite a lot for a technology such as OSGi, because the collaboration among these models could be severely impaired. All these application models, however, use the OSGi service registry at the base. Through the registry, a Spring-OSGi application works seamlessly with an iPOJO application or a declarative services application. Developers can therefore choose which model provides the best solution for them but still reuse components written in other application models.

Reflecting

The future of the OSGi technology looks pretty rosy. It is a mature standard, proven in many markets, has many implementations, and has shown to scale well. It provides the foundation for a true universal middleware standard that could have a huge impact in our industry, if we can explain the technology to a wider audience.

We have done the groundwork, but we are far from finished. We need more companies that are willing to take the standard in different directions so we can get closer to fulfilling the promises of the Lego hypothesis: a model where components are wired together to create advanced applications. On that day, I can finally say that my original pitch to my manager has come true.

PETER KRIENS is the OSGi director of technology and CEO of aQute. He has worked as consultant for a large number of international companies introducing object-oriented techniques. In 1994 he moved to Sweden to work for Ericsson. In 2001, he was hired part-time by OSGi to act as its technical director. His responsibilities include editing the specifications and serving as the OSGi evangelist.

1. JNDI 왜  사용하나? 

JNDI 의 역할을 이해하기위해  "JNDI 가 없다면 어떻게 해야하는지"  를 먼저 보고  JNDI 를 사용하는것에 대해 살펴보자. 

JNDI 없이 

MySQL 데이타베이스에 접근하기위한 어플리케이션을 개발할때,  MySQL JDBC 드라이버 클래스를  참조하기위해 

해당되는 JDBC URL 를 사용하는데 대략 다음과 같다.

Java code 

이것은 전통적인 접근방법이며 , 다른 언어개발자들에게도 일반적인 방법이다. 이 접근법은 일반적으로 작은규모의 개발

 프로세스에 적합하며  자바언어에 익숙하기만하면 어플리케이션을 금방 만들수있는 장점이 있다. 

JNDI 식 접근 

1. 데이타베이스 서버이름 MYDBSERVER/사용자이름,비밀번호/ 바꿀필요가 있을때라든지 JDBC URL 을 수정할필요가 있을때

2. 데이타베이스가 다른것(DB2, Oracle등) 으로 바뀔수있을때

3. JDBC 설정이 바뀔필요가 있을때 (커넥션 풀 파라미터등등) 

해결책 : 

프로그래머는 데이타베이스 백그라운드에서의 특별한 세팅에 대해 신경쓰게 하고 싶지 않다. 데이타베이스 관리자가 

진두지휘하고 프로그래머는 그냥 가져다 쓰게하고싶다.

그럴때 JNDI 가 있다.

우선 J2EE 컨테이너에 JNDI 파라미터를 설정하고, 데이타소스등을 정의한다. JBoss 에서의 예를 보자

2 . 소스에서 사용하기 

시스템에 대해 배포후에 , 만약 데이타베이스 관련된 파라미터가 바뀔때 오직 mysql-ds.xml 설정만 바꿔주면 된다.

소스코드를 바꿀필요없이  아마 그것만 하는 관리(개발)자를 두면 그사람이 알아서 회사(제품)방침에 따라서 조작 할것이다.

JNDI 는 프로그램과 데이타베이스간에 타이트하게 묶여있는 커플링을 피하게 해주며, 쉽게 설정,배포하게해준다.

3. 관련 이미지 

위의 예는 DB 에 접근하기위한 방법에 대한 예이지만, 모든 리소스들에 대해서도 투명화하기위하면 사용할만하겠다. 

예를 들어서  밴더별 컴포넌트, 디바이스 드라이버, 환경설정등등..

근데 요즘 OSGi 도 살펴보는중인데 OSGi 는 JNDI 의 특성(위치투명성)과 기존 컴포넌트베이스개발방법론이 합쳐진거

같은 느낌을 받았다.

2. JNDI 모습들과 환경설정에 관하여

환경 설정에 관한 이야기들 

웹로직/톰캣 서버가 부팅시에 JNDI 객체를 등록합니다.

JNDI 서버의 실제 구현 기능은 각 Application Server의 Vendor (톰캣, 웹로직같은) 가 제공함

JNDI 서버 단독실행 가능함 : http://meri-stuff.blogspot.kr/2012/01/running-jndi-and-jpa-without-j2ee.html

간단한 JNDI 서버 : https://code.google.com/p/osjava/wiki/SimpleJNDI

레퍼런스:

http://www.databaseskill.com/216815/

https://thrift.apache.org/

아파치 쓰리프트 프레임워크는 다양한 언어로 서비스되며 , 효율적인 코드생성엔진을 갖고 소프트웨어 스택을 묶으며 다음과 같은 다양한 언어들을 지원한다  C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi and 기타등등.

시작하기 

• Apache Thrift 다운로드 

  To get started, download a copy of Thrift.

• Apache Thrift compiler 빌드/인스톨

  You will then need to build the Apache Thrift compiler and install it. See the installing Thrift guide for any help with this step.

•  .thrift 파일 작성 

  After the Thrift compiler is installed you will need to create a thrift file. This file is an interface definitionmade up of thrift types and Services. The services you define in this file are implemented by the server and are called by any clients. The Thrift compiler is used to generate your Thrift File into source code which is used by the different client libraries and the server you write. To generate the source from a thrift file run

              thrift --gen <language> <Thrift filename>
            

  The sample tutorial.thrift file used for all the client and server tutorials can be found here.

To learn more about Apache Thrift Read the Whitepaper

예제 

아파치 쓰리프트는 데이타타입 및 서비스 인터페이스를  간단한 정의파일안에 제공한다.파일을 통해 입력하면 

컴파일러는 교차언어간에 자연스럽게 통신할수있는  RPC 클라이언트/서버로  쉽게 사용되는 코드를 생성해준다. 

당신이 만든 객체를 이동하거나 직렬화 하기위해 행사코드를 쓰는 수고를 덜어주며, 원격메소드를 호출하여 당신이 

비지니스로직에만 집중할수있게한다.

다음 예제는 웹프런트엔드에 대해  유저객체를 저장하기위한 간단한 서비스를 보여준다.

쓰리프트 정의 파일 

service Calculator extends shared.SharedService {

  /**
   * 메소드 정의는 C 코드같다. 리턴타입 과 매개변수 , 예외를 가지고있다.
   * Note that argument
   * lists and exception lists are specified using the exact same syntax as
   * field lists in struct or exception definitions.
   */

   void ping(),

   i32 add(1:i32 num1, 2:i32 num2),

   i32 calculate(1:i32 logid, 2:Work w) throws (1:InvalidOperation ouch),

   /**
    * 단방향 콜로써 요청한후에 리턴받는걸 무시한다.
    */
   oneway void zip()

파이썬 클라이언트 

 # Make socket
  transport = TSocket.TSocket('localhost', 9090)

  # Buffering is critical. Raw sockets are very slow
  transport = TTransport.TBufferedTransport(transport)

  # Wrap in a protocol
  protocol = TBinaryProtocol.TBinaryProtocol(transport)

  # Create a client to use the protocol encoder
  client = Calculator.Client(protocol)

  # Connect!
  transport.open()

  client.ping()
  print 'ping()'

  sum = client.add(1,1)
  print '1+1=%d' % (sum)

자바 서버 

Initialize the Server:

    try {
      TServerTransport serverTransport = new TServerSocket(9090);
      TServer server = new TSimpleServer(new Args(serverTransport).processor(processor));

      // Use this for a multithreaded server
      // TServer server = new TThreadPoolServer(new TThreadPoolServer.Args(serverTransport).processor(processor));

      System.out.println("Starting the simple server...");
      server.serve();
    } catch (Exception e) {
      e.printStackTrace();
    }

This snippet was generated by Apache Thrift's source tree docs: tutorial/java/src/JavaServer.java

The CalculatorHandler:

public class CalculatorHandler implements Calculator.Iface {

  private HashMap<Integer,SharedStruct> log;

  public CalculatorHandler() {
    log = new HashMap<Integer, SharedStruct>();
  }

  public void ping() {
    System.out.println("ping()");
  }

  public int add(int n1, int n2) {
    System.out.println("add(" + n1 + "," + n2 + ")");
    return n1 + n2;
  }

  public int calculate(int logid, Work work) throws InvalidOperation {
    System.out.println("calculate(" + logid + ", {" + work.op + "," + work.num1 + "," + work.num2 + "})");
    int val = 0;
    switch (work.op) {
    case ADD:
      val = work.num1 + work.num2;
      break;
    case SUBTRACT:
      val = work.num1 - work.num2;
      break;
    case MULTIPLY:
      val = work.num1 * work.num2;
      break;
    case DIVIDE:
      if (work.num2 == 0) {
        InvalidOperation io = new InvalidOperation();
        io.what = work.op.getValue();
        io.why = "Cannot divide by 0";
        throw io;
      }
      val = work.num1 / work.num2;
      break;
    default:
      InvalidOperation io = new InvalidOperation();
      io.what = work.op.getValue();
      io.why = "Unknown operation";
      throw io;
    }

    SharedStruct entry = new SharedStruct();
    entry.key = logid;
    entry.value = Integer.toString(val);
    log.put(logid, entry);

    return val;
  }

  public SharedStruct getStruct(int key) {
    System.out.println("getStruct(" + key + ")");
    return log.get(key);
  }

  public void zip() {
    System.out.println("zip()");
  }

}

This snippet was generated by Apache Thrift's source tree docs: tutorial/java/src/CalculatorHandler.java\