ES2582384T3 - Integración de funcionalidad de detección dentro de un gestor de instalaciones y dispositivo - Google Patents

Integración de funcionalidad de detección dentro de un gestor de instalaciones y dispositivo

Info

Publication number
ES2582384T3
ES2582384T3 ES07122381.2T ES07122381T ES2582384T3 ES 2582384 T3 ES2582384 T3 ES 2582384T3 ES 07122381 T ES07122381 T ES 07122381T ES 2582384 T3 ES2582384 T3 ES 2582384T3
Authority
ES
Spain
Prior art keywords
thread
web services
network
threads
dfm
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
ES07122381.2T
Other languages
English (en)
Inventor
Alain Regnier
Yaotian Wang
Lifen Tian
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ricoh Co Ltd
Original Assignee
Ricoh Co Ltd
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
Priority claimed from US11/644,181 external-priority patent/US8112766B2/en
Priority claimed from US11/652,179 external-priority patent/US8321546B2/en
Application filed by Ricoh Co Ltd filed Critical Ricoh Co Ltd
Application granted granted Critical
Publication of ES2582384T3 publication Critical patent/ES2582384T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0273—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using web services for network management, e.g. simple object access protocol [SOAP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0273—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using web services for network management, e.g. simple object access protocol [SOAP]
    • H04L41/0286—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using web services for network management, e.g. simple object access protocol [SOAP] for search or classification or discovery of web services providing management functionalities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Facsimiles In General (AREA)
  • Multi Processors (AREA)
  • Accessory Devices And Overall Control Thereof (AREA)

Abstract

Un método implementado por ordenador para implementar una especificación de perfil de dispositivos de servicios web, comprendiendo el método: ejecutar, en un dispositivo (102, 202, 302), una pluralidad de subprocesos que se ejecutan de forma concurrente que implementan, de forma colectiva, una funcionalidad que es especificada por la especificación de perfil de dispositivos de servicios web; en el que el dispositivo (102, 202, 302) comprende al menos dos de: (a) una aplicación de servicios web de exploración de imagen, (b) una aplicación de servicios web de impresión y (c) una aplicación de servicios web de fax.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Integracion de funcionalidad de deteccion dentro de un gestor de instalaciones y dispositivo Campo de la invencion
La presente invencion se refiere a proporcionar servicios web y, mas en particular, a implementar la norma de Perfil de Dispositivos de Servicios Web (WS-DeviceProfile) como un proceso de multiples subprocesos que se ejecuta en un periferico multifuncion ("MFP", multi-function peripheral).
Antecedentes
Los enfoques que se describen en esta seccion son enfoques que se podnan perseguir, pero no necesariamente enfoques que se hayan concebido o perseguido previamente. Por lo tanto, a menos que se indique lo contrario, no se debena suponer que enfoque alguno de los que se describen en esta seccion reuna los requisitos para ser considerado tecnica anterior meramente en virtud de su inclusion en esta seccion.
World Wide Web ("WWW") es un espacio de informacion de lectura - escritura global. Los documentos de texto, imagenes, multimedia y muchos otros artfculos de informacion, a los que se hace referencia como recursos, son identificados por identificadores cortos, unicos y globales que se denominan Identificadores de Recursos Uniformes ("URI", Uniform Resource Identifier) de tal modo que se puede hallar, es posible tener acceso a y se puede establecer una relacion mediante referencias cruzadas de, cada uno de los mismos, de la forma mas simple posible. El Consorcio World Wide Web ("W3C", World Wide Web Consortium) es un consorcio internacional en el que la organizacion miembro, un personal a tiempo completo, y el publico trabajan conjuntamente para desarrollar normas para la World Wide Web. El W3C define un "servicio web" como un sistema de soporte logico que esta disenado para soportar una interaccion de maquina a maquina interoperable a traves de una red. Esta definicion abarca muchos sistemas diferentes, pero en el uso comun, la expresion se refiere a aquellos servicios que usan envolventes de Lenguaje de Marcado Extensible ("XML", Extensible Markup Language) de formato SOAP y que tienen sus interfaces descritas por Lenguaje de Descripcion de Servicios Web ("WSDL", Web Services Description Language). Los servicios web permiten que dispositivos y aplicaciones se comuniquen entre sf a traves de una o mas redes sin la intervencion de ser humano alguno, al tiempo que se usa el mismo conjunto de protocolos (por ejemplo, Protocolo de Transferencia de Hipertexto ("HTTP", Hypertext Transfer Protocol)) que usana un ser humano para comunicarse con tales dispositivos y aplicaciones a traves de una o mas redes.
Las especificaciones que definen servicios web son deliberadamente modulares y, como resultado, no hay documento alguno que defina todos los servicios web. En su lugar, hay unas pocas especificaciones basicas que estan complementadas por otras especificaciones segun indiquen las circunstancias y la eleccion de tecnologfa. Las especificaciones basicas mas comunes son SOAP, WSDL, Seguridad de Servicios Web (WS-Security) e Intercambio Fiable de Servicios Web (WS-Reliable-Exchange). Diferentes especificaciones abordan diferentes tareas y funciones.
SOAP es un formato de envolvente de mensajes extensible basado en XML, con enlaces a los protocolos subyacentes (por ejemplo, HTTP y Protocolo Simple de Transferencia de Correo ("SMTP", Simple Mail Transfer Protocol)). Usando XML, SOAP define como se debena dar formato a los mensajes, de tal modo que se da formato a esos mensajes de una forma tal que los destinatarios de esos mensajes (dispositivos y aplicaciones) pueden entender esos mensajes. SOAP se puede usar, por ejemplo, para realizar llamadas a procedimiento remotas.
WSDL es un formato de XML que permite que se describan interfaces de servicios web junto con los detalles de los enlaces de esas interfaces con protocolos espedficos. Por lo general, WSDL se usa para generar codigo de servidor y de cliente, y para configuracion. La Seguridad de Servicios Web define como usar el cifrado de XML y la firma de XML en SOAP para hacer seguros los intercambios de mensajes. El Intercambio Fiable de Servicios Web es un protocolo para una mensajena fiable entre dos servicios web.
El documento XP 002485809 de Microsoft, "Management of Hardware Resources in the data center using embedded Web Services", divulga el uso de Servicios Web para Gestion de Soporte Ffsico.
Sumario
Unas realizaciones del primer aspecto de la invencion implican una implementacion espedfica de la especificacion de Perfil de Dispositivos de Servicios Web. La implementacion espedfica se ajusta a la especificacion de Perfil de Dispositivos de Servicios Web. La implementacion espedfica incluye un gestor de instalaciones y dispositivo ("DFM", device and facility manager) que no se especifica de forma expresa en la especificacion de Perfil de Dispositivos de Servicios Web. El DFM usa diversos servicios web (por ejemplo, los que son especificados por Direccionamiento de Servicios Web (WS-Addressing), Deteccion de Servicios Web (WS-Discovery), Seguridad de Servicios Web, etc.) y describe como usar esos servicios web para realizar diversas tareas. El DFM se ocupa de la deteccion de dispositivos y servicios en una red. El DFM tambien actua como un gestor de instalaciones. El DFM implementa
5
10
15
20
25
30
35
40
45
50
55
60
65
diversos servicios web en un unico componente que las aplicaciones pueden usar y reutilizar. El DFM afsla estas aplicaciones de algunos de los detalles mas complejos de los servicios web que implementa el DFM.
En una realizacion de la invencion, el DFM se implementa dentro de un periferico multifuncion ("MFP", multi-function peripheral). El MFP puede comprender varias aplicaciones diferentes, cada una con una funcion especializada diferente (por ejemplo, impresion, exploracion, fax, etc.). Cada una de estas aplicaciones usa los servicios web que son proporcionados por el DFM. Aplicaciones adicionales que, mas adelante, se anaden de forma dinamica al mFp, tambien pueden usar los servicios web que son proporcionados por el DFM. Debido a que los servicios web de uso mas comun son proporcionados por el DFM, no es necesario que estos servicios web se implementen por separado en cada aplicacion.
En una realizacion de la invencion, el DFM se implementa como multiples subprocesos de ejecucion. La naturaleza de multiples subprocesos del DFM aumenta la eficiencia. Cuando el DFM comprende multiples subprocesos, subprocesos separados pueden manejar tareas separadas de forma concurrente. Por ejemplo, un subproceso puede manejar comunicaciones con procesos, aplicaciones y dispositivos en el exterior del MFP, mientras que otro subproceso puede manejar, de forma simultanea, comunicaciones con procesos y aplicaciones en el interior del MFP. Adicionalmente, implementar el DFM de una forma de tipo multiples subprocesos permite que una porcion de la funcionalidad del DFM se apague, se actualice y/o se depuren sus errores de forma temporal mientras que el resto del DFM permanece operativo. Un subproceso aquejado por un error se puede terminar y reiniciar mientras que los subprocesos restantes permanecen no afectados por el error. Por lo tanto, el DFM de multiples subprocesos es mas robusto de lo que sena un DFM de unico subproceso.
Unas realizaciones del segundo aspecto de la invencion implican una implementacion espedfica de la especificacion de Perfil de Dispositivos de Servicios Web. Unas realizaciones de la invencion incluyen un gestor de instalaciones y dispositivo ("DFM", device and facility manager) que no se especifica de forma expresa en la especificacion de Perfil de Dispositivos de Servicios Web. El DFM usa diversos servicios web (por ejemplo, los que son especificados por Direccionamiento de Servicios Web, Deteccion de Servicios Web, Seguridad de Servicios Web, etc.) y describe como usar esos servicios web para realizar diversas tareas. El DFM realiza una deteccion de dispositivos y servicios en una red. El DFM tambien actua como un gestor de instalaciones. El DFM implementa diversos servicios web en un unico componente que las aplicaciones pueden usar y reutilizar. El DFM afsla estas aplicaciones de detalles de los servicios web que implementa el DFM.
En una realizacion de la invencion, el DFM se implementa dentro de un dispositivo, que puede incluir, pero no se limita a, un periferico multifuncion ("MFP", multi-function peripheral). Por ejemplo, el MFP puede comprender varias aplicaciones diferentes, cada una de las cuales tiene una funcion diferente (por ejemplo, impresion, exploracion, fax, etc.). Cada una de estas aplicaciones puede usar los servicios web que son proporcionados por el DFM. Aplicaciones adicionales que, mas adelante, se anaden de forma dinamica al MFP tambien pueden usar los servicios web que son proporcionados por el DFM. Debido a que los servicios web de uso mas comun (tales como Deteccion de Servicios Web) son proporcionados por el DFM, no es necesario que estos servicios web sean implementados por separado por cada aplicacion.
En una realizacion de la invencion, el DFM se implementa como multiples subprocesos de ejecucion. La naturaleza de multiples subprocesos del DFM aumenta la eficiencia. Cuando el DFM comprende multiples subprocesos, subprocesos separados pueden manejar tareas separadas de forma concurrente. Por ejemplo, un subproceso que se ejecuta en el dispositivo puede realizar un primer conjunto de una o mas funciones que son especificadas por el protocolo de Perfil de Dispositivos de Servicios Web, por ejemplo, el subproceso puede realizar tareas en relacion con la gestion de protocolos de servicios web que son proporcionados por el dispositivo. Otro subproceso que se ejecuta en el dispositivo puede realizar un segundo conjunto de una o mas funciones que son especificadas por un protocolo de Deteccion de Servicios Web, por ejemplo, el subproceso se puede comunicar con otros dispositivos para informar a esos dispositivos de que el dispositivo se encuentra disponible y de cuales son las capacidades del dispositivo.
Unas realizaciones de la invencion pueden aumentar la eficiencia del DFM usando otros enfoques. Por ejemplo, los subprocesos del DFM se pueden comunicar entre sf mediante el establecimiento y la lectura de indicadores, reduciendo al mmimo de ese modo el tiempo que un subproceso esta esperando a otro. Asimismo, se pueden implementar porciones del DFM usando una clase estatica, evitando de ese modo las complejidades de la gestion de punteros a objetos con instancias.
Breve descripcion de los dibujos
La presente invencion se ilustra a modo de ejemplo, y no a modo de limitacion, en las figuras de los dibujos adjuntos y en los que numeros de referencia semejantes se refieren a elementos similares y en los que:
la figura 1 es un diagrama de bloques que ilustra un ejemplo de un periferico multifuncion ("MFP", multi-function
peripheral) en un entorno de red, de acuerdo con una realizacion de la invencion;
5
10
15
20
25
30
35
40
45
50
55
60
65
la figura 2 es un diagrama de bloques que ilustra un ejemplo de una aplicacion de servicios web en un MFP, de acuerdo con una realizacion de la invencion;
la figura 3 es un diagrama de bloques que ilustra un ejemplo de multiples aplicaciones de servicios web diferentes y un DFM que se ejecuta en un MFP, de acuerdo con una realizacion de la invencion; la figura 4 es un diagrama de bloques que ilustra una arquitectura a modo de ejemplo de un MFP que comprende un DFM de multiples subprocesos, de acuerdo con una realizacion de la invencion;
la figura 5 es un diagrama de secuencia que muestra multiples subprocesos de un DFM que se ejecutan de forma concurrente, de acuerdo con una realizacion de la invencion;
la figura 6 es un diagrama de flujo que ilustra unas etapas que son realizadas por varios de los subprocesos que se ejecutan de forma concurrente de un DFM, de acuerdo con una realizacion de la invencion; la figura 7 es un diagrama de bloques que ilustra un sistema informatico en el que se puede implementar una realizacion de la invencion;
la figura 8 es un primer diagrama de secuencia que ilustra una comunicacion entre multiples subprocesos de un DFM de acuerdo con una realizacion de la invencion; y
la figura 9 es un segundo diagrama de secuencia que ilustra una comunicacion entre multiples subprocesos de un DFM de acuerdo con una realizacion de la invencion.
Descripcion detallada
En la siguiente descripcion, por razones de explicacion, numerosos detalles espedficos se exponen con el fin de proporcionar una comprension exhaustiva de la presente invencion. Sera evidente, no obstante, que la presente invencion se puede poner en practica sin estos detalles espedficos. En otros casos, se muestran estructuras y dispositivos bien conocidos en forma de diagrama de bloques con el fin de evitar complicar de forma innecesaria la presente invencion.
La descripcion en el presente documento se proporciona en unas secciones organizadas tal como sigue:
1.0 Vision general de la arquitectura
1.1 Cliente
1.2 Red
1.3 Gestor de instalaciones de dispositivos
1.4 Gestor de WSD
1.4.1 API general
1.4.2 Implementacion de API general
1.5 Aplicacion de servicios web
1.5.1 API abstracta
1.5.2 Implementacion de API abstracta
2.0 DFM de multiples subprocesos
3.0 Integracion de funcionalidad de Deteccion de Servicios Web dentro de un DFM de multiples subprocesos
4.0 Mecanismos de implementacion
1.0 VISION GENERAL DE LA ARQUITECTURA
La figura 1 es un diagrama de bloques que ilustra un ejemplo de un dispositivo en un entorno de red de acuerdo con una realizacion de la invencion. En el ejemplo que se muestra en la figura 1, el dispositivo es un periferico multifuncion (MFP, multi-function peripheral). Un MFP es un dispositivo que comprende multiples modulos que realizan, cada uno, una funcion diferente. Tales funciones pueden incluir, por ejemplo, impresion, fotocopia, fax, exploracion, archivado y notificacion de documentos. El dispositivo Aficio Color 5560 de Ricoh es un ejemplo de un MFP. Este MFP puede actuar como una impresora, un escaner y una maquina fotocopiadora, entre otros usos.
A pesar de que la figura 1 muestra el dispositivo como un MFP, en otras realizaciones de la invencion, el MFP 102 se puede corresponder con un dispositivo diferente que no sea un MFP, tal como una impresora, una fotocopiadora, una maquina de fax, un dispositivo de formacion de imagen, a digital camera y un escaner. Por lo tanto, unas realizaciones de la invencion pueden implementar un DFM en otros dispositivos que no sean un MFP; no obstante, para facilitar la explicacion, los ejemplos que se analizan en el presente documento se analizaran principalmente en terminos de la implementacion del DFM en un MFP. Como resultado, unas realizaciones de la invencion no estan limitadas en lo que respecta a en que tipo de dispositivo se puede implementar el DFM, por ejemplo, el DFM se puede implementar en una maquina expendedora, un aparato de cocina, un ordenador personal y un ordenador integrado.
5
10
15
20
25
30
35
40
45
50
55
60
65
La figura 1 muestra un MFP 102, una red de area local (LAN, local area network) 104, un cortafuegos 106 e Internet 108. El MFP 102 esta acoplado de forma comunicativa con la LAN 104. La LAN 104 esta acoplada de forma comunicativa con el cortafuegos 106. El cortafuegos 106 esta acoplado de forma comunicativa con Internet 108. Por lo tanto, el MFP 102 se puede comunicar con otros dispositivos por medio de la LAN 104, el cortafuegos 106 e Internet 108.
El MFP 102 comprende multiples modulos diferentes, cada uno de los cuales cumple una funcion diferente. Estos modulos incluyen una unidad de procesamiento central ("CPU", central processing unit) 110, una interfaz de red (por ejemplo, una tarjeta de Ethernet) 112, una memoria (por ejemplo, memoria de acceso aleatorio ("RAM", random access memory)) 114, un dispositivo de almacenamiento (por ejemplo, una unidad de disco duro) 116, un visualizador (por ejemplo, un visualizador de cristal ffquido) 118, un dispositivo de entrada de panel frontal (por ejemplo, un teclado numerico) 120, un motor de fax 122, un motor de exploracion 124 y un motor de impresion 126. En diversas realizaciones de la invencion, un MFP puede comprender unos modulos que son mas, menos o diferentes de los que se ilustran en la figura 1.
La figura 2 es un diagrama de bloques que ilustra una aplicacion de servicios web y un DFM en un MFP, de acuerdo con una realizacion de la invencion. La figura 2 muestra un MFP 202 (que se corresponde con el MFP 102 de la figura 1), una red 204, un cliente de servicios web 218 y un DFM 220. En una realizacion de la invencion, el DFM 220 es una implementacion de la especificacion de Perfil de Dispositivos de Servicios Web. De ese modo, el MFP 202 y el cliente de servicios web 218 estan acoplados de forma comunicativa con la red 204, y se comunican entre sf.
El MFP 202 comprende una aplicacion de servicios web 206, que se ejecuta en el MFP 202. La aplicacion de servicios web 206 se comunica con el cliente de servicios web 218 por medio de la red 204 y el DFM 220. El MFP 202 comprende adicionalmente un kit de desarrollo de soporte logico ("SDK", software development kit) de SOAP 208 y los protocolos de servicios web 210. El MFP 202 puede comprender cualquiera de un numero de diferentes plataformas 216A-216N. Cada una de tales plataformas puede ser un sistema operativo diferente y/o un conjunto diferente de soporte ffsico, por ejemplo. A pesar de que la figura 2 muestra multiples plataformas 216A-216N, en una realizacion de la invencion, el MFP 202 comprende solo una plataforma, que puede ser una cualquiera de las plataformas 216A - N.
La figura 3 es un diagrama de bloques que ilustra un ejemplo de multiples aplicaciones de servicios web diferentes y un DFM que se ejecuta en un MFP, de acuerdo con una realizacion de la invencion. La figura 3 muestra el MFP 302 (que se corresponde con el MFP 202 de la figura 2) acoplado de forma comunicativa con la red 304. El MFP 302 comprende la aplicacion de servicios web 306A y 306B, cada una de las cuales puede estar especializada para manejar una funcion espedfica del MFP 302. La aplicacion de servicios web 306A podna ser una aplicacion que maneja, de forma espedfica, tareas de impresion, mientras que la aplicacion de servicios web 306B podna ser una aplicacion que maneja, de forma espedfica, tareas de exploracion, por ejemplo. Las aplicaciones de servicios web 306A y 306B tambien se denominan "protocolos de control de dispositivos" ("DCP", device control protocol). El MFP 302 tambien comprende el SDK de SOAP 308 y los protocolos de servicios web 310. Las aplicaciones de servicios web tanto 306A como 308B usan el SDK de SoAp 308 y los protocolos de servicios web 310.
El MFP 302 puede comprender cualquiera de un numero de diferentes plataformas 316A - 316N. Cada una de tales plataformas puede ser un sistema operativo diferente y/o un conjunto diferente de soporte ffsico, por ejemplo. A pesar de que la figura 3 muestra multiples plataformas 316A - 316N, en una realizacion de la invencion, el MFP 302 comprende solo una plataforma, que puede ser una cualquiera de las plataformas 316A- N.
Para cada una de las plataformas 316A- N, hay, para cada una de las aplicaciones de servicios web 306A y 306B, una implementacion de API separada que es espedfica de esa plataforma y de esa aplicacion de servicios web. Cada una de las implementaciones de API abstracta 314AA-NA implementa la API abstracta 312A para una plataforma espedfica. De forma similar, cada una de las implementaciones de API abstracta 314AB-NB implementa la API abstracta 312B para una plataforma espedfica. Por lo tanto, la implementacion de API abstracta 314AA es una implementacion espedfica de la plataforma de la API abstracta 312A para la plataforma 316A, la implementacion de API abstracta 314BA es una implementacion espedfica de la plataforma de la API abstracta 312A para la plataforma 316B, y asf sucesivamente. De forma similar, la implementacion de API abstracta 314AB es una implementacion espedfica de la plataforma de la API abstracta 312B para la plataforma 316A, la implementacion de API abstracta 314BB es una implementacion espedfica de la plataforma de la API abstracta 312B para la plataforma 316B, y asf sucesivamente. La aplicacion de servicios web 306A se comunica con las plataformas 316A- N por medio de sus implementaciones de API abstracta 314AA- NA correspondientes, mientras que la aplicacion de servicios web 306B se comunica con las plataformas 316A-N por medio de sus implementaciones de API abstracta 314AB - NB correspondientes.
El MFP 302 tambien comprende el DFM 320 que, en una realizacion de la invencion, es una implementacion de la especificacion de Perfil de Dispositivos de Servicios Web. Para cada una de las plataformas 316A-N, hay una implementacion de API general separada que es espedfica de esa plataforma. Cada una de las implementaciones de API general 318A-N implementa la API general 322 para una plataforma espedfica. Por lo tanto, la
5
10
15
20
25
30
35
40
45
50
55
60
65
implementacion de API general 318A es una implementacion espedfica de la plataforma de la API general 322 para la plataforma 316A, la implementacion de API general 318B es una implementacion espedfica de la plataforma de la API general 322 para la plataforma 316B, y asf sucesivamente. El DFM 320 se comunica con las plataformas 316A- N por medio de sus implementaciones de API general 318A- N correspondientes.
La figura 4 es un diagrama de bloques que ilustra una arquitectura 400 a modo de ejemplo de un MFP que comprende un DFM de multiples subprocesos, de acuerdo con una realizacion de la invencion. La arquitectura 400 incluye un cliente 402, un administrador 404 y un MFP que comprende un gestor de instalaciones de dispositivos ("DFM", device and facility manager) 406 y una pluralidad de aplicaciones de servicios web ("WSA", web service application) 408 que se ejecutan en el MFP.
El MFP, tal como se indica mediante la figura 4, puede comprender una cualquiera de varias plataformas (por ejemplo, una plataforma heredada 430, una plataforma basada en Linux 440 y una plataforma basada en VxWorks 450), en cada una de las cuales se pueden ejecutar una o mas de las WSA 408. Las plataformas que se muestran en la figura 4 se proporcionan meramente como ejemplos, debido a que el enfoque se puede aplicar a cualquier tipo de plataforma.
El DFM 406 representa el MFP mediante la respuesta a solicitudes de deteccion, solicitudes de metadatos a partir del cliente 402, y solicitudes de configuracion y otras solicitudes de administracion de MFP a partir de un administrador 404. El DFM 406 puede actuar como un deposito de implementaciones de multiples especificaciones de Servicios Web, tal como la deteccion de Servicios Web (WS-Discovery) 412 y el WS-MeX (es decir, Intercambio de Metadatos de Servicios Web) 416.
El cliente 402 solicita servicios a partir del MFP. Cada WSA 408 que se ejecuta en el MFP proporciona un servicio al cliente 402 (usando el protocolo SOAP, por ejemplo). Cada WSA 408 puede emplear una aPi abstracta espedfica del servicio, tal como una API abstracta 424, independiente de la plataforma objetivo. Cada WSA 408 tambien puede emplear Eventos de Servicios Web (WS-Eventing) 422.
El cliente 402 detecta que un MFP existe por medio de una solicitud de deteccion o un mensaje de SALUDO de deteccion (es decir, un mensaje de difusion o de multidifusion que anuncia el MFP a los dispositivos en la misma red). Una vez que el cliente 402 es consciente de la existencia de un MFP, el cliente 402 puede enviar una solicitud de intercambio de metadatos de dispositivo, por ejemplo, por medio de Intercambio de Metadatos de Servicios Web, para detectar la totalidad de los servicios que proporciona el MFP. El DFM 406, que actua para la totalidad del dispositivo, recibe la solicitud y devuelve unos metadatos que describen los diversos servicios provistos por el MFP. El cliente 402 puede solicitar unos metadatos de servicio a partir de una aplicacion de servicios web particular que se ejecuta en el MFP, tal como una aplicacion de Servicios Web (WSA, web service application) 408. La WSA 408 puede solicitar los metadatos de servicio a partir de un Gestor de Dispositivo de Servicios Web (WSD, web service device) 410, el cual devuelve los metadatos de servicio a la WSA 408. La WSA 408 reenvfa los metadatos de servicio al cliente 402.
Como alternativa, los metadatos de dispositivo del MFP y los metadatos de servicio de una o mas WSA se pueden enviar al cliente 402 en la misma respuesta.
Basandose en los metadatos de servicio, el cliente 402 genera y transmite una solicitud de SOAP que se corresponde con un servicio provisto por la WSA 408. La WSA 408 recibe y procesa la solicitud de SOAP. Basandose en una solicitud de servicio, la WSA 408 puede usar una API abstracta 424 para realizar una llamada espedfica de la plataforma a una implementacion de la API abstracta 424, tal como una implementacion de API abstracta 444. Un desarrollador de una aplicacion de Servicios Web (por ejemplo, la WSA 408) de puede centrar en el desarrollo del propio servicio Web sin tener que conocer las complejidades de la plataforma subyacente en la cual se ejecuta el servicio Web. Por lo tanto, alguien con conocimiento de la plataforma objetivo, incluso alguien que no sea el desarrollador de aplicaciones de Servicios Web, puede definir la implementacion de la API abstracta correspondiente.
1.1 CLIENTE
El cliente 402 es una aplicacion que esta asociada con un proceso que solicita uno o mas servicios provistos por el MFP. Por lo general, el cliente 402 es una aplicacion que esta asociada con el sistema operativo que soporta el proceso solicitante inicial. Un fin del cliente 402 es convertir una llamada de procedimiento espedfica de la plataforma, de un proceso solicitante, en una solicitud de SOAP que puede ser procesada por una aplicacion que entiende SOAP.
Por ejemplo, el proceso solicitante se puede asociar con una aplicacion de Microsoft Word. La WSA 408 puede proporcionar un servicio de impresion. El cliente 402 puede ser una aplicacion que esta asociada con el sistema operativo que soporta el proceso solicitante inicial. El cliente 402 podna recibir una solicitud de "datos de impresion" espedfica de la plataforma que se envio desde el proceso solicitante. El cliente 402 codificana entonces la solicitud de datos de impresion en un mensaje de SOAP que puede ser procesado por la WSA 408.
5
10
15
20
25
30
35
40
45
50
55
60
65
1.2 RED
La comunicacion de SOAP entre el cliente 402 y el MFP se puede hacer a traves de una red (que no se muestra). La red se puede implementar por cualquier medio o mecanismo que prevea el intercambio de datos entre diversos nodos en la red. Los ejemplos de una red de este tipo incluyen, sin limitacion, una red tal como una Red de Area Local (LAN, Local Area Network), una Red de Area Extensa (WAN, Wide Area Network), Ethernet y/o Internet, y/o uno o mas enlaces terrestres, por satelite o inalambricos. La red puede incluir una combinacion de redes tales como las que se describen. La red puede transmitir datos de acuerdo con el Protocolo de Control de Transmision (TCP, Transmission Control Protocol), el Protocolo de Datagramas de Usuario (UDP, User Datagram Protocol) y/o el Protocolo de Internet (IP, Internet Protocol), por ejemplo.
1.3 GESTOR DE INSTALACIONES DE DISPOSITIVOS
El DFM 406 representa el MFP mediante la aceptacion de solicitudes de deteccion, solicitudes para informacion de inicio de sesion e instrucciones de configuracion. De acuerdo con una realizacion de la invencion, el DFM 406 tambien actua como un deposito de implementaciones de multiples especificaciones de Servicios Web. Por lo tanto, el DFM 406 puede incluir una biblioteca compartida de rutinas que implementan, cada una, una o mas funciones que son definidas por una o mas especificaciones de Servicios Web (por ejemplo, seguridad de Servicios Web (WS- Security) e Intercambio de Metadatas de Servicios Web (WS-MetadataExchange)). De esta forma, multiples especificaciones de Servicios Web se pueden implementar una vez y compartirse entonces con cada una de las multiples aplicaciones de Servicios Web (por ejemplo, la WSA 408) que se ejecutan en el MFP. Como resultado, los desarrolladores de aplicaciones de Servicios Web pueden usar y basarse en la especificacion de servicios web implementados en el MFP sin conocer muchos detalles acerca de cualquiera de estas especificaciones. Algunas especificaciones de Servicios Web que se implementan en el DFM 406 pueden incluir, pero no se limitan a, la deteccion de Servicios Web 412, la transferencia de Servicios Web (WS-Transfer) 414, el WS-MeX (es decir, Intercambio de Metadatos de Servicios Web) 416 y la seguridad de Servicios Web 418.
En una realizacion de la invencion, el DFM 406 incluye unas rutinas de biblioteca que se corresponden con el protocolo SOAP. Cada rutina de biblioteca de SOAP implementa una o mas funciones que estan definidas por una o mas especificaciones de SOAP. Las rutinas de biblioteca de SOAP se usan para analizar solicitudes de SOAP y empaquetar mensajes de SOAP. Se pueden soportar multiples versiones de la norma de protocolo SOAP. Actualizaciones a una version mas reciente de una norma de protocolo SOAP se pueden realizar con poca o ninguna modificacion a la WSA 408.
En una realizacion de la invencion, el DFM 406 emite mensajes de difusion para indicar actualizaciones a una o mas WSA en el MFP. En una realizacion de la invencion, no es necesario que el cliente 402 se abone a un evento de actualizacion de este tipo. No obstante, en una realizacion de la invencion, el cliente 402 se registra para recibir notificaciones de actualizaciones a una o mas WSA en el MFP. En una realizacion de la invencion de este tipo, si el DFM 406 recibe una informacion de actualizacion que esta relacionada con una actualizacion de una aplicacion particular y si el cliente 402 esta registrado para recibir una notificacion de una actualizacion de este tipo, entonces el DFM 406 envfa, a la aplicacion de cliente, una notificacion de la actualizacion.
En una realizacion de la invencion, el DFM 406 recibe una informacion de actualizacion que esta relacionada con una WSA. Por ejemplo, la WSA 408 puede proporcionar un servicio de fax. El MFP podna detectar que la lmea de fax esta desconectada. Cuando el servicio de fax no se encuentra disponible, el DFM 406 no debena responder a solicitudes de metadatos futuras con unos metadatos de dispositivo que indiquen que el MFP proporciona un servicio de fax. Por lo tanto, en respuesta a recibir una informacion de actualizacion a partir de la wSa 408, el DFM 406 actualiza los metadatos de dispositivo y/o de servicio que estan asociados con la WSA 408.
En una realizacion de la invencion, el DFM 406 recibe solicitudes de configuracion a partir de un administrador 404. Una solicitud de configuracion indica una o mas WSA que se van a configurar y/o a actualizar. El DFM 406 maneja solicitudes de configuracion y realiza, o da lugar a que se realice, la instruccion de configuracion o de actualizacion en la WSA apropiada. Como alternativa, el DFM 406 puede indicar al Gestor de WSD 410 que maneje tales solicitudes de configuracion.
En una realizacion de la invencion, el DFM 406 recibe y responde a solicitudes de inicio de sesion a partir de un administrador 404. El DFM 406 recupera una informacion de inicio de sesion que esta relacionada con una o mas WSA que se ejecutan en el MFP y envfa la informacion de inicio de sesion al administrador 404. El Gestor de WSD 410 puede recuperar y proporcionar la informacion de inicio de sesion al DFM 406.
1.4 GESTOR DE WSD
De acuerdo con una realizacion de la invencion, el DFM 406 tambien comprende el Gestor de WSD 410. El Gestor de WSD 410 proporciona un punto central para informacion de inicio de sesion, consultas de estatus y gestion externa del mFp. En una realizacion de la invencion, el administrador 404 es una aplicacion que esta configurada para recuperar, a traves del Gestor de WSD 410, una informacion que esta relacionada con el MFP. Por ejemplo, el
5
10
15
20
25
30
35
40
45
50
55
60
65
Gestor de WSD 410 puede centralizar toda la informacion de inicio de sesion que viene internamente a partir de todas las WSA 408 y a partir de las diversas plataformas en las cuales se estan ejecutando las WSA 408. El administrador 404 tambien puede configurar, actualizar o deshabilitar una WSA 408 usando el Gestor de WSD 410.
En una realizacion de la invencion, el Gestor de WSD 410 mantiene una informacion de estatus global, tal como en donde esta ubicada el MFP, que WSA estan instaladas en el MFP, y si las WSA se estan ejecutando de forma apropiada.
En una realizacion de la invencion, el Gestor de WSD 410 mantiene los metadatas para el MFP. En una realizacion de la invencion, el Gestor de WSD 410 mantiene unos metadatos de servicio que estan relacionados con cada WSA 408 en ejecucion en el MFP.
1.4.1 API GENERAL
De acuerdo con una realizacion de la invencion, el Gestor de WSD 410 recupera una informacion general que esta relacionada con el MFP, tal como la direccion de IP y el numero de modelo del MFP, a traves de una API general 420. La API general 420 define una interfaz mediante la cual el DFM 406 recibe una informacion espedfica de cada plataforma del MFP. Como resultado, no se requiere que un desarrollador de DFM conozca los detalles de una plataforma espedfica: solo es necesario que el desarrollador de DFM conozca los detalles del DFM que el desarrollador esta construyendo para un mFp (las lmeas de puntos en la figura 4 representan llamadas de API a partir de una API particular a la implementacion de API apropiada).
1.4.2 IMPLEMENTACION DE API GENERAL
Si la API general 420 se ha definido para el DFM 406, entonces se define una implementacion de la API general espedfica de la plataforma 420. Por ejemplo, una implementacion de API general 432 se define para la API general 420 en la plataforma heredada 430. De forma similar, una implementacion de API general 442 se define para la API general 420 en la plataforma basada en Linux 440. Una implementacion de API general define las funciones que se especifican en una solicitud espedfica del dispositivo y que se implementan en el MFP. El desarrollador del DFM 406 puede definir la implementacion de API general. Como alternativa, alguna otra persona que tenga conocimiento de la plataforma objetivo puede definir la implementacion de API general.
1.5 APLICACION DE SERVICIOS WEB
La aplicacion de servicios Web (WSA) 408 es un modulo que proporciona uno o mas servicios Web y se basa en tecnologfas y protocolos de Servicios Web, tales como aquellos protocolos provistos por el DFM 406. La WSA 408 tambien puede basarse en un modulo de SOAP independiente (que no se muestra) para analizar solicitudes de SOAP si la WSA 408 no incluye una logica para analizar solicitudes de SOAP. Tal como se ha indicado en lo que antecede, el modulo de SOAP independiente puede ser provisto por el DFM 406 y compartirse entre todas las WSA 408.
En una realizacion de la invencion, la WSA 408 tambien comprende un modulo de Eventos de Servicios Web 422 para responder a solicitudes de evento a partir del cliente 402. El cliente 402 se puede abonar a un evento que esta asociado con el servicio provisto por la WSA 408. Por ejemplo, la WSA 408 podna ser una aplicacion de impresion. Un evento al que el cliente 402 se abona podna ser la complecion por parte del MFP de un trabajo de impresion. En tales circunstancias, tras la complecion del evento, la WSA 408 envfa un mensaje de evento al cliente 402. El mensaje de evento indica que el trabajo de impresion se ha completado.
1.5.1 API ABSTRACTA
La WSA 408 tambien puede comprender una API abstracta (por ejemplo, la API abstracta 424) a traves de la cual se pueden generar llamadas espedficas de dispositivo. La API abstracta define una interfaz mediante la cual la WSA 408 asociada invoca una o mas funciones en el MFP. Por lo tanto, no se requiere que el desarrollador de una aplicacion de Servicios Web conozca las complejidades subyacentes de la plataforma objetivo, sino solo del nuevo servicio que el desarrollador tiene por objeto proporcionar.
1.5.2 IMPLEMENTACION DE API ABSTRACTA
Si una API abstracta ha sido definida por un desarrollador de aplicaciones de Servicios Web, entonces se define una implementacion de la API abstracta para una plataforma espedfica. Por ejemplo, tal como se muestra en la figura 4, una implementacion de API abstracta 434 se define para la API abstracta 424 en una plataforma heredada 430. De forma similar, una implementacion de API abstracta 454 se define para la API abstracta 424 en una plataforma de VxWorks 450. Una implementacion de API abstracta define las funciones que se especifican en una solicitud espedfica del dispositivo y que se implementan en el MFP. El desarrollador de la aplicacion de Servicios Web puede definir la implementacion. Como alternativa, alguna otra persona que tenga conocimiento de la plataforma objetivo puede definir la implementacion.
5
10
15
20
25
30
35
40
45
50
55
60
65
2.0 DFM DE MULTIPLES SUBPROCESOS
Tal como se ha analizado en lo que antecede, en una realizacion de la invencion, el DFM (por ejemplo, el DFM 320) se implementa por medio de multiples subprocesos que se ejecutan de forma concurrente. En una realizacion de la invencion, hay al menos cuatro subprocesos, incluyendo (1) un subproceso de gestor de WSD, (2) un subproceso de Deteccion de Servicios Web, (3) un subproceso de distribuidor interior y (4) un subproceso de procesamiento de solicitudes externas.
En una realizacion de la invencion, cuando se enciende el MFP, un subproceso principal inicializa y pone en marcha multiples componentes. Despues de que el subproceso principal haya iniciado los otros subprocesos, el subproceso principal da control a (o comienza a actuar como) el subproceso de gestor de WSD. El subproceso de gestor de WSD supervisa el registro y la anulacion del registro de aplicaciones de servicios web (por ejemplo, las aplicaciones de servicios web 306A y 306B). El subproceso de gestor de WSD tambien supervisa cualquier cambio que este llegando del MFP por medio de la capa abstracta (por ejemplo, la API general 322/la implementacion de API general 318A). En respuesta a que se plantee cualquier cambio de este tipo, el subproceso de gestor de WSD (1) actualiza una version de metadatos de dispositivo que estan almacenados en el MFP y (2) indica al subproceso de Deteccion de Servicios Web que difunda (por ejemplo, por medio de la red 304) el cambio en los metadatos de dispositivo a otros dispositivos que son externos con respecto al MFP.
En una realizacion de la invencion, el subproceso de Deteccion de Servicios Web aguarda la aprobacion del subproceso de gestor de WSD para enviar un mensaje de "Hola". En respuesta a la obtencion, por parte del subproceso de Deteccion de Servicios Web, de tal aprobacion a partir del subproceso del gestor de WSD, el subproceso de Deteccion de Servicios Web difunde (por ejemplo, por medio de la red 304) un mensaje de "Hola" a otros dispositivos para indicar la presencia del MFP. Despues de enviar un mensaje de "Hola" de este tipo, el subproceso de Deteccion de Servicios Web escucha en busca de mensajes de "Sondeo" y de "Resolucion" entrantes. En respuesta a la recepcion de un mensaje de "Sondeo" o de "Resolucion", el subproceso de Deteccion de Servicios Web responde de forma apropiada, tal como es especificado por la especificacion de Deteccion de Servicios Web.
Adicionalmente, en una realizacion de la invencion, en respuesta a la recepcion, a partir del subproceso de gestor de WSD, de una notificacion que indica que se han actualizado los metadatos de dispositivo del mFp, el subproceso de Deteccion de Servicios Web difunde (por ejemplo, a traves de la red 304) el cambio en los metadatos de dispositivo. Por ejemplo, el mensaje puede indicar a otros dispositivos que un servicio web adicional (por ejemplo, impresion, exploracion, etc.) se encuentra ahora disponible en el MFP, o que un servicio web que se encontraba disponible previamente en el MFP se encuentra ahora no disponible.
En una realizacion de la invencion, el subproceso de distribuidor interno maneja intercambios de mensajes entre el DFM 320 y las aplicaciones de servicios web 306A y 306B, y/u otras aplicaciones que se estan ejecutando en el MFP. Estos mensajes estan compuestos de tal modo que los mismos siguen un formato especificado. El subproceso de distribuidor interno analiza sintacticamente los mensajes recibidos. El subproceso de distribuidor interno distribuye estos mensajes al componente apropiado del DFM. El subproceso de distribuidor interno retransmite las respuestas de los componentes de DFM a estos mensajes de vuelta a las entidades apropiadas (por ejemplo, las aplicaciones de servicios web 306A y 306B).
En una realizacion de la invencion, el subproceso de procesamiento de solicitudes externas supervisa mensajes de solicitud que se originan en dispositivos y procesa que son externos con respecto al mFp. Por ejemplo, el subproceso de procesamiento de solicitudes externas puede supervisar los mensajes que los clientes de servicios web envfan al MFP a traves de la red 304. Por lo tanto, en una realizacion de la invencion, el subproceso de distribuidor interno maneja solo mensajes que se originan dentro del MFP, mientras que el subproceso de procesamiento de solicitudes externas maneja solo mensajes que se originan en el exterior del MFP. De forma beneficiosa, los subprocesos de distribuidor interno y de procesamiento de solicitudes externas pueden manejar mensajes de forma concurrente, de tal modo que el MFP puede reaccionar a solicitudes procedentes tanto de dentro como de fuera, de una forma en paralelo en lugar de en serie. El subproceso de distribuidor de mensajes externo determina los tipos de los mensajes entrantes, distribuye los mensajes a los componentes de DFM apropiados basandose en los tipos de esos mensajes, recibe respuestas a los mensajes a partir de los componentes de DFM a los que se distribuyeron los mensajes, y envfa (por ejemplo, a traves de la red 304) las respuestas a las entidades externas a partir de las cuales se originaron los mensajes.
De forma beneficiosa, un DFM de multiples subprocesos permite que las solicitudes externas se pongan en cola y se manejen de una forma de tipo primero en llegar, primero en ser atendido, sin afectar al resto del MFP. Adicionalmente, un DFM de multiples subprocesos permite que las aplicaciones de servicios web se registren y se desregistren con el MFP de forma dinamica, sin afectar a las otras tareas del DFM. Ademas, un DFM de multiples subprocesos permite que las comunicaciones con la plataforma de MFP se manejen sin poner limitacion alguna al trabajo que esta haciendo el DFM. Adicionalmente, un DFM de multiples subprocesos permite que un subproceso se centre en la logica de negocio del DFM sin necesidad de hacer nada en lo que respecta a las comunicaciones con la plataforma de MFP, las aplicaciones de servicios web, o entidades externas al mFp. Desde un punto de vista de la
5
10
15
20
25
30
35
40
45
50
55
60
65
programacion, tener un DFM de multiples subprocesos hace al DFM mas modular, flexible y robusto.
La figura 5 es un diagrama de secuencia que muestra multiples subprocesos de un DFM que se ejecutan de forma concurrente, de acuerdo con una realizacion de la invencion. Un subproceso principal (el cual puede servir mas adelante como el subproceso de gestor de WSD) inicia los otros subprocesos con invocaciones de un metodo "CreateThread( )", en una realizacion de la invencion. Los subprocesos que se crean de esta forma incluyen un subproceso de Deteccion de Servicios Web, un subproceso de distribuidor interno y un subproceso de procesamiento de solicitudes externas. El subproceso de Deteccion de Servicios Web implementa la especificacion de Deteccion de Servicios Web y maneja las solicitudes y respuestas de deteccion. El subproceso de distribuidor interno maneja comunicaciones con entidades que son internas con respecto al MFP (por ejemplo, aplicaciones de servicios web). El subproceso de procesamiento de solicitudes externas maneja (1) la logica de negocio del DFM y (2) comunicaciones con entidades que son externas con respecto al MFP (por ejemplo, clientes de servicios web que acceden al MFP por medio de una red). En una realizacion de la invencion, despues de crear estos otros subprocesos, el subproceso principal se vuelve el subproceso de gestor de WSD y realiza las operaciones del subproceso de gestor de wSd tal como se ha analizado en lo que antecede (por ejemplo, la gestion de los metadatos del MFP).
Debido a que el subproceso de procesamiento de solicitudes externas esta separado del subproceso de distribuidor interno, el DFM es capaz de manejar comunicaciones con entidades internas al MFP y externas al MFP de forma simultanea; no es necesario que el DFM espere a que se completen las comunicaciones con una entidad interna al MFP antes de comenzar las comunicaciones con una entidad externa al MFP, o viceversa. A pesar de que la realizacion de la invencion que se ilustra incluye solo cuatro subprocesos, realizaciones alternativas de la invencion pueden incluir un numero mayor o menor de subprocesos. Por ejemplo, para cada aplicacion de servicios web en el MFP, se podna iniciar un subproceso separado para manejar comunicaciones que implican esa aplicacion de servicios web y ninguna otra aplicacion de servicios web. No obstante, a medida que aumenta el numero de subprocesos, tambien aumenta la tara que se requiere para mantener esos subprocesos.
En una realizacion alternativa de la invencion, solo hay dos subprocesos que se ejecutan de forma concurrente: el subproceso de Deteccion de Servicios Web, que maneja todas las comunicaciones que son especificadas por la especificacion de Deteccion de Servicios Web, y otro subproceso que realiza operaciones que no son realizadas por el subproceso de Deteccion de Servicios Web.
En una realizacion de la invencion, la invocacion del subproceso principal de un metodo "DFMCleanUp()" da lugar a que la totalidad de los otros subprocesos se apaguen de una forma elegante.
La figura 6 es un diagrama de flujo que ilustra unas etapas que son realizadas por varios de los subprocesos que se ejecutan de forma concurrente de un DFM, de acuerdo con una realizacion de la invencion. Algunas de las etapas que se muestran en la figura 6 se pueden realizar de forma concurrente con otras de las etapas que se muestran en la figura 6.
Las etapas 602-628 son realizadas por el subproceso principal. En el bloque 602, el gestor de WSD se inicializa. En el bloque 604, el puerto y la direccion de Protocolo de Internet (IP, Internet Protocol) externa e interna se recuperan del gestor de WSD. En el bloque 606, el subproceso de Deteccion de Servicios Web se inicializa. El subproceso de Deteccion de Servicios Web comienza a realizar las etapas 630 - 646 de forma concurrente con las etapas 602-628 que son realizadas por el subproceso principal. En el bloque 608, el subproceso de distribuidor interno se inicializa. El subproceso de distribuidor interno comienza a realizar las etapas 648 - 658 de forma concurrente con las etapas 602-628 que son realizadas por el subproceso principal. En el bloque 610, el subproceso de procesamiento de solicitudes externas se inicializa. El subproceso de procesamiento de solicitudes externas se ejecuta de forma concurrente con el subproceso principal y otros subprocesos.
En el bloque 612, el gestor de WSD se inicia. En el bloque 614, el gestor de WSD aguarda un registro de aplicacion de servicios web o un tiempo de espera de registro. En el bloque 616, el gestor de WSD indica a la Deteccion de Servicios Web que se inicie. En el bloque 618, el gestor de WSD comprueba si hay un nuevo cambio de metadatos o registro de aplicacion de servicios web. En el bloque 620, se realiza una determinacion en lo que respecta a si se ha recibido una senal de finalizacion. Si se ha recibido una senal de finalizacion, entonces el control pasa al bloque 622. De lo contrario, el control pasa de vuelta al bloque 618.
En el bloque 622, el subproceso de distribuidor interno se detiene. En el bloque 624, el subproceso de procesamiento de solicitudes externas se detiene. En el bloque 626, el subproceso de Deteccion de Servicios Web se desinicializa. En el bloque 628, el gestor de WSD se desinicializa.
El subproceso de Deteccion de Servicios Web se ejecuta de forma concurrente con los otros subprocesos. En el bloque 630, se comprueban indicadores (senales). En el bloque 632, se realiza una determinacion en lo que respecta a si se ha establecido una senal de "inicio" (por ejemplo, por el gestor de WSD en el bloque 616). Si se ha establecido una senal de "inicio", entonces el control pasa al bloque 634. De lo contrario, el control pasa de vuelta al bloque 630.
5
10
15
20
25
30
35
40
45
50
55
60
65
En el bloque 634, se envfa un mensaje de "Hola". En el bloque 636, se borra un indicador de inicio de deteccion. En el bloque 638, el subproceso de Deteccion de Servicios Web comienza a escuchar la red. En el bloque 640, se manejan mensajes de "Sondeo" y de "Resolucion" entrantes (por ejemplo, a partir de la red) y se envfan mensajes de "Coincidencia de Sondeo" y de "Coincidencia de Resolucion" (por ejemplo, a traves de la red) en respuesta segun sea apropiado. En el bloque 642, se comprueban y se manejan otras senales segun sea apropiado. En el bloque 644, se realiza una determinacion en lo que respecta a si se ha recibido una senal de finalizacion. Si se ha recibido una senal de finalizacion, entonces el control pasa al bloque 646. De lo contrario, el control pasa de vuelta al bloque 640.
En el bloque 646, el subproceso de Deteccion de Servicios Web termina.
El subproceso de distribuidor interno se ejecuta de forma concurrente con el subproceso principal y los otros subprocesos. En el bloque 648, el subproceso de distribuidor interno aguarda mensajes de comunicacion entre modulos ("IMC", inter-module communication). Los mensajes de IMC son comunicaciones dentro del MFP, entre el DFM y las WSA. Los mensajes de IMC son procesados por el subproceso de distribuidor interno en el bloque 650, los mensajes de IMC se procesan. En el bloque 652, el subproceso de distribuidor interno obtiene una o mas respuestas a uno o mas mensajes de IMC. En el bloque 654, el subproceso de distribuidor interno envfa las una o mas respuestas de vuelta a las entidades a partir de las cuales se recibieron los mensajes de IMC. En el bloque 656, se realiza una determinacion en lo que respecta a si se ha recibido una senal de finalizacion. Si se ha recibido una senal de finalizacion, entonces el control pasa al bloque 658. De lo contrario, el control pasa de vuelta al bloque 648.
En el bloque 658, el subproceso de distribuidor interno termina.
El subproceso de procesamiento de solicitudes externas se ejecuta de forma concurrente con el subproceso principal y los otros subprocesos. En el bloque 660, el subproceso de procesamiento de solicitudes externas aguarda mensajes de solicitud procedentes de un cliente (por ejemplo, el cliente de servicios web 218) que es externo con respecto al MFP. En el bloque 662, se comprueba el tipo de mensaje. En el bloque 664, el mensaje se distribuye a otros modulos o subprocesos (por ejemplo, el gestor de WSD y/o el subproceso de distribuidor interno) basandose en el tipo del mensaje. En el bloque 666, el subproceso de distribuidor externo obtiene una respuesta al mensaje a partir del modulo o subproceso al que se distribuyo el mensaje. En el bloque 668, la respuesta se envfa de vuelta al cliente a partir del cual se recibio el mensaje. En el bloque 670, se realiza una determinacion en lo que respecta a si se ha recibido una senal de finalizacion. Si se ha recibido una senal de finalizacion, entonces el control pasa al bloque 672. De lo contrario, el control pasa de vuelta al bloque 660.
En el bloque 672, el subproceso de procesamiento de solicitudes externas termina.
3.0 INTEGRACION DE FUNCIONALIDAD DE DETECCION DENTRO DE UN DFM DE MULTIPLES SUBPROCESOS
En una realizacion, un DFM, tal como el DFM 320, se puede implementar por medio de multiples subprocesos que se ejecutan de forma concurrente. Tal como se ha analizado en lo que antecede, un DFM de multiples subprocesos puede incluir al menos cuatro subprocesos, incluyendo (1) un subproceso de gestor de WSD, (2) un subproceso de deteccion, (3) un subproceso de distribuidor interior y (4) un subproceso de procesamiento de solicitudes externas.
En otras realizaciones de la invencion, el DFM de multiples subprocesos tambien puede incluir un subproceso de manejador de senal de DFM. En una realizacion, el subproceso de manejador de senal de DFM es responsable de informar a los otros subprocesos del DFM de multiples subprocesos de cuando se detecta una senal particular. Tales senales pueden incluir una senal que esta asociada con una instruccion para apagar el dispositivo en el que se implementa el DFM de multiples subprocesos y una senal que esta asociada con una determinacion de que se ha restablecido una conexion de red perdida.
En una realizacion, el subproceso de deteccion realiza la mayona de la funcionalidad de deteccion, tal como enviar mensajes de Hola y mensajes de Adios, escuchar en busca de mensajes de Sondeo y de Resolucion, y replicar a mensajes de Sondeo y de Resolucion con mensajes de Coincidencia de Sondeo y de Coincidencia de Resolucion, respectivamente. A pesar de que las actividades que son realizadas por el subproceso de deteccion se describiran principalmente en el presente documento en el contexto de realizar una funcionalidad de deteccion de acuerdo con el protocolo de Deteccion de Servicios Web, se contempla que otras realizaciones de la invencion puedan emplear un subproceso de deteccion que realiza una funcionalidad de deteccion de acuerdo con uno o mas protocolos de deteccion ademas del protocolo de Deteccion de Servicios Web, por ejemplo, en otras realizaciones, el subproceso de deteccion puede realizar una funcionalidad de deteccion de acuerdo con cualquier protocolo de deteccion que no sea el protocolo de Deteccion de Servicios Web.
En una realizacion, los subprocesos del DFM de multiples subprocesos pueden supervisar un conjunto de indicadores. Tras la deteccion por parte de un subproceso de que se ha establecido un indicador, el subproceso puede realizar una accion de respuesta. Por ejemplo, cuando se establece un indicador particular, que esta asociado con un cambio en las capacidades del dispositivo que implementa el DFM, el subproceso de deteccion envfa un
5
10
15
20
25
30
35
40
45
50
55
60
65
nuevo mensaje de Hola, que refleja las nuevas capacidades del dispositivo, a traves de la red. De esta forma, los subprocesos del DFM se pueden comunicar entre s^ mediante el establecimiento y la lectura de indicadores, reduciendo al mmimo de ese modo el tiempo que un subproceso esta esperando a otro. El proceso de subprocesos del DFM que establecen y que leen indicadores se analizara en detalle adicional en lo sucesivo con referencia a las figuras 8 y 9.
Los metadatos de dispositivo estan almacenados en un MFP, o este puede acceder a los mismos. Los metadatos de dispositivo pueden incluir datos que describen una informacion que identifica el MFP, por ejemplo, los metadatos de dispositivo pueden incluir informacion acerca del numero de serie o el modelo del MFP. Los metadatos de dispositivo tambien pueden incluir una informacion ("informacion de capacidad") que describe las capacidades actuales del MFP, por ejemplo, la informacion de capacidad puede incluir informacion acerca de los servicios que son proporcionados en la actualidad por el MFP.
En una realizacion de la invencion, en respuesta a la recepcion, por parte del subproceso de deteccion, de una notificacion que indica que se han cambiado los metadatos de dispositivo para el MFP 202, el subproceso de deteccion difunde (por ejemplo, a traves de la red 204) un mensaje que indica que han cambiado los metadatos de dispositivo para el MFP 202. El mensaje de difusion que es enviado por el subproceso de deteccion puede contener, en su totalidad o en parte, datos de deteccion de dispositivos.
En una realizacion, los datos de deteccion de dispositivos pueden incluir informacion acerca del tipo de dispositivo y el alcance del MFP. Ademas, los datos de deteccion de dispositivos pueden incluir una informacion de direccion que describe como se debenan comunicar las entidades con el MFP, por ejemplo, la informacion de direccion puede identificar una direccion de IP del MFP. Adicionalmente, los datos de deteccion de dispositivos pueden identificar una version de metadatos que esta asociada con los metadatos de dispositivo del MFP. Por ejemplo, la version de metadatos se puede incrementar cada vez que cambian los metadatos de dispositivo. Si un destinatario de los datos de deteccion de dispositivos tiene una version de metadatos mas baja que la version de metadatos que es identificada por los datos de deteccion de dispositivos, se puede informar al destinatario de los datos de deteccion de dispositivos de que han cambiado los metadatos de dispositivo, y puede emprender una accion apropiada. En una realizacion, el mensaje de difusion que es enviado por el subproceso de deteccion puede identificar la version de metadatos sin incluir otros tipos de datos de deteccion de dispositivos. Esta forma de informar a una entidad de que han cambiado los metadatos de dispositivo de un MFP es meramente ilustrativa, debido a que se pueden usar otros enfoques.
En una realizacion, el funcionamiento del DFM de multiples subprocesos es mas eficiente mediante la integracion del desempeno de la funcionalidad de deteccion dentro del DFM. El subproceso de deteccion interacciona con el subproceso de Gestor de WSD. El subproceso de Gestor de WSD provee al subproceso de deteccion con unos datos de deteccion de dispositivos y notificacion de cambios en los metadatos de dispositivo. De esta forma, se puede notificar al subproceso de deteccion cuando tiene lugar un cambio en el MFP 202 y puede obtener unos datos de deteccion de dispositivos que reflejan las nuevas capacidades del MFP 202. La comunicacion entre el subproceso de Gestor de WSD y el subproceso de deteccion asegura que la informacion que se pasa al subproceso de deteccion es actual y esta actualizada.
En una realizacion, el subproceso de Gestor de WSD tambien controla cuando se inicia y se detiene la ejecucion del subproceso de deteccion. Este control del subproceso de Gestor de WSD sobre el subproceso de deteccion se puede implementar usando un indicador, dando de ese modo una comunicacion eficiente entre los dos subprocesos y permitiendo que el subproceso de Gestor de WSD vuelva rapidamente de las llamadas de API realizadas para establecer el indicador para comunicarse con el subproceso de deteccion.
En una realizacion, el subproceso de deteccion tambien puede interaccionar con el subproceso de manejador de senal de DFM. Tal interaccion se puede lograr mediante el establecimiento, por parte del subproceso de manejador de senal de DFM, de un indicador apropiado que supervisa el subproceso de deteccion. Una vez que el subproceso de deteccion ha detectado que se ha establecido un indicador, el subproceso de deteccion puede realizar una accion apropiada, tal como enviar un Mensaje de Hola de Deteccion de Servicios Web o terminar el subproceso de deteccion.
En una realizacion, el subproceso de deteccion se puede implementar usando una clase estatica sin ningunas funciones miembro o datos miembro de instancia. Un enfoque de este tipo es ventajoso, debido a que se pueden evitar las complejidades de la gestion de punteros a objetos con instancias.
Para ilustrar adicionalmente la interaccion entre los subprocesos del DFM de multiples subprocesos, considerense las figuras 8 y 9. La figura 8 es un primer diagrama de secuencia que ilustra una comunicacion entre los modulos de un DFM de acuerdo con una realizacion de la invencion. Para facilitar la explicacion, los subprocesos ilustrativos de un DFM de multiples subprocesos a modo de ejemplo se explicaran con referencia a su implementacion en el MFP 102 de la figura 1 (tambien se hara referencia a la figura 2, que ilustra el MFP 202, que es una ilustracion mas detallada del MFP 102).
5
10
15
20
25
30
35
40
45
50
55
60
65
Tal como se muestra en la figura 8, el subproceso principal de DFM inicializa el subproceso de deteccion. En una realizacion, el subproceso principal de DFM usa una clase estatica para inicializar el subproceso de deteccion. El subproceso principal de dFm puede proporcionar una informacion determinada, tal como una direccion de red del dispositivo en el que se implementa el DFM, a la clase estatica cuando se inicializa el subproceso de deteccion.
Despues de que se haya creado el subproceso de deteccion, el subproceso principal de DFM puede indicar al subproceso de Gestor de WSD que se inicie. En respuesta, el subproceso de Gestor de WSD puede recuperar metadatas de dispositivo para el DFM 202. Despues de recuperar los metadatas de dispositivo, el subproceso de Gestor de WSD provee al subproceso de deteccion con unos datos de deteccion de dispositivos. El subproceso de deteccion, a su vez, almacena los datos de deteccion de dispositivos. Antes de almacenar los datos de deteccion de dispositivos, el subproceso de deteccion puede analizar sintacticamente, validar y/o realizar un procesamiento adicional sobre los datos de deteccion de dispositivos para asegurar su precision.
Despues de que el subproceso de deteccion haya almacenado datos de deteccion de dispositivos, el subproceso de Gestor de wSd puede realizar una llamada de API para establecer un indicador (el "indicador de inicio") que esta asociado con indicar al subproceso de deteccion que inicie el desempeno de sus deberes. En una realizacion, el subproceso de deteccion, una vez creado, supervisana este indicador. Como resultado, una vez que se ha establecido el indicador de inicio, el subproceso de deteccion detecta que se establece el indicador de inicio, borra el indicador de inicio y comienza el desempeno de sus deberes. Por ejemplo, los deberes del subproceso de deteccion pueden incluir escuchar en busca de mensajes de Sondeo y de Resolucion, continuar supervisando indicadores que se usan en la comunicacion con otros subprocesos, enviar mensajes de Hola y enviar mensajes de Coincidencia de Sondeo y de Coincidencia de Resolucion segun sea apropiado. Los mensajes (tales como mensajes de hola, mensajes de Coincidencia de Sondeo y mensajes de Coincidencia de Resolucion) que son enviados por el subproceso de deteccion pueden contener informacion acerca de que servicios son soportados por el dispositivo que implementa el DFM, por ejemplo, el mensaje de Hola puede indicar que DCP estan activos en el DFM 202.
En una realizacion, en algun momento posterior en el tiempo, el subproceso de Gestor de WSD puede detectar un cambio en los metadatos de dispositivo y/o los datos de deteccion de dispositivos. Por ejemplo, el subproceso de Gestor de WSD puede detectar que un DCP particular ya no se encuentra disponible o que ha cambiado la direccion de IP del MFP. En respuesta a la deteccion, por parte del subproceso de Gestor de WSD, de un cambio en los metadatos de dispositivo y/o datos de deteccion de dispositivos, el subproceso de Gestor de WSD notifica al subproceso de deteccion el cambio y provee al subproceso de deteccion con un conjunto actualizado de datos de deteccion de dispositivos que reflejan el cambio. El subproceso de deteccion, a su vez, almacena los datos de deteccion de dispositivos. Al igual que antes, antes de almacenar los datos de deteccion de dispositivos, el subproceso de deteccion puede analizar sintacticamente, validar y/o realizar un procesamiento adicional sobre los datos de deteccion de dispositivos para asegurar su precision.
En una realizacion, el subproceso de Gestor de WSD puede establecer un indicador (el "indicador de cambio") que esta asociado con notificar que se ha actualizado el subproceso de deteccion para esos metadatos. El subproceso de deteccion puede supervisar este indicador. Como resultado, una vez que se ha establecido el indicador de cambio, el subproceso de deteccion borra el indicador de cambio y envfa nuevos mensajes de Hola, a traves de la red 204, para informar a las entidades que estan escuchando de que han cambiado los metadatos de dispositivo para el MFP y para informar a las entidades que estan escuchando de cualesquiera datos de deteccion de dispositivos actualizados. De esta forma, el cambio en el MFP se puede publicar de una forma eficiente y oportuna de tal modo que se pueda notificar rapidamente a las partes interesadas acerca del cambio en los metadatos de dispositivo del MFP.
La figura 9 es un segundo diagrama de secuencia que ilustra unas comunicaciones entre los subprocesos de un DFM de multiples subprocesos de acuerdo con una realizacion de la invencion. Tal como se muestra en la realizacion de la figura 9, en algun momento en el tiempo, el subproceso de manejador de senal de DFM puede detectar que ha tenido lugar un "restablecimiento de red". Un restablecimiento de red puede tener lugar cuando la conexion de un dispositivo con una red se pierde y se recupera a continuacion. Por ejemplo, el MFP 102 puede experimentar un restablecimiento de red cuando se vuelve a arrancar un encaminador en la red de area local 104 o el MFP 102 recupera una conexion de red perdida.
Despues de que el subproceso de manejador de senal de DFM haya detectado que ha tenido lugar un "restablecimiento de red", el subproceso de manejador de senal de DFM puede indicar al subproceso de deteccion que maneje la reconexion. En una realizacion, el subproceso de manejador de senal de DFM puede indicar al subproceso de deteccion que maneje la reconexion mediante el establecimiento de un indicador (el "indicador de restablecimiento de red") al que puede acceder el subproceso de deteccion. Una vez que el subproceso de deteccion ha detectado que se ha establecido el indicador de restablecimiento de red, el subproceso de deteccion borra el indicador de restablecimiento de red y emite un nuevo mensaje de Hola a traves de la red 204. De esta forma, se puede notificar a otros dispositivos en la red (tales como el cliente de servicios web 218 de la figura 2) que el MFP 202 se encuentra en lmea y disponible. Despues de que el subproceso de deteccion haya enviado el nuevo mensaje de Hola, el subproceso de deteccion continuara escuchando en busca de mensajes de Sondeo y de Resolucion asf como supervisando indicadores que se usan en la comunicacion con otros subprocesos.
5
10
15
20
25
30
35
40
45
50
55
60
65
Ilustrado tambien en la realizacion de la figura 9, en algun momento en el tiempo, el subproceso de manejador de senal de DFM puede detectar que se ha recibido una "senal de apagado de dispositivo". Una senal de apagado de dispositivo se corresponde con una instruccion, que se recibe en el MFP, que indica al MFP que se apague. Por ejemplo, un administrador puede enviar una senal de apagado de dispositivo al MFP 202 de la figura 2 para dar lugar a que se apague el MFP 202.
Una vez que el subproceso de manejador de senal de DFM ha recibido la senal de apagado de dispositivo, el manejador de senal de DFM indica al subproceso de Gestor de WSD que se detenga. El subproceso de Gestor de WSD, a su vez, indica al subproceso de deteccion que se detenga. En la realizacion que se muestra en la figura 8, el subproceso de Gestor de WSD indica al subproceso de deteccion que inicie el procesamiento mediante el establecimiento de un indicador de inicio. De forma similar, en la realizacion que se muestra en la figura 9, el subproceso de Gestor de WSD indica al subproceso de deteccion que detenga el procesamiento mediante el establecimiento de un indicador de detencion. De esta forma, el subproceso de Gestor de WSD puede controlar cuando el subproceso de deteccion comienza y termina el procesamiento.
Despues de que el subproceso de deteccion detecte que se ha establecido el indicador de detencion, el subproceso de deteccion borra el indicador de detencion y detiene el procesamiento. Por ejemplo, el subproceso de deteccion puede dejar de procesar mediante el envfo de un mensaje de Adios a traves de la red 204 para informar a todos los clientes de servicios web de que el MFP 202 ya no se encuentra disponible y, posteriormente, puede dejar de escuchar en busca de mensajes.
En algun momento en el tiempo despues de que el subproceso de manejador de senal de DFM haya enviado una instruccion de detencion al subproceso de Gestor de WSD, el subproceso de manejador de senal de DFM puede enviar una instruccion de detencion al subproceso principal de DFM. Tras la recepcion, por parte del subproceso principal de DFM, de la instruccion de detencion a partir del subproceso de manejador de senal de DFM, el subproceso principal de DFM envfa una instruccion de desinicializar al subproceso de deteccion. En una realizacion, la instruccion de desinicializar puede ser enviada por el subproceso principal de DFM mediante el establecimiento de un indicador de limpieza al que puede acceder el subproceso de deteccion.
En una realizacion, cuando el subproceso de deteccion detecta que se ha establecido el indicador de limpieza, el subproceso de deteccion borra el indicador de limpieza y realiza una funcionalidad de limpieza. La funcionalidad de limpieza que es realizada por el subproceso de deteccion puede incluir limpiar o deshacer la atribucion de cualquier estructura de datos que este asociada con el subproceso de deteccion.
En una realizacion, cuando un MFP detecta que ha tenido lugar un cambio en un servicio web provisto en el MFP, el MFP envfa un nuevo mensaje de Hola a traves de la red. No obstante, si el cambio es temporal, por ejemplo, un servicio de escaner se esta dando de baja de forma temporal, el MFP puede determinar que no es necesario enviar un nuevo mensaje de Hola a traves de la red. En una realizacion de este tipo, tras la determinacion, por parte del MFP, de que un cambio en un servicio no es temporal, el subproceso de deteccion puede dar lugar a que se envfe un mensaje de hola (tal como un mensaje de Hola de Deteccion de Servicios Web) a traves de la red 204 y, tras la determinacion, por parte del MFP, de que un cambio en un servicio es temporal, el subproceso de deteccion puede determinar que no se debena enviar un mensaje de hola a traves de la red 204.
4.0 MECANISMOS DE IMPLEMENTACION
La figura 7 es un diagrama de bloques que ilustra un sistema informatico 700 en el cual se puede implementar una realizacion de la invencion. El sistema informatico 700 incluye un bus 702 u otro mecanismo de comunicacion para comunicar informacion, y un procesador 704 que se acopla con el bus 702 para procesar informacion. El sistema informatico 700 tambien incluye una memoria principal 706, tal como una memoria de acceso aleatorio (RAM, random access memory) u otro dispositivo de almacenamiento dinamico, que se acopla con el bus 702 para almacenar informacion e instrucciones que van a ser ejecutadas por el procesador 704. La memoria principal 706 tambien se puede usar para almacenar variables temporales u otra informacion intermedia durante la ejecucion de instrucciones que van a ser ejecutadas por el procesador 704. El sistema informatico 700 incluye adicionalmente una memoria de solo lectura (ROM, read only memory) 708 u otro dispositivo de almacenamiento estatico que se acopla con el bus 702 para almacenar informacion estatica e instrucciones para el procesador 704. Un dispositivo de almacenamiento 710, tal como un disco magnetico o un disco optico, se proporciona y se acopla con el bus 702 para almacenar informacion e instrucciones.
El sistema informatico 700 se puede acoplar por medio del bus 702 a un visualizador 712, tal como un tubo de rayos catodicos (CRT, cathode ray tube), para presentar visualmente una informacion a un usuario informatico. Un dispositivo de entrada 714, que incluye teclas alfanumericas y de otro tipo, se acopla con el bus 702 para comunicar informacion y selecciones de instrucciones al procesador 704. Otro tipo de dispositivo de entrada de usuario es el control de cursor 716, tal como un raton, una bola de seguimiento o teclas de direccion de cursor para comunicar informacion de direccion y selecciones de instrucciones al procesador 704 y para controlar el movimiento del cursor en el visualizador 712. Por lo general, este dispositivo de entrada tiene dos grados de libertad en dos ejes, un primer eje (por ejemplo, x) y un segundo eje (por ejemplo, y), que permiten que el dispositivo especifique posiciones en un
5
10
15
20
25
30
35
40
45
50
55
60
65
plano.
La invencion se refiere al uso del sistema informatico 700 para implementar las tecnicas que se describen en el presente documento. De acuerdo con una realizacion de la invencion, esas tecnicas son realizadas por el sistema informatico 700 en respuesta a la ejecucion por el procesador 704 de una o mas secuencias de una o mas instrucciones que estan contenidas en la memoria principal 706. Tales instrucciones se pueden ingresar por lectura en la memoria principal 706 a partir de otro medio legible por maquina, tal como el dispositivo de almacenamiento 710. La ejecucion de las secuencias de instrucciones que estan contenidas en la memoria principal 706 da lugar a que el procesador 704 realice las etapas de proceso que se describen en el presente documento. En realizaciones alternativas, se puede usar un conjunto de circuitos cableado en lugar de o en combinacion con instrucciones de soporte logico para implementar la invencion. Por lo tanto, las realizaciones de la invencion no se limitan a combinacion espedfica alguna de conjunto de circuitos de soporte ffsico y soporte logico.
La expresion "medio legible por maquina" tal como se usa en el presente documento se refiere a cualquier medio que participe en la provision de datos que dan lugar a que una maquina funcione de una forma espedfica. En una realizacion que se implementa usando el sistema informatico 700, diversos medios legibles por maquina estan involucrados, por ejemplo, en la provision de instrucciones al procesador 704 para su ejecucion. Un medio de este tipo puede adoptar muchas formas, incluyendo pero sin limitarse a, medios no volatiles, medios volatiles y medios de transmision. Los medios no volatiles incluyen, por ejemplo, discos opticos o magneticos, tales como el dispositivo de almacenamiento 710. Los medios volatiles incluyen memoria dinamica, tal como la memoria principal 706. Los medios de transmision incluyen cables coaxiales, hilo de cobre y fibra optica, incluyendo los hilos que comprenden el bus 702. Los medios de transmision tambien pueden adoptar la forma de ondas acusticas o luminosas, tales como las que se generan durante las comunicaciones de datos por ondas de radio e infrarrojos.
Las formas comunes de medios legibles por maquina incluyen, por ejemplo, un disquete flexible, un disco flexible, disco duro, cinta magnetica, o cualquier otro medio magnetico, un CD-ROM, cualquier otro medio optico, tarjetas perforadas, cinta de papel, cualquier otro medio ffsico con patrones de orificios, una RAM, una PROM y una EPROM, una EPROM FLASH, cualquier otro cartucho o microplaca de memoria, una onda portadora tal como se describe en lo sucesivo en el presente documento, o cualquier otro medio a partir del cual pueda leer un ordenador.
Diversas formas de medios legibles por maquina pueden estar involucradas en portar una o mas secuencias de una o mas instrucciones al procesador 704 para su ejecucion. Por ejemplo, las instrucciones se pueden portar inicialmente en un disco magnetico de un ordenador remoto. El ordenador remoto puede cargar las instrucciones en su memoria dinamica y enviar las instrucciones a traves de una lmea telefonica usando un modem. Un modem local con respecto al sistema informatico 700 puede recibir los datos por la lmea telefonica y usar un transmisor de infrarrojos para convertir los datos en una senal de infrarrojos. Un detector de infrarrojos puede recibir los datos portados en la senal de infrarrojos y un conjunto de circuitos apropiado puede colocar los datos en el bus 702. El bus 702 porta los datos hasta la memoria principal 706, a partir de la cual el procesador 704 recupera y ejecuta las instrucciones. Las instrucciones recibidas por la memoria principal 706 se pueden almacenar, de forma opcional, en el dispositivo de almacenamiento 710 o bien antes o bien despues de su ejecucion por el procesador 704.
El sistema informatico 700 tambien incluye una interfaz de comunicacion 718 que se acopla con el bus 702. La interfaz de comunicacion 718 proporciona un acoplamiento de comunicacion de datos bidireccional con un enlace de red 720 que esta conectado con una red local 722. Por ejemplo, la interfaz de comunicacion 718 puede ser una tarjeta de red digital de servicios integrados (ISDN, integrated services digital network) o un modem para proporcionar una conexion de comunicacion de datos a un tipo correspondiente de lmea telefonica. Como otro ejemplo, la interfaz de comunicacion 718 puede ser una tarjeta de red de area local (LAN, local area network) para proporcionar una conexion de comunicacion de datos a una LAN compatible. Tambien se pueden implementar enlaces inalambricos. En cualquier implementacion de este tipo, la interfaz de comunicacion 718 envfa y recibe senales electricas, electromagneticas u opticas que portan flujos de datos digitales que representan diversos tipos de informacion.
Por lo general, el enlace de red 720 proporciona una comunicacion de datos a traves de una o mas redes a otros dispositivos de datos. Por ejemplo, el enlace de red 720 puede proporcionar una conexion a traves de la red local 722 a un ordenador central 724 o un equipo de datos operado por un Proveedor de Servicios de Internet (ISP, Internet Service Provider) 726. El ISP 726 proporciona, a su vez, servicios de comunicacion de datos a traves de la red de comunicacion de datos por paquetes a nivel mundial a la que se hace referencia en la actualidad como "Internet" 728. Tanto la red local 722 como Internet 728 usan senales electricas, electromagneticas u opticas que portan flujos de datos digitales. Las senales a traves de las diversas redes y las senales en el enlace de red 720 y a traves de la interfaz de comunicacion 718, las cuales portan los datos digitales a y desde el sistema informatico 700, son formas a modo de ejemplo de ondas portadoras que transportan la informacion.
El sistema informatico 700 puede enviar mensajes y recibir datos, incluyendo codigo de programa, a traves de la red o redes, el enlace de red 720 y la interfaz de comunicacion 718. En el ejemplo de Internet, un servidor 730 podna transmitir un codigo solicitado para un programa de aplicacion a traves de Internet 728, el ISP 726, la red local 722 y la interfaz de comunicacion 718.
El codigo recibido puede ser ejecutado por el procesador 704 tal como se recibe este, y/o almacenarse en el dispositivo de almacenamiento 710, u otro almacenamiento no volatil para su ejecucion. De esta forma, el sistema informatico 700 puede obtener codigo de aplicacion en forma de onda portadora.
5 En la memoria descriptiva anterior, se han descrito realizaciones de la invencion con referencia a numerosos detalles espedficos que pueden variar de implementacion a implementacion. Por lo tanto, el indicador unico y exclusivo de que es la invencion, y es previsto por los solicitantes que sea la invencion, es el conjunto de reivindicaciones que surgen de la presente solicitud, en la forma espedfica en la que surgen tales reivindicaciones, incluyendo cualquier correccion posterior. Cualesquiera definiciones expuestas de forma expresa en el presente 10 documento para las expresiones contenidas en tales reivindicaciones regiran el significado de tales expresiones tal como se usan en las reivindicaciones. Por lo tanto, ninguna limitacion, elemento, propiedad, caractenstica, ventaja o atributo que no se enuncie de forma expresa en una reivindicacion debena limitar el alcance de tal reivindicacion en modo alguno. En consecuencia, la memoria descriptiva y los dibujos se han de considerar en un sentido ilustrativo mas que restrictivo.
15

Claims (20)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Un metodo implementado por ordenador para implementar una especificacion de perfil de dispositivos de servicios web, comprendiendo el metodo:
    ejecutar, en un dispositivo (102, 202, 302), una pluralidad de subprocesos que se ejecutan de forma concurrente que implementan, de forma colectiva, una funcionalidad que es especificada por la especificacion de perfil de dispositivos de servicios web;
    en el que el dispositivo (102, 202, 302) comprende al menos dos de: (a) una aplicacion de servicios web de exploracion de imagen, (b) una aplicacion de servicios web de impresion y (c) una aplicacion de servicios web de fax.
  2. 2. El metodo de la reivindicacion 1, en el que el dispositivo (102, 202, 302) funciona como tanto una maquina fotocopiadora como una impresora.
  3. 3. El metodo de la reivindicacion 1, en el que al menos uno de la pluralidad de subprocesos realiza solo tareas que son especificadas por el protocolo de Deteccion de Servicios Web.
  4. 4. El metodo de la reivindicacion 1, en el que al menos uno de la pluralidad de subprocesos maneja comunicaciones procedentes de procesos que se ejecutan dentro del dispositivo (102, 202, 302), pero no maneja comunicacion alguna procedente de proceso alguno que se ejecute externamente con respecto al dispositivo (102, 202, 302).
  5. 5. El metodo de la reivindicacion 1, en el que al menos uno de la pluralidad de subprocesos maneja comunicaciones procedentes de procesos que se ejecutan externamente con respecto al dispositivo (102, 202, 302) y que se comunican con el dispositivo (102, 202, 302) por medio de una red (104, 204, 304), pero no maneja comunicacion alguna procedente de proceso alguno que se ejecute dentro del dispositivo (102, 202, 302).
  6. 6. El metodo de la reivindicacion 1, en el que al menos uno de los subprocesos maneja comunicaciones procedentes de procesos que se ejecutan externamente con respecto al dispositivo (102, 202, 302), mientras que otro de los subprocesos maneja comunicaciones procedentes de procesos que se ejecutan dentro del dispositivo (102, 202, 302).
  7. 7. El metodo de la reivindicacion 1, en el que al menos uno de los subprocesos (1) detecta cambios en metadatos que estan relacionados con el dispositivo (102, 202, 302) y (2) indica a otro subproceso de la pluralidad de subprocesos que difunda, a traves de una red (104, 204, 304), a otros uno o mas dispositivos, una informacion de actualizacion que indica cambios en los metadatos.
  8. 8. El metodo de la reivindicacion 1, en el que al menos uno de los subprocesos inicializa otros uno o mas subprocesos de la pluralidad de subprocesos.
  9. 9. El metodo de la reivindicacion 1, en el que la finalizacion de uno cualquiera de la pluralidad de subprocesos no da lugar a que termine ningun otro subproceso de la pluralidad de subprocesos.
  10. 10. El metodo de la reivindicacion 1, en el que cada subproceso de la pluralidad de subprocesos es parte de un mismo gestor de instalaciones y dispositivo de multiples subprocesos (220, 320) para el dispositivo (102, 202, 302).
  11. 11. El metodo de la reivindicacion 10, en el que el gestor de instalaciones y dispositivo (220, 320) gestiona uno o mas protocolos de servicios web que se encuentran presentes en el dispositivo (102, 202, 302).
  12. 12. El metodo de la reivindicacion 10, en el que al menos una aplicacion de servicios web (206, 306A, 306B) que se ejecuta en el dispositivo (102, 202, 302) usa una implementacion de un protocolo de servicios web particular que (a) es implementada por el gestor de instalaciones y dispositivo (220, 320) y (b) no es implementada por dicha al menos una aplicacion de servicios web (206, 306A, 306B).
  13. 13. El metodo de la reivindicacion 1, en el que uno o mas subprocesos de la pluralidad de subprocesos se comunican con mensajes a los que se da formato basandose en SOAP y WSDL.
  14. 14. El metodo de la reivindicacion 1, en el que al menos un subproceso de la pluralidad de subprocesos difunde, a traves de una red (104, 204, 304), una informacion que indica que un servicio web que no se encontraba disponible previamente en el dispositivo (102, 202, 302) se encuentra disponible en la actualidad en el dispositivo (102, 202, 302).
  15. 15. El metodo de la reivindicacion 1, en el que al menos un subproceso de la pluralidad de subprocesos difunde, a traves de una red (104, 204, 304), una informacion que indica que un servicio web que se encontraba disponible previamente en el dispositivo (102, 202, 302) ya no se encuentra disponible en el dispositivo (102, 202, 302).
    5
    10
    15
    20
    25
    30
    35
    40
    45
    50
  16. 16. El metodo de la reivindicacion 1, en el que dichos subprocesos incluyen:
    al menos un subproceso que difunde, a traves de una red (104, 204, 304), una informacion que indica la presencia del dispositivo particular en la red;
    al menos un subproceso que escucha, en la red (104, 204, 304), en busca de una informacion que indica presencias de otros dispositivos en la red (104, 204, 304);
    al menos un subproceso que maneja comunicaciones con procesos que se ejecutan en el dispositivo (102, 202, 302) particular, pero que no maneja comunicacion alguna con proceso alguno que no se ejecute en el dispositivo (102, 202, 302) particular;
    al menos un subproceso que maneja comunicaciones con procesos que no se ejecutan en el dispositivo (102, 202, 302) particular, pero que no maneja comunicacion alguna con proceso alguno que se ejecute en el dispositivo (102, 202, 302) particular;
    al menos un subproceso que detecta cambios en el dispositivo (102, 202, 302) particular y actualiza, en respuesta, metadatos que indican servicios que son ofrecidos por el dispositivo (102, 202, 302) particular; al menos un subproceso que difunde, a traves de la red, una informacion que indica que el dispositivo (102, 202, 302) particular ofrece en la actualidad un servicio web que el dispositivo (102, 202, 302) particular no ofreda previamente; y
    al menos un subproceso que difunde, a traves de la red (104, 204, 304), una informacion que indica que el dispositivo (102, 202, 302) particular ya no ofrece un servicio web que el dispositivo (102, 202, 302) particular ofreda previamente.
  17. 17. El metodo de la reivindicacion 1, en el que el dispositivo (102, 202, 302) particular es un dispositivo de formacion de imagen.
  18. 18. El metodo de la reivindicacion 1, en el que el dispositivo (102, 202, 302) particular es un periferico multifuncion que actua como tanto una maquina fotocopiadora como una impresora.
  19. 19. Un medio legible por maquina que porta unas instrucciones que, cuando son procesadas por uno o mas procesadores (110), dan lugar a que los uno o mas procesadores (110) realicen unas etapas que comprenden:
    ejecutar, en un dispositivo (102, 202, 302), una pluralidad de subprocesos que se ejecutan de forma concurrente que implementan, de forma colectiva, una funcionalidad que es especificada por una especificacion de perfil de dispositivos de servicios web;
    en el que el dispositivo (102, 202, 302) comprende al menos dos de: (a) un modulo de exploracion de imagen, (b) un modulo de impresion y (c) un modulo de fax.
  20. 20. Un dispositivo (102, 202, 302) particular que ejecuta un proceso de multiples subprocesos de acuerdo con las etapas de metodo de la reivindicacion 1 que incluye dos o mas mecanismos que realizan, de forma simultanea entre sf, operaciones a partir de un conjunto de operaciones, incluyendo dicho conjunto de operaciones:
    difundir, a traves de una red (104, 204, 304), una informacion que indica la presencia del dispositivo particular en la red;
    escuchar, en la red (104, 204, 304), en busca de una informacion que indica presencias de otros dispositivos en la red;
    manejar comunicaciones con procesos que se ejecutan en el dispositivo (102, 202, 302) particular; manejar comunicaciones con procesos que no se ejecutan en el dispositivo (102, 202, 302) particular; detectar cambios en el dispositivo (102, 202, 302) particular y actualizar, en respuesta, metadatos que indican servicios que son ofrecidos por el dispositivo (102, 202, 302) particular;
    difundir, a traves de la red (104, 204, 304), una informacion que indica que el dispositivo (102, 202, 302) particular ofrece en la actualidad un servicio web que el dispositivo (102, 202, 302) particular no ofrecfa previamente; y
    difundir, a traves de la red (104, 204, 304), una informacion que indica que el dispositivo (102, 202, 302) particular ya no ofrece un servicio web que el dispositivo (102, 202, 302) particular ofreda previamente.
ES07122381.2T 2006-12-21 2007-12-05 Integración de funcionalidad de detección dentro de un gestor de instalaciones y dispositivo Active ES2582384T3 (es)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US11/644,181 US8112766B2 (en) 2006-12-21 2006-12-21 Multi-threaded device and facility manager
US644181 2006-12-21
US11/652,179 US8321546B2 (en) 2007-01-10 2007-01-10 Integrating discovery functionality within a device and facility manager
US652179 2007-01-10

Publications (1)

Publication Number Publication Date
ES2582384T3 true ES2582384T3 (es) 2016-09-12

Family

ID=39509608

Family Applications (1)

Application Number Title Priority Date Filing Date
ES07122381.2T Active ES2582384T3 (es) 2006-12-21 2007-12-05 Integración de funcionalidad de detección dentro de un gestor de instalaciones y dispositivo

Country Status (3)

Country Link
EP (1) EP1959638B9 (es)
JP (1) JP2008181487A (es)
ES (1) ES2582384T3 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7804823B2 (en) * 2007-09-09 2010-09-28 Xpedite Systems, Llc Systems and methods for communicating documents via an autonomous multiple-function peripheral device
CN106921688B (zh) * 2015-12-24 2020-10-02 阿里巴巴集团控股有限公司 分布式系统的服务提供方法及分布式系统

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020156872A1 (en) * 2001-01-04 2002-10-24 Brown David W. Systems and methods for transmitting motion control data
JP2004005503A (ja) * 2002-03-25 2004-01-08 Ricoh Co Ltd Ｗｅｂサービス機能を有する画像形成装置
JP4645164B2 (ja) * 2004-11-12 2011-03-09 セイコーエプソン株式会社 ネットワーク型プラグアンドプレイに対応したネットワーク装置の制御
JP4533186B2 (ja) * 2005-02-25 2010-09-01 キヤノン株式会社 画像形成装置及び画像形成方法

Also Published As

Publication number Publication date
EP1959638A3 (en) 2008-08-27
EP1959638B1 (en) 2016-04-27
EP1959638B9 (en) 2016-09-28
EP1959638A2 (en) 2008-08-20
JP2008181487A (ja) 2008-08-07

Similar Documents

Publication Publication Date Title
US8321546B2 (en) Integrating discovery functionality within a device and facility manager
US7987278B2 (en) Web services device profile on a multi-service device: dynamic addition of services
US7254601B2 (en) Method and apparatus for managing intelligent assets in a distributed environment
US8127306B2 (en) Integrating eventing in a web service application of a multi-functional peripheral
US7917619B2 (en) Supporting multiple service discovery protocols on a device
JP2004535634A (ja) 遠隔地にあるドキュメントを検索するシステムおよび方法
EP1887466A1 (en) Advanced web services on a legacy platform
US20080147777A1 (en) System and method for communication agent within a fully distributed network
EP2023579B1 (en) Extensible web services system
CA2560743A1 (en) Method and apparatus for communicating data between computer devices
US8135822B2 (en) Reporting events from multiple WS-enabled devices
US7680877B2 (en) Implementing a web service application on a device with multiple threads
ES2582384T3 (es) Integración de funcionalidad de detección dentro de un gestor de instalaciones y dispositivo
US8112766B2 (en) Multi-threaded device and facility manager
US7873647B2 (en) Web services device profile on a multi-service device: device and facility manager
ES2594625T3 (es) Descubrimiento y adición de servicios en un dispositivo multiservicio
US20080141280A1 (en) Method for handling communication without centralized component within a fully distributed network
EP1956798B1 (en) Integrating Eventing in a Web Service Application of a Multi-Functional Peripheral
US7904917B2 (en) Processing fast and slow SOAP requests differently in a web service application of a multi-functional peripheral
US20080147839A1 (en) System and method for central component console within a fully distributed network