KR101860611B1 - 화상 형성 장치 및 리소스 관리 방법 - Google Patents

화상 형성 장치 및 리소스 관리 방법 Download PDF

Info

Publication number
KR101860611B1
KR101860611B1 KR1020150118574A KR20150118574A KR101860611B1 KR 101860611 B1 KR101860611 B1 KR 101860611B1 KR 1020150118574 A KR1020150118574 A KR 1020150118574A KR 20150118574 A KR20150118574 A KR 20150118574A KR 101860611 B1 KR101860611 B1 KR 101860611B1
Authority
KR
South Korea
Prior art keywords
application
resource
group
management
amount
Prior art date
Application number
KR1020150118574A
Other languages
English (en)
Other versions
KR20160026713A (ko
Inventor
마나미 하타노
Original Assignee
캐논 가부시끼가이샤
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 캐논 가부시끼가이샤 filed Critical 캐논 가부시끼가이샤
Publication of KR20160026713A publication Critical patent/KR20160026713A/ko
Application granted granted Critical
Publication of KR101860611B1 publication Critical patent/KR101860611B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Facsimiles In General (AREA)

Abstract

리소스 서비스에 대하여 프래그먼트 번들로서 도입되는 그룹에 대하여 리소스량의 상한값을 설정한다. 그룹 도입 시에는 해당 그룹에 속하는 애플리케이션에 의해 사용되는 리소스의 양을 그룹 단위로 관리에 이관할 수 있다.

Description

화상 형성 장치 및 리소스 관리 방법{IMAGE FORMING APPARATUS AND RESOURCE MANAGEMENT METHOD}
본 발명은 내장 애플리케이션을 복수 인스톨해서 실행하기 위한 실행 환경에서 애플리케이션이 사용하는 리소스의 사용량을 동적으로 관리하는 화상 형성 장치 및 리소스 관리 방법에 관한 것이다.
종래, 내장 애플리케이션 실행 환경에서는, 애플리케이션이 사용하는 일반적인 계산기 리소스인 리소스의 총량에 제한이 있는 것이 일반적이다. 이것 때문에 이하와 같은 것이 일반적으로 행하여지고 있다. 즉, 애플리케이션이 사용하는 리소스의 양에 대해서 상한값을 정한다. 또한, 검사 단계에서 당해 애플리케이션의 사용량이 그 상한값을 초과하지 않는 것을 확인함으로써, 애플리케이션이 안정적으로 가동하는 것을 보증한다.
그러한 애플리케이션을 복수 가동시키는 것을 상정한 내장 애플리케이션 실행 환경에서는, 애플리케이션 관리 프레임워크가 당해 실행 환경에 인스톨된 애플리케이션이 사용하는 리소스의 사용량을 감시하고 있다. 즉, 애플리케이션을 실행 환경에 인스톨할 때에, 인스톨된 애플리케이션의 전체가 실행 환경이 제공하는 리소스의 총량을 초과하지 않도록 제어한다. 이때, 그 제한을 초과하는 애플리케이션에 대해서는 인스톨을 허가하지 않는다. 이러한 리소스 관리 장치 및 리소스 관리 방법이 일반적으로 제공된다.
또한, 리소스의 사용에 대해서 복수의 애플리케이션이 서로 경합하는 상태를 검출해서 그 애플리케이션을 제어함으로써 복수의 애플리케이션 간의 리소스의 사용량을 억제하는 기술도 제공되고 있다. 예를 들어, 일본 특허 공개 제2004-362425호 공보에 개시된 기술에 의하면, 리소스 관리 장치는 미리 복수의 애플리케이션에 대해서 당해 리소스를 사용할 때의 우선 순위를 부여하는 데이터베이스를 포함한다. 여기에서는, 하나의 애플리케이션이 당해 리소스를 사용하고자 하나, 우선 순위가 높은 다른 애플리케이션이 그것을 사용 중이라면 에러를 발생시키는 구조를 제공함으로써 리소스의 사용을 제어하고 있다.
일본 특허 공개 평8-328884호 공보에서는, 리소스 관리 장치는 미리 복수의 애플리케이션에 대해서 리소스를 사용할 때의 우선 순위를 부여한다. 또한, 이 리소스 관리 장치는 배타적인 제어의 필요성을 나타내는 관리 테이블을 포함한다. 우선도가 낮은 애플리케이션이 배타 제어가 필요한 리소스를 사용하고자 하는 경우에는 우선도가 높은 애플리케이션에 의한 리소스 사용이 완료할 때까지 애플리케이션을 정지함으로써 경합을 제어하고 있다.
일본 특허 공개 제2010-39689호 공보에 개시된 기술에서는, 애플리케이션이 특정한 다른 애플리케이션과 리소스의 사용에 대해서 경합할 경우에, 당해 다른 애플리케이션에 이하와 같은 구조를 제공하고 있다. 즉, 당해 다른 애플리케이션이 현재 사용하고 있는 리소스의 양을 관리자가 알 수 있도록 화면이 제공된다. 그리고, 당해 애플리케이션이, 다른 애플리케이션에 의한 리소스의 소비량을 알 수 있도록 인터페이스가 제공된다. 이들 기구에 의해, 당해 애플리케이션이 당해 다른 애플리케이션에 의한 리소스 사용량을 확인하고 나서, 자신에 의한 리소스 사용을 개시하여 경합을 피하고 있다.
그러나, 이들의 기술에는 이하와 같은 과제가 있다. 즉, 각각의 애플리케이션에 대해서 부여되는 상한값의 합이 시스템 전체에 의해 제공가능한 리소스의 사용량을 초과할 경우에는, 이들 애플리케이션을 동시에 인스톨할 수 없다. 그러나, 실제로는, 동작 중에 이들 애플리케이션에 의한 리소스 사용량이 동시에 상한에 달하는 경우는 거의 없다. 이것은, 실제로는 필요한 리소스의 사용량을 제공가능하지만, 그러한 애플리케이션을 동시에 시스템 내에 배치할 수는 없다는 과제를 부과한다.
일본 특허 공개 제2004-362425호 공보 및 일본 특허 공개 평8-328884호 공보에 개시된 기술에서는, 우선 순위를 부여함으로써 리소스의 경합의 발생 시에 우선 순위가 낮은 애플리케이션이 리소스를 사용할 수 없도록 하고 있다. 사용량이 상한에 도달하는 것을 저지함으로써, 이들 애플리케이션을 동시에 배치하는 것이 가능하게 된다. 그러나, 우선 순위가 낮은 애플리케이션에 의한 처리는 결국 리소스가 이용가능해질 때까지 정지된다. 리소스를 공유하고, 그 리소스에 대한 우선 순위가 상이한 복수의 애플리케이션을 동시에 이용하는 것이 곤란해지는 과제가 있다.
일본 특허 공개 제2010-39689호 공보에 개시된 기술에도 과제가 있다. 애플리케이션이 리소스를 사용하기 전에, 애플리케이션은 다른 애플리케이션에 의한 리소스의 사용량을 확인하고, 그 후에 자신의 동작을 제어한다. 따라서, 이러한 기술은, 예를 들어 다른 처리를 먼저 행하는 등의 대응이 채택되어, 처리의 진행이 중단되지 않는 이점을 가진다. 그러나, 이를 위해서는, 애플리케이션은 미리 그러한 인터페이스를 구비할 필요가 있어, 그 인터페이스를 구비하지 않은 애플리케이션에는 적용할 수 없다. 애플리케이션이 리소스가 부족할 경우에는, 어느 애플리케이션에 문의할지를 미리 정해 둘 필요가 있기 때문에, 예측하지 못한 조합에 대하여는 상기 해결 수단을 적용할 수 없다.
이상과 같이, 애플리케이션에 의한 리소스 소비량이 실행 환경에 의해 제공가능한 리소스량을 초과하지 않도록 관리하는 리소스 관리를, 애플리케이션의 인스톨 시에 정적으로 행하거나, 또는 리소스 관리를 인스톨된 애플리케이션의 실행 시에 동적으로 행하는 경우에도, 적절한 리소스 관리를 행하는 것이 곤란하다.
일본 특허 공개 제2004-362425호 공보 일본 특허 공개 평8-328884호 공보 일본 특허 공개 제2010-39689호 공보
본 발명은 상기한 종례의 기술을 감안해서 이뤄진 것으로, 애플리케이션 간의 리소스의 경합을 적절하게 조정하고, 리소스의 효율적인 이용을 가능하게 하는 화상 형성 장치 및 리소스 관리 방법을 제공한다.
본 발명에서는 이하와 같은 구성을 포함한다. 즉, 화상 형성 장치는, 애플리케이션 군에 속하는 애플리케이션의 식별자와, 상기 애플리케이션 군에 대한 사용 리소스 선언량을 정의하는 정보를 취득하는 취득 수단과, 상기 애플리케이션으로부터의 리소스 취득 API의 호출에 응답하여, 상기 애플리케이션의 식별자에 기초하여 상기 애플리케이션이 속하는 애플리케이션 군을 특정하고, 특정된 상기 애플리케이션 군에 대한 사용 리소스 선언량을 상기 정보로부터 특정하는 특정 수단과, 상기 애플리케이션에 의해 요구되는 리소스량을 상기 애플리케이션 군에 의해 사용되는 리소스량의 합계에 가산하여 얻어지는 값이, 상기 특정 수단에 의해 특정되는 상기 사용 리소스량을 초과하는 경우, 상기 애플리케이션에 리소스 오브젝트를 이관하지 않고, 상기 값이 상기 사용 리소스량을 초과하지 않는 경우, 상기 애플리케이션에 상기 리소스 오브젝트를 이관하는 리소스 관리 수단을 포함한다.
본 발명에 따르면, 리소스 서비스가 각각의 애플리케이션에 대해서 단독 관리 상태와 그룹 관리 상태의 양쪽 모두에서 적절하게 리소스의 상한값 관리를 행할 수 있다. 관리자가 애플리케이션을 적절하게 관리 운용하기 위한 수고가 대폭으로 경감될 수 있다.
본 발명의 추가적인 특징은 첨부 도면을 참조하여 아래의 예시적인 실시예의 설명으로부터 명확해질 것이다.
도 1은 본 발명의 제1 및 제2 실시예에 따른 장치의 전체 구성을 도시하는 도면.
도 2는 본 발명의 제1 및 제2 실시예에 따른 화상 형성 장치(100)의 하드웨어 구성을 도시하는 블록도.
도 3은 본 발명의 제1 및 제2 실시예에 따른 애플리케이션 실행 환경의 구성을 도시하는 블록도.
도 4a 및 4b는 본 발명의 제1 및 제2 실시예에 따른 애플리케이션 및 프래그먼트 번들을 구성하는 파일의 내용을 도시하는 도면.
도 5a 및 도 5b는 본 발명의 제1 실시예에 따른 애플리케이션 관리 프레임워크의 화면 일례를 나타내는 도면.
도 6a 및 도 6b는 본 발명의 제1 및 제2 실시예에 따른 그룹 데이터 테이블의 내용과, 제1 실시예에 따른 애플리케이션 데이터 테이블의 내용을 도시하는 테이블.
도 7a는 본 발명이 제1 실시예에 따른 리소스 서비스에 의한 기동 시의 처리의 흐름도.
도 7b 내지 도 7g는 본 발명이 제1 실시예에 따른 리소스 서비스에 의한 기동 시의 처리의 흐름도.
도 8은 본 발명의 제1 실시예에 따른 리소스 조작의 개념도.
도 9는 본 발명의 제1 실시예에 따른 애플리케이션의 인스톨 처리의 흐름도.
도 10은 본 발명의 제1 실시예의에 따른 애플리케이션의 언인스톨 처리의 흐름도.
도 11a 및 도 11b는 본 발명의 제2 실시예에 따른 애플리케이션 관리 프레임워크의 화면의 예를 나타내는 도면.
도 12a는 본 발명의 제2 실시예에 따른 프래그먼트 번들의 기동 시의 처리의 흐름도.
도 12b 및 도 12c는 본 발명의 제2 실시예에 따른 프래그먼트 번들의 기동 시의 처리의 흐름도.
도 13은 본 발명의 제2 실시예에 따른 애플리케이션의 인스톨 처리의 흐름도.
도 14는 본 발명의 제2 실시예에 따른 애플리케이션의 언인스톨 처리의 흐름도.
이하, 본 발명을 실시하기 위한 실시예에 대해서 도면을 참조해서 설명한다.
[제1 실시예]
<화상 형성 장치의 구성>
도 1은 본 발명이 제1 실시예의 장치 전체 구성을 도시하는 도면이다. 화상 형성 장치(100)는 본 실시예에 따른 발명을 적용한 화상 형성 장치이다. 네트워크(130)는 화상 형성 장치(100)와 정보 처리 장치(101)를 접속하는 네트워크이다. 정보 처리 장치(101)는 화상 형성 장치(100)를 네트워크(130)를 경유해서 이용하기 위해서 사용된다.
애플리케이션(110)은 화상 형성 장치(100) 상에서 동작하는 애플리케이션의 일례인 애플리케이션 A이다. 애플리케이션(111)은, 마찬가지로 화상 형성 장치(100) 상에서 동작하는 애플리케이션의 다른 예인 애플리케이션 B이다. 또한 애플리케이션(112)은 화상 형성 장치(100) 상에서 동작하는 애플리케이션의 또 다른 예인 애플리케이션 C이다. 화상 형성 장치(100) 상에서는 하나, 혹은 복수의 애플리케이션이 동작할 수 있다. 여기에서는 애플리케이션을 3개 예시하고 있다. "애플리케이션(11n)"이라는 표현은, 애플리케이션 A(110), 애플리케이션 B(111), 애플리케이션 C(112)로 대표되는 1개 또는 복수의 애플리케이션을 가리킨다. 일반 이용자 및 관리자는 화상 형성 장치(100)의 기본 기능, 애플리케이션(11n) 및 화상 형성 장치(100) 및 애플리케이션(11n)을 관리하기 위한 리소스 관리 장치를 이용하는 것이 가능하다. 이용 시에는, 화상 형성 장치(100)를 직접 조작하거나, 혹은 네트워크(130)를 경유하여 정보 처리 장치(101)로부터 조작하는 것이 가능하다.
도 2는 화상 형성 장치(100)의 하드웨어 구성을 도식화한 것이다. 코어 유닛(200)은 프로세서, 메모리 등을 포함하고, 오퍼레이팅 시스템 및 애플리케이션 등의 프로그램을 실행하고, 본 실시예에 따른 리소스 관리를 실현한다. 유저 인터페이스 유닛(201)은, 터치 패널, 디스플레이, 키보드 등을 포함하고, 유저에 대하여 정보를 출력(표시)하고, 또한 유저로부터 조작 등의 입력을 접수한다. 기억 장치(202)는 하드 디스크 등에 의해 구성되고, 프로그램 및 데이터를 파일로서 저장한다. 네트워크 인터페이스 유닛(203)은, 예를 들어 LAN 등의 네트워크(130)에 접속하기 위한 네트워크 인터페이스이다. 스캐너 유닛(204)은, 원고 화상을, 예를 들어 광학적으로 판독해서 화상 데이터를 출력한다. 프린터 유닛(205)은 화상 데이터에 대응하는 화상을 매체 상에 형성한다. 피니셔 유닛(206)은 프린터 유닛에 의해 화상을 형성한 시트 매체에, 소팅, 스테이플링, 천공 등의 피니싱 처리를 실시한다.
<화상 형성 장치의 애플리케이션 및 그 실행 환경>
도 3은 본 실시예에서의 화상 형성 장치(100) 상에서 애플리케이션(11n)을 실행하기 위한 애플리케이션 실행 환경을 나타낸다. 애플리케이션 실행 플랫폼(301)은, 애플리케이션을 실행하기 위한 프로그램이며, 예를 들어 Java® 가상 머신(Java VM)이다. 애플리케이션 관리 프레임워크(302)는 애플리케이션(11n)의 인스톨, 언인스톨, 실행 및 정지를 관리하는 프레임워크이며, 예를 들어 Java® 베이스의 OSGi(Open Service Gateway initiative) 프레임워크 등이다. 서포트 라이브러리(303)는 애플리케이션(11n)이 화상 형성 장치(100)이 다양한 기능을 이용하기 위한 서포트 라이브러리이다. 리소스 서비스(304)는 본 실시예에서 애플리케이션(11n)이 필요로 하는 리소스에 대해서 효율적 관리를 실현하기 위해서 이용하기 위한 프로그램이다. 리소스 서비스(304)는 애플리케이션의 하나이지만, 애플리케이션(11n)에는 포함되지 않는다. 프래그먼트 번들(305)은 리소스 서비스(304)에 대하여 보완용 모듈로서 동작하는 프로그램이다. 또한, 본 실시예에서의 애플리케이션이란, 애플리케이션 관리 프레임워크(302)가 OSGi 프레임워크일 경우에는 번들에 상당한다. 번들이란, OSGi 프레임워크 상에서 Java®의 실행 플랫폼인 Java VM과는 독립하여 인스톨되거나, 언인스톨되거나, 기동 혹은 정지될 수 있는 프로그램 컴포넌트(소위 플러그인)이다. 프래그먼트 번들이란, OSGi 프레임워크에서 그 내용을 다른 번들(호스트 번들이라고 칭한다)과 공유할 수 있는 번들이다. 프래그먼트 번들은 애플리케이션과 마찬가지로 매니페스트 헤더를 갖는 Java® 아카이브 파일로서 제공된다. 이것에 대해서는 도 4a 및 4b 등을 참조하여 상세하게 설명한다. 본 예에서 말하는 프래그먼트 번들은 상기와 같은 일반적인 사물을 가리키는 것이 아니고, 후술하는 실시예에서 설명하는 것 같이 리소스 서비스의 일부이고, 리소스의 그룹 관리를 위해서 기능하는 프래그먼트 번들을 가리킨다. 이러한 프래그먼트 번들을 다른 애플리케이션의 프래그먼트 번들과 구별하기 위해서, 이러한 프래그먼트 번들을 특히 리소스 서비스 프래그먼트 번들이라고도 칭한다. 프래그먼트 번들은 애플리케이션의 환경이 OSGi 프레임워크가 아닌 경우라도, OSGi 프레임워크의 프래그먼트 번들에 상당하는 소프트웨어 컴포넌트를 포함한다.
리소스 서비스(304)는 기본적인 동작으로서 애플리케이션(11n)으로부터의 리소스의 리퀘스트를 접수한다. 애플리케이션(11n)은 리소스를 취득할 때 및 사용 후에 해방(release)하는 때에 리소스 서비스(304)에 대하여 리소스 취득 리퀘스트 및 리소스 해방 리퀘스트를 보낸다. 리소스 서비스(304)는 리퀘스트를 보낸 애플리케이션(11n)이 리소스를 사용할 권리를 가진 상태에서 동작하고 있는지 여부를 확인하고, 애플리케이션(11n)이 권리를 가지지 않은 상태에 있다면 에러를 뒤돌려 주는 동작을 한다. 애플리케이션(11n)이 권리를 가지는 경우에는, 리소스 서비스(304)는 당해 애플리케이션(11n)에 대하여 설정되어 있는 리소스의 사용량의 상한값을 참조한다. 그 사용량이 리소스의 상한에 도달하고 있지 않으면 리소스 서비스(304)는 리소스를 확보해서 애플리케이션(11n)에 돌려준다. 그 사용량이 상한을 초과하는 경우에는 리소스 서비스(304)는 에러를 돌려준다. 리소스 서비스(304)는 리소스를 확보했을 경우에는 애플리케이션(11n)에 의한 현재 리소스의 사용량의 수치를 파악하기 위해, 새롭게 확보한 리소스의 양을 가산하는 동작을 행한다. 리소스 서비스(304)는 리소스의 해방 시에는 해방된 리소스의 양을 감산하는 동작을 행한다. 리소스의 해방에 실패하는 경우는 거의 없지만, 해방에 실패했을 경우에는 에러를 돌려주고 관리자에 대하여 경고를 출력한다. 또한, 이러한 경고는 그 밖에도 출력되는 경우가 있다. 이러한 종류의 경고는, 구체적으로는, 리소스 서비스(304)의 관리자 대상 인터페이스상에 표시하거나, 혹은, 시스템 로그에 추가하는 등의 수단을 사용해서 출력되어 관리자에게 전달된다.
도 4a는 본 실시예에 따른 애플리케이션(11n)을 구성하는 대표적인 파일의 내용에 대해서 해설한 도면이다. 애플리케이션(11n)은 내용으로서 몇 가지의 종류의 파일을 포함하고 있다. 애플리케이션 실행 코드 파일(400)은 애플리케이션의 실행 코드 등을 포함한다. 애플리케이션 고정 데이터 파일(401)은 애플리케이션의 고정 데이터를 포함하고 있는 파일이다. 애플리케이션 리소스 상한 선언 파일(402)은 애플리케이션이 사용하는 리소스의 상한값, 즉 사용 리소스 선언량을 선언하기 위한 파일이다. 또한, 애플리케이션 리소스 상한 선언 파일(402)은 그 내용으로서 이하의 기술을 포함하고 있다. 애플리케이션 ID(410)는 애플리케이션(11n)의 애플리케이션 ID, 즉 식별자의 값의 기재이다. 그룹 ID(411)는 애플리케이션(11n)이 속하는 그룹을 지정하는 그룹 ID의 기재이다. 리소스 상한값(412)은 애플리케이션(11n)이 사용하는 리소스의 상한값 선언인 리소스 상한값이다. 애플리케이션 리소스 상한 선언 파일(402)은 OSGi 프레임워크 하에서는 매니페스트에 상당한다.
애플리케이션 실행 환경 내에 애플리케이션(11n)을 인스톨해서 실행하는 경우, 애플리케이션 관리 프레임워크(302)를 이용한다. 기본 동작으로서, 애플리케이션 관리 프레임워크(302)는, 관리자가 애플리케이션(11n)을 인스톨하기 위한 리퀘스트를 발행하면, 인스톨 동작을 행한다. 이때에, 애플리케이션 관리 프레임워크(302)는 그 애플리케이션 리소스 상한 선언 파일(402)을 참조하고, 거기에 선언되고 있는 리소스 상한값이 현재의 애플리케이션 실행 환경 내의 리소스의 빈 용량 내에 들어가는지 여부를 판정한다. 리소스 상한값이 그 빈 용량 내에 들어가지 않으면, 인스톨은 실패한다.
리소스 서비스(304) 또한 기본적으로는 애플리케이션의 하나이며, 도 4a에 도시된 애플리케이션(11n)과 마찬가지의 구성으로 되어 있다. 리소스 서비스를 애플리케이션(11n)과 구별하는 특징은, 이 리소스 서비스는 다른 불특정한 애플리케이션(11n)에 대하여 서비스를 제공하는 공통의 애플리케이션 프로그래밍 인터페이스(이하 "API"라고 약칭한다)를 제공한다는 것이다. 이 API를 리소스 취득 API라고 칭한다. 다른 애플리케이션은 리소스 취득 API를 개재해서 리소스 서비스에 의한 서비스를 받을 수 있다. 단, 리소스 서비스의 API의 호출은 애플리케이션에 의해 코딩된 후에만 당해 애플리케이션에 의해 이용되므로, 일부 애플리케이션은 그 리소스 서비스를 이용하고, 다른 애플리케이션은 이용하지 않는다. 그러나, 본 예에서는 모든 애플리케이션이 리소스 서비스를 이용해서 리소스를 취득하는 것을 전제로 한다.
도 4b는 프래그먼트 번들(305)을 구성하는 대표적인 파일의 내용에 대해서 설명하는 도면이다. 프래그먼트 번들(305) 또한 기본적으로는 도 4a에 도시된 애플리케이션(11n)과 마찬가지의 구성으로 되어 있다. 프래그먼트 번들 실행 코드 파일(420)은 프래그먼트 번들의 실행 코드를 포함하는 파일이다. 프래그먼트 번들 고정 데이터 파일(421)은 프래그먼트 번들의 고정 데이터를 포함하는 파일이다. 프래그먼트 번들 리소스 상한 선언 파일(422)은 프래그먼트 번들이 사용하는 리소스의 상한값을 선언하기 위한 파일이다. 프래그먼트 번들 ID(430)는 프래그먼트 번들의 ID를 나타내고 있다. 그룹 ID(431)는 이 프래그먼트 번들(305)이 선언하는 그룹의 그룹 ID를 나타내고 있다. 리소스 상한값(432)은, 프래그먼트 번들(305)을 리소스 서비스(304)에 대하여 추가할 시에, 증가하는 리소스 사용량을 리소스마다 선언하는 리소스 상한값을 나타내고 있다. 이 값은 단순히 프래그먼트 번들(305)에 의해 소비되는 리소스의 상한을 나타내고 있는 것이 아니라, 프래그먼트 번들(305)에 의해 정의된 각 그룹에 의해 관리되는 애플리케이션이 소비하는 리소스의 상한값(즉, 그룹의 리소스 상한값)을 나타내고 있다. 단, 이 그룹에 속하는 애플리케이션이 인스톨되었을 때에 본체 파일이 차지하는 스토리지 사이즈는 이 상한값에는 포함되지 않는다. 바꾸어 말하면, 그룹에 의해 관리되는 애플리케이션 각각은 리소스 상한값(432)으로 선언된 값인 상한값까지 각 리소스를 사용할 수 있고, 스토리지에 관해서는 각 애플리케이션의 본체 파일이 차지하는 영역을 더 사용할 수 있다. 소속 애플리케이션 ID(433)는 이 프래그먼트 번들(305)이 선언하는 그룹에 속하는, 즉 포함되는 1개 또는 복수의 애플리케이션(11n)(애플리케이션 군이라고도 칭한다)의 애플리케이션 ID를 나타낸다.
<프래그먼트 번들의 인스톨 및 언인스톨>
애플리케이션 관리 프레임워크(302)는 프래그먼트 번들(305)의 인스톨이 지시된 경우에는, 애플리케이션과 마찬가지로 프래그먼트 번들(305)의 플래그먼트 번들 리소스 상한 선언 파일(422)을 참조한다. 그리고, 애플리케이션 관리 프레임워크(302)는, 거기에 선언되고 있는 각 리소스의 리소스 상한값(432)을 리소스 서비스(304)의 이 리소스의 현재의 리소스 상한값에 가산하더라도, 현재의 애플리케이션 실행 환경 내의 리소스의 빈 용량 내에 전체 리소스 상한값이 들어갈 것인지 여부를 판정한다. 바꾸어 말하면, 리소스 상한값에 의해 기술된 리소스를 확보한다. 현재의 애플리케이션 실행 환경 내에서 제공가능한 리소스 용량은 미리 부여되고 있다. 현재의 리소스 상한값은, 리소스 서비스(304)가 원래 선언하고 있는 리소스 상한값에, 인스톨된 프래그먼트 번들이 선언하고 있는 리소스 상한값을 가산하여 얻어지는 값이다. 전체 리소스 상한값이 빈 용량 내에 들어가면, 프래그먼트 번들(305)의 인스톨을 완료한다. 이것은 다른 애플리케이션의 인스톨에도 적용된다. 인스톨이 완료하면, 인스톨된 프래그먼트 번들(305)이 선언한 리소스 상한값(432)은, 추가 목적지인 리소스 서비스(304)의 현재의 리소스 상한값에 가산된다. 이 가산에 의해, 그룹에 의해 관리된 애플리케이션의 리소스 상한값은, 리소스 서비스(304)의 리소스 상한값으로서 관리된다. 예를 들어, 그룹에 의해 관리된 애플리케이션의 리소스(예를 들어 스토리지)는, 리소스 서비스(304)에 의해 대체적으로 확보되게 된다. 리소스 상한값(432)으로서는, 당해 그룹에 속하는 애플리케이션 개개의 리소스 상한값 중, 최대값 이상의 값이 설정되는 것이 바람직하다.
반대로, 프래그먼트 번들(305)이 언인스톨되면, 프래그먼트 번들(305)이 선언하고 있는 리소스 상한값(432)이 리소스 서비스(304)의 현재의 리소스 상한값으로부터 감산된다. 물론 감산은 리소스 종별마다 행하여진다. 또한, 이 감산은, 언인스톨되는 프래그먼트 번들을 통해서 리소스 서비스에 의해 관리된 공유 리소스를 해방하고 나서 행해야 하므로, (후술하는) 도 7f 및 도 7g의 처리를 완료하고 나서 행하는 것이 바람직하다.
이러한 방식으로, 프래그먼트 번들은 호스트 번들인 리소스 서비스에 대하여 나중에 기능을 부가하거나, 혹은 기능을 교환하는 데에 사용될 수 있다.
도 5a 및 도 5b는 애플리케이션 관리 프레임워크(302)의 화면(애플리케이션 관리 화면이라고 칭한다)의 일례를 나타낸 것이다. 도 5a에 나타낸 화면은 프래그먼트 번들(305)을 인스톨하기 전의 화면이다. 도 5b에 나타낸 화면은 프래그먼트 번들(305)이 인스톨된 후의 화면이다.
도 5a에서, 애플리케이션명(501)은 애플리케이션명의 표시란이다. 여기에는 애플리케이션(11n) 및 리소스 서비스(304)의 명칭이 표시된다. 도 5a에는 나타나지 않고 있지만, 도 5b에 나타낸 바와 같이 프래그먼트 번들(305)이 인스톨되었을 경우에도, 애플리케이션명의 표시란(501)에 하나의 애플리케이션으로서 표시된다. 도 5b에 나타낸 바와 같이, 프래그먼트 번들(305)에 대하여도, 애플리케이션명의 표시란(501)에 프래그먼트 번들(305)의 명칭(이 예에서는 "애플리케이션 ABC 그룹 설정 0.1")이 표시된다.
갱신 일시(502)는 애플리케이션(11n), 리소스 서비스(304), 프래그먼트 번들(305)의 갱신된 일시를 나타내는 갱신 일시의 표시란이다. 상태(503)는 그들 애플리케이션 등의 가동 상황을 나타내는 상태란이다. 이 예에서는 애플리케이션의 가동 시에는 "개시"가 표시되고, 애플리케이션의 비가동 시에는 "정지"가 표시된다. 관리 행위 실행 버튼(504)은 관리 행위 실행 버튼 표시란이다. 이 예에서는 "개시" 상태에 있는 애플리케이션에 대해서는 "정지" 버튼(510) 및 "언인스톨" 버튼(511)이 표시된다. 개시/정지 버튼(510)은 각 행에 나타나는 애플리케이션(11n), 리소스 서비스(304), 프래그먼트 번들(305) 각각의 개시 또는 정지를 지시하기 위한 버튼이다. 가동 상태에 따라서 "개시" 또는 "정지" 중 어느 하나가 표시된다. 언인스톨 버튼(511)은 애플리케이션의 언인스톨을 지시하기 위한 언인스톨 버튼이다. 본 실시예에서는 관리 행위 실행 버튼 표시란(504)에는 개시/정지 버튼(510) 및 언인스톨 버튼(511)이 표시된다. 라이센스(505)는 각 행에 나타나는 애플리케이션(11n), 리소스 서비스(304), 프래그먼트 번들(305) 각각에 대해서 라이센스가 필요한지의 여부를 표시하기 위한 라이센스 표시란이다.
도 5a에 나타낸 화면 예에서는 프래그먼트 번들(305)이 아직 인스톨되지 않고 있다. 도 5a에서는 "애플리케이션 ALPHA", "애플리케이션 BETA" 및 "애플리케이션 GAMMA"라고 표시되어 있는 3개의 애플리케이션이 하나의 그룹에 속해 있다. 이들 애플리케이션의 갱신 일시(520)가 나타내는 대로, 프래그먼트 번들(305)이 아직 인스톨되어 있지 않은 상태에서는 이 애플리케이션(11n)의 갱신 일시는 그들이 인스톨된 시각이다. 도 5b에 나타낸 화면 예는 프래그먼트 번들(305)을 인스톨한 후의 상태이다. 프래그먼트 번들(305)을 관리자가 인스톨하기 위해서는, 관리자는 리소스 서비스(304)를 개시/정지 버튼(510)으로 정지한다. 그 후에 관리자는 통상의 수순에 따라서 프래그먼트 번들(305)을 인스톨한다. 관리자는 리소스 서비스(304)를 개시/정지 버튼(510)에 의해 다시 개시한다. 이에 응답하여, 프래그먼트 번들의 표시행(530)에 나타난 바와 같이, 프래그먼트 번들(305)이 인스톨되어 있는 것이 화면에도 나타난다. 이 상태에서는 프래그먼트 번들(305)이 나타내는 그룹 정보의 그룹에 속하는 애플리케이션(11n)은 프래그먼트 번들(305)이 인스톨된 직후에 덮어 쓰여 인스톨된다. 이 인스톨에서는 새로운 애플리케이션 리소스 상한 선언 파일(402)이 적용되고 있다. 이로 인해, 이 그룹에 속하는 애플리케이션의 갱신 일시(540)가 나타내는 대로 갱신 일시가 갱신된다.
이 화면 예에서, 프래그먼트 번들(305)은 프래그먼트 번들(305)이 관리 대상으로 하는 그룹에 속하는 애플리케이션(11n)이 인스톨된 후에 인스톨된다. 그러나, 본 실시예에서도, 애플리케이션(11n)을 나중에 인스톨하는 것은 가능하다.
도 5a 및 도 5b 각각에 나타낸 애플리케이션 관리 화면은, 예를 들어 프래그먼트 번들을 포함하는 애플리케이션의 속성, 상태 등에 기초하여 표시되고, 그 속성 및 상태는 애플리케이션 관리 테이블 등의 인스톨된 애플리케이션의 속성 및 상태를 저장하는 테이블에 보존된다. 속성으로서는, 예를 들어 라이센스의 필요성/불필요성, 애플리케이션명 및 갱신 일시 등이 포함된다. 그 가동 상태가 상태로서 포함된다. 애플리케이션이 일단 인스톨된 후에 언인스톨되었을 경우에도, 당해 애플리케이션의 항목을 테이블에 남기고, 인스톨/언인스톨을 나타내는 상태를 유지해도 된다. 애플리케이션의 인스톨이나 언인스톨, 상태의 변화는 이 테이블의 갱신을 트리거한다. 도 6a 및 도 6b에 나타내는 그룹 데이터 테이블 및 애플리케이션 데이터 테이블이 유지하는 항목에 대해서는 애플리케이션 관리 테이블에서 관리하는 필요는 없다. 단, 테이블에의 링크를 위한 정보, 예를 들어 애플리케이션 ID 및 프래그먼트 번들 ID는 중복해서 유지할 필요가 있다. 도 5a 및 도 5b의 애플리케이션 관리 화면은, 애플리케이션 관리 프레임워크(302)가 OSGi 프레임워크라면, OSGi 프레임워크에 의해 관리되어, 표시되고, 그 표시를 위해서 필요한 애플리케이션 관리 테이블 또한 OSGi 프레임워크에 의해 관리된다.
<리소스 서비스>
여기서 리소스 서비스(304)에 대해서 변경해서 설명한다. 리소스 서비스(304)는 애플리케이션 관리 프레임워크(302) 상에서 동작하는 애플리케이션의 하나이다. 애플리케이션 관리 프레임워크(302)가 OSGi 프레임워크라면, OSGi 프레임워크는 복수의 Java® 애플리케이션을 병렬로 실행하고, 그 애플리케이션 중 기능 제공 애플리케이션(서비스 번들으로도 칭하고, 본 예에서는 리소스 서비스에 상당한다)으로부터 애플리케이션 프로그램 인터페이스(API)를 개재해서 기능 이용 애플리케이션(서비스 소비 번들이라고도 칭한다)에 서비스를 제공하는 구조를 갖는다. 애플리케이션은 API를 개재해서 리소스 서비스에 대한 리소스 요구 혹은 리소스 해방에 의해 리소스의 취득이나 해방을 행한다. 리소스의 취득 및 해방은 Java 표준클래스로서 제공된 오브젝트(API)에 의해 행하여지고, 리소스 서비스는 그들 표준 클래스를 랩핑(wrapping)하는 래퍼 클래스(wrapper class)를 제공함으로써 리소스 관리를 위한 추가적인 서비스를 실현하고 있다. 추가적인 서비스는 리소스 요구 애플리케이션에 할당되는 리소스가 선언된 리소스 상한값을 초과할지 여부를 체크하고, 리소스가 선언된 리소스 상한값을 초과한다면, 요구를 거절하고, 리소스가 선언된 리소스 상한값을 초과하지 않는다면, 할당을 행하는 서비스이다. 리소스의 생성 및 애플리케이션에의 제공은, 랩핑된 표준 클래스에 의해 제공되는 기능에 의해 행하여진다.
리소스 서비스가 제공하는 기능은 전술한 바와 같이 API를 개재해서 행하여지고, API는 서비스 이용 애플리케이션마다 생성되는 오브젝트에 의해 실현된다. OSGi에서는, API는 API를 이용하는 서비스 이용 애플리케이션으로부터의 요구에 따라서 생성되어 제공된다. 서비스 이용 애플리케이션은 생성한 API를 사용해서 서비스 제공 애플리케이션인 리소스 서비스에 대하여 리소스 취득이나 해방 등의 서비스를 요구한다.
한편, 리소스 서비스는, 리소스 서비스를 사용하는 애플리케이션마다, 예를 들어 리소스 서비스의 API를 생성한 애플리케이션마다, 할당된 리소스의 양과, 할당되는 상한인 리소스 상한값을, 애플리케이션 ID와 관련지어서 기억하고 있다. 리소스 상한값은 당해 애플리케이션의 애플리케이션 리소스 상한 선언 파일(402)의 리소스 상한값(412)로부터 취득한 값이다. 또한, 프래그먼트 번들마다의 리소스 상한값, 즉 그룹마다의 리소스 상한값도 인스톨 시에 프래그먼트 번들 리소스 상한 선언 파일(422)로부터 판독해서 기억한다. 리소스 상한값에 추가하여, 그룹에 대하여 할당된 리소스량도 그룹 ID와 관련지어서 기억해 둔다. 리소스 서비스(304)에 의한 애플리케이션 리소스 상한 선언 파일로부터의 리소스 상한값의 특정과 판독은, 예를 들어 OSGi 에서는, 리소스 서비스를 이용하는 애플리케이션이 인스톨되고, 실행이 개시되어서 리소스 서비스에 대하여 API의 생성을 요구할 때에, 그 애플리케이션을 위한 API의 초기화 처리의 일부로서 행하면 충분하다. 혹은, OSGi 이외의 프레임워크의 경우, API 오브젝트를 생성하지 않으면, 리소스 취득 요구마다 리소스 상한값(412)을 참조하여도 된다.
리소스 서비스가, 예를 들어 리소스 취득 요구를 애플리케이션으로부터 수취하는 경우, 요구 애플리케이션이 단독 관리되는 애플리케이션이라면, 그 요구 애플리케이션에 할당된 리소스량을 참조하고, 그 값과 요구된 리소스량의 합을 당해 애플리케이션의 리소스 상한값과 비교한다. 상기 합이 리소스 상한값을 초과하면 리소스 요구를 거부하고, 그 취지를 요구 애플리케이션에 응답한다. 상기 합이 리소스 상한값을 초과하지 않으면, 리소스 오브젝트를 요구 애플리케이션에 대하여 돌려주고, 요구 애플리케이션에 할당된 리소스량에 요구된 리소스량을 가산한다. 리소스 오브젝트는, 리소스를 애플리케이션 프로그램에 의해 취급하기 위해서 생성한 오브젝트이다. 리소스 오브젝트를 애플리케이션에 이관하는 것은, 요구된 리소스를 애플리케이션에 할당하는 것에 상당한다.
리소스 취득 요구 애플리케이션이 그룹에 의해 관리되는 애플리케이션이라면, 그 요구 애플리케이션이 속하는 그룹에 할당된 리소스량을 참조하고, 그 값과 요구된 리소스량의 합을 당해 그룹의 리소스 상한값과 비교한다. 상기 합이 리소스 상한값을 초과하면 리소스 요구를 거부하고, 그 취지를 요구 애플리케이션에 응답한다. 상기 합이 리소스 상한값을 초과하지 않으면 리소스 오브젝트를 요구 애플리케이션에 대하여 돌려주고, 당해 그룹에 할당된 리소스량에 요구된 리소스량을 가산한다. 바꾸어 말하면, 리소스를 그룹에 의해 관리된 애플리케이션 군에 의해 공유한다. 그 애플리케이션 군에 속하는 애플리케이션으로부터의 리소스 요구가 있으면, 그 애플리케이션 군이 사용하고 있는 리소스량의 총계에 요구된 리소스량을 가산하고, 그 결과가 당해 그룹의 리소스 상한값, 즉 사용 리소스 선언량을 초과하는지 여부를 판정한다. 그 결과가 리소스 선언량을 초과하지 않고 있으면 리소스는 요구원에 할당된다. 또한, 애플리케이션의 그룹 관리는, (후술하는) 도 6b의 애플리케이션 데이터 테이블(620)을 검색하고, 애플리케이션 ID가 애플리케이션 데이터 테이블(620)에 등록되어 있고, 그룹 관리 상태가 유효한 것을 확인함으로써 행할 수 있다.
<그룹 데이터 테이블 및 애플리케이션 데이터 테이블>
도 6a는 본 실시예의 리소스 서비스(304)가 애플리케이션(11n)의 그룹 관리를 실시하기 위해서 필요로 하는 데이터를 유지하기 위한 데이터 테이블 중, 그룹 데이터 테이블(600)을 모식적으로 나타낸 것이다. 그룹 데이터 테이블(600)은, 예를 들어 기억 장치(202)에 저장된다. 프래그먼트 번들 ID란(601)은 프래그먼트 번들 ID(430)의 유지란이다. 그룹 ID란(602)은 그룹 ID(431)의 유지란이다. 검출 시각란(603)은 리소스 서비스(304)가 프래그먼트 번들(305)을 최초에 검출한 시각의 유지란이다. 리소스 서비스(304)가 프래그먼트 번들(305)을 최초에 검출하는 것은, 관리자가 리소스 서비스(304)를 개시/정지 버튼(510)으로 정지한 후, 프래그먼트 번들(305)의 인스톨을 행한 후, 다시 리소스 서비스(304)를 개시한 시각이다. 마찬가지로, 삭제 검출 시각란(604)은, 리소스 서비스(304)가 일단 인스톨되어서 검출된 프래그먼트 번들(305)이 삭제되어서 사라지는 것을 검출한 시각의 유지란이다. 마찬가지로, 삭제의 검출도 관리자가 프래그먼트 번들(305)의 언인스톨 조작을 행하고 리소스 서비스(304)를 다시 개시한 시각에 행해진다. 관리 대상 애플리케이션 ID란(605)은 그 프래그먼트 번들(305)에 의해 그룹으로서 관리되는 애플리케이션의 애플리케이션 ID(410)의 유지란이다. 유효화 상태란(606)은 당해 프래그먼트 번들이 유효한지 여부를 기록하는 유효화 상태의 유지란이다. 이 유효화 상태란(606)에는 "유효", "무효" 및 "언인스톨됨"의 3가지 상태가 유지될 수 있다. 엔트리(610)는 어떤 하나의 프래그먼트 번들(305)에 관한 그룹 데이터 테이블(600)의 엔트리이다.
도 6b는 본 실시예의 리소스 서비스(304)가 애플리케이션(11n)의 그룹 관리를 실시하기 위해서 필요로 하는 데이터를 유지하기 위한 데이터 테이블 중에서 애플리케이션 데이터 테이블(620)을 모식적으로 나타낸 것이다. 애플리케이션 데이터 테이블(620) 또한, 예를 들어 기억 장치(202) 등에 유지된다. 애플리케이션 ID란(621)은 애플리케이션 ID(410)의 유지란이다. 그룹 ID란(622)은 그룹 ID(431)의 유지란이다. 버전란(623)은 각 행의 애플리케이션(11n)의 버전의 유지란이다. 단독 관리 시의 리소스 상한값란(624)은, 이 애플리케이션(11n)의 그룹 관리 하에 있지 않은 상태에서의 애플리케이션 리소스 상한 선언 파일(402)에 의해 선언된 리소스 상한값(412)을 유지하는 단독 관리 시의 리소스 상한값의 유지란이다. 본체 파일 사이즈란(625)은 각각의 애플리케이션(11n)의 프로그램 본체 파일의 크기 값이다. 리소스 상한값(412)에 의해 선언된 스토리지의 값에서 프로그램 본체의 파일 크기 값(625)을 빼서 얻어지는 값이 그 애플리케이션(11n)이 그룹 관리 하에 있지 않은 상태에서 이용될 수 있는 데이터용 스토리지 영역의 크기이다. 그룹 관리 상태란(626)은 그 애플리케이션(11n)이 그룹 관리 하에 있는지의 여부를 나타내는 그룹 관리 상태의 유지란이다.
<리소스 서비스 기동 수순>
도 7a는 본 실시예에서의 리소스 서비스(304)가 기동되었을 때의 리소스 서비스에 의한 처리의 흐름을 나타낸 흐름도이다. 전술한 바와 같이, 리소스 서비스(304)에 대하여 그룹 정보를 유지하는 프래그먼트 번들(305)을 추가로 인스톨함으로써 그룹 정보를 추가로 인식시키는 것이 가능하다. 마찬가지로, 프래그먼트 번들(305)을 언인스톨함으로써 그룹 정보를 리소스 서비스의 제어 하에서 제거하는 것이 가능하다. 이때에, 리소스 서비스(304)는 프래그먼트 번들(305)에 대하여 호스트 번들로서 동작하고 있기 때문에, 프래그먼트 번들(305)의 인스톨 및 언인스톨 이전에 리소스 서비스를 일단 정지시킬 필요가 있다. 프래그먼트 번들(305)의 인스톨 및 언인스톨은 애플리케이션 관리 프레임워크(302)에 의해 실시된다. 여기서 설명하는 처리는, 프래그먼트 번들(305)이 인스톨 혹은 언인스톨된 후에, 리소스 서비스(304)가 정지 상태로부터 기동되는 때에 실행되는 것이다.
처리는 스텝 S7001로부터 개시한다. 스텝 S7002에서, 리소스 서비스(304)는 먼저 프래그먼트 번들(305)의 초기 상태를 확인한다. 예를 들어, 전회 종료 시까지 존재하지 않은 프래그먼트 번들(305)이 새롭게 인스톨되어 있지 않은지, 또는, 전회 종료 시까지 존재하고 있었던 프래그먼트 번들(305)이 언인스톨되어 있지 않은지 등을 체크한다. 이 체크는, 애플리케이션 관리 프레임워크(302)에 의해 관리된 애플리케이션에 관한 정보, 예를 들어 도 5a 및 도 5b에 관련해서 설명한 애플리케이션 관리 테이블을 참조함으로써 실현할 수 있다. 참조는, 예를 들어 애플리케이션 관리 프레임워크가 제공하는 기능을 통해서 행할 수 있다. 스텝 S7003에서는 새롭게 인스톨된 프래그먼트 번들(305)이 존재하는지 여부를 판정한다. 그러한 새롭게 인스톨된 프래그먼트 번들(305)이 존재하고 있으면 처리는 스텝 S7004로 진행한다. 새롭게 인스톨된 프래그먼트 번들(305)이 존재하지 않고 있으면 처리는 스텝 S7005로 진행한다. 스텝 S7004에서는 리소스 서비스(304)는 프래그먼트 번들(305)의 인스톨 시의 처리를 행한다. 프래그먼트 번들(305)의 인스톨 시의 처리가 완료하면 처리는 스텝 S7005로 진행한다.
스텝 S7005에서는, 리소스 서비스(304)는 언인스톨된 프래그먼트 번들(305)이 존재하는지 여부를 판정한다. 그러한 언인스톨된 프래그먼트 번들(305)이 존재하면 처리는 스텝 S7006으로 진행한다. 그러한 언인스톨된 프래그먼트 번들(305)이 존재하지 않으면 처리는 스텝 S7007로 진행한다. 스텝 S7006에서는 리소스 서비스(304)는 프래그먼트 번들(305)의 언인스톨 시의 처리를 행한다. 프래그먼트 번들(305)의 언인스톨 시의 처리가 완료하면 처리는 스텝 S7007로 진행한다. 처리가 스텝 S7007에 도달하면 리소스 서비스(304)의 기동 처리는 완료한다.
도 7b 내지 도 7e는 또한 프래그먼트 번들(305)의 인스톨 시의 처리인 스텝 S7004의 내용에 대해서 더 설명한 흐름도이다. 스텝 S7101에서, 일련의 처리가 개시한다. 스텝 S7102에서, 먼저 리소스 서비스(304)는 새롭게 인스톨된 프래그먼트 번들(305)로부터 그룹 정보, 구체적으로는 그룹 ID(431)를 취득한다. 그 후에, 스텝 S7103에서, 취득한 그룹 정보가 그룹 데이터 테이블(600)에 등록되었는지 여부를 판정한다. 취득된 그룹 정보가 등록되지 않았으면 처리는 스텝 S7104로 진행한다. 스텝 S7104에서, 취득된 그룹 정보가 그룹 데이터 테이블(600)에 등록되고, 처리는 스텝 S7106으로 진행한다. 취득된 그룹 정보가 등록되어 있으면, 처리는 스텝 S7105로 진행한다. 스텝 S7105에서는, 취득된 그룹 정보를 사용해서 그룹 데이터 테이블(600)의 데이터를 갱신하고, 처리는 스텝 S7106으로 진행한다. 스텝 S7104 및 스텝 S7105에서는, 도 6a에 나타낸 각 항목을 등록 또는 갱신한다. 프래그먼트 번들 ID란(601), 그룹 ID란(602), 관리 대상 애플리케이션 ID란(605)의 내용은, 프래그먼트 번들 상한 선언 파일(422)의 프래그먼트 번들 ID(430), 그룹 ID(431), 소속 애플리케이션 ID(433)로부터 취득한다. 검출 시각은, 검출한 시각을 실시간 클럭, 인터넷의 시각 사이트 등으로부터 판독하고, 그것을 기록한다. 스텝 S7106에서는, 인스톨된 애플리케이션(11n)이 인스톨된 프래그먼트 번들(305)이 유지하고 있는 그룹 정보가 나타내는 그룹에 속하는 애플리케이션(11n)을 포함하는지 여부를 체크한다. 만약 그러한 애플리케이션(11n)이 존재하지 않으면 처리는 스텝 S7117로 진행한다. 그러한 그룹에 속하는 애플리케이션(11n)이 존재하고 있을 경우에는, 그들 애플리케이션을 대상으로 해서 처리는 스텝 S7107로 진행한다.
스텝 S7107 내지 스텝 S7113에서는 그러한 애플리케이션(11n)에 대해서 반복적인 처리를 실행한다. 스텝 S7108에서는 리소스 서비스(304)는 애플리케이션 관리 프레임워크(302)를 통해서 처리 대상 애플리케이션(11n)이 개시하였는지 여부를 확인한다. 처리 대상 애플리케이션(11n)이 개시하였으면 처리는 스텝 S7109로 진행한다. 처리 대상 애플리케이션(11n)이 정지 상태라면 처리는 스텝 S7110으로 진행한다. 스텝 S7109에서는 처리 대상의 애플리케이션(11n)을 애플리케이션 관리 프레임워크(302)를 통해서 정지한다. 그 후 처리는 스텝 S7110으로 진행한다. 스텝 S7110에서는 처리 대상의 애플리케이션(11n)의 매니페스트에 기재되고 선언되어 있는 스토리지의 상한값을 취득한다. 스텝 S7111에서, 처리 대상의 애플리케이션의 현재의 스토리지 사용량을 취득한다. 이 값은, 예를 들어 애플리케이션 관리 프레임워크(302)를 통해서 애플리케이션 실행 플랫폼(301)으로부터 취득한다. 스텝 S7112에서, 리소스 서비스(304)는 애플리케이션 관리 프레임워크(302)를 통해서 처리 대상의 애플리케이션(11n)의 프로그램 본체 파일의 사이즈를 취득한다. 프로그램 본체 파일의 사이즈란, 프로그램 코드를 수용하는 파일 및 인스톨 시에 전개되어 프로그램 실행에 필요한 파일이 화상 형성 장치(100)에서 전개될 때에 이들 파일이 스토리지를 점유하는 사이즈의 합계를 가리킨다. 계속해서, 스텝 S7113에서, 처리 대상의 애플리케이션(11n)에 관한 반복 처리가 완료했는지를 판정한다. 상기 반복 처리가 완료하지 않으면 처리는 스텝 S7107로부터 속행된다. 상기 반복 처리가 완료되면 처리는 스텝 S7114로 진행한다.
스텝 S7114에서는 스텝 S7107로부터 시작하는 반복 처리에서 처리 대상의 애플리케이션(11n) 각각에 관하여 산출된 스토리지 사용량 가운데 데이터 부분의 사용량의 합계를 산출한다. 데이터 부분의 사용량은 스텝 S7111에서 취득한 스토리지 사용량으로부터 스텝 S7112에서 취득한 프로그램 본체 파일의 사이즈를 차감하여 얻어지는 값이다. 즉, 데이터 부분의 사용량은 애플리케이션(11n)의 인스톨 시에 전개된 프로그램 본체 파일 이외에, 가동 시에 나중에 추가적으로 사용한 스토리지의 사용량과 동일하다. 스텝 S7114에서는 이 데이터 부분의 사용량의 합계가 그룹에 속하는 인스톨된 애플리케이션 모두에 관해서 산출된다. 스텝 S7115에서, 이 합계 값이 처리 대상의 프래그먼트 번들(305)이 선언하고 있는 그룹의 스토리지의 상한값(432)을 초과하고 있는지 여부를 체크한다. 상기 합계 값이 상한값(432)을 초과하는 경우에는 처리는 스텝 S7116으로 진행한다. 상기 합계 값이 상기 상한값(432)을 초과하지 않을 경우에는 처리는 스텝 S7119로 진행한다.
스텝 S7119 내지 스텝 S7130에서는 인스톨되어서 그룹에 속해 있는 애플리케이션(11n)을 처리 대상으로 해서 반복 처리를 다시 행한다. 먼저, 스텝 S7120에서, 처리 대상의 애플리케이션(11n)의 애플리케이션 리소스 상한 선언 파일(402)의 리소스 상한값(412)을 재기입한 새로운 애플리케이션 리소스 상한 선언 파일(402)을 생성한다. 이 새로운 애플리케이션 리소스 상한 선언 파일(402)은, 스토리지에 대해서는 스텝 S7112에서 취득한 처리 대상의 애플리케이션(11n)의 프로그램 본체 파일의 사이즈를 상한값으로서 선언한다. 기타의 리소스에 대해서는 상한값은 0이다. 계속되는 스텝 S7121에서, 스텝 S7120로 생성한 애플리케이션 리소스 상한 선언 파일(402)과 기타의 프로그램 본체 파일을 통합해서 인스톨용 파일을 작성한다. 스텝 S7122에서, 리소스 서비스(304)는 스텝 S7121에서 작성한 인스톨용 파일을 사용해서 애플리케이션 관리 프레임워크(302)을 통해서 덮어쓰기 인스톨 조작을 행한다. 스텝 S7123에서, 덮어쓰기 인스톨에 성공했는지의 여부를 체크한다. 덮어쓰기 인스톨에 성공하였으면 처리는 스텝 S7124로 진행한다. 덮어쓰기 인스톨에 실패하였으면 처리는 스텝 S7128로 진행한다. 스텝 S7124에서는 처리 대상의 애플리케이션의 그룹 관리 상태(626)를 애플리케이션 데이터 테이블(620)에서 유효하게 변경한다. 스텝 S7125에서, 처리 대상의 애플리케이션(11n)이 지금까지 사용하고 있는 데이터 부분의 스토리지 리소스 및 기타의 리소스를 그룹 관리 하로 이관한다. 즉, 애플리케이션(11n) 단위의 관리를 인스톨된 프래그먼트 번들(305)이 나타내는 각 군에 대한 관리로 변경한다. 스텝 S7126에서, 인스톨된 프래그먼트 번들(305)의 그룹 관리가 그룹 데이터 테이블(600)에서 무효인지 여부를 판정한다. 인스톨된 프래그먼트 번들(305)의 그룹 관리가 무효가 아니면, 즉 유효하면, 처리는 스텝 S7128로 진행한다. 인스톨된 프래그먼트 번들(305)의 그룹 관리가 무효일 경우에는 처리는 스텝 S7127로 진행하여, 그룹 데이터 테이블(600)에서 유효화 상태(606)를 유효하게 변경한다. 그 후에, 처리는 스텝 S7128로 진행한다. 스텝 S7128에서는, 처리 대상의 애플리케이션(11n)이 정지 상태인지의 여부를 판정한다. 처리 대상 애플리케이션(11n)이 개시된 경우에는 처리는 스텝 S7130으로 진행한다. 처리 대상 애플리케이션(11n)이 정지 상태인 경우에는 처리는 스텝 S7129로 진행한다. 리소스 서비스(304)는 애플리케이션 관리 프레임워크(302)를 통해서 처리 대상의 애플리케이션(11n)을 개시시킨다. 그리고 처리는 스텝 S7130으로 진행한다. 스텝 S7130에서는, 처리 대상의 애플리케이션(11n)에 관한 반복 처리가 완료했는지의 여부를 확인한다. 반복 처리가 완료하지 않은 경우, 처리는 스텝 S7119로 복귀되어서 반복 처리를 속행한다. 반복 처리가 완료한 경우, 처리는 스텝 S7133으로 진행한다. 스텝 S7106에서 인스톨된 프래그먼트 번들(305)의 그룹에 속하는 애플리케이션(11n)이 하나도 인스톨되지 않고 있었을 경우에는 처리는 스텝 S7117로 진행한다. 스텝 S7117에서는 리소스 서비스(304)는 "인스톨된 프래그먼트 번들(305)의 그룹에 속하는 애플리케이션(11n)이 인스톨되지 않았다"고 경고를 출력한다. 그리고, 처리는 스텝 S7131로 진행한다.
스텝 S7115에서 인스톨된 프래그먼트 번들(305)의 그룹에 속하는 애플리케이션(11n)의 스토리지의 데이터 부분의 사용량의 합계가 그룹의 상한을 초과하는 경우에는 처리는 스텝 S7116로 진행한다. 스텝 S7116에서는, 리소스 서비스(304)는 "인스톨된 프래그먼트 번들(305)의 그룹에 속하는 애플리케이션(11n)의 스토리지의 사용량 총계가 그룹의 상한을 초과하고 있다"라는 경고를 출력한다. 그리고 처리는 스텝 S7131으로 진행한다.
스텝 S7131에서는, 인스톨된 프래그먼트 번들(305)의 그룹의 유효화 상태(606)가 무효화되었는지 여부를 체크한다. 무효화 상태(606)가 무효이면, 처리는 스텝 S7133으로 진행한다. 무효화 상태(606)가 유효이면, 처리는 스텝 S7132로 진행하여, 인스톨된 프래그먼트 번들(305)의 그룹의 유효화 상태(606)를 무효로 설정한다. 처리는 스텝 S7133으로 진행한다. 스텝 S7133에서는, 다른 인스톨된 프래그먼트 번들(305)이 있는지를 판정한다. 다른 인스톨된 프래그먼트 번들(305)이 있는 경우에는 그 프래그먼트 번들(305)에 관한 처리를 스텝 S7102로부터 속행한다. 다른 인스톨된 프래그먼트 번들(305)이 존재하지 않는 경우에는 처리는 스텝 S7134로 진행한다. 스텝 S7134에서 일련의 처리를 완료한다.
도 7f 및 7g는 프래그먼트 번들(305)의 언인스톨 시의 처리인 스텝 S7006의 내용에 대해서 더 설명한 흐름도이다. 스텝 S7201에서, 일련의 처리가 개시한다. 스텝 S7202에서, 먼저 리소스 서비스(304)는 언인스톨된 프래그먼트 번들(305)의 그룹 정보를 그룹 데이터 테이블(600)로부터 취득한다. 계속해서, 스텝 S7203에서, 그룹 데이터 테이블(600) 내의 유효화 상태(606)를 언인스톨 완료 상태로 변경한다. 스텝 S7204에서, 인스톨된 애플리케이션(11n)이 언인스톨된 프래그먼트 번들(305)에 의해 유지되는 그룹 정보에 의해 나타나는 그룹에 속하는 애플리케이션(11n)을 포함하는지 여부를 체크한다. 만약 그러한 애플리케이션(11n)이 존재하지 않으면 처리는 스텝 S7220으로 진행한다. 그러한 그룹에 속하는 애플리케이션(11n)이 인스톨되어 있는 경우에는, 처리는 스텝 S7205로 진행한다.
스텝 S7205 내지 스텝 S7219에서, 그룹에 속하는 그러한 애플리케이션(11n)에 대해서 반복 처리를 실행한다. 스텝 S7206에서는, 리소스 상한(412)의 부분이 재기입된 처리 대상의 애플리케이션(11n)의 애플리케이션 리소스 상한 선언 파일(402)을 생성한다. 이때 재기입되는 리소스 상한(412)의 값은, 처리 대상의 애플리케이션(11n)이 그룹 관리에 이관되는 때에 리소스 서비스(304)에 의해 재기입되기 전의 값을 사용한다. 즉, 처리 대상의 애플리케이션(11n)이 단독 관리 하에서 동작하고 있는 때에 선언되고 있는 상한값이 사용된다. 이 값은 애플리케이션 데이터 테이블(620)에 보존되고 있다. 스텝 S7207에서, 처리 대상의 애플리케이션의 프로그램 본체 파일 및 스텝 S7206에서 생성한 애플리케이션 리소스 상한 선언 파일(402)로부터 인스톨용 파일을 생성한다. 스텝 S7208에서, 리소스 서비스(304)는 스텝 S7207에서 생성한 파일을 사용해서 애플리케이션 관리 프레임워크(302)를 통해서 덮어쓰기 인스톨을 실행한다. 스텝 S7209에서는 덮어쓰기 인스톨이 성공했는지의 여부를 체크한다. 덮어쓰기 인스톨이 성공한 경우에는 처리는 스텝 S7210로 진행한다. 덮어쓰기 인스톨이 성공하지 않은 경우에는 처리는 스텝 S7217로 진행한다.
스텝 S7210에서는 처리 대상의 애플리케이션(11n)이 개시되었는지 여부를 체크한다. 처리 대상의 애플리케이션(11n)이 정지 상태라면 처리는 스텝 S7212로 진행한다. 처리 대상의 애플리케이션(11n)이 개시되었다면, 처리는 스텝 S7211로 진행한다. 스텝 S7211에서는 처리 대상의 애플리케이션(11n)을 개시한다. 그리고 처리는 스텝 S7212로 진행한다. 스텝 S7212에서는 처리 대상의 애플리케이션(11n)에 대해서 그룹 관리 하에서 확보되고 있었던 리소스를 그 애플리케이션(11n)의 단독 관리 하에서 확보하고 있는 영역으로 이관하는 동시에 사용량을 단독 관리의 사용량으로서 다시 합계한다. 스텝 S7213에서, 애플리케이션 데이터 테이블(620)의 그룹 관리 상태(626)를 무효로 변경한다. 스텝 S7214에서, 처리 대상의 애플리케이션(11n)이 사용하고 있는 데이터용의 스토리지의 사용량과 프로그램 본체의 파일 사용량을 더하여 얻어지는 값을 체크한다. 즉, 그 값이 처리 대상의 애플리케이션(11n)의 단독 관리에서의 스토리지의 상한 선언값을 초과하는지 여부를 확인한다. 이 값이 상한 선언값을 초과하는 경우에는 처리는 스텝 S7218로 진행한다. 이 값이 상한값 내에 들어가는 경우에는 처리는 스텝 S7215로 진행한다. 스텝 S7215에서는 처리 대상의 애플리케이션이 정지 상태인지의 여부를 확인한다. 처리 대상의 애플리케이션이 정지 상태라면 처리는 스텝 S7216으로 진행한다. 스텝 S7216에서는 리소스 서비스(304)는 처리 대상의 애플리케이션(11n)을 애플리케이션 관리 프레임워크(302)를 통해서 개시시킨다. 그리고, 처리는 스텝 S7219로 진행한다.
스텝 S7209에서 덮어쓰기 인스톨이 실패했다고 판정했을 경우에는 처리는 스텝 S7217로 진행한다. 스텝 S7217에서는 "그룹 관리 하의 애플리케이션(11n)을 단독 관리로 되돌리는 처리에서 에러가 발생하였다"는 것을 나타내는 경고를 출력한다. 처리는 스텝 S7219로 진행한다.
스텝 S7214에서 그 합이 처리 대상의 애플리케이션(11n)의 단독 관리에서의 스토리지의 상한값을 초과하고 있었을 경우에는 처리는 스텝 S7218로 진행한다. 스텝 S7218에서는 리소스 서비스(304)는 "그룹 관리 하에 있는 애플리케이션(11n)을 단독 관리로 복귀시켰지만 스토리지의 사용량이 상한을 초과하기 때문에, 애플리케이션(11n)의 실행을 일시적으로 정지한다"는 것을 나타내는 경고를 출력한다. 처리는 스텝 S7219로 진행한다.
스텝 S7219에서는, 모든 처리 대상의 애플리케이션(11n)에 관한 반복 처리가 완료했는지를 판정한다. 아직 처리되지 않은 처리 대상의 애플리케이션(11n)이 잔존하는 경우에는 처리는 스텝 S7205로부터 속행한다. 모든 처리 대상 애플리케이션(11n)에 관한 처리가 완료하면 처리는 스텝 S7220으로 진행한다. 스텝 S7220에서는 다른 언인스톨된 프래그먼트 번들(305)이 있는지를 체크한다. 다른 언인스톨된 프래그먼트 번들(305)이 있으면 처리는 다음 프래그먼트 번들(305)로부터 스텝 S7202로부터 속행된다. 언인스톨된 프래그먼트 번들(305)이 없을 경우에는 처리는 스텝 S7221로 진행한다. 스텝 S7221에서, 일련의 처리는 완료한다.
<리소스 관리의 구체적 설명>
도 8은 본 실시예에서 리소스 서비스(304)가 스토리지의 그룹 관리를 행하는 방법을 더 모식적으로 도시한 도면이다.
상태(800)는 리소스 서비스(304)에 대하여 프래그먼트 번들(305)이 인스톨되어 있지 않은 상태를 나타내고 있다. 이때, 애플리케이션 ALPHA가 선언하고 있는 상한값은 상한값(809)에 의해 나타나는 크기이다. 이 중에서, 애플리케이션 ALPHA의 프로그램 본체의 파일이 점유하는 사용량은 사용량(801)에 의해 나타나는 크기이다. 애플리케이션 ALPHA의 동작 시에 데이터용의 파일을 작성하는 데에 사용되는 스토리지의 양은 사용량(802)에 의해 나타나는 크기이다. 빈 용량이 용량(803)이다. 이것은 애플리케이션 BETA에 대해서도 마찬가지이다. 상한값은 상한값(819)으로 나타난다. 프로그램 본체의 파일이 스토리지를 점유하고 있는 양은 사용량(811)으로 나타나는 크기이며, 데이터용의 파일을 작성하는 데에 사용되는 양은 사용량(812)으로 나타난다. 빈 용량은 용량(813)이다. 이것은 또한 애플리케이션 GAMMA에 대해서도 마찬가지이다. 상한값이 상한값(829)으로 나타난다. 프로그램 본체의 파일이 스토리지를 점유하는 양이 사용량(821)으로 나타나며, 데이터용의 사용량이 사용량(822)이며, 빈 용량이 용량(823)이다. 또한 각각의 애플리케이션(11n)이 인스톨되고 있는 상태에서 프로그램 본체의 파일의 용량이 점유하고 있는 용량은 각각 용량(801, 811, 821)이다. 애플리케이션 관리 프레임워크(302)의 원칙에 의해, 이 용량을 애플리케이션과 분리해서 관리할 수는 없다.
상태(890)는 프래그먼트 번들(305)이 인스톨된 상태를 나타내고 있다. 프래그먼트 번들(305)이 인스톨된 상태에서의 그룹 전체에서 데이터에 대해서 사용가능한 스토리지의 양은 용량(899)으로 나타난다. 전술한 원칙에 따르면, 예를 들어 애플리케이션 ALPHA에 대하여는, 프로그램 본체의 파일이 스토리지를 점유하는 용량(801)만이 애플리케이션 리소스 상한 선언 파일(402)에 의해 확보되어야 한다. 마찬가지로, 애플리케이션 BETA에 대해서도 용량(811)에 의해 나타나는 용량이 확보될 필요가 있다. 또한, 애플리케이션 GAMMA에 대해서도 용량(821)을 확보할 필요가 있다. 본 실시예에서는, 프래그먼트 번들(305)이 인스톨된 상태에서도 이들 용량에 대해서는 이들 애플리케이션의 애플리케이션 리소스 상한 선언 파일(402)에 의해 선언되어 확보될 필요가 있다. 이를 위하여, 프래그먼트 번들(305)의 인스톨과정에서, 애플리케이션 리소스 상한 선언 파일(402)을 재기입하는 처리를 행하고 있다. 그 결과, 화살표 831에 의해서 나타나는 바와 같이, 프로그램 본체 파일의 사용량(801, 811, 821)은 각 애플리케이션의 리소스의 사용량으로서 남는다. 한편, 단독 관리 시에는, 각 애플리케이션의 선언된 영역 내에서 확보되고 있는 데이터용의 영역의 사용량(802, 812, 822)은 이관된다. 화살표 832에 의해 나타난 바와 같이, 프래그먼트 번들(305) 내의 그룹에 대하여 새롭게 확보된 리소스 영역 내에서 사용량(802, 812, 822)이 관리된다. 이에 의해, 리소스 서비스(304)는 이 스토리지에 대한 사용량의 합계가 프래그먼트 번들(305)에 할당된 영역(899)의 크기를 초과하지 않도록 관리를 속행할 수 있다. 프래그먼트 번들(305)을 언인스톨할 때에는 역의 조작을 행한다.
<애플리케이션의 인스톨 수순>
도 9는 본 실시예에서의 애플리케이션(11n)의 인스톨의 처리 시퀀스를 모식적으로 나타낸 흐름도이다. 애플리케이션 관리 프레임워크(302)로부터 애플리케이션(11n)의 인스톨이 행하여졌다는 통지를 수취하면 리소스 서비스(304)가 이 시퀀스를 실행한다. 스텝 S9001로부터 처리를 개시한다. 스텝 S9002에서 리소스 서비스(304)는 애플리케이션 관리 프레임워크(302)로부터 인스톨된 애플리케이션(11n)의 데이터를 수취한다. 스텝 S9003에서, 리소스 서비스(304)는 애플리케이션 데이터 테이블(620)에 인스톨된 애플리케이션(11n)의 데이터를 등록한다. 스텝 S9004에서, 인스톨된 애플리케이션이 속하는 그룹이 판정된다. 인스톨된 애플리케이션이 어떠한 그룹에도 속하지 않으면 처리는 스텝 S9017로 진행한다. 인스톨된 애플리케이션이 어떠한 그룹에 속해 있는 경우에는 처리는 스텝 S9005로 진행한다. 스텝 S9005에서는 인스톨된 애플리케이션이 속해 있는 그룹의 정보가 그룹 데이터 테이블(600)에 등록되어 있는지의 여부를 판정한다. 정보가 등록되어 있지 않으면 처리는 스텝 S9017로 진행한다. 정보가 등록되어 있으면 처리는 스텝 S9006으로 진행한다. 스텝 S9006에서는 인스톨된 애플리케이션(11n)이 속하는 그룹의 그룹 정보가 그룹 데이터 테이블(600)의 유효화 상태(606)에서 유효한지의 여부를 체크한다. 그룹 정보가 무효인 경우, 처리는 스텝 S9017로 진행한다. 그룹 정보가 유효할 경우에는 처리는 스텝 S9008로 진행한다. 스텝 S9004 내지 스텝 S9007의 판정은, 그룹 데이터 테이블(600) 및 애플리케이션 데이터 테이블(620)을 검색하여 행할 수 있다. 스텝 S9008에서는 인스톨된 애플리케이션(11n)이 개시되었는지의 여부를 판정한다.
처리 대상 애플리케이션(11n)이 정지 상태라면 처리는 스텝 S9010으로 진행한다. 인스톨된 애플리케이션(11n)이 개시되었다면, 처리는 스텝 S9009로 진행한다. 스텝 S9009에서는 리소스 서비스(304)는 애플리케이션 관리 프레임워크(302)를 통해서 인스톨된 애플리케이션(11n)을 정지한다. 그 후, 처리는 스텝 S9010으로 진행한다. 스텝 S9010에서는 리소스 서비스(304)는 인스톨된 애플리케이션(11n)의 프로그램 본체의 파일 사이즈를 취득한다. 스텝 S9011에서, 인스톨된 애플리케이션(11n)의 애플리케이션 리소스 상한 선언 파일(402)의 리소스 상한값(412)을 재기입한 새로운 애플리케이션 리소스 상한 선언 파일(402)을 생성한다. 이 새로운 애플리케이션 리소스 상한 선언 파일(402)은 스토리지에 대해서는 전단에서 취득한, 인스톨될 애플리케이션(11n)의 프로그램 본체 파일의 사이즈를 상한값으로서 선언한다. 기타의 리소스에 대해서는 상한값은 0이다. 즉, 그룹 관리가 가능하다면, 단독 관리용의 리소스 상한값을, 그룹 관리용의 리소스 상한값으로 치환한다. 스텝 S9012에서, 스텝 S9011에서 생성한 애플리케이션 리소스 상한 선언 파일(402)과 기타의 프로그램 본체 파일을 통합해서 인스톨용 파일을 작성한다. 스텝 S9013에서, 리소스 서비스(304)는 스텝 S9012에서 작성한 인스톨용 파일을 사용해서 애플리케이션 관리 프레임워크(302)를 통해서 덮어쓰기 인스톨 조작을 행한다. 스텝 S9014에서, 덮어쓰기 인스톨에 성공했는지의 여부를 체크한다. 덮어쓰기 인스톨에 성공했으면 처리는 스텝 S9015로 진행한다. 덮어쓰기 인스톨에 실패했으면 처리는 스텝 S9109로 진행한다. 스텝 S9015에서는 인스톨된 애플리케이션(11n)의 애플리케이션 데이터 테이블(620)에서의 그룹 관리 상태(626)를 유효한 상태로 변경한다. 그 후, 처리는 스텝 S9019로 진행한다.
스텝 S9017로 처리가 진행하면 리소스 서비스(304)는 애플리케이션 관리 프레임워크(302)를 통해서 인스톨된 애플리케이션이 정지 상태일지를 체크한다. 인스톨된 애플리케이션이 정지 상태라면 처리는 스텝 S9018로 진행한다. 인스톨된 애플리케이션이 개시되었다면 처리는 스텝 S9019로 진행한다. 스텝 S9018에서는 리소스 서비스(304)는 애플리케이션 관리 프레임워크(302)를 통해서 인스톨된 애플리케이션(11n)을 개시시킨다. 처리는 스텝 S9019로 진행한다. 스텝 S9019에서는 일련의 처리가 완료한다.
이 수순에 의해, 그룹 관리 대상인 애플리케이션이 인스톨되었지만 그룹 관리할 수 있는 상태가 아니면, 애플리케이션 단독으로 리소스가 관리되어, 애플리케이션이 실행된다.
<애플리케이션의 언인스톨 수순>
도 10은 본 실시예에서의 애플리케이션(11n)의 언인스톨의 처리 시퀀스를 모식적으로 나타낸 흐름도이다. 애플리케이션 관리 프레임워크(302)로부터 애플리케이션(11n)의 언인스톨이 행하여졌다는 통지를 수취한 리소스 서비스(304)가 이 시퀀스를 실행한다. 스텝 S10001로부터 처리를 개시한다. 스텝 S10002에서 리소스 서비스(304)는 언인스톨된 애플리케이션(11n)의 데이터를 수취한다. 스텝 S10003에서 언인스톨된 애플리케이션(11n)이 취득한 리소스 중에서 해방되지 않은 리소스가 있는지의 여부를 체크한다. 해방되지 않은 리소스가 없을 경우에는 처리는 스텝 S10010으로 진행한다. 해방되지 않은 리소스가 존재하는 경우에는 처리는 스텝 S10004로 진행한다.
스텝 S10004에서는 언인스톨된 애플리케이션(11n)이 취득한 리소스 중에서 해방되지 않은 리소스에 대해서 반복 처리를 실행한다. 스텝 S10005에서 리소스의 해방이 가능한지 여부를 체크한다. 리소스의 해방이 가능하면 처리는 스텝 S10006으로 진행한다. 리소스의 해방이 불가능한 경우에는 처리는 스텝 S10008로 진행한다. 스텝 S10006에서는 리소스를 해방한다. 스텝 S10007에서 해방된 리소스의 양을 관리 단위의 사용량으로부터 감산한다. 예를 들어, 해방된 리소스의 양은, 단독 관리의 경우에는, 전체의 사용량으로부터 감산되고, 그룹 관리의 경우에는, 그룹의 사용량으로부터 감산된다. 그 후에, 처리는 스텝 S10009로 진행한다. 스텝 S10008로 처리가 진행했을 경우에는 리소스 서비스(304)는 "리소스의 해방에 실패했다"는 경고를 출력한다. 처리는 스텝 S10009로 진행한다. 스텝 S10009에서는 반복 처리의 대상이 되는 리소스를 모두 처리했는지를 판정한다. 처리되지 않은 리소스가 남은 경우에는, 처리는 스텝 S10004로 복귀되어서 속행한다. 모든 리소스가 처리된 경우에는, 처리는 스텝 S10010으로 진행한다.
스텝 S10010에서는 언인스톨된 애플리케이션(11n)이 그룹에 속하는지를 판정한다. 언인스톨된 애플리케이션(11n)이 그룹에 속하지 않으면 처리는 스텝 S10013으로 진행한다. 언인스톨된 애플리케이션(11n)이 그룹에 속하는 경우에는 처리는 스텝 S10011로 진행한다. 스텝 S10011에서는 언인스톨된 애플리케이션(11n)이 속하는 그룹에 다른 인스톨된 애플리케이션(11n)이 존재하고 있는지를 판정한다. 이 판정에서는, 예를 들어 애플리케이션 데이터 테이블(620)로부터 언인스톨된 애플리케이션과 같은 그룹에 속하는 다른 애플리케이션을 검색하고, 그러한 애플리케이션이 존재하는 경우에는 이 애플리케이션에 대응하는 그룹 관리 상태(626)를 참조한다. "유효한" 그룹 관리가 존재하는 경우에는, 동일한 그룹에 속하는 다른 애플리케이션 존재하고 있다고 판정할 수 있다. 동일한 그룹에 속하는 다른 애플리케이션(11n)이 존재하고 있으면 처리는 스텝 S10013으로 진행한다. 다른 애플리케이션(11n)이 존재하지 않으면 처리는 스텝 S10012로 진행한다. 스텝 S10012에서는 언인스톨된 애플리케이션(11n)이 속하는 그룹의 유효화 상태(606)를 무효로 변경한다. 이 스텝에서는, 예를 들어 그룹 데이터 테이블(600)의 해당하는 그룹의 유효화 상태(606)를 "무효"로 재기입한다. 처리는 스텝 S10013으로 진행한다. 스텝 S10013에서는 언인스톨된 애플리케이션(11n)의 정보를 애플리케이션 데이터 테이블(620)로부터 소거한다. 처리는 스텝 S10014로 진행한다. 스텝 S10014에서 일련의 처리를 완료한다.
전술한 바와 같이, 본 발명의 제1 실시예에서는, 리소스 서비스(304)를 사용함으로써, 애플리케이션(11n)은 애플리케이션마다 리소스를 배타적으로 관리하는 단독 관리 하에서 동작하는 것이 가능하다. 리소스 서비스(304)는, 그러한 애플리케이션(11n)이 단독 관리 하에 있는 경우에도, 그 애플리케이션 리소스 상한 선언 파일(402)에 의해 선언되는 리소스 상한(412)을 초과하지 않도록 애플리케이션(11n)을 제어할 수 있다. 또한, 본 실시예에 따르면, 리소스 서비스(304)는 그룹 정보를 유지하는 프래그먼트 번들(305)을 인스톨함으로써 애플리케이션(11n)을, 그룹에 속하는 애플리케이션 간에 리소스를 공유하는 그룹 관리 하에서 동작시키는 것이 가능하다. 이때, 리소스 서비스(304)는, 애플리케이션(11n)이 그룹 관리 하에서 동작하는 때에 그룹에 대하여 설정된 리소스의 상한값을 초과하지 않도록 애플리케이션(11n)을 제어할 수 있다. 본 실시예에서는, 애플리케이션(11n)이 동작하고 있는 상태에서 프래그먼트 번들(305)이 인스톨되었을 경우에도, 리소스 서비스(304)는 모순없이 리소스 관리를 계속할 수 있다. 이 경우, 애플리케이션(11n)은 단독 관리로부터 그룹 관리로 계속적으로 이행하는 것이 가능하다. 마찬가지로, 프래그먼트 번들(305)이 언인스톨되는 때에, 애플리케이션(11n)을 그룹 관리로부터 단독 관리로 이행해서 계속적으로 사용하는 것이 가능하다. 이와 같이, 본 실시예에서는 애플리케이션(11n)의 리소스 관리에 관한 단독 관리와 그룹 관리의 두 가지 양상을 자유로이 전환하여 적용하는 것을 가능하게 한다.
그 결과, 본 실시예에 따르면, 복수의 애플리케이션(11n)을 조합해서 도입할 때에 그룹 정보를 유지하는 프래그먼트 번들(305)을 이용할 수 있다. 그룹의 리소스의 상한을, 각각의 애플리케이션(11n)이 단독으로 선언하는 상한의 단순한 합계 값보다 적게 억제하는 것이 가능해진다. 이에 의해, 본 실시예의 리소스 관리 장치를 설치하지 않은 경우에는, 리소스 상한값의 합계가 애플리케이션 실행 환경의 제한을 초과하기 때문에 도입할 수 없었던 조합의 애플리케이션(11n)을 도입하는 것이 가능해지는 효과가 얻어질 수 있다. 또한, 본 실시예에 따르면, 그룹 정보를 갖는 프래그먼트 번들(305)은, 그룹 관리가 필요하게 되었을 때에만 도입하는 것으로 충분하다. 이에 의해, 애플리케이션(11n)의 도입의 장애물을 낮출 수 있고, 화상 형성 장치(100)를 관리하는 관리자의 부담이 대폭 경감하는 효과가 얻어진다.
그룹 관리 대상인 애플리케이션에 대하여 그룹의 프래그먼트 번들이 인스톨되어 있지 않은 경우, 혹은 프래그먼트 번들이 인스톨되어 있어도 무효인 경우에는, 당해 애플리케이션은 단독 관리 대상인 애플리케이션으로 간주되어 리소스가 관리된다.
[제2 실시예]
본 발명의 제2 실시예에 대해서 첨부 도면을 참조해서 해설한다. 제1 실시예에서는, 애플리케이션(11n)을 단독 관리 상태에서도 가동시키기 위해서, 애플리케이션 리소스 상한 선언 파일(402)의 리소스 상한값(412)에 단독 관리 하의 가동 시의 값이 기재될 필요가 있다. 그러나, 그룹 관리 상태에서의 가동이 전제라면, 그러한 값의 선언은 불필요하다. 제2 실시예에서는, 그룹 관리 상태에 정확하게 놓이지 않고 있는 애플리케이션(11n)을 정지 상태로 이행시킴으로써, 그룹 관리에 의한 애플리케이션(11n)의 리소스 관리를 용이하게 행하는 리소스 관리 장치를 설명한다.
본 발명의 제2 실시예의 장치 구성은 도 1에 도시하는 것과 마찬가지이다. 제2 실시예에서의 화상 형성 장치(100)의 하드웨어 구성은 도 2에 도시한 것과 마찬가지이다. 제2 실시예에서의 애플리케이션(11n)을 실행하기 위한 애플리케이션 실행 환경의 구성은 도 3에 도시한 것과 마찬가지이다. 제2 실시예에서의 애플리케이션(11n)을 구성하는 파일의 내용 및 프래그먼트 번들(305)을 구성하는 파일의 내용은 도 4b에 도시한 것과 마찬가지이다.
도 11a 및 도 11b는 본 실시예에서의 애플리케이션 관리 프레임워크(302)의 화면(유저 인터페이스)의 일례를 나타낸 것이다. 도 5a 및 도 5b와의 차이점에 대해서만 설명한다. 본 실시예에서는, 그룹 정보에 의해서 나타나는 그룹에 속하는 애플리케이션(11n)은, 그 그룹 정보를 갖는 프래그먼트 번들(305)이 인스톨되어 있지 않은 상태에서는 정지 상태로 설정된다. 그것은 도 11a의 상태란(1100)에 나타난다. 그룹에 속하는 애플리케이션 ALPHA, 애플리케이션 BETA, 애플리케이션 GAMMA를 나타내는 상태란(1100)은 정지 상태로 설정된다. 이에 대해, 행(530)에 의해 나타낸 바와 같이, 프래그먼트 번들(305)이 인스톨되면, 도 11b의 상태란(1101)에 의해 나타나는 바와 같이, 애플리케이션(11n)이 개시 상태로 이행한다.
본 실시예에서의 그룹 데이터 테이블(600)의 내용은 도 6a와 마찬가지이다. 본 실시예에서의 리소스 서비스(304)가 기동되었을 때의 처리의 흐름은 도 7a에 나타낸 것과 마찬가지이다.
<제2 실시예에서의 프래그먼트 번들의 인스톨 처리>
프래그먼트 번들(305)의 인스톨 시의 처리인 스텝 S7004의 내용을 도 12a의 흐름도에 나타내고 설명한다. 본 실시예에서는, 스토리지에 대하여, 애플리케이션 리소스 상한 선언 파일(402)의 리소스 상한값(412)으로서 프로그램 본체의 파일 사이즈가 부여되고, 다른 종류의 리소스로서, 0이 부여되고 있다. 즉, 제1 실시예에서의 그룹 관리 하의 각 애플리케이션의 리소스 상한값이 애플리케이션 리소스 상한 선언 파일(402)에 의해 정의되고 있다.
스텝 S12101에서, 일련의 처리가 개시한다. 스텝 S12102에서, 리소스 서비스(304)는 인스톨된 프래그먼트 번들(305)로부터 그룹 정보를 취득한다. 스텝 S12103에서, 취득된 그룹 정보가 그룹 데이터 테이블(600)에 등록되었는지의 여부를 판정한다. 취득된 그룹 정보가 등록되지 않았으면 처리는 스텝 S12104로 진행한다. 스텝 S12104에서는 그룹 데이터 테이블(600)에 상기 취득된 그룹 정보를 등록하고, 처리는 스텝 S12106으로 진행한다. 취득된 그룹 정보가 등록되었으면 처리는 스텝 S12105로 진행한다. 스텝 S12105에서는 취득된 그룹 정보를 사용해서 그룹 데이터 테이블(600)의 데이터를 갱신하고, 처리는 스텝 S12106으로 진행한다. 스텝 S12106에서는, 인스톨된 애플리케이션(11n)이 인스톨된 프래그먼트 번들(305)이 유지하고 있는 그룹에 속하는 애플리케이션(11n)을 포함하는지 여부를 체크한다. 만약 그러한 애플리케이션(11n)이 존재하지 않으면 처리는 스텝 S12113으로 진행한다. 그러한 그룹에 속하는 애플리케이션(11n)이 존재하는 경우에는 처리는 스텝 S12107로 진행한다.
스텝 S12107 내지 스텝 S12110에서는 그러한 그룹에 속해 있는 애플리케이션(11n)에 대하여 반복 처리를 행한다. 스텝 S12108에서, 처리 대상인 애플리케이션(11n)이 정지 상태인지의 여부를 판정한다. 처리 대상인 애플리케이션(11n)이 정지 상태가 아닐 경우에는 처리는 스텝 S12109로 진행한다. 처리 대상인 애플리케이션(11n)이 정지 상태라면 처리는 스텝 S12110으로 진행한다. 스텝 S12109에서는 리소스 서비스(304)가 애플리케이션 관리 프레임워크(302)를 통해서 처리 대상인 애플리케이션(11n)을 개시하고, 처리는 스텝 S12110으로 진행한다. 스텝 S12110에서는, 다른 처리 대상인 애플리케이션(11n)이 존재하는지의 여부를 판정한다. 다른 처리 대상인 애플리케이션(11n)이 존재하는 경우에는 스텝 S12107로부터의 반복 처리를 속행한다. 다른 처리 대상인 애플리케이션(11n)이 존재하지 않는 경우에는 처리는 스텝 S12112로 진행한다. 스텝 S12109에서는 인스톨된 프래그먼트 번들(305)이 유지하고 있는 그룹에 관해서 그룹 관리를 유효화하고 처리는 스텝 S12114로 진행한다. 처리가 스텝 S12106으로부터 스텝 S12113로 진행했을 경우에는, 리소스 서비스(304)는 "그룹에 속하는 애플리케이션이 인스톨되어있지 않다"라는 경고를 출력한다. 스텝 S12113의 처리가 완료하면 처리는 또한 스텝 S12114로 진행한다. 스텝 S12114에서는 다른 인스톨된 프래그먼트 번들(305)이 있는지를 리소스 서비스가 체크한다. 다른 인스톨된 프래그먼트 번들(305)이 존재하는 경우에는 처리는 스텝 S12102로 복귀하여, 그 프래그먼트 번들(305)에 대해서 마찬가지의 처리를 실행한다. 다른 프래그먼트 번들(305)이 존재하지 않는 경우에는 처리는 스텝 S12115로 진행하여, 일련의 처리를 종료한다.
<제2 실시예에서의 프래그먼트 번들의 언인스톨 수순>
프래그먼트 번들(305)의 언인스톨 시의 처리인 스텝 S7006의 내용에 대해서 도 12b 및 도 12c를 참조해서 설명한다. 스텝 S12201에서, 일련의 처리가 개시한다. 스텝 S12202에서 리소스 서비스(304)는 그룹 데이터 테이블(600)을 참조해서 언인스톨된 프래그먼트 번들(305)의 그룹 정보를 취득한다. 스텝 S12203에서 그룹 데이터 테이블(600)의 당해 그룹에 관해서 삭제 검출 시각(604)을 갱신하고, 유효화 상태(606)를 "언인스톨됨"으로 갱신한다. 스텝 S12204에서는, 인스톨된 애플리케이션(11n)이, 언인스톨된 프래그먼트 번들(305)이 유지하고 있던 그룹 정보가 나타내는 그룹에 속했던 애플리케이션(11n)을 포함하는지를 체크한다. 그러한 애플리케이션(11n)이 없을 경우에는 처리는 스텝 S12216으로 진행한다. 그러한 그룹에 속하는 애플리케이션(11n)이 존재하는 경우에는 처리는 스텝 S12205로 진행한다. 스텝 S12205 내지 스텝 S12215에서는 대상 애플리케이션(11n)에 대해서 반복 처리를 행한다. 스텝 S12206에서는 처리 대상인 애플리케이션(11n)이 개시하였는지 여부를 판정한다. 처리 대상인 애플리케이션(11n)이 개시하지 않았지만 정지 상태인 경우에는 처리는 스텝 S12208로 진행한다. 처리 대상인 애플리케이션(11n)이 개시한 경우에는 처리는 스텝 S12207로 진행한다. 스텝 S12207에서는 리소스 서비스(304)가 애플리케이션 관리 프레임워크(302)를 통해서 처리 대상인 애플리케이션(11n)을 정지한다. 그 후에 처리는 스텝 S12208로 진행한다. 스텝 S12208에서는 리소스 서비스(304)는 처리 대상인 애플리케이션(11n)이 취득한 리소스 중에서 해방되지 않은 리소스가 있는지를 판정한다. 해방되지 않은 리소스가 있을 경우에는 처리는 스텝 S12209로 진행한다. 해방되지 않은 리소스가 존재하지 않을 경우에는 처리는 스텝 S12215로 진행한다.
스텝 S12209 내지 스텝 S12214에서는 그러한 해방되지 않은 리소스에 대해서 반복 처리를 행한다. 스텝 S12210에서 처리 대상인 해방되지 않은 리소스가 해방가능한지 여부를 체크한다. 그러한 리소스가 해방가능한 경우에는 처리는 스텝 S12211로 진행한다. 스텝 S12211에서는 리소스를 실제로 해방하는 처리를 행하고, 처리는 스텝 S12212로 진행한다. 스텝 S12212에서는 해방된 리소스의 사용량을 전체로서 관리하고 있는 리소스의 사용량으로부터 감산한다. 그리고, 처리는 스텝 S12214로 진행한다. 리소스의 해방이 가능하지 않을 경우에는 처리는 스텝 S12213으로 진행한다. 스텝 S12213에서는 "리소스의 해방에 실패했다"라는 경고를 출력하고, 처리는 스텝 S12214로 진행한다. 스텝 S12214에서는 처리 대상인 리소스가 아직 존재하는지를 판정한다. 처리 대상인 리소스가 존재하는 경우에는 처리는 스텝 S12209에 복귀되어서 반복 처리를 속행한다. 처리 대상인 리소스가 존재하지 않는 경우에는 처리는 스텝 S12215로 진행한다. 스텝 S12215에서는 처리 대상인 애플리케이션(11n)이 아직 존재할지를 판정한다. 처리 대상인 애플리케이션(11n)이 존재하는 경우에는 처리는 스텝 S12205로 복귀되어서 반복 처리를 속행한다. 처리 대상인 애플리케이션(11n)이 존재하지 않는 경우에는 처리는 스텝 S12216으로 진행한다.
스텝 S12216에서는 다른 언인스톨된 프래그먼트 번들(305)이 존재하는지의 여부를 체크한다. 다른 언인스톨된 프래그먼트 번들(305)이 존재하는 경우에는 그 프래그먼트 번들(305)을 처리 대상으로 하고, 처리는 스텝 S12202로부터 속행된다. 다른 언인스톨된 프래그먼트 번들(305)이 존재하지 않는 경우에는 처리는 스텝 S12217로 진행하여, 일련의 처리를 종료한다.
<애플리케이션 인스톨 시의 리소스 서비스의 동작>
도 13은 본 실시예에서의 애플리케이션(11n)의 인스톨이 행하여졌을 때의 리소스 서비스(304)의 동작을 모식적으로 나타낸 흐름도이다. 처리는 스텝 S13001로부터 개시된다. 스텝 S13002에서는 리소스 서비스(304)가 애플리케이션 관리 프레임워크(302)로부터 애플리케이션(11n)이 인스톨되었다는 통지를 수취한다. 스텝 S13003에서 리소스 서비스(304)는 인스톨된 애플리케이션(11n)이 그룹 관리의 대상인지를 체크한다. 애플리케이션(11n)이 그룹 관리에 속하지 않는 경우에는 처리는 스텝 S13013으로 진행한다. 애플리케이션(11n)이 그룹 관리에 속하는 경우에는 처리는 스텝 S13004로 진행한다. 스텝 S13004에서는 인스톨된 애플리케이션(11n)이 속하는 그룹의 그룹 정보가 그룹 데이터 테이블(600)에 존재하고 있는지의 여부를 체크한다. 그룹 정보가 존재하지 않으면 처리는 스텝 S13010으로 진행한다. 그룹 정보가 존재하고 있을 경우에는 처리는 스텝 S13005로 진행한다. 스텝 S13005에서는 당해 그룹의 그룹 관리가 삭제되지 않고 인스톨된 상태인지의 여부를 체크한다. 이 판정에서는, 그룹 데이터 테이블(600)에 속하는 대상 그룹의 엔트리가 있으면, 그룹 관리가 인스톨된 상태라고 판정할 수 있다. 그룹 관리가 인스톨된 상태라면 처리는 스텝 S13006으로 진행한다. 그룹 관리가 언인스톨된 상태일 경우에는 처리는 스텝 S13010으로 진행한다. 스텝 S13006에서는 당해 그룹의 그룹 관리가 유효한 상태일지를 체크한다. 그룹 데이터 테이블(600) 내에서 그룹 관리가 유효한 상태라면 처리는 스텝 S13008로 진행한다. 그룹 관리가 무효이면 처리는 스텝 S13007로 진행한다. 스텝 S13007에서, 당해 그룹의 그룹 관리를 유효화한다. 유효화가 완료하면 처리는 스텝 S13008로 진행한다. 스텝 S13008에서는 인스톨된 애플리케이션이 정지 상태인지의 여부를 확인한다. 인스톨된 애플리케이션이 정지 상태라면 처리는 스텝 S13009로 진행한다. 인스톨된 애플리케이션이 개시되었다면, 처리는 스텝 S13013으로 진행한다. 스텝 S13009에서는 리소스 서비스(304)는 인스톨된 애플리케이션(11n)을 개시하고, 처리는 스텝 S13013으로 진행한다.
스텝 S13004 혹은 스텝 S13005로부터 스텝 S13010으로 처리가 진행하면, "그룹 정보가 인스톨되지 않았다"라는 경고를 출력한다. 이것은 인스톨된 애플리케이션(11n)에 대응하는 그룹 정보가 인스톨되지 않은 케이스이다. 이 경우에는 경고를 출력한 후에 스텝 S13011에서 인스톨된 애플리케이션이 개시되었는지의 여부를 체크한다. 인스톨된 애플리케이션이 개시되었다면 처리는 스텝 S13012로 진행한다. 인스톨된 애플리케이션이 개시되지 않았고 정지 상태라면 처리는 스텝 S13013으로 진행한다. 스텝 S13012에서는 리소스 서비스(304)는 인스톨된 애플리케이션(11n)을 애플리케이션 관리 프레임워크(302)를 통해서 정지한다. 스텝 S13013에서 일련의 처리를 완료한다.
<애플리케이션 언인스톨 시의 리소스 서비스의 동작>
도 14는 본 실시예에서 애플리케이션(11n)이 언인스톨되었을 때의 리소스 서비스(304)의 동작을 모식적으로 나타낸 흐름도이다. 스텝 S14001로부터 처리를 개시한다. 스텝 S14002에서 리소스 서비스(304)는 애플리케이션 관리 프레임워크(302)로부터 애플리케이션(11n)이 언인스톨되었다는 통지를 수취한다. 스텝 S14003에서 그 언인스톨된 애플리케이션(11n)이 그룹 관리의 대상인지 여부를 체크한다. 애플리케이션(11n)이 그룹 관리의 대상이 아닌 경우에는 처리는 스텝 S14016으로 진행한다. 애플리케이션(11n)이 그룹 관리의 대상이었을 경우에는 처리는 스텝 S14004로 진행한다. 스텝 S14004에서는 언인스톨된 애플리케이션(11n)이 속해 있는 그룹의 정보가 그룹 데이터 테이블(600)에 존재하였는지 여부를 체크한다. 그러한 정보가 존재하고 있었을 경우에는 처리는 스텝 S14005로 진행한다. 그러한 정보가 존재하고 있지 않았을 경우에는 처리는 스텝 S14015로 진행한다.
스텝 S14005에서는 언인스톨된 애플리케이션(11n)이 속해 있는 그룹의 그룹 관리가 인스톨된 상태인지의 여부를 체크한다. 그룹 관리가 언인스톨 상태라면 처리는 스텝 S14016으로 진행한다. 그룹 관리가 인스톨된 상태라면 처리는 스텝 S14006으로 진행한다. 스텝 S14006에서는 언인스톨된 애플리케이션(11n)이 속하는 그룹의 그룹 관리가 유효한지 여부를 체크한다. 그룹 관리가 무효인 경우에는 처리는 스텝 S14016으로 진행한다. 그룹 관리가 유효인 경우에는 처리는 스텝 S14007로 진행한다. 스텝 S14007에서는 언인스톨된 애플리케이션(11n)이 취득하고 있었던 리소스 중에서 해방되지 않은 리소스가 있는지를 체크한다. 해방되지 않은 리소스가 있으면 처리는 스텝 S14008로 진행한다. 해방되지 않은 리소스가 없으면 처리는 스텝 S14016으로 진행한다. 스텝 S14008에서는 언인스톨된 애플리케이션(11n)이 취득하고 있었던 해방되지 않은 리소스에 대해서 반복 처리를 행한다. 스텝 S14009에서는 처리 대상의 리소스가 해방가능한지를 체크한다. 그러한 리소스가 해방가능하면 처리는 스텝 S14010으로 진행한다. 스텝 S14010에서는 처리 대상인 리소스를 해방한다. 그 후에, 처리는 스텝 S14011로 진행해서, 해방된 리소스의 양을 전체의 사용량으로부터 감산한다. 처리는 스텝 S14013으로 진행한다. 스텝 S14012에서는 리소스 서비스(304)는 "리소스의 해방에 실패했다"라는 경고를 출력한다. 처리는 스텝 S14013으로 진행한다. 스텝 S14013에서는 처리 대상인 리소스에 대해서 모두 처리가 끝났는지를 판정한다. 처리가 끝나지 않은 경우에는 스텝 S14008로부터 반복 처리를 속행한다. 처리가 끝난 경우에는 처리는 스텝 S14014로 진행한다.
스텝 S14014에서는, 언인스톨된 애플리케이션(11n)이 속하는 그룹에 대해서, 그 그룹에 속하는 다른 애플리케이션(11n)이 인스톨된 상태로 존재하고 있는지를 판정한다. 다른 애플리케이션(11n)이 존재하고 있으면 처리는 스텝 S14016으로 진행한다. 다른 애플리케이션(11n)이 존재하지 않고 있으면 처리는 스텝 S14015로 진행한다. 스텝 S14015에서는 그룹 데이터 테이블(600)에서 당해 그룹의 그룹 관리를 무효화하고, 처리는 스텝 S14016으로 진행한다. 처리가 스텝 S14016으로 진행한 후에, 일련의 처리를 완료한다.
전술한 바와 같이, 본 발명의 제2 실시예에 따르면, 리소스 서비스(304)를 사용함으로써, 그룹 관리 대상인 애플리케이션(11n)을 항상 그룹 관리 하에서 동작시킬 수 있다.
그 결과, 본 실시예에 따르면, 복수의 애플리케이션(11n)을 조합해서 도입할 때에, 그룹 정보를 유지하는 프래그먼트 번들(305)을 이용할 수 있다. 이에 의해, 리소스가 불충분하기 때문에 종래에는 단독으로 도입될 수 없었던 애플리케이션(11n)을 그룹으로서 도입할 수 있다는 효과가 얻어질 수 있다.
제1 실시예와는 달리, 그룹 관리 대상인 애플리케이션을 단독 관리 하에서 실행하지 않는다. 따라서, 처리 수순이 간결해지고, 리소스의 효율적 이용을 더욱 촉진할 수 있다.
기타의 실시예
본 발명의 실시예는 전술한 하나 이상의 실시예의 기능을 실행하기 위해서 기억 매체(보다 완전하게는 '비일시적 컴퓨터 판독가능 기억 매체'라고도 불릴 수 있음)에 기록된 컴퓨터 실행가능 명령어(예를 들면, 하나 이상의 프로그램)를 판독해서 실행하고/실행하거나, 전술한 하나 이상의 실시예의 기능을 실행하기 위한 하나 이상의 회로(예를 들면, ASIC(application specific integrated circuit))를 포함하는 시스템 또는 장치의 컴퓨터에 의해, 그리고, 예를 들면 전술한 하나 이상의 실시예의 기능을 실행하기 위해서 기억 매체로부터 컴퓨터 판독가능 명령어를 판독하여 실행하고/실행하거나, 전술한 하나 이상의 실시예의 기능을 수행하기 위해서 하나 이상의 회로를 제어함으로써 시스템 또는 장치의 컴퓨터에 의해 수행되는 방법에 의해 구현될 수도 있다. 컴퓨터는 하나 이상의 프로세서(예를 들면, CPU(central processing unit), MPU(micro processing unit))를 포함할 수 있으며, 컴퓨터 판독가능 명령어를 판독해서 실행하는 별개의 컴퓨터 또는 별개의 프로세서의 네트워크를 포함할 수도 있을 것이다. 컴퓨터 실행가능 명령어는, 예를 들면 네트워크 또는 기억 매체로부터 컴퓨터에 제공될 수 있을 것이다. 기억 매체는, 예를 들면 하나 이상의 하드 디스크, RAM(random-access memory), ROM(read only memory), 분산 컴퓨팅 시스템의 저장소, 광 디스크(CD(compact disc), DVD(digital versatile disc) 또는 블루레이 디스크(BD)™ 등), 플래시 메모리 장치, 메모리 카드 등을 포함할 수도 있다.
본 발명은, 상기의 실시형태의 1개 이상의 기능을 실현하는 프로그램을, 네트워크 또는 기억 매체를 개입하여 시스템 혹은 장치에 공급하고, 그 시스템 혹은 장치의 컴퓨터에 있어서 1개 이상의 프로세서가 프로그램을 읽어 실행하는 처리에서도 실현가능하다. 또한, 1개 이상의 기능을 실현하는 회로(예를 들어, ASIC)에 의해서도 실행가능하다.
본 발명이 예시적인 실시예를 참조하여 기술되었지만, 본 발명이 개시된 예시적인 실시예에 한정되지 않음을 이해하여야 한다. 아래의 청구범위의 범주는 모든 변경과, 등가 구조 및 기능을 포함하도록 최광의의 해석에 따라야 한다.

Claims (12)

  1. 화상 형성 장치로서,
    애플리케이션 군에 속하는 애플리케이션의 식별자와, 상기 애플리케이션 군에 대한 사용 리소스 선언량을 정의하는 정보를 취득하는 취득 수단과,
    상기 애플리케이션으로부터의 리소스 취득 API의 호출에 응답하여, 상기 애플리케이션의 식별자에 기초하여 상기 애플리케이션이 속하는 애플리케이션 군을 특정하고, 특정된 상기 애플리케이션 군에 대한 사용 리소스 선언량을 상기 정보로부터 특정하는 특정 수단과,
    상기 애플리케이션에 의해 요구되는 리소스량을 상기 애플리케이션 군에 의해 사용되는 리소스량의 합계에 가산하여 얻어지는 값이, 상기 특정 수단에 의해 특정되는 상기 사용 리소스 선언량을 초과하는 경우, 상기 애플리케이션에 리소스 오브젝트를 이관하지 않고, 상기 값이 상기 사용 리소스 선언량을 초과하지 않는 경우, 상기 애플리케이션에 상기 리소스 오브젝트를 이관하는 리소스 관리 수단과,
    상기 리소스 취득 API를 호출하는 애플리케이션이 상기 애플리케이션 군에 속하고, 상기 애플리케이션이 상기 애플리케이션 군에 공유되는 리소스로부터 리소스가 할당되는 그룹 관리의 대상인 것을 판정하는 판정 수단을 포함하고,
    상기 특정 수단은, 상기 애플리케이션이 상기 그룹 관리의 대상이 아닐 경우, 상기 애플리케이션에 대한 사용 리소스 선언량을 상기 정보로부터 특정하고,
    상기 리소스 관리 수단은, 상기 애플리케이션이 상기 그룹 관리의 대상이 아닐 때에, 상기 애플리케이션에 의해 요구되는 리소스량을 상기 애플리케이션에 의해 사용되는 리소스량의 총합에 가산한 결과로서 상기 특정 수단에 의해 특정되는 사용 리소스 선언량을 상기 애플리케이션이 초과하는 경우, 상기 애플리케이션에 상기 리소스 오브젝트를 이관하지 않고, 상기 애플리케이션이 상기 사용 리소스 선언량을 초과하지 않을 경우, 상기 애플리케이션에 상기 리소스 오브젝트를 이관하는, 화상 형성 장치.
  2. 삭제
  3. 제1항에 있어서,
    상기 특정 수단은, 상기 애플리케이션이 상기 그룹 관리의 대상인 경우, 상기 애플리케이션 군에 대한 사용 리소스 선언량을 상기 정보로부터 특정하고,
    상기 리소스 관리 수단은, 상기 애플리케이션이 상기 그룹 관리의 대상일 때에, 상기 애플리케이션에 의해 요구되는 상기 리소스량을 상기 애플리케이션 군에 의해 사용되는 리소스량의 총합에 가산한 결과로서 상기 특정 수단에 의해 특정되는 상기 사용 리소스 선언량을 상기 애플리케이션이 초과하는 경우, 상기 애플리케이션에 상기 리소스 오브젝트를 이관하지 않고, 상기 애플리케이션이 상기 사용 리소스 선언량을 초과하지 않을 경우, 상기 애플리케이션에 상기 리소스 오브젝트를 이관하는 화상 형성 장치.
  4. 제1항에 있어서, 상기 애플리케이션 군에 속하고, 상기 그룹 관리의 대상이 아닌 애플리케이션의 그룹 관리를 개시할 경우, 상기 애플리케이션에 할당된 리소스를 해방하고, 상기 애플리케이션이 속하는 상기 애플리케이션 군에 대한 상기 사용 리소스 선언량의 리소스를 확보하는 수단을 더 포함하는 화상 형성 장치.
  5. 제4항에 있어서, 상기 그룹 관리의 대상인 애플리케이션의 그룹 관리를 정지할 경우, 상기 애플리케이션 군에 할당된 리소스를 해방하고, 상기 애플리케이션에 대한 상기 사용 리소스 선언량의 리소스를 확보하는 수단을 더 포함하는 화상 형성 장치.
  6. 제1항에 있어서, 애플리케이션이 인스톨되었을 때에, 상기 애플리케이션이 상기 그룹 관리의 대상인지 여부를 판정하고, 상기 애플리케이션이 상기 그룹 관리의 대상인 경우, 상기 애플리케이션에 할당한 리소스를 해방하고, 상기 애플리케이션이 속하는 애플리케이션 군에 대한 상기 사용 리소스 선언량의 리소스를 확보하는 수단을 더 포함하는 화상 형성 장치.
  7. 제1항에 있어서, 애플리케이션이 언인스톨되었을 때에, 상기 애플리케이션이 상기 그룹 관리의 대상인지 여부가 판정되고, 상기 애플리케이션이 상기 그룹 관리의 대상인 경우, 상기 애플리케이션 군에 속하는 애플리케이션이 인스톨되었는지 여부가 판정되고, 상기 애플리케이션 군에 속하는 애플리케이션이 인스톨되지 않은 경우, 상기 애플리케이션 군에 할당된 리소스가 해방되고, 상기 애플리케이션 군에 대한 그룹 관리가 정지되는 화상 형성 장치.
  8. 제1항에 있어서, 상기 그룹 관리의 대상인 애플리케이션의 그룹 관리를 정지할 경우, 상기 애플리케이션에 할당된 리소스가 해방되고, 상기 애플리케이션이 정지되는 화상 형성 장치.
  9. 제8항에 있어서, 애플리케이션이 언인스톨 되었을 때에, 상기 애플리케이션이 상기 그룹 관리의 대상인지 여부가 판정되고, 상기 애플리케이션이 상기 그룹 관리의 대상인 경우, 상기 애플리케이션 군에 속하는 애플리케이션이 인스톨되었는지 여부가 판정되고, 상기 애플리케이션 군에 속하는 애플리케이션이 인스톨되지 않은 경우, 상기 애플리케이션 군에 할당된 리소스가 해방되고, 상기 애플리케이션 군에 대한 그룹 관리가 정지되는 화상 형성 장치.
  10. 제1항에 있어서, 상기 그룹 관리는, 상기 애플리케이션 군에 속하는 상기 애플리케이션의 식별자와, 상기 애플리케이션 군에 대한 상기 사용 리소스 선언량을 정의하는 상기 정보를 추가함으로써 개시되고, 상기 정보를 삭제함으로써 정지되는 화상 형성 장치.
  11. 리소스 관리 방법으로서,
    취득 수단에 의해, 애플리케이션 군에 속하는 애플리케이션의 식별자와, 상기 애플리케이션 군에 대한 사용 리소스 선언량을 정의하는 정보를 취득하는 취득 공정과,
    특정 수단에 의해, 상기 애플리케이션으로부터의 리소스 취득 API의 호출에 응답하여, 상기 애플리케이션의 식별자에 기초하여 상기 애플리케이션이 속하는 애플리케이션 군을 특정하고, 특정된 상기 애플리케이션 군에 대한 사용 리소스 선언량을 상기 정보로부터 특정하는 특정 공정과,
    리소스 관리 수단에 의해, 상기 애플리케이션에 의해 요구되는 리소스량을 상기 애플리케이션 군에 의해 사용되는 리소스량의 총합에 가산하여 얻어지는 값이, 상기 특정 공정에서 특정된 상기 사용 리소스 선언량을 초과하는 경우, 상기 애플리케이션에 리소스 오브젝트를 이관하지 않고, 상기 값이 상기 사용 리소스 선언량을 초과하지 않을 경우, 상기 애플리케이션에 상기 리소스 오브젝트를 이관하는 이관 공정과,
    판정 수단에 의해, 상기 리소스 취득 API를 호출하는 애플리케이션이 상기 애플리케이션 군에 속하고, 상기 애플리케이션이 상기 애플리케이션 군에 공유되는 리소스로부터 리소스가 할당되는 그룹 관리의 대상인 것을 판정하는 판정 공정을 포함하고,
    상기 특정 수단은, 상기 애플리케이션이 상기 그룹 관리의 대상이 아닐 경우, 상기 애플리케이션에 대한 사용 리소스 선언량을 상기 정보로부터 특정하고,
    상기 리소스 관리 수단은, 상기 애플리케이션이 상기 그룹 관리의 대상이 아닐 때에, 상기 애플리케이션에 의해 요구되는 리소스량을 상기 애플리케이션에 의해 사용되는 리소스량의 총합에 가산한 결과로서 상기 특정 공정에서 특정되는 사용 리소스 선언량을 상기 애플리케이션이 초과하는 경우, 상기 애플리케이션에 상기 리소스 오브젝트를 이관하지 않고, 상기 애플리케이션이 상기 사용 리소스 선언량을 초과하지 않을 경우, 상기 애플리케이션에 상기 리소스 오브젝트를 이관하는, 리소스 관리 방법.
  12. 컴퓨터가 프로세스를 수행하게 하는, 기록 매체에 저장된 컴퓨터 프로그램으로서,
    상기 프로세스는,
    애플리케이션 군에 속하는 애플리케이션의 식별자와, 상기 애플리케이션 군에 대한 사용 리소스 선언량을 정의하는 정보를 취득하는 취득 공정과,
    상기 애플리케이션으로부터의 리소스 취득 API의 호출에 응답하여, 상기 애플리케이션의 식별자에 기초하여 상기 애플리케이션이 속하는 애플리케이션 군을 특정하고, 특정된 상기 애플리케이션 군에 대한 사용 리소스 선언량을 상기 정보로부터 특정하는 특정 공정과,
    상기 애플리케이션에 의해 요구되는 리소스량을 상기 애플리케이션 군에 의해 사용되는 리소스량의 총합에 가산하여 얻어지는 값이, 상기 특정 공정에서 특정된 상기 사용 리소스 선언량을 초과하는 경우, 상기 애플리케이션에 리소스 오브젝트를 이관하지 않고, 상기 값이 상기 사용 리소스 선언량을 초과하지 않을 경우, 상기 애플리케이션에 상기 리소스 오브젝트를 이관하는 이관 공정과,
    상기 리소스 취득 API를 호출하는 애플리케이션이 상기 애플리케이션 군에 속하고, 상기 애플리케이션이 상기 애플리케이션 군에 공유되는 리소스로부터 리소스가 할당되는 그룹 관리의 대상인 것을 판정하는 판정 공정을 포함하고,
    상기 특정 공정은, 상기 애플리케이션이 상기 그룹 관리의 대상이 아닐 경우, 상기 애플리케이션에 대한 사용 리소스 선언량을 상기 정보로부터 특정하고,
    상기 이관 공정은, 상기 애플리케이션이 상기 그룹 관리의 대상이 아닐 때에, 상기 애플리케이션에 의해 요구되는 리소스량을 상기 애플리케이션에 의해 사용되는 리소스량의 총합에 가산한 결과로서 상기 특정 공정에서 특정되는 사용 리소스 선언량을 상기 애플리케이션이 초과하는 경우, 상기 애플리케이션에 상기 리소스 오브젝트를 이관하지 않고, 상기 애플리케이션이 상기 사용 리소스 선언량을 초과하지 않을 경우, 상기 애플리케이션에 상기 리소스 오브젝트를 이관하는, 기록 매체에 저장된 컴퓨터 프로그램.
KR1020150118574A 2014-09-01 2015-08-24 화상 형성 장치 및 리소스 관리 방법 KR101860611B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014177432A JP2016051395A (ja) 2014-09-01 2014-09-01 画像形成装置およびリソース管理方法
JPJP-P-2014-177432 2014-09-01

Publications (2)

Publication Number Publication Date
KR20160026713A KR20160026713A (ko) 2016-03-09
KR101860611B1 true KR101860611B1 (ko) 2018-05-23

Family

ID=55312374

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020150118574A KR101860611B1 (ko) 2014-09-01 2015-08-24 화상 형성 장치 및 리소스 관리 방법

Country Status (4)

Country Link
US (1) US9727381B2 (ko)
JP (1) JP2016051395A (ko)
KR (1) KR101860611B1 (ko)
DE (1) DE102015114244B4 (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7172342B2 (ja) * 2018-09-19 2022-11-16 富士フイルムビジネスイノベーション株式会社 情報処理装置および画像処理装置
JP7455601B2 (ja) * 2020-02-05 2024-03-26 キヤノン株式会社 情報処理装置とその制御方法、及びプログラム
CN115794337B (zh) * 2022-11-14 2023-09-26 北京百度网讯科技有限公司 资源调度方法、装置、云平台、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003263324A (ja) 2002-03-11 2003-09-19 Canon Inc 情報処理装置及びその方法、プログラム
US6654780B1 (en) 1997-03-28 2003-11-25 International Business Machines Corporation System of managing processor resources in a non-dedicated computer system
JP2007072674A (ja) 2005-09-06 2007-03-22 Canon Inc ソフトウェアアプリケーション及び印刷システム
JP2007199811A (ja) 2006-01-24 2007-08-09 Hitachi Ltd プログラム制御方法、計算機およびプログラム制御プログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08328884A (ja) 1995-06-02 1996-12-13 Toshiba Corp 資源管理装置
JP4150853B2 (ja) 2003-06-06 2008-09-17 日本電気株式会社 資源競合制御システム及び制御方法並びにプログラム
JP4817994B2 (ja) * 2006-07-03 2011-11-16 キヤノン株式会社 データ管理システム
JP2010039689A (ja) 2008-08-04 2010-02-18 Canon Inc 情報処理装置
JP5511483B2 (ja) * 2010-04-20 2014-06-04 キヤノン株式会社 情報処理装置、制御方法、およびプログラム
JP5904800B2 (ja) * 2012-01-16 2016-04-20 キヤノン株式会社 装置、制御方法、並びにプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6654780B1 (en) 1997-03-28 2003-11-25 International Business Machines Corporation System of managing processor resources in a non-dedicated computer system
JP2003263324A (ja) 2002-03-11 2003-09-19 Canon Inc 情報処理装置及びその方法、プログラム
JP2007072674A (ja) 2005-09-06 2007-03-22 Canon Inc ソフトウェアアプリケーション及び印刷システム
JP2007199811A (ja) 2006-01-24 2007-08-09 Hitachi Ltd プログラム制御方法、計算機およびプログラム制御プログラム

Also Published As

Publication number Publication date
DE102015114244A1 (de) 2016-03-03
DE102015114244B4 (de) 2024-07-18
JP2016051395A (ja) 2016-04-11
KR20160026713A (ko) 2016-03-09
US20160062801A1 (en) 2016-03-03
US9727381B2 (en) 2017-08-08

Similar Documents

Publication Publication Date Title
JP7090657B2 (ja) アプリケーションをアップグレードするための方法、装置、デバイスならびに記憶媒体
US8135813B2 (en) Method, system and program product for remotely deploying and automatically customizing workstation images
US7979869B2 (en) Method and system for performing I/O operations using a hypervisor
US8713552B2 (en) Avoiding conflict in update in distributed environment employing multiple clients
JP5229486B2 (ja) 管理計算機及び処理管理方法
US10402216B1 (en) Live support integration in a virtual machine based development environment
JP2011076605A (ja) 仮想マシン・イメージの実行方法及びシステム
KR20130140777A (ko) 시스템 리셋
US9501344B2 (en) Data dump for a memory in a data processing system
KR101860611B1 (ko) 화상 형성 장치 및 리소스 관리 방법
US8275980B2 (en) Server computer, computer system, and file management method
JP2014170515A (ja) 機器、情報記録プログラム、及び情報記録方法
US9753775B2 (en) Resource management apparatus and resource management method
US10565355B2 (en) Techniques of managing licenses of virtual desktops
US20130263159A1 (en) Information processing apparatus, information processing method, and recording medium
JP6497157B2 (ja) 情報管理装置、情報管理方法、情報管理プログラム、データ構造、及び、ソフトウェア資産管理システム
US20170039215A1 (en) Image forming apparatus and control method thereof
US10606748B2 (en) Apparatus and method for garbage collection on socket objects
JP7102783B2 (ja) システム管理装置、システム管理方法、およびプログラム
JP3941597B2 (ja) 論理区画式計算機システム
JP5633608B2 (ja) 画像形成装置、カウンタ管理方法、及びカウンタ管理プログラム
US9619306B2 (en) Information processing device, control method thereof, and recording medium
US11435997B2 (en) Desired state model for managing lifecycle of virtualization software installed in heterogeneous cluster of hosts
JP5996094B2 (ja) 仮想マシンイメージ管理サーバ、及び仮想マシンイメージ管理方法
US20170242866A1 (en) Management system and control method

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant