ES2315970T3 - Sistema y procedimiento para administrar una pluralidad de servicios web. - Google Patents
Sistema y procedimiento para administrar una pluralidad de servicios web. Download PDFInfo
- Publication number
- ES2315970T3 ES2315970T3 ES06015020T ES06015020T ES2315970T3 ES 2315970 T3 ES2315970 T3 ES 2315970T3 ES 06015020 T ES06015020 T ES 06015020T ES 06015020 T ES06015020 T ES 06015020T ES 2315970 T3 ES2315970 T3 ES 2315970T3
- Authority
- ES
- Spain
- Prior art keywords
- execution
- web
- end point
- web service
- request
- 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.)
- Expired - Lifetime
Links
Classifications
-
- 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]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Warehouses Or Storage Devices (AREA)
- Train Traffic Observation, Control, And Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Un sistema para gestionar una pluralidad de servicios web comprendiendo un registro (10) incluyendo una descripción (WSDL1, WSDL2, WSDL3) para al menos uno de la pluralidad de servicios web, en el que la descripción (WSDL1, WSDL2, WSDL3) del al menos un servicio web comprende un primer punto final (WS1, WS2, WS3) para una primera condición de ejecución y un segundo punto final (WS1'', WS2'', WS3'') para una segunda condición de ejecución, caracterizado porque el sistema comprende además medios para monitorizar los puntos finales (WSJ, WS2, WS3, WS1; WS2; WS3'') de la pluralidad de servicios web durante la ejecución y medios para emitir un aviso si se llama a un primer servicio web con un punto final para una primera condición de ejecución y si se llama a un segundo servicio web con un punto final para una segunda condición de ejecución.
Description
Sistema y procedimiento para administrar una
pluralidad de servicios web.
La presente invención se refiere a un sistema y
a un procedimiento para administrar una pluralidad de servicios web
de una arquitectura de software orientada al servicio.
\vskip1.000000\baselineskip
Los servicios web son interfaces estandarizadas
para intercambiar datos de un ordenador a otro a través de una red
informática, por ejemplo, Internet. Una solicitud puede requerir
datos de un servidor a través de la red informática utilizando un
servicio web provisto por el servidor. Una petición de este tipo se
incluye típicamente en un sobre SOAP ("SOAP envelope")
que se transporta utilizando HTTP y puede comprender XML junto con
otros estándares relacionados con la web. Aplicaciones más avanzadas
desde el punto de vista técnico combinan varios servicios web para
obtener o procesar los datos deseados. Una arquitectura de software,
que se desarrolla alrededor de una pluralidad de servicios web, se
llama arquitectura orientada al servicio (SOA).
En un SOA, los recursos SOA se ponen a la
disposición de los participantes en la red como servicios
independientes a los que los participantes pueden acceder de una
manera estandarizada. Mientras que muchas definiciones de SOA
utilizan peticiones SOAP transportadas vía HTTP/HTTPS a través de
TCP/IP, un SOA puede utilizar cualquier tecnología basada en
servicio web. Los servicios web interactúan en base a definiciones
formales que son independientes de la plataforma subyacente y del
lenguaje de programación. La definición de interfaz engloba las
implementaciones específicas. Un SOA es independiente de una
tecnología de desarrollo específica (como el Java y el NET). Los
componentes de software se vuelven muy reutilizables ya que la
interfaz cumple con los estándares y es independiente de la
implementación subyacente de la lógica del servicio web. Por
ejemplo, una solicitud JAVA podría utilizar un servicio C# (C
Sharp) y viceversa.
El desarrollador de una nueva solicitud en un
SOA necesita acceso a los diversos servicios web que la nueva
solicitud va a utilizar. Esto no sólo se refiere a la disponibilidad
de las especificaciones de la interfaz de los servicios web
implicados, sino también a la provisión de servicios web realmente
activos a los que se puede llamar para probar la nueva solicitud.
Sin embargo, dichas llamadas de prueba no deben interferir con el
mundo real. Por ejemplo, llamar a un servicio web que provoque una
transferencia de dinero a modo de prueba no debe provocar una
transferencia de dinero real.
Se aplica un escenario similar tras el
desarrollo, cuando la nueva solicitud debe probarse en un entorno
mayor antes de ser aprobada para su uso en producción. De nuevo,
deben crearse nuevos casos de prueba de servicios web llamados por
la nueva solicitud, a causa de los diferentes requisitos
relacionados con la estabilidad o la generación de resultado
durante la fase de desarrollo y la fase de prueba en un entorno
mayor. Cuando la solicitud queda finalmente aprobada para
producción, las llamadas a los diversos servicios web de prueba
deben ser reemplazadas por llamadas a los servicios reales. Las
diversas etapas de reemplazo que intercambian los servicios web
para el desarrollo, prueba a gran escala y, finalmente, producción
presentan un riesgo substancial por introducir errores en la
solicitud
final.
final.
En la Patente WO 2005/029807 A1 se presenta un
procedimiento y un sistema para procesar información de contexto en
solicitudes basadas en la web para proporcionar Servicios Web
mediante peticiones respectivas. Se describe para incluir
información de contexto en la especificación de punto final
("endpoint") de una petición de servicio con el fin de
simplificar la comunicación entre el cliente y el proveedor del
servicio sin los cambios necesarios en las interfaces de servicio
web existentes.
En el documento "Web Services Description
Language (WSDL) Version 2.0 Part 1: Core Language" de Chinnici
et al. se define un lenguaje XML para describir servicios
Web basados en un modelo abstracto de lo que el servicio ofrece.
Además, el documento proporciona criterios de conformidad para
documentos en este lenguaje.
La Patente Europea 1 641 215 A2 presenta un
sistema y un procedimiento para enlazar identidades en un SOA. Un
enlace asociado con un primer dominio de seguridad sirve para
interceptar mensajes de un usuario de este dominio para un servicio
de un segundo dominio de seguridad. El enlace autentifica las
identidades del usuario contra una fuente local de autentificación.
El enlace conlleva una credencial de seguridad con el mensaje cuya
autenticidad se verifica mediante una pasarela asociada con el
segundo dominio cuando se recibe el mensaje autentificado.
Es pues el problema técnico subyacente de la
presente invención proporcionar un sistema y un procedimiento que
superen las desventajas arriba mencionadas de la técnica anterior y
que, en particular, faciliten el cambio desde las diferentes etapas
de desarrollo y prueba hasta la difusión misma de una nueva
solicitud que involucre a uno o varios servicios web sin el riesgo
de introducir errores.
En un aspecto de la invención, este problema se
soluciona mediante un sistema según la reivindicación 1.
Por consiguiente, servicios web para marcos de
ejecución diferentes (por ejemplo, desarrollo, prueba, producción)
pueden manejarse dentro de un mismo registro sin perder el control
sobre los servicios de los marcos y el riesgo implicado de
introducir errores. En la difusión, los puntos finales correctos
pueden escogerse automáticamente según la condición de ejecución
respectiva. Como resultado, se pueden generar automáticamente
diversos entornos de prueba y de producción de una nueva
solicitud.
En un modo de realización, el sistema está
adaptado además para seleccionar uno de los primer y segundo puntos
finales durante la ejecución dependiendo de una evaluación de la
información del entorno relacionada con la condición de ejecución
provista por una solicitud que llama al servicio web. Establecer el
valor de una sola variable en la solicitud permite pues determinar
qué marco se utiliza, ya que la o las descripciones de los
servicios web en el registro incluyen automáticamente puntos finales
adaptados a la condición de ejecución respectiva (por ejemplo,
prueba, difusión,
etc.).
etc.).
En otro modo de realización, el sistema está
adaptado además para seleccionar uno de los primer y segundo puntos
finales durante la ejecución dependiendo de la condición de
ejecución almacenada en el registro. El registro puede, por
ejemplo, almacenar información que refleje el estado actual del
proceso de desarrollo y, por consiguiente, selecciona el marco
adecuado de los servicios web para la nueva solicitud.
En un modo de realización, el primer y el
segundo puntos finales se definen en un primer y un segundo
documentos WSDL para el servicio web almacenado en el registro, que
están relacionados entre sí, por ejemplo, haciendo referencia el
uno al otro, donde cada uno de los documentos WSDL puede estar
marcado por su condición de ejecución especifica.
Sin embargo, en el presente modo de realización
preferente, el primer y el segundo puntos finales están definidos
en un único documento WSDL para el servicio web, preferiblemente
como un componente característico del documento WSDL. Como
resultado, el registro almacena descripciones WSDL de servicios web
"gemelos", en las que uno de los gemelos se utiliza para una
primera condición de ejecución y el otro para otra condición de
ejecución. El valor del componente característico se determina, en
un modo de realización, durante la ejecución utilizando un módulo
SOAP de una petición para el servicio web.
En el presente modo de realización preferente,
el primer punto final está adaptado para ser utilizado para probar
una solicitud que llama al, al menos un, servicio web, mientras que
el segundo punto final está preferiblemente adaptado para ser
utilizado en la difusión de una solicitud que llama al, al menos un,
servicio web. Sin embargo, el concepto de la presente invención
puede utilizarse también para escoger entre otros marcos, es decir,
para otras condiciones de ejecución.
El sistema comprende además medios para
monitorizar los puntos finales de la pluralidad de servicios web
durante la ejecución y medios para emitir un aviso si se llama a un
primer servicio web con un punto final para una primera condición
de ejecución y si se llama a un segundo servicio web con un punto
final para una segunda condición de ejecución. La función de
monitorización evita inconsistencias que pueden causar errores en la
ejecución de la nueva solicitud.
Según otro aspecto, la presente invención se
refiere a un procedimiento de acuerdo con la reivindicación 11.
Modificaciones ventajosas adicionales de los
modos de realización del sistema y del procedimiento de la invención
se definen en las reivindicaciones dependientes adicionales.
\vskip1.000000\baselineskip
En la siguiente descripción detallada, se
describen con más detalle modos de realización actualmente
preferidos de la invención con referencia a las siguientes
figuras:
Fig. 1: Una vista general de un ejemplo de un
SOA simplificado que comprende una solicitud que llama a un
Servicio Web y un registro con una descripción del Servicio Web;
y
Fig. 2: Una vista simplificada de un SOA de dos
marcos con una pluralidad de servicios web gemelos; y
Fig. 3: Un organigrama que ilustra las etapas
llevadas a cabo durante la ejecución en un sistema y procedimiento
según un modo de realización de la invención.
\vskip1.000000\baselineskip
La Fig. 1 presenta una visión global de un SOA
extremadamente simplificado: Una solicitud 30 emite una petición 31
para un servicio web 20. Con este fin, la solicitud 30 necesita
primeramente una descripción de las definiciones de interfaz del
servicio web 20. Esta descripción 40, que puede ser suministrada,
por ejemplo, en el Lenguaje de Definición del Servicio Web (WSDL
del inglés "Web Service Definition Language"), se puede
obtener tanto directamente del servicio web 20 como a través de un
registro 10 (cf. Fig. 1).
El registro 10 comprende preferiblemente
descripciones de todos los servicios web del SOA, por ejemplo
archivos WSDL 40 con información sobre la función, los datos, el
tipo de dato y los protocolos de intercambio del servicio web
respectivo. Por consiguiente, si la solicitud 30 intenta enviar una
petición al servicio web 20, puede obtener el archivo WSDL 40 desde
el registro 10 para descubrir como acceder al servicio web 20.
Sin embargo, cuando la nueva solicitud 30 se
está desarrollando, es necesario contactar repetidamente con el
servicio web implicado 20, ya con fines de prueba, por ejemplo para
verificar si se cumplen todos los requisitos de la interfaz en la
llamada al servidor web y si la solicitud 30 recibe y procesa
correctamente la respuesta del servicio web. Si el servicio web 20
está realmente en uso, cada una de estas llamadas de prueba causará
algunas operaciones en el mundo real (por ejemplo, la reserva de un
billete de avión o la transferencia de dinero de una cuenta a
otra). En este contexto, hay que notar que el servicio web 20 puede
estar en algún lugar en internet y que su funcionamiento puede no
estar necesariamente bajo el control del desarrollador de la nueva
solicitud 30.
Por consiguiente, la presente invención
proporciona, de acuerdo con un modo de realización preferido,
servicios "gemelos" como se muestra de forma esquemática en la
Fig. 2: Como se puede ver, el registro 10 almacena preferentemente
descripciones únicas WSDL1-WSDL3 de servicios web
correspondientes con, sin embargo, múltiples puntos finales cada
uno de los cuales lleva una referencia a marco de ejecución 50 o 50'
al que pertenece. El término "marco" se refiere a una parte
específica del SOA 100 en su conjunto que puede distinguirse
mediante algunos tipos de atributos designados. En el modo de
realización simplificado que se muestra en la Fig. 2 hay un marco de
prueba separado 50 y un marco de producción separado 50'. Ambos
marcos 50, 50' proporcionan, al menos en parte, los mismos
servicios web WS1-WS3 y WS1'-WS3',
pero sólo los servicios web de producción WS1'-WS3'
funcionan en la vida real y causan, por ejemplo, transacciones
comerciales. Las versiones de prueba de servicios productivos (por
ejemplo, los proporcionados por alguna 3ª parte) se pueden generar y
añadir automáticamente al registro 10.
También se pueden utilizar otros tipos de
distinciones de marcos, por ejemplo un marco de desarrollo contra
un marco de prueba mayor, o el marco de una empresa contra el marco
de otra empresa. Además, puede haber no sólo dos sino tres o más
marcos.
Para manejar sin errores la familia de servicios
gemelos arriba descrita, se definen en el registro único 10 los
puntos finales de los dos marcos 50, 50' en los que existen los
servicios web WS1-WS3 y WS1'-WS3',.
Así, las descripciones de la interfaz de servicio web
WSDL1-WSDL3 se comparten entre los marcos 50, 50',
mientras que los puntos finales no.
Sin embargo, hay que notar que, en vez de
utilizar descripciones WSDL únicas WSDL1-WSDL3 para
los servicios web WS1-WS3 y
WS1'-WS3', puede haber también como alternativa dos
conjuntos de descripciones relacionadas WSDL1-WSDL3
y WSDL1'-WSDL3' almacenadas en el registro (no
mostrado en la Fig. 2), donde las dos descripciones WSDL que
pertenecen a un servicio gemelo (por ejemplo WSDL1 y WSDL1') están
relacionadas entre sí. Dependiendo de la condición de ejecución, se
utiliza una descripción o la otra (o posiblemente una tercera).
En el presente modo de realización preferente,
los puntos finales de los dos marcos 50, 50' se definen en un solo
archivo WSDL para un servicio gemelo que utiliza el mecanismo de
extensibilidad de "características" provisto en el WSDL 2.0.
Una "características" representa un llamado valor de ejecución
que afecta al comportamiento de un aspecto de una interacción de
servicio web. Por ejemplo, un modulo SOAP de una petición puede
especificar una características para controlar los puntos finales.
Esto se ilustra en el siguiente ejemplo de archivo WSDL que
describe servicios gemelos:
Como se puede ver, se definen dos puntos
finales, uno para el marco de prueba, el otro para el marco de
producción. El valor de ejecución del componente característico
determina pues uno de dos posibles puntos finales y, por ello, si
el servicio web del marco de prueba o del marco de producción serán
tratados o no.
De manera alternativa, los puntos finales de los
dos marcos se pueden especificar según el esquema
UDDI-XML (UDDI 3.0) tal como se muestra a
continuación:
Una petición UDDI para encontrar el punto final
de un marco dado (por ejemplo, de prueba) puede parecerse pues a lo
siguiente:
La información de punto final que aparece así en
el archivo WSDL o el registro (UDDI) se puede utilizar en varios
escenarios, uno de los cuales se describe a continuación con
referencia al organigrama de la Fig. 3 que ilustra tres componentes
implicados:
Un componente de ejecución de servicio web 70
está disponible en ejecución (por ejemplo para llevar a cabo una
prueba) para una solicitud 30. La solicitud 30 llama al componente
de ejecución de servicio web 70 en la etapa 200, cuando se tiene
que ejecutar un servicio web 20, y recibe una única identificación
del servicio web 20 como entrada (por ejemplo, su clave UDDI, o el
URL de su archivo WSDL). En la etapa 201, el componente de
ejecución de servicio web 70 prepara la ejecución de la llamada. En
la etapa 202, accede a la información almacenada en el registro 10
para determinar en la etapa 204 el punto final para el servicio web
al que hay que llamar, por ejemplo en base al archivo WSDL obtenido
del registro 10. Hay que notar que el punto final que resulta de la
etapa 204 puede depender de un parámetro de entrada proporcionado
por la solicitud 30 y contenido en su llamada como se explica más
arriba, por ejemplo un cierto valor característico con el fin de
definir un cierto entorno para la ejecución de la llamada de
servicio web. Si no hay ningún servicio web disponible en el punto
final indicado, se indica un error. De lo contrario, el componente
de ejecución de servicio web 70 llama al servicio web identificado
en la etapa 205, que se ejecuta en la etapa 206 para que los
resultados puedan devolverse a la solicitud 30 en la etapa 207.
La gestión descrita de los puntos finales en el
registro permite además, en el tiempo de difusión de la solicitud
probada 30, identificar todos los puntos finales de servicio
utilizados previamente para probar esa solicitud y reemplazarlos
permanentemente por los puntos finales ya registrados en el registro
10 para el marco de producción. Además, las llamadas de servicio
web pueden ser monitorizadas en la ejecución y verificadas si ocurre
un cruce de marcos, es decir, si se llama a un servicio web que
pertenece a un primer marco, tal como el marco de prueba 50, y se
llama a otro servicio web 50' que pertenece a otro marco como el
marco de producción 50'. Si se detecta tal inconsistencia durante
la ejecución, se emite una alerta.
Generalmente, la identificación del marco de la
persona que llama puede utilizar múltiples mecanismos, por ejemplo,
una separación de los marcos de prueba y producción en base a
dominios DNS. Se puede enviar la información de marco junto con la
llamada de servicio web. El siguiente ejemplo de un archivo WSDL
almacenado en el registro 10 requiere tal información y asume que
hay un módulo SOAP específico para la gestión de la información de
marco:
De modo alternativo, el registro 10 puede
almacenar información sobre la fase de desarrollo de una cierta
solicitud y causar una selección adecuada de los puntos finales (por
ejemplo, en base a la difusión registrada de la solicitud). Esto se
puede hacer o bien para todo el marco o individualmente para cada
servicio web.
Claims (20)
1. Un sistema para gestionar una pluralidad de
servicios web comprendiendo un registro (10) incluyendo una
descripción (WSDL1, WSDL2, WSDL3) para al menos uno de la pluralidad
de servicios web, en el que la descripción (WSDL1, WSDL2, WSDL3)
del al menos un servicio web comprende un primer punto final (WS1,
WS2, WS3) para una primera condición de ejecución y un segundo
punto final (WS1', WS2', WS3') para una segunda condición de
ejecución, caracterizado porque
el sistema comprende además medios para
monitorizar los puntos finales (WSJ, WS2, WS3, WS1; WS2; WS3') de
la pluralidad de servicios web durante la ejecución y medios para
emitir un aviso si se llama a un primer servicio web con un punto
final para una primera condición de ejecución y si se llama a un
segundo servicio web con un punto final para una segunda condición
de ejecución.
2. El sistema de la reivindicación 1 adaptado
además para escoger uno de los primer (WS1, WS2, WS3) y segundo
puntos finales (WS1', WS2', WS3') durante la ejecución dependiendo
de una evaluación de información del entorno sobre la condición de
ejecución proporcionada por una solicitud (30) que llama al servicio
web.
3. El sistema de la reivindicación 1 adaptado
además para escoger uno de los primer (WS1, WS2, WS3) y segundo
puntos finales (WS1', WS2', WS3') durante la ejecución dependiendo
de la condición de ejecución almacenada en el registro (10).
4. El sistema de cualquiera de las
reivindicaciones precedentes, en el que el primer (WS1, WS2, WS3) y
el segundo punto final (WS1', WS2', WS3') se definen en un primer y
un segundo documentos WSDL para el servicio web, que están
relacionados entre sí.
5. El sistema de cualquiera de las
reivindicaciones precedentes 1-3, en el que el
primer (WS1, WS2, WS3) y el segundo punto final (WS1', WS2', WS3')
se definen en un único documento WSDL (WSDL1, WSDL2, WSDL3) para el
servicio web, como un componente característico del documento
WSDL.
6. El sistema de la reivindicación 5, en el que
el valor del componente característico se determina durante la
ejecución utilizando un módulo SOAP de una solicitud para el
servicio web.
7. El sistema de cualquiera de las
reivindicaciones precedentes 1-6, en el que el
registro (10) es un registro UDDI.
8. El sistema de cualquiera de las
reivindicaciones precedentes, en el que el primer punto final (WS1,
WS2, WS3) está adaptado para ser utilizado para probar una
solicitud que llama al, al menos un, servicio web.
9. El sistema de cualquiera de las
reivindicaciones precedentes, en el que el segundo punto final
(WS1', WS2', WS3') está adaptado para ser utilizado para la
difusión de una solicitud (30) que llama al, al menos un, servicio
web.
10. El sistema de cualquiera de las
reivindicaciones precedentes, en el que el registro (10) comprende
además un tercer punto final para una tercera condición de
ejecución.
11. Un procedimiento para gestionar una
pluralidad de servicios web comprendiendo la etapa de almacenar una
descripción (WSDL1, WSDL2, WSDL3) para al menos uno de la pluralidad
de servicios web en un registro (10), en el que la descripción del,
al menos un, servicio web comprende un primer punto final (WS1, WS2,
WS3) para una primera condición de ejecución y un segundo punto
final (WS1', WS2', WS3') para una segunda condición de ejecución,
caracterizado porque
el procedimiento comprende además la etapa de
monitorizar los puntos finales (WS1, WS2, WS3, WS1', WS2', WS3) de
la pluralidad de servicios web durante la ejecución y emitir un
aviso; si se llama a un primer servicio web con un punto final para
una primera condición de ejecución y si se llama a un segundo
servicio web con un punto final para una segunda condición de
ejecución.
12. El procedimiento de la reivindicación 11
comprendiendo además la etapa de seleccionar uno de los primer
(WS1, WS2, WS3) y segundo punto final (WS1', WS2', WS3') durante la
ejecución dependiendo de la evaluación de la información del
entorno sobre la condición de ejecución proporcionada por una
solicitud que llama al servicio
web.
web.
13. El procedimiento de la reivindicación 11
comprendiendo además la etapa de almacenar la condición de ejecución
en el registro; y
escoger uno de los primer (WS1, WS2, WS3) y
segundo punto final (WS1', WS2', WS3') durante la ejecución.
14. El procedimiento de cualquiera de las
reivindicaciones precedentes 11-13, en el que la
etapa de almacenar una descripción para al menos uno de la
pluralidad de servicios web en un registro comprende almacenar un
primer documento WSDL para el servicio web indicando el primer punto
final y almacenando un segundo documento WSDL para el servicio web
indicando el segundo punto final, en el que los primer y segundo
documentos WSDL están almacenados en el registro como documentos
WSDL relacionados.
15. El procedimiento de cualquiera de las
reivindicaciones precedentes 11-13, en el que la
etapa de almacenar una descripción (WSDL1, WSDL2, WSDL3) para al
menos uno de la pluralidad de servicios web en un registro comprende
almacenar un único documento WSDL para el servicio web con
componentes característicos indicando los primer y segundo puntos
finales.
16. El procedimiento de la reivindicación 15, en
el que los valores de los componentes característicos se determinan
durante la ejecución utilizando un módulo SOAP de una petición para
el servicio web.
17. El procedimiento de cualquiera de las
reivindicaciones precedentes 11-16, en el que el
registro (10) es un registro UDDI.
18. El procedimiento de cualquiera de las
reivindicaciones precedentes 11-17, comprendiendo
además la etapa de utilizar el primer punto final (WS1, WS2, WS3)
para probar una solicitud que llama al, al menos un, servicio
web.
19. El procedimiento de cualquiera de las
reivindicaciones precedentes 11-17, comprendiendo
además la etapa de utilizar el segundo punto final (WS1', WS2',
WS3') para la difusión una solicitud que llama al, al menos un,
servicio web.
20. El procedimiento de cualquiera de las
reivindicaciones precedentes 11-19, en el que el
registro (10) comprende además un tercer punto final para una
tercera condición de ejecución.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP06015020A EP1881675B1 (en) | 2006-07-19 | 2006-07-19 | System and method for managing a plurality of web services |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2315970T3 true ES2315970T3 (es) | 2009-04-01 |
Family
ID=37575002
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES06015020T Expired - Lifetime ES2315970T3 (es) | 2006-07-19 | 2006-07-19 | Sistema y procedimiento para administrar una pluralidad de servicios web. |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US8935370B2 (es) |
| EP (1) | EP1881675B1 (es) |
| CN (1) | CN101174983B (es) |
| AT (1) | ATE409384T1 (es) |
| DE (1) | DE602006002884D1 (es) |
| ES (1) | ES2315970T3 (es) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8972939B1 (en) * | 2007-04-13 | 2015-03-03 | United Services Automobile Association (Usaa) | Systems and methods for processing and producing content for web sites |
| US20090070335A1 (en) * | 2007-09-06 | 2009-03-12 | Cozianu Costin V | System and method for web processing monitoring |
| EP2093676A1 (de) * | 2008-02-20 | 2009-08-26 | Siemens Aktiengesellschaft | Verfahren zur Generierung von Funktionsbausteinen für Webdienste. |
| RU2591651C2 (ru) * | 2010-09-21 | 2016-07-20 | ПэйПэл, Инк. | Способ и система инициализации услуг программирования |
| GB2502998A (en) * | 2012-06-13 | 2013-12-18 | Ibm | Automatic creation of endpoint definition documents for different environments |
| CN108833135B (zh) * | 2018-05-04 | 2023-06-06 | 深圳市共进电子股份有限公司 | 一种Mesh组网管理方法、管理设备以及延长器 |
| US10735300B1 (en) * | 2018-11-30 | 2020-08-04 | Intuit Inc. | Discovery and testing of program dependencies in computer networks |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080281969A1 (en) * | 2000-12-15 | 2008-11-13 | Horton John C | Controlling access to versions of application software by a server, based on site ID |
| WO2005029807A1 (en) * | 2003-09-24 | 2005-03-31 | International Business Machines Corporation | Personalized web service description |
| US20050160153A1 (en) * | 2004-01-21 | 2005-07-21 | International Business Machines Corp. | Publishing multipart WSDL files to URL |
| EP1641215B1 (en) * | 2004-09-28 | 2017-08-16 | CA, Inc. | System and method for bridging identities in a service oriented architecture |
| US7509398B2 (en) * | 2005-01-13 | 2009-03-24 | International Business Machines Corporation | System and method for protocol independent access and invocation of web services |
-
2006
- 2006-07-19 EP EP06015020A patent/EP1881675B1/en not_active Expired - Lifetime
- 2006-07-19 DE DE602006002884T patent/DE602006002884D1/de not_active Expired - Lifetime
- 2006-07-19 ES ES06015020T patent/ES2315970T3/es not_active Expired - Lifetime
- 2006-07-19 AT AT06015020T patent/ATE409384T1/de not_active IP Right Cessation
-
2007
- 2007-07-18 US US11/779,317 patent/US8935370B2/en active Active
- 2007-07-19 CN CN200710146445.0A patent/CN101174983B/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP1881675B1 (en) | 2008-09-24 |
| DE602006002884D1 (de) | 2008-11-06 |
| US20080028316A1 (en) | 2008-01-31 |
| CN101174983B (zh) | 2011-04-06 |
| CN101174983A (zh) | 2008-05-07 |
| US8935370B2 (en) | 2015-01-13 |
| EP1881675A1 (en) | 2008-01-23 |
| ATE409384T1 (de) | 2008-10-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Erl et al. | Web service contract design and versioning for SOA | |
| CN108171083B (zh) | 区块链可信数据管理方法、系统及计算机可读存储介质 | |
| Sinha et al. | Building an E Ective IoT Ecosystem for Your Business | |
| US8843877B2 (en) | Integrated SOA deployment and management system and method for software services | |
| ES2579454T3 (es) | Ajuste de servicios web a un contrato actualizado | |
| CN111641710A (zh) | 基于微服务的数据处理方法、装置、终端及存储介质 | |
| JP2011527781A (ja) | ネットワーク資源がサービス・ランドスケープ・インスタンス内でプロビジョンされるときに、ネットワーク・セキュリティ・ポリシ・ルールを更新するためのコンピュータ実装方法、システム及びコンピュータ・プログラム | |
| US20140089148A1 (en) | Systems and methods for network inventory managment utilizing mobile technology | |
| CN117917681A (zh) | 基于多区块链的资产转移方法、装置、设备、介质及产品 | |
| US11343352B1 (en) | Customer-facing service for service coordination | |
| US8935370B2 (en) | System and method for managing a plurality of web services | |
| US8655757B1 (en) | System and method for assigning a unique asset identity | |
| CN114296880B (zh) | 基于大规模集群的服务请求处理方法、装置、设备及介质 | |
| US10397342B2 (en) | Web service contract selection | |
| US9892023B2 (en) | Systems and methods of analyzing software systems having service components | |
| CN119027038A (zh) | 业务流程处理方法、装置、计算机设备和可读存储介质 | |
| CN117472741A (zh) | 全链路环境隔离方法、装置和设备 | |
| CN115952099B (zh) | 一种基于智能路由策略的mock测试方法、装置及设备 | |
| Zhou et al. | Pi4soa: A policy infrastructure for verification and control of service collaboration | |
| CN111553683B (zh) | 具有智能合同的可验证分析学平台 | |
| CN111382121B (zh) | 一种信息管理系统及存储介质 | |
| US20130275571A1 (en) | Configuring an enforcement device according to a contract | |
| CN116346478B (zh) | 用于数据访问的方法、装置、设备和存储介质 | |
| CN122027688A (zh) | 多域系统互联方法及设备 | |
| Adams et al. | The architecture |