2008. 10. 23. 20:42

디바이스 미들웨어 2 - 기능 요소

일반적으로 디바이스 미들웨어가 갖는 필요성이나 특성이라고 하면 다음과 같이 정리할 수 있다. (이 정의는 2005년 본인이 RFID 협회에 "RFID 미들웨어란?" 이란 주제로 발표한 내용 중 일부이다.)

- 단순성
: 복잡한 개별 장비의 사양이나 인터페이스 방법을 모르더라도 어떠한 장비, 어떠한 애플리케이션과도 쉽게 연결할 수 있다.

- 영속성
: 미들웨어의 계층 구조에 따라 데이터를 일정 기간 보관하고 필요한 경우 외부 애플리케이션에 이를 제공할 수 있다.

- 표준화
: 동일한 표준화된 방법으로 모든 장비나 애플리케이션에 대한 접근이 가능하다.

- 확장성
: 시스템 추가 및 수정, 비즈니스 프로세스의 추가 및 변경시에도 전체 시스템에 위험을 주지 않고 용이한 처리가 가능하다.

요약해 보자면 디바이스 미들웨어는 장비와 애플리케이션 사이에서 여러가지 복잡함을 단순화하여 연결해 주는 편의성을 제공해 주는 것이라고 할 수 있겠다.

좀더 자세하게 내부를 들여다 보도록 하자. <그림1>은 디바이스 미들웨어가 가져야 하는 구성요소를 분해한 것이다.

사용자 삽입 이미지

<그림 1> 디바이스 미들웨어 구성 요소

각 구성 요소에 대한 설명은 다음과 같다.

1. 표준과 비표준 방식의 인터페이스 API 이다. 외부 시스템이 미들웨어와 연동하여 데이터를 주고 받기 위해 개발이 필요할 것인데 이러한 경우 개발 편의성을 주기 위해 제공하는 API (Application Programming Interface)이다.

2. 실제적인 애플리케이션 인터페이스 프로토콜을 구현한 기능이다. 이것 역시 표준과 비표준이 있을 수 있다. 표준이라고 하면 EPCglobal 에서 정의한 ALE (Application Level Events)도 있을 수 있지만, SAP 와 같이 많은 곳에서 사용하는 서버 애플리케이션이 정의한 RFC (Remote Function Call), BAPI (Business API), IDoc (Interdemiate Documents) 같은 실제적인 표준이 있을 수도 있다. 그렇지 않고 내부 애플리케이션에서 임의로 정의한 프토토콜을 구현해 써야만 하는 경우도 많다.

3. 만일 인터페이스를 표준 방식으로 사용한다고 하면 그 표준 인터페이스를 지원하기 위해 내부적으로 데이터 관리를 해야할 필요가 있다. 예를 들어 ALE 표준이라고 한다면 정의된 ECspec 에 맞게 수집된 데이터를 잘 보관하고 있다가 주어진 스펙에 맞게 응답해야 하기 때문이다.

4. 필요한 경우는 미들웨어 내부에서 현장 상황에 맞게 요구되는 별도의 로직과 프로세스를 구현하여야 한다. 예를 들어 A 공정과 B 공정이 유사한 업무 처리를 하고는 있지만 A 프로세스의 경우는 특별한 데이터 처리를 해야 하는 등의 요구 사항이 발생할 수 있다.

5. 또한 미들웨어를 사용하여 시스템을 꾸미고자 할때마다 로직이나 프로세스가 매번 새롭게 개발되어져야 한다면 이는 진정한 미들웨어를 사용한다고 볼 수 없을 것이다. 미들웨어의 생명은 재사용으로 인해 업무의 편의성을 주는 것이기 때문이다. 따라서 주로 많이 이용되고 있는 현장 상황에 맞게 개발되어진 로직이 많이 제공되는 디바이스 미들웨어가 진정한 미들웨어라고 할 수 있을 것이다. 많은 사람들이 디바이스 인터페이스만 많이 제공되는 것만을 주목하는 경우가 많은데 이는 빙산의 일각에 불과한 기능이다.

6. 위에서 설명되어진 기능들은 일단 디바이스에서 수집된 데이터를 어떻게 이용하는가에 대한 기능인데 이를 위해서 디바이스 정보를 저수준에서 우선 처리하는 기능이 필요하다. 무엇보다 데이터의 신뢰성을 보장해야만 하고 쓸데없는 데이터를 삭제하는 등의 기능이 그것이다. 데이터 뿐만 아니라 연결되는 디바이스의 적절한 최적의 파라미터를 자동으로 설정한다든지 하는 기능도 여기에서 행한다.

7. 가장 기본적인 기능으로 디바이스와의 인터페이스 모듈이다. 당연한 이야기겠지만 다양한 디바이스와 연결되기 위한 다양한 물리적, 논리적 프토토콜을 구현하여야만 한다.

8. 외부에서 이 디바이스 미들웨어와 디바이스, 애플리케이션 들과의 상태, 데이터 등을 손쉽게 확인할 수 있도록 편리한 방법과 관리 기능들이 제공되어야만 한다. 여기에서 중요한 것은 원격에서 한꺼번에 여러개의 기기들을 조작 및 확인이 가능해야만 한다는 것이다.

9. 관리와 감시 기능은 관리자가 각자 입맛에 맞게 조작하여 사용해야 할 필요가 있다. 따라서 기본적으로 제공하는 UI가 아니더라도 새롭게 꾸며서 사용이 가능하도록 별도의 API를 제공하는 것이 필요하다.

10. 이러한 모든 기능들은 새로운 것을 쉽게 만들어 낼 수 있도록 개발 프레임워크를 제공해야만 개발자들이 잘 쓸 수 있을 것이다.

이러한 기능들을 반드시 필요한 핵심 요소부터 추가적으로 제공되는 요소까지를 마치 눈덩이를 뭉치는 것처럼 표현한 Value-Added Snowball을 나타낸 그림이 <그림2>에 보이고 있다.

사용자 삽입 이미지

<그림 2> Value-Added Snowball of the device middleware

이것에 대한 각각의 기능들에 대한 설명은 다음과 같다.

- Development Framework
: 디바이스 미들웨어를 사용하여 개발하는 개발자들이 동일한 형태로 개발이 가능하도록 해주는 개발 표준과 공통 라이브러리를 가장 근본적으로 제공해야만 할 것이다. 그리고 이렇게 개발되어진 콤포넌튿이 실행될 수 있는 런타임 엔진 기능이 최소 기능의 미들웨어라 할 것이다.

- Data Capture Middleware
: 실행되는 디바이스 미들웨어의 최소 기능은 역시 장비와 애플리케이션의 연결이 될 것이다. 이것은 별도의 특별한 로직이나 프로세스를 담지는 못하고 장비에서 데이터를 잘 읽어 들여 이것을 애플리케이션이 원하는 형태로 잘 제공해 주는 기능만을 우선시한다. 따라서 RFID Middleware에서 얘기하는 ALE 와 같은 표준 인터페이스도 이곳에서 제공되어야 하는 기능이다.

- Data & Device Management
: 관리자와 개발자들을 위해서 편리한 관리와 감시 기능이 제공되어져야 한다. 이것을 위해서 원격에서의 접근이 필수적이고 문제가 발생할 때 휴대폰으로 문자를 주든, 이메일로 알려 주든 알림 서비스가 필요할 수도 있고, 또한 환경 구성 파일을 손쉽게 변경하여 설정 구성을 쉽게하는 기능을 제공할 필요도 있다.

- Process Oriented Solution
: 가장 마지막 단계라고 할 수 있는데, 디바이스 미들웨어를 설치하는 것만으로 전자 선반이 완성되고 방향 판별을 하면서 에러 처리가 되는 RFID 입출고 포탈이 만들어지는 등의 기능이 제공되면 정말 편리할 것이다. 이러한 기능이 바로 디바이스 미들웨어를 제대로 사용하는 방법이 될 것이다.

Trackback 0 Comment 0