por Dipanjan Chakraborty y Harry Chen
Traducido por Pablo J. Rogina
Este artículo se enfoca en el efecto de la computación móvil en el comercio electrónico y discute la tecnología detrás del cambio que está teniendo lugar. Explica distintas forma de descubrir servicios en un entorno dinámico. El incremento en el uso de Asistentes Digitales Personales (Personal Digital Assistants) como PalmPilots brinda a los usuarios la capacidad de llevar a cabo transacciones electrónicas desde una plataforma móvil. Esto ha acuñado el nuevo término "Comercio Móvil". El Comercio Electrónico puede definirse en general como la suma de todas las transacciones en Internet. Cuando estos tipos de aplicaciones e instalaciones de procesamiento de transacciones necesitan ser accedidas desde un dispositivo inalámbrico, una nueva área de investigación y problemas retadores aparecen en escena. Como es evidente en forma inmediata, el Comercio Móvil tiene que lidiar con el nuevo problema de encontrar datos que dependen de la ubicación.
Los servicios pueden definirse como facilidades que están disponibles para una computadora. Una computadora conectada a un sistema distribuido tiene acceso a la impresora, escáner, copiadora, etc. Si es un nodo conectado a Internet, puede acceder a precios de libros a través de sitios web y realizar otras transacciones varias. Ya que los negocios ofrecen distintos tipos de servicios heterogéneos a sus clientes, encontrar un servicio en forma eficiente se vuelve importante. Este artículo resume las arquitecturas existentes para el descubrimiento de servicios, compara y contrasta las arquitecturas existentes, y explica algunas de las desventajas inherentes. También presentamos el marco de Agente Ronin y el trabajo hecho en el proyecto XReggie para mejorar las técnicas existentes de descubrimiento de servicios [4, 6].
Jill está conduciendo en la autopista. El auto tiene una computadora de abordo. Ella tiene un teléfono celular y una PalmPilot. La computadora de abordo del automóvil se conecta con otras computadoras de autos cercanos usando su dispositivo inalámbrico incorporado e intercambia información acerca del tráfico más adelante, información de accidentes, etc. Jill tiene muy poco combustible y quiere encontrar la estación e servicio más cercana. Su computadora de abordo o su PalmPilot pueden hacer este trabajo por ella. La computadora de abordo se conecta con otras computadoras de abordo de automóviles que pasan en el sentido opuesto usando protocolos de red adhoc e intenta recoger la información sobre si algún auto ha cargado combustible recientemente y también trata de saber la ubicación de la estación de servicio. Mientras tanto, su PalmPilot está buscando agentes estación de servicio en el barrio. De repente, obtiene respuesta de uno y calcula su posición. La PalmPilot también encuentra un agente mapa quien da las instrucciones de manejo para la estación de servicio en la computadora de mano.
Jill no tiene problemas en cargar combustible.
Ella estuvo manejando todo el día y casi es de noche. Jill decide parar a descansar. Jill le dice a su PalmPilot que reserve una habitación en el hotel más cercano. El dispositivo de mano se contacta con los agentes de las asociaciones locales de hoteles/restaurantes y consigue el mejor trato posible en la habitación que ella prefiere. Jill quiere que su cena estilo mexicana esté lista cuando llegue al hotel. El agente en su PalmPilot hace su pedido para que sea realizado por el agente hotel. Se obtienen instrucciones de manejo como de costumbre. La Figura 1 da una breve reseña de la comunicación en proceso dentro de los distintos agentes durante todo el episodio.
Hay algunas suposiciones básicas al describir el escenario anterior. Asumimos que el nivel de interconexión y hardware aumentará en forma consistente en el futuro cercano. Asumimos que la aparición de sistemas tales como PalmPilots y Bluetooth, los cuales proveerán conexiones con ancho de banda moderada de corto alcance a muy bajo costo. También asumimos la existencia de redes inalámbricas de fácil acceso e instaladas ampliamente tanto de área local (LAN por sus iniciales en inglés - Local Area Networks) como de área amplia (WAN por sus iniciales en inglés - Wide Area Networks).
La tecnología Bluetooth es en esencia un reemplazo de la tecnología de cables donde dos dispositivos habilitados para Bluetooth se pueden comunicar de manera eficiente unos con otros usando radio frecuencia. Es un emprendimiento conjunto de nueve compañías líderes dentro de la industria de la computación y las telecomunicaciones.
¿Qué tecnologías necesitamos para hacer factible el escenario anterior? Debería haber agentes de servicio en la vecindad para recibir los pedidos y procesarlos. Pero otra pregunta importante rebotando en la mente de un científico de computación sería "¿Cómo mi PalmPilot sabe acerca de las facilidades electrónicas a mi alrededor?". Descubrir estos tipos de servicios en forma dinámica se está volviendo muy importante en el presente escenario. En el futuro cercano, un servicio debería seleccionarse automáticamente para un trabajo, teniendo en consideración su ubicación física, historia previa, y diversa información semántica adicional. El mecanismo de descubrimiento necesita moverse más allá de la comparación trivial de atributo o interfaz. El mecanismo de descubrimiento debería estar mucho más basado en conocimiento, y la inteligencia artificial jugará un rol importante en la selección del servicio. Al tratar de construir una arquitectura de descubrimiento de servicios eficiente, algunas de las preguntas de alto nivel que un investigador podría tratar de resolver son:
Nos internamos en Internet y viajamos de red en red para encontrar los protocolos de de descubrimiento de servicios existentes. Tratamos de identificar algunos de los problemas inherentes asociados con las arquitectura de descubrimiento existentes. Subsecuentemente, describimos el trabajo que hemos hecho en el campo de descubrimiento de servicios para hacerlo más dinámico.
El Protocolo de Ubicación de Servicios (SLP por sus iniciales en inglés - Service Location Protocol) es un producto del Grupo de Trabajo del Protocolo de Ubicación de Servicios (SVRLOC por sus iniciales en inglés - Service Location Protocol Working Group) de la Fuerza de Ingeniería de Internet (IETF por sus iniciales en inglés - Internet Engineering Task Force) [9, 10]. Es un protocolo para descubrimiento automático de servicios para redes basadas en el Protocolo Internet. SLP es un protocolo independiente del lenguaje. De este modo la especificación del protocolo puede implementarse en cualquier lenguaje. Basa su mecanismo de descubrimiento en atributos de servicio, los cuales son en esencia formas diferentes de describir a un servicio. Puede satisfacer formas de servicios tanto de hardware como de software.
La infraestructura SLP consiste en tres tipos de agentes:
Los Agentes Usuarios adquieren vínculos de servicios para las aplicaciones de usuario final que piden los servicios. Los Agentes de Servicio son responsables de publicar los vínculos de servicio a los Agentes de Directorio haciendo así que los servicios estén disponibles a los Agentes Usuarios. El Agente de Directorio mantiene una lista de servicios publicados en una red. En el escenario anterior, el agente que reside en la computadora de mano es el agente usuario y el agente que lleva el registro de información de hoteles es el agente de servicio. SLP ofrece los siguientes servicios:
Un servicio se describe por los valores de configuración de los posibles atributos para ese servicio. Por ejemplo, un servicio que permite a los usuarios descargar contenido de audio o video puede describirse como un servicio que es sin-cargo o pago-por-uso. SLP también soporta un mecanismo simple de arriendo de registro de servicios que maneja los casos donde el hardware del servicio está averiado pero el servicio continua siendo anunciado.
Jini es una arquitectura distribuida orientada a servicios desarrollada por Sun Microsystems [1]. Los servicios en Jini pueden representar dispositivos de hardware, programas de software, o una combinación de los dos. Una colección de servicios Jini forma una federación Jini. Los servicios Jini coordinan unos con otros dentro de la federación. El objetivo general de Jini es convertir a la red en una herramienta flexible y fácilmente administrable en la cual los clientes computacionales y humanos puedan encontrar servicios en un modo robusto y flexible. Jini esta diseñada para hacer a la red una entidad más dinámica que refleje mejor la naturaleza dinámica del grupo de trabajo al posibilitar la capacidad de agregar y quitar servicios en forma flexible.
Uno de los componentes claves de Jini es el Servicio de Búsqueda Jini (JLS por sus iniciales en inglés - Jini Lookup Service), el cual mantiene información dinámica acerca de los servicios disponibles en una federación Jini. Cada servicio debe descubrir uno o más Servicios de Búsqueda Jini antes de que pueda ingresar en una federación. La ubicación del JLS podría conocerse de antemano, o podrían descubrirse usando multicast. Un JLS puede en potencia estar disponible a la red local o a otras redes remotas (por ej. Internet). El JLS también puede asignarse para tener nombres de grupo de modo que un servicio pueda descubrir a un grupo específico en su vecindad.
Cuando un servicio Jini quiere unirse a una federación Jini, primero descubre uno o más JLS de la red local o redes remotas. El servicio entonces carga su proxy de servicio (es decir, un conjunto de clases Java) al JLS. Los clientes de servicio pueden usar este proxy para contactar al servicio original e invocar métodos del servicio. Ya que los clientes de servicio sólo interactúan con proxies de servicio basados en Java, ésto permite que varios tipos de servicios, tanto servicios de hardware y software, sean accedidos de modo uniforme. Por ejemplo, un cliente de servicio puede invocar pedidos de impresión a un servicio de impresión PostScript aún si no tiene ningún conocimiento del lenguaje PostScript.
Un usuario que busque un servicio en una red primero envía en simultáneo (multicast) una consulta para encontrar el JLS en la red. Si existe un JLS, el objeto remoto correspondiente se descarga a la máquina del usuario. El usuario entonces usa el objeto para encontrar el servicio deseado. En Jini, el descubrimiento de servicios se hace por coincidencia (matching) de interfaz o coincidencia de atributos Java. Si el JLS contiene un servicio válido implementando la interfaz especificada por el usuario, entonces se descarga un proxy para ese servicio en la máquina del usuario. El proxy se usa de ahora en adelante para llamar a diferentes funcionas ofrecidas por el servicio.
Universal Plug and Play (UPnP), impulsado básicamente por Microsoft, es una arquitectura que evoluciona diseñada para extender el modelo original de periféricos Plug and Play de Microsoft a un mundo altamente dinámico de muchos dispositivos de red provistos por muchos proveedores [12]. UPnP trabaja básicamente con conjuntos de protocolos de red de las capas más bajas (esto es, TCP/IP), implementando estándares a este nivel. UPnP intenta asegurar que todos los fabricantes de dispositivos pueden adherir rápidamente al estándar propuesto sin mayores problemas. Al brindar una conjunto de protocolos de red definidos, UPnP permite que los dispositivos construyan sus propias APIs (Application Programming Interfaces) que implementen estos protocolos - en cualquier lenguaje o plataforma que ellos elijan.
UPnP usa el Protocolo Simple de Descubrimiento de Servicios (SSDP por sus iniciales en inglés - Simple Service Discovery Protocol) para descubrir servicios en redes basadas en el Protocolo Internet. SSDP puede operarse con o sin un servicio de directorio o búsqueda en la red. SSDP opera sobre los protocolos abiertos existentes, usando HTTP (HyperText Transfer Protocol) tanto sobre envío único (unicast) y envío múltiple (multicast) UDP (User Datagram Protocol). El proceso de registro envía y recibe datos en forma de hipertexto, pero tiene alguna semántica especial.
Cuando un servicio quiere unirse a la red, primero envía un mensaje de aviso (o anuncio), notificando al mundo acerca de su presencia. En el caso de aviso de envío múltiple, el servicio envía el aviso en una dirección de envío múltiple reservada. Si está presente un servicio de directorio o búsqueda, éste puede registrar tales avisos. Mientras tanto, otros servicios en la red pueden ver directamente estos avisos. El mensaje de "aviso" contiene un URL (Universal Resource Locator) que identifica el servicio publicado y un URL a un archivo que brinda una descripción del servicio publicado.
Cuando un cliente de servicios quiere descubrir un servicio, puede tanto contactar al servicio directamente a través del URL que se provee en el anuncio del servicio, o puede enviar un pedido de búsqueda de envío simultáneo (multicast). En el caso de descubrir un servicio a través del pedido de búsqueda de envío simultáneo, el pedido del cliente puede ser respondido por el servicio directamente o por un servicio de directorio o búsqueda. La descripción del servicio no juega ningún rol en el proceso de descubrimiento del servicio.
Salutation es un protocolo de descubrimiento de servicios y administración de sesión desarrollado por compañías líderes de la tecnología de la información [7]. Salutation es un estándar abierto independiente de sistemas operativos, protocolos de comunicaciones y plataformas de hardware. Salutation fue creado para resolver los problemas de descubrimiento de servicios y utilización entre un amplio conjunto de dispositivos y equipos en un entorno de gran cobertura de conectividad y movilidad. La arquitectura provee aplicaciones con diferentes servicios que son escasos a través de toda la red. También contiene funciones para descubrir las capacidades de servicios remotos. Salutation brinda características para que una aplicación establezca sesiones interoperables con cualquier servicio remoto.
La arquitectura Salutation define una entidad llamada Administrador Salutation (SLM por sus iniciales en inglés - Salutation Manager) que funciona como un intermediario de servicios para los servicios en la red. Las diferentes funciones de un servicio están representadas por unidades funcionales. Las Unidades Funcionales representan características esencial de un servicio (por ej. fax, impresora, escáner, etc). Además, los atributos de cada Unidad Funcional se capturan in el Registro de Descripción de Unidad Funcional. Salutation define la sintaxis y semántica del Registro de Descripción de Unidad Funcional (por ej. nombre, valor). SLM puede ser descubierto por los servicios en un número de maneras tales como:
El proceso de descubrimiento de servicios puede realizarse a través de múltiples SLMs. Un SLM puede descubrir otros SLMs remotos y determinar los servicios que están registrados allí. El Descubrimiento de Servicios se lleva a cabo comparando el tipo de servicio requerido, según lo especifica el SLM local, con el tipo de servicio disponible en un SLM remoto. Se usan Llamadas a Procedimientos Remotos para transmitir el tipo de Servicio requerido desde el SLM local al SLM remoto y para transmitir la respuesta desde el SLM remoto al SLM local. El SLM determina las características de todos los servicios registrados en un SLM remoto al manipular la especificación del tipo de servicio requerido. También puede determinar las características de un servicio específico registrado en un SLM remoto o la presencia de un servicio específico en un SLM remoto al comparar un conjunto específico de características.
Los protocolos descriptos más arriba en esencia usan atributos típicos o comparación de interfaz para comparar los servicios existentes en la red. SLP asume la existencia de un mecanismo subyacente basado en el Protocolo Internet (IP) y usa UDP (por sus iniciales en inglés - User Datagram Protocol) para comunicarse. Salutation en contraste es una arquitectura independiente de protocolo de red. La presencia de un administrador de transporte en Salutation aísla el mecanismo de comunicación subyacente del administrador de salutation. De este modo se espera que salutation tenga prominencia cuando estén en boga redes no basadas en el Protocolo Internet. UPnP trabaja con conjuntos de protocolos de más bajo nivel y su especificación está basada en la suposición de una red tipo Protocolo Internet por debajo.
Tanto SLP, Salutation y UPnP son protocolos independientes del lenguaje. Las especificaciones del protocolo pueden implementarse en cualquier lenguaje. Jini por otra parte es totalmente dependiente de Java para su implementación. Java es un lenguaje independiente de la plataforma lo cual hace a su vez a Jini independiente de la plataforma. En Jini, la interacción entre servicios y usuarios está definida en términos de la interfaz de un objeto, mientras que en UPnP, la interacción está definida en términos de un protocolo de red. UPnP usa un esquema de coincidencia basado en XML para descubrir servicios. Jini en cambio usa interfaces Java.
UPnP y Salutation usan en esencia multicasting para encontrar servicios o escuchan a pedidos de servicios para encontrar la ubicación de los servicios deseados. Jini por su parte usa un esquema centralizado donde todos los tipos de servicios se registran en un servicio de búsqueda. Los usuarios contactan al servicio de búsqueda para descubrir los servicios existentes en la red. El Protocolo de Ubicación de Servicios implementa un esquema basado en un directorio centralizado como también un esquema de envío simultáneo para descubrir servicios. Mientras que los esquemas centralizados del Protocolo de Ubicación de Servicios y Jini son más escalables, son también proclives a un único punto de falla. Salutation a diferencia de Jini es un protocolo liviano y hace menos suposiciones del protocolo subyacente y recursos de computación. De este modo puede llevarse fácilmente a dispositivos de mano poco potentes. Jini en cambio, debido a su dependencia de Java requiere considerables recursos de computación para funcionar correctamente.
Todos las infraestructuras y arquitecturas de descubrimiento de servicios mencionadas arriba como SLP, Jini, UPnP, y Salutation han sido desarrolladas para explorar los aspectos de descubrimiento de servicios en el contexto de sistemas distribuidos. Mientras muchas de las arquitecturas brindan una buena base para desarrollar sistemas con componentes distribuidos en redes, no solucionan de forma adecuada todos los problemas que pueden surgir en un dominio dinámico.
Algunas de las deficiencias son:
Los servicios en el Comercio Electrónico son heterogéneos por naturaleza. Estos servicios se definen en términos de sus funcionalidades y capacidades. Las descripciones de functionalidad y capacidad de estos servicios son usados por los clientes del servicio para descubrir los servicios deseados. Coincidencia de atributos es un componente muy importante para encontrar los servicios apropiados en tal entorno. Las arquitecturas de descubrimiento de servicios existentes carecen de lenguajes expresivos, representaciones y herramientas que sean buenas al representar un amplio rango de descripciones de servicios y sean buenas para razonar acerca de las funcionalidades y capacidades de los servicios. Por ej., los protocolos de descubrimiento de servicios no usan ningún parámetro de rendimiento para los servicios existentes. Solamente están satisfechos con encontrar un servicio. No consideran si el servicio sería capaz de atender el pedido.
En la arquitectura Jini, las funcionalidades y capacidades de los servicios se describen en términos de objetos Java de interfaces. Las coincidencias de capacidad de Servicios son procesados solamente a nivel objeto y a nivel sintaxis. Por ejemplo, la Búsqueda Jini genérica y otros protocolos de descubrimiento permite que un servicio cliente encuentre un servicio de impresión que soporte impresión a color, pero los protocolos no son lo suficientemente potentes para encontrar el servicio de impresión geográficamente más cercano que tenga la cola de impresión más corta. Los protocolos realizan comparación semántica exacta mientras encuentran un servicio. De esta forma ellos pierden el poder de dar una "coincidencia justa" aun si estaba disponible.
Habiendo identificado algunas de las deficiencias comunes en las técnicas de descubrimiento de servicios existentes, presentamos una breve descripción de nuestro trabajo enfocado en resolver los temas. Uno puede mejorar el mecanismo de descubrimiento de servicios aplicando herramientas y técnicas de Inteligencia Artificial a los sistemas existentes. El proyecto XReggie se concentra en mejorar la coincidencia de atributos más allá del la comparación trivial basado en sintaxis. Con el advenimiento de redes ad-hoc y aproximaciones basados en agentes, será extremadamente necesario comunicarse entre diferentes grupos de agentes en diferentes redes quienes hablan diferentes lenguajes. En el proyecto Ronin hemos resuelto este problema y provisto una marco para dichas comunicaciones.
El Marco de Agentes Ronin es un de desarrollo de agente distribuido basado en Jini [2,4]. Ronin introduce una arquitectura híbrida, una composición de arquitectura orientada a servicios y orientada a agentes, para desplegar en sistemas distribuidos dinámicos. Entre muchas de las características distinguibles del marco, Ronin ofrece una facilidad de descripción de agente simple pero potente que permite que los agentes se encuentren unos a otros y una infraestructura que alienta el reuso de aplicaciones de Inteligencia Artificial no Java.
En Ronin, los agentes se describen usando dos tipos de atributos: los atributos de Agente Común y los atributos de Agente de Dominio. Estos son dos conjuntos de atributos de servicio Jini que están asociados con cada agente Ronin en el Servicio de Búsqueda Jini. Los atributos de Agente Común definen las funcionalidades y capacidades genéricas de un agente de modo independiente del dominio. Los atributos de Agente de Dominio definen las funcionalidades específicas del dominio del agente. El marco define el significado semántica de cada atributo de Agente Común, pero no define el significado semántico de ningún atributo de Agente de Dominio.
La facilidad de descripción de Ronin puede mejorar la infraestructura de descubrimiento de servicios de Jini para Comercio Móvil de la siguiente forma:
El marco Ronin alienta el reuso de aplicaciones existentes de Inteligencia Artificial no Java. La filosofía es que desarrollar infraestructuras, tales como el descubrimiento de servicios en Comercio Móvil, que son altamente adaptables, interactivas, interoperables y autónomas requiere más que la arquitectura Jini. Desarrollar infraestructuras que son más "inteligentes" a menudo requiere técnicas y herramientas de IA sofisticadas, tales como motores de inferencia, sistemas de representación de conocimiento, programación con restricciones, etc. Por ejemplo, sería útil para un Servicio de Búsqueda Jini ser capaz de razonar acerca de las capacidades de sus servicios registrados, permitiendo que el JLS haga recomendaciones de búsqueda de servicios más "inteligentes".
El marco Ronin brinda un Servicio de Motor Prolog Jini (JPES por sus iniciales en inglés - Jini Prolog Engine Service) [3]. Este servicio provee servicios de motor Prolog remoto para componentes habilitados para Jini en la red. JPES provee una herramienta de programación lógica distribuida para servicios habilitados para Jini. Un Servicio de Búsqueda mejorado puede usar el JPES para razonar acerca de las capacidades de servicios y poder hacer recomendaciones más "inteligentes".
El proyecto XReggie investiga como Jini y sistemas similares pueden ser llevados más allá de sus simples aproximaciones de conicidencia de servicios basadas en sintaxis, agregando poder expresivo a las descripciones de servicios. XReggie agrega las facilidades para describir funcionalidades y capacidades de servicios usando XML (Extended Markup Language). XReggie permite que el descubrimiento de servicios se realice de manera más estructurada y descriptiva [6]. En el corazón de XReggie está el Servicio de Búsqueda Jini mejorado que brinda "ubicación de servicios" para dispositivos habilitados para Jini. XReggie puede ayudar a que los clientes de servicios descubra dichos servicios de manera esencialmente sin cambios respecto de la infraestructura Búsqueda y Descubrimiento Jini. Además, permite que los servicios anuncien sus capacidades en un formato descriptivo bien estructurado usando XML. Aún más, XReggie permite que los servicios sean descubiertos usando descripciones XML.
Este artículo describe las arquitectura de descubrimiento de servicios que tendrían prominencia con el advenimiento del Comercio Móvil. Ya que más personas comienzan a usar computadoras portátiles y de mano, aumentará su necesidad de conectarse a Internet para compartición ubicua y acceso a datos. Las computadoras estacionarias conectadas a Internet ya no serán consideradas suficientes para la computación en "cualquier lugar" y en "cualquier momento". El Comercio Móvil y su proliferación obviamente nos está llevando a una manera más refinada y flexible de acceder a instalaciones desde cualquier lugar. Un modelo orientado a servicios basados en ubicación (location based service oriented model) es una de las necesidades más importantes en tal entorno distribuido. Una buena infraestructura de descubrimiento jugará un rol importante en tal entorno. Hemos revisado un número de infraestructuras de descubrimiento de servicios existentes. Hemos encontrado que todas estas infraestructuras sufren un problema común, meramente la falta de lenguajes descriptivos y herramientas que sean buenas para representar un amplio rango de descripciones de servicios y sean buenas para razonar acerca de las funcionalidades y capacidades des los servicios. La falta de infraestructuras para definir ontologismo común a través de empresas y clientes es otro problema clave en las infraestructuras de descubrimiento de servicios existentes.
Hemos desarrollado el Ronin Agent Framework y XReggie que apuntan a aumentar el rendimiento de la infraestructura de descubrimiento de servicios Jini en el futuro Mercado Electrónico Móvil. El marco Ronin mejora la infraestructura de descubrimiento de servicios Jini al proveer una facilidad de descripción simple pero poderosa y alienta la reutilización de las herramientas no Java en el entorno Jini. El proyecto XReggie mejora la infraestructura de descubrimiento de servicios Jini al extender el Servicio de Búsqueda Jini existente para manejar el registro y coincidencia de servicios usando descripciones XML bien estructuradas.
Dipanjan Chakraborty puede ser contactado en dchakr1@cs.umbc.edu. Es un estudiante de Ph.D. y Asistente de Investigación en el Departamento de Ciencias de la Computación & Ingeniería Eléctrica, Universidad de Maryland Baltimore County. Sus intereses de investigación incluyen computación Móvil y distribuida, Comercio Electrónico, Protocolos de Redes, Redes y Sistemas Distribuidos Ad-hoc. Es un miembro estudiante de ACM.
Harry Chen puede ser contactado en hchen4@cs.umbc.edu. Es un estudiante de Ph.D. y Asistente de Investigación en el Departamento de Ciencias de la Computación & Ingeniería Eléctrica, Universidad de Maryland Baltimore County. Sus intereses de investigación incluyen Sistemas Multi-Agente, Computación Móvil, Computación Dominante, Comercio Electrónico, y Sistemas Distribuidos. La dirección de su página en Internet es http://www.acm.org/~hchen1/