要約002ーIoTでの課題

IoTでの課題

1. ゼロ-エントロピーシステム

ゼロ-エントロピーシステムは環境発電、エネルギーの保存、エネルギーの使用を含める。

エネルギーは重要な課題になり、どんな操作にでもロスにならなく環境から発電できるIoTシステムを開発するための研究は必ず行われる。

2. スケーラビ利ティ

IoTは多いな機器で構成される。

それは、すべての機器がメッシュに接続、まだ階層サーブドメインになることは不可能である。

相互連結くオブジェクトの数が現在のインターネットに数十倍多いである。

3. セキュリティとプライバシー

IoTインフラの中で多い機器が存在するように、限られた機能を持つ機器が十分のセキュリティがある問題には議論、説得力を持って解決されなければならない。

記述のアーキテクチャはこれからのどんな開発でも個人情報の保護を考慮すべきだ。

4. 相互運用性

IoTインフラの中で機器とサービスの間で相互運用性は重要な要素で考慮されるべきだ。

相互運用性は一貫性がある標準化のプラットホームとテスティングの方法論、そして便利なテスティングツールを含めてある。

標準化のプラットホームは一貫性を得るために必要である。

テスト仕様に基づいた標準化されたテスティングの方法論は、機器とサービスの有効性を確認する方法を指定する。

正確なテストスイートとテストツールは、機器とサービスの相互運用性を保証する。

IoTで、意味論的相互運用性は、内部情報システムが相違にもかかわらず、プロバイダーと要求者が意味のあるコミュニケーションをするために不可欠です。

5. 標準化と統合

IoTで、異機種の機器の多くが自律的な方法で通信と独自のネットワーク構成を再調整する。

このような理由で、標準的な周波数割り当て、放射電力レベルと通信規約が最も重要である。

標準は、機器の環境および監視、制御、サポートと関係があるオブジェクトの間で双方向通信と情報交換のために要求される。

したがって、IoT環境で共通の標準化と統合ソリューションが必要になる。


参照
Principle Elements and Framework of Internet of Things
V. Challenges in IoT
http://www.researchinventy.com/papers/v3i5/C35024029.pdf

要約001 - 易しく効率的な職員教育アイデア６項

易しく効率的な職員教育アイデア６項

１．上級者会議ダウンロード
　　下級者の個人別器量、知識、興味、経歴計画によって、管理者が持っている情報を提供するだけで立派な教育である。

２．情報、読書の推薦
本人の情報体系を注入しようとせず、個人別に特化された情報を説明及び推薦して、被教育者が消化出来るようにコーチングすることが正しいし、効率的である。

３．会議参席の調節
特定職員が本人と関係ない会議（適材適所、職員の時間管理尊重）へ参席するだけで教育の効果がある。

４．Ｌａｕｎｃｈ　＆　Ｌｅａｒｎ
軽い形でワークショップの性格で教務時間外の時間を使って教育をすることも一つの方法である。

５．出張おしゃべり
部下と出張を一緒に行く場合は教務以外の話をして被教育者の性向及び関心事を把握出来るので教育内容のアイディアの創出が可能である。

６．Ｖｅｎｄｏｒ　Ｉｎｆｏｒｍａｔｉｏｎａｌ　Ｓｅｓｓｉｏｎ
業務分野によって、サービスプロバイダが業務以外の情報提供をしてくれる場合がある。管理者が調整をよくすれば、外の世界がどのように動くか聞くことができる機会となる。

이것이 현실인가

일본에서 일을 시작한 지 이제 10일..

한국에서의 주먹구구식은 더 이상 없을거야

라고 생각한 내가 잘못된 것 같다

프로젝트 관리자가 날 찍었다

뭔가 보여줘야하는데 다 처음 써 보는 거라 늦게까지 하는 것 밖에

보여줄 게 없는 내 자신이 한심하다

차라리 잘 됐다

이 기회에 말라비틀어져 보자

문어대가리는 신경 끄고 내가 할 수 있는 것에 집중하자.

퇴근하는 전철에서...

스프링에서 mock사용하여 테스트하기

http://ddakker.tistory.com/m/post/307

Spring Framework Study 1일차

DAO (Data Access Object)
-> DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트를 말한다.

자바빈 (JavaBean)
-> 원래 비주얼 툴에서 조작 가능한 컴포넌트를 말한다. 자바의 주력 개발 플랫폼이 웹 기반의 엔터프라이즈 방식으로 바뀌면서 비주얼 컴포넌트로서 자바빈은 인기를 잃어갔지만, 자바빈의 몇 가지 코딩 관례는 JSP 빈, EJB와 같은 표준 기술과 자바빈 스타일의 오브젝트를 사용하는 오픈소스 기술을 통해 계속 이어져 왔다. 이제는 자바빈이라고 말하면 비주얼 컴포넌트라기보다는 다음 두 가지 관례를 따라 만들어진 오브젝트를 가리킨다. 간단히 빈이라고 부르기도 한다.

 - 디폴트 생성자 : 자바빈은 파라미터가 없는 디폴트 생성자를 갖고 있어야 한다. 툴이나 프레임워크에서는 리플렉션을 이용해 오브젝트를 생성하기 때문에 필요하다.

 - 프로퍼티 : 자바빈이 노출하는 이름을 가진 속성을 프로퍼티라고 한다. 프로퍼티는 set으로 시작하는 수정자 메소드(setter)와 get으로 시작하는 접근자 메소드(getter)를 이용해 수정 또는 조회할 수 있다.


관심사의 분리(Separation of Concerns)
변화가 한 번에 한 가지 관심에 집중돼서 일어난다면, 한가지 관심이 한 군데에 집중되게 하는 것이다.
관심이 같은 것끼리는 모으고, 관심이 다른 것은 따로 떨어져 있게 하는 것.

리팩토링 (Refactoring)
- 중복 코드의 메소드 추출 : 메소드 추출 기법 (extract method)
- 추천 책(리팩토링 : 마틴 파울러, 켄트 벡 공저)


템플릿 메소드 패턴(template method pattern)

팩토리 메소드 패턴(factory method pattern)

* 팩토리 메소드(factory method)

전략 패턴(Strategy Pattern)


SOLID - 로버트 마틴이 정리한 객체지향 설계 원칙
- SRP(The Single Responsibility Principle) : 단일 책임 원칙
- OCP(The Open Closed Principle) : 개방 폐쇄 원칙
  -> 클래스나 모듈은 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.
  -> 높은 응집도와 낮은 결합도(high coherence and low coupling)
- LSP(The Liskov Substitution Principle) : 리스코프 치환 원칙
- ISP(The Interface Segregation Principle) : 인터페이스 분리 원칙
- DIP(The Dependency Inversion Principle) : 의존관계 역전 원칙


1.4 제어의 역전(IoC, Inversion of Control)

팩토리
- 단지 오브젝트를 생성하는 쪽과 생성된 오브젝트를 사용하는 쪽의 역활과 책임을 깜끔하게 분리하려는 목적으로 사용하는 것이다.


つつく。。。

일본에서의 첫 프로젝트 시작

3월 4일

일본에서의 첫 프로젝트가 시작됐다.

수 백명이 참가하고 있는 대규모 프로젝트의 일원이 되었다.

뭐 아직 팀 배정이 안됐으므로 일원이 되었다는 표현은 시기상조일지도...

출근한 지 2일이 지났지만, 이런 저런 이유로 팀 배정이 미뤄지고 있는 상황이다.

이틀동안 업무 문서 200페이지는 넘게  본 것 같다.

일본어로 회화는 가능하지만, 한자가 어려워 읽는 것이 더딘 나에게는 어려운 문서뿐이다.

하지만, 2일동안 주구장창 보다보니 속도가 좀 느는 것 같기도 하다.

모르는 한자를 적어와서 네이버 단어장에 추가하니 벌써 120단어가 등록되었다.

이를 어째.... 하루빨리 외워야 하는 단어들이다.

오고가는 전철 안에서 네이버 단어장만 보고 있다.

출퇴근 시간에 독서를 할 요량으로 Kindle voyage까지 큰 맘 먹고 샀는데,

이 놈은 그냥 가방안에서 뒹굴고 있다.

업무가 익숙해질 때 까지는 아마 비슷한 일상이 될 것 같다.

하루 빨리 一人前にならないと。。。

Jersey Framework?

오늘은 고객사와 면접이 있는 날이다.

이런 저런 얘기를 나누던 차에 사용하는 프레임워크가 Jersey란다.

Jersey 써 본 적 있으세요? 라는 질문에  ありません。이라고 대답할 수 밖에 없었다.

그럼 Jersey Framework는 뭐지? 라는 의문이 들어 정리해 보기로 했다.

Jersey Framework

Jersey RESTful Web Services framework is an open source, production quality, framework for developing RESTful Web Services in Java that provides support for JAX-RS APIs and serves as a JAX-RS (JSR 311 & JSR 339) Reference Implementation. 

The following components are part of Jersey:

• Core Server: For building RESTful services based on annotation (jersey-core, jersey-server, jsr311-api)
• Core Client: Aids you in communicating with REST services (jersey-client)
• JAXB support
• JSON support
• Integration module for Spring and Guice

우선 두 단어가 많이 보인다.

RESTful 그리고 JAX-RS이다.

RESTful이란?

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다. 그는 하이퍼텍스트 전송 프로토콜(HTTP)의 주요 저자들 가운데 한 사람이다. 그 뒤로 이 개념은 네트워킹 문화에 널리 퍼졌다.

엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 네트워크 아키텍처 원리란 리소스를 정의하고 리소스에 대한 주소를 지정하는 방법에 대한 개괄을 말한다. 간단한 의미로는, 도메인 지향 데이터를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 부가적인 전송 레이어 없이, 전송하기 위한 아주 간단한 인터페이스를 말한다. 이 두 가지의 의미는 당연히 겹치는 부분과 충돌되는 부분이 있다. 필딩의 REST 아키텍처 형식을 따르면 HTTP 프로토콜을 사용하지 않은 채로 또 월드 와이드 웹에서 전송하지 않고도 아주 커다란 소프트웨어 시스템을 설계하는 것도 가능하다. 또한, 리모트 프로시저 콜을 이용하는 대신에 간단한 XML과 HTTP 인터페이스(REST 원리에 부합하지는 않지만)를 이용해 설계하는 것도 가능하다. 현실 세계에서의 REST 용어에 대한 이러한 두 가지 의미는 기술 토론에서 종종 혼란을 야기한다.

필딩의 REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다. 열정적인 REST 옹호자들은 스스로를 RESTafrians 이라고 부른다.

원리

REST의 지지자들은 웹이 REST의 핵심 설계 원칙을 통해 확장성과 성장성을 갖게 되었다고 주장한다.

• 응용 프로그램의 상태와 기능은 리소스들로 나뉜다.
• 모든 리소스는 하이퍼미디어 링크를 사용하는 공통 문법을 이용하여 유일한 방식으로 주소를 지정한다.
• 모든 리소스들은 클라이언트와 리소스 사이의 상태 전송을 위한 유일한 인터페이스를 공유한다. 다음과 같이 이루어져 있다.
  • 잘 정의된 명령어들의 제약 집합.
  • 콘텐츠 종류와, Client-side_scripting|Code on demand를 부분적으로 지원하는 제약 집합
• REST 아키텍처에 적용된 6가지 제한 조건 ^[1]
  • 클라이언트/서버 구조 - 일관적인 인터페이스로 분리되어야 한다
  • 무상태(Stateless) - 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 된다
  • 캐시 처리 가능(Cacheable) - WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
    • 잘 관리되는 캐싱은 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 scalability와 성능을 향상시킨다.
  • 계층화(Layered System) - 클라이언트는 보통 대상 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결되었는지를 알 수 없다. 중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 scalability를 향상시키는 데 유용하다.
  • Code on demand(optional) - 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
  • Uniform Interface - 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준다.

REST 인터페이스의 원칙에 대한 가이드

리소스의 구별

개별적인 리소스는 요청에서 구별된다 - 웹 기반의 REST 시스템에서의 URI의 사용을 예로 들 수 있다. 리소스 그 자체는 클라이언트로 리턴되는 representation으로부터 개념적으로 분리되어 있다. 예를 들어, 서버는 그 데이터베이스를 전송하지 않는다, 단지 아마 어떤 데이터베이스 레코드를 나타내는 HTML, XML이나 JSON 등이 요청에서 구체적으로 요구되거나 서버의 구현에 따라서 예를 들어, 프랑스 어로, UTF-8로 인코딩되어 보내질 것이다.

representation을 통한 리소스의 조작

클라이언트가 어떤 메타데이터가 첨부된 상태로 어떤 리소스의 representation을 가지고 있을 때, 만약 승인이 있다면, 서버에 있는 그 리소스를 변경 또는 삭제할 수 있는 충분한 정보를 가지고 있는 것이다.

자기-서술적 메시지

각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다 - 예를 들어 어떤 파서를 불러야 하는지. 그 한 예는 MIME type과 같은 인터넷 미디어 타입의 사용을 들 수 있다. 미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야할 지 알 수 있어야 한다. 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기-서술적이 아니다. 예를 들어, 단순히 "application/xml"이라는 미디어 타입은, 코드 다운로드가 사용되지 않으면, 그 내용을 가지고 무엇을 해야할지에 대해 충분히 알려주지 못한다.

애플리케이션의 상태에 대한 엔진으로서 하이퍼미디어

만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 representation에서 구별될 수 있어야 한다. 충분한 콘텍스트 속에서의 URI를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있겠다.

REST 의 주요한 목표

• 컴포넌트의 상호 연동 상의 확장성(scalability of component interactions)
• 인터페이스의 범용성(Genrality of interfaces)
• 컴포넌트의 독립적인 배포(Independent deployment of components)
• 지연을 감소시키고, 보안을 강화하고, 레거시 시스템을 인캡슐레이션 시키는 중간 컴포넌트(Intermediary components to reduce latency, enforce security and encapsulate legacy systems)

JAX-RS란?

JAX-RS(Java™ API for RESTful Web Services)는 자바 플랫폼에서 경량화된 REST 방식의 웹 애플리케이션 구현을 지원하는 자바 API이다.

SOAP기반의 SOA 연동은 자바 애플리케이션을 무겁게 한다는 비판과 함께, 최근 웹 애플리케이션의 경향인 AJAX기반으로 JSON이나RSS와 같이 간결한 프로토콜을 사용한 연동이 보편화되면서 쉽게 구현할 수 있도록 Java EE에 JAX-RS 라는 사양이 포함되고 있다.

출처 : http://en.wikipedia.org/wiki/Project_Jersey#cite_note-1
http://ko.wikipedia.org/wiki/REST
http://ko.wikipedia.org/wiki/JAX-RS

Jersey Framework에 대해 좀 더 알게되면 더 추가하도록 하겠다.