Integración de repositorios de metadatos IBM, parte 2: Gobernabilidad del ciclo de vida de los metadatos en WebSphere Service Registry and Repository

Aprenda cómo activar un desarrollo basado en activos integrando sus aplicaciones con IBM® Rational® Asset Manager. En la parte 2, aprenderá cómo usar WebSphere® Service Registry and Repository para definir y gobernar el ciclo de vida de los metadatos.

Bei Bei Wang, Software Engineer, IBM

Bei Bei Wang es Software Engineer en el Centro de Diseño SOA del China Development Lab. Se especializa en la gobernabilidad de SOA y otros temas relacionados, y actualmente se desempeña como desarrolladora en el proyecto de incubación SOA Federated Metadata Management (FMDM).



Tian Tan, Software Engineer, IBM

Tian Tan se unió al Centro de Diseño SOA del China Development Lab como Software Engineer en 2007. Desde hace dos años, trabaja en el proyecto de incubación FMDM centrándose en la integración de Rational Asset Manager, la gestión de metadatos, la ontología y la Web semántica. Además, tiene amplia experiencia en técnicas relacionadas con Web 2.0, Java, J2EE y Eclipse RCP. Tan Tian es IBM Certified SOA Solution Designer.



Zhe Yan, Software Engineer, IBM

Zhe Yan es Staff Software Engineer del Centro de Diseño SOA del China Development Lab. Su actividad se concentra en temas relacionados con la gobernabilidad SOA, especialmente la federación de metadatos. Actualmente se dedica al diseño y desarrollo relacionado con la integración de WBG y WebSphere Services Registry and Repository.



Xiao Xing Liang, Software Engineer, IBM

Xiao Xing Liang es Software Engineer en el Centro de Diseño SOA del China Development Lab. Es IBM Certified WebSphere Enterprise Developer e IBM Certified SOA Solution Designer. Actualmente se dedica a gobernabilidad SOA y temas relacionados, como WebSphere Service Registry and Repository, Rational Asset Manager, Tivoli Application Dependency Discovery Manager y Tivoli Change and Configuration Management Database



Yu Chen Zhou, Staff Software Engineer, IBM

Yu Chen Zhou se desempeña como Staff Software Engineer en el IBM China Software Development Lab. Se especializa en soluciones ubicuas y de portal. Para contactarlo, escríbale a zhouyuc@cn.ibm.com.



Chuan Feng Li, Software Engineer, IBM

Chuan Feng Li photoChuan Feng Li is a Software Engineer working at the SOA Design Center in IBM's China Software Development Lab. He has several years of work experience in the IT industry, and is strongly interested in software development and application. Currently, he is engaged in development work relevant to ESB and SCA.



03-02-2010

Introducción

Usando el perfil de gobernabilidad de WebSphere Service Registry and Repository (en adelante, Service Registry) como ejemplo, este artículo describe la definición de ciclo de vida y las directivas de gobernabilidad, así como su uso en la gobernabilidad de servicios. Además, presenta una solución de metadatos de integración denominada Service Registry Advanced Lifecycle Edition (Service Registry ALE) para el ciclo de vida del tiempo de diseño y del tiempo de ejecución.


Perfiles de configuración de Service Registry

Service Registry V6.0.2 introduce un concepto llamado perfil de configuración, el cual contiene un conjunto completo de archivos de configuración de Service Registry. Su funcionalidad se amplía gradualmente en las últimas versiones, y en Service Registry V6.2 es posible personalizar un conjunto de archivos de configuración, como control de acceso, sistemas de modelos de negocios, sistemas de clasificación, ciclos de vida, interfaces de usuario Web, notificadores, modificadores y validadores definidos por el usuario. Service Registry V6.2 ofrece un perfil predeterminado, así como un perfil de gobernabilidad adecuado para un entorno de aplicación real. Ambos perfiles se cargan en la instalación. Para visualizar los perfiles de configuración y su estado, como se puede ver en la figura 1, vaya a la perspectiva Configuration (Configuración) en la consola Web de Service Registry y seleccione Manage Configuration Profiles (Gestionar perfiles de configuración) => Configuration Profiles (Perfiles de configuración). Podrá cargar todos los perfiles que desee en Service Registry, pero solo uno estará Active (Activo) en un momento determinado. Todos los demás quedarán Archived (Archivados). Para activar un perfil diferente, seleccione el perfil y haga clic en Make Active (Activar). En el árbol de navegación, expanda Active Configuration Profile (Perfil de configuración activo); podrá visualizar todos los elementos definidos en el perfil activo, como se puede ver en la figura 1.

Figura 1. Perfiles de configuración
Perfiles de configuración

Haga clic para ver una versión ampliada de la figura 1.)


Generalidades del perfil de gobernabilidad de Service Registry

El perfil de gobernabilidad de Service Registry V6.2 es un conjunto de artefactos de configuración de Service Registry, incluidos modelos de negocios, sistemas de clasificación, ciclos de vida y directivas de gobernabilidad que soportan una gobernabilidad de SOA básica. Este perfil está proyectado como punto de partida para la gobernabilidad de SOA de Service Registry. Sin embargo, es posible modificar el modelo de negocios, los ciclos de vida y las directivas en función de sus necesidades.

Esta sección trata del ciclo de vida y de las directivas de gobernabilidad del perfil de gobernabilidad, que facilitan la promoción del servicio a través de su ciclo de vida como una importante función de gobernabilidad. En la próxima sección se explicará en detalle la manera de usarlos.

Máquina de estados compuestos

Un modelo de ciclo de vida de metadatos gobernados usa una máquina de estados de negocios para describir los estados del ciclo de vida y la transición entre ellos. Se usa el editor visual en WebSphere Integration Developer (Integration Developer).

El perfil predeterminado únicamente soporta un ciclo de vida de SOA. Sin embargo, en una aplicación real, es poco probable que todos los metadatos de los diferentes tipos en Service Registry sigan este ciclo de vida. Por eso el perfil de gobernabilidad proporciona una máquina de estados compuestos, donde los metadatos de diferentes tipos pueden seguir diferentes máquinas de subestados.

Usando la vista Life Cycle Configuration (Configuración de ciclo de vida), que se muestra en la figura 2, es posible visualizar y actualizar el contenido de la definición de ciclo de vida, así como importar el archivo a Integration Developer para visualizarlo en una vista de gráficos, como se muestra en la figura 3. El estado inicial es Created (Creado) y el estado final es Completed (Finalizado). Hay cuatro estados compuestos: InterfaceLifecycle, PolicyLifecycle, ServiceVersionLifecycle y ServiceLifecycle. Cada estado compuesto incluye una máquina de subestados.

Figura 2. Definición de ciclo de vida en el perfil de gobernabilidad
Definición de ciclo de vida en el perfil de gobernabilidad
Figura 3. Definición de ciclo de vida en una vista de gráficos de Integration Developer
Definición de ciclo de vida en una vista de gráficos de Integration Developer

Haga clic para ver una versión ampliada de la figura 3.)

Directivas de gobernabilidad

Después de ver la máquina de estados anterior, es posible que se haga las siguientes preguntas:

  • ¿Para qué tipo o tipos de entidades es adecuada una máquina de subestados?
  • Cuando se ejecuta una transición de un estado a otro, ¿existen condiciones necesarias para los metadatos?

Las respuestas para ambas preguntas están definidas en las directivas de gobernabilidad. Es posible ver y personalizar esta configuración desde la perspectiva Configuration (Configuración) de la consola Web de Service Registry seleccionando Active Configuration Profile (Perfil de configuración activo) => Plug-ins (Complementos) => Governance Policies (Directivas de gobernabilidad), como se puede ver en la figura 4.

Figura 4. Políticas de gobernabilidad
Políticas de gobernabilidad

Cada estado compuesto debe tener una directiva que defina los tipos para los cuales ese estado es adecuado. Por ejemplo, la directiva de gobernabilidadServiceInterfaceLifecycle - InitiatePolicydescribe las condiciones necesarias aplicables a ServiceInterfaceLifecycle. El listado 1 muestra parte de la directiva de gobernabilidad ServiceInterfaceLifecycle - InitiatePolicy.

Listado 1. Parte de la directiva de gobernabilidad ServiceInterfaceLifecycle - InitiatePolicy
					1 <wsp:Policy
                xmlns:wsp="http://www.w3.org/ns/ws-policy" … 
				> 2
                <wsrrgp:
				ValidatorPolicy wsrrgp:name="ServiceInterfaceLifecycle
				3 - Initiate
                Policy 4 … 5 <
				wsrrgp:WSRROperationFilter> 6 7
                <wsrrgp:WSRROperation>MAKE_GOVERNABLE</wsrrgp:WSRROperation>
                8
                <wsrrgp:WSRROperation>TRANSITION<
				/wsrrgp:WSRROperation>
                9 </wsrrgp:WSRROperationFilter> 
				10
                <wsrrgp:TransitionOperationFilter>
				11
                <wsrrgp:TransitionOperation> 12
http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileLifecycle 13
                #InitiateInterfaceLifecycle 14
				</wsrrgp:TransitionOperation> 15
                </wsrrgp:TransitionOperationFilter> 16
                <wsrrgp:EntityAssertionPolicy> 17 
				<wsp:Policy
                wsrr:policyClass="EntityAssertionClass" 18
                wsrr:policyClassDomain=
"http://www.ibm.com.policy/GovernancePolicyDomain"> 19
                <wsrrgp:AnyOfAssertion 20
                wsrrgp:
name="GovernanceProfileLifecycleInitializationPolicy. 21
                ServiceInterfaceLifecycleEntityAssertion"
				> 22 <wsrrgp:EntityAssertion 23
				wsrrgp:name=
"GovernanceProfileLifecycleInitializationPolicy. 
24 ServiceInterfaceLifecycleEntityAssertion"
				25 wsrrgp:entityType="XSDDocument"
				/> 26 
				<wsrrgp:EntityAssertion 27
                wsrrgp:
				name="GovernanceProfileLifecycleInitializationPolicy. 28
                ServiceInterfaceLifecycleEntityAssertion" 29
                wsrrgp:
				primaryType=
	"http://www.ibm.com/xmlns/prod/serviceregistry 30
                /6/1/TechnicalModel#ServiceInterface"
				/> 31 <wsrrgp:EntityAssertion 32
                wsrrgp:
				name="GovernanceProfileLifecycleInitializationPolicy. 33
                ServiceInterfaceLifecycleEntityAssertion" 34
                wsrrgp:primaryType=
				"http://www.ibm.com/xmlns/prod/serviceregistry 35
                /6/1/TechnicalModel#ServiceBinding" /> 36 <wsrrgp:EntityAssertion 37
                wsrrgp:
				name="GovernanceProfileLifecycleInitializationPolicy. 38
                ServiceInterfaceLifecycleEntityAssertion" 39
                wsrrgp:primaryType=
				"http://www.ibm.com/xmlns/prod/serviceregistry 40
                /6/1/TechnicalModel#MessageSchema"
				/> 41
                </wsrrgp:AnyOfAssertion> 
				42 </wsp:Policy> 43
                </wsrrgp:EntityAssertionPolicy> 
				44 … 45
                </wsrrgp:ValidatorPolicy> 46 
				</wsp:Policy>
  • Las líneas 5-9 definen WSRROperationFilter y especifican que únicamente las operaciones MAKE_GOVERNABLE y TRANSITIONson aplicables a la directiva.MAKE_GOVERNABLE hace que los metadatos no gobernados pasen a ser gobernados, y TRANSITION realiza una transición del estado de los datos gobernados.
  • Las líneas 10-14 indican que la directiva es adecuada para la transición de InitiateInterfaceLifecycle, que ingresa en la máquina de subestados InterfaceLifecycle (ver figura 2 ).http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileLifecycle#InitiateInterfaceLifecycle especifica la URL de clasificación de transición apropiada.
  • Las líneas 16-43 describen los límites de ServiceInterfaceLifecycle respecto de metadatos de los siguientes tipos: XSDDocument, ServiceInterface, ServiceBinding y MessageSchema.

Para cada tipo de metadatos compatible con un estado compuesto existe una directiva de restricción en cada transición de la máquina de subestados. Por ejemplo, la directiva de gobernabilidad ServiceInterfaceLifecycle - ServiceInterface - ApproveInterfacePolicy describe las condiciones necesarias al ejecutar la transición ApproveInterface para los metadatos de tipo Service Interface. El listado 2 muestra parte de la directiva de gobernabilidad ServiceInterfaceLifecycle - ServiceInterface - ApproveInterfacePolicy.

Listado 2. Parte de la directiva de gobernabilidad ServiceInterfaceLifecycle - ServiceInterface - ApproveInterfacePolicy
					1 <wsp:Policy
                xmlns:wsp="http://www.w3.org/ns/ws-policy" ... > 2
                <wsrrgp:ValidatorPolicy wsrrgp:name="ServiceInterface Lifecycle 3 -
                ServiceInterface - ApproveInterface Policy"> 4 <wsp:Policy …
                wsp:Name="urn:ServiceInterfaceLifecycle_ServiceInterface_ 5
                ApproveInterfacePolicy"> 6 … 7
                <wsrrgp:TransitionOperationFilter> 8
                <wsrrgp:TransitionOperation> 9
                http://www.ibm.com/xmlns/
				prod/serviceregistry/6/1/GovernanceProfileLifecycle
				10
                #ApproveInterface 11 
				</wsrrgp:TransitionOperation> 12
                </wsrrgp:TransitionOperationFilter> 13
                <wsrrgp:EntityAssertionPolicy> 14 <wsp:Policy …> 15
                <wsrrgp:RelationshipAssertion 16
                wsrrgp:
				relationshipName=
				"wsrrtm_authoritativeWSDLs" 17 
				wsrrgp:minCardinality="1"
                wsrrgp:maxCardinality="1" 18 wsrrgp:
				name="ServiceInterfaceLifecyclePolicy. 19
                ExactlyOneAuthoritativeInterfaceWSDLAssertion"
				> 20
                <wsrrgp:EntityAssertion wsrrgp:entityType="WSDLDocument" 21
                wsrrgp:name="ServiceInterfaceLifecyclePolicy. 22
                ExactlyOneAuthoritativeInterfaceWSDLAssertion" /> 23
                </wsrrgp:RelationshipAssertion> 24 </wsp:Policy> 25
                </wsrrgp:EntityAssertionPolicy> 26 </wsp:Policy> 27
                </wsrrgp:ValidatorPolicy> 28 </wsp:Policy>

Las líneas 15-23 definen una condición que los metadatos de tipo Service Interface deben satisfacer para que no falle la ejecución de la transición. Además, los metadatos deberían tener una relación wsrrtm_authoritativeWSDLs con un único documento WSDL.


Uso del perfil de gobernabilidad de Service Registry

Service Registry se puede usar en todas las fases del ciclo de vida de SOA. Veamos un escenario que demuestra cómo usar una máquina de estados compuestos y directivas para la gobernabilidad de metadatos. Este escenario incluye varios tipos de ciclos de vida definidos en el perfil de gobernabilidad, incluidos InterfaceLifecycle,ServiceVersionLifecycle y ServiceLifecycle.

Es muy fácil personalizar el perfil de gobernabilidad en función de las necesidades del usuario (modificar el ciclo de vida, cambiar las directivas de gobernabilidad, etc.). En el presente ejemplo, modificaremos la directiva de gobernabilidad ServiceLifecycle - BusinessService - ApproveForDeploymentPolicy, como se puede ver en el listado 3. Las secciones en negrita se agregan para relajar la restricción; la condición de Business Service respecto de ambas clasificaciones en función de wsrrgp:ClassificationAssertion se limita a cualquiera de ellas.

Si desea obtener más información acerca de la personalización del perfil de gobernabilidad, consulte el siguiente artículo: Customize the WebSphere Service Registry and Repository governance profile.

Listado 3. Personalización de ServiceLifecycle – BusinessService - ApproveForDeploymentPolicy
					<wsrrgp:RelationshipAssertion
                wsrrgp:
				relationshipName="wsrrgp_realizingServices"
				wsrrgp:minCardinality="1"
                wsrrgp:
	name=
"ServiceLifecyclePolicy.DeployedServiceVersionAvailableAssertion"
	><
	wsrrgp:EntityAssertion wsrrgp:
	 entityType="GenericObject"
                wsrrgp:name=
"ServiceLifecyclePolicy.DeployedServiceVersionAvailableAssertion">
            <wsrrgp:ClassificationAssertion 
			wsrrgp:combinationCode="Any" 
			><wsrrgp:Classification>
			http://www.ibm.com/xmlns/
 prod/serviceregistry/6/1/GovernanceProfileLifecycle#ServiceVersionDeploy
 </wsrrgp:Classification>
 <wsrrgp:Classification>
 http://www.ibm.com/xmlns/
prod/serviceregistry/6/1/GovernanceProfileLifecycle#ServiceVersionManage
</wsrrgp:Classification>
 </wsrrgp:ClassificationAssertion>
 </wsrrgp:EntityAssertion>
 </wsrrgp:RelationshipAssertion>

Las entidades de descripción de servicio constituyen una categoría de metadatos en el modelo de información mantenido por Service Registry que incluye documentos físicos, derivaciones lógicas y objetos genéricos. Para ver estos metadatos, use la perspectiva GP Administrator (Administrador de perfil de gobernabilidad) en la consola Web de Service Registry.

  • Documentos físicos: documentos reales que describen un servicio, como un documento WSDL. Para ver los tipos de documentos físicos, expanda Service Documents (Documentos de servicio) en el árbol de navegación.
  • Derivaciones lógicas: Service Registry redistribuye los documentos físicos de manera automática para generar objetos derivados que representan construcciones dentro del documento, como una definición portType derivada de un WSDL. Para ver los tipos de derivaciones lógicas, expanda Service Metadata (Metadatos de servicio) en el árbol de navegación.
  • Objetos genéricos: representan cualquier elemento del modelo de información que no tenga un documento físico en Service Registry. Para ver los objetos genéricos, seleccione Business Metadata (Metadatos de negocios) => Concepts (Conceptos).

En el escenario planteado, se usan tres tipos de objetos genéricos: Business Service (Servicio de negocios), Service Interface (Interfaz de servicio) y Service Version (Versión de servicio). La figura 5 ofrece una visión general de las relaciones entre ellos y de sus respectivos ciclos de vida.

Figura 5. Diversos tipos de condiciones previas de ciclo de vida y de transición de estado
Diversos tipos de condiciones previas de ciclo de vida y de transición de estado

En los siguientes pasos se pueden ver más detalles de este escenario. Pongamos como ejemplo el servicio de matemática, un sencillo servicio de cálculos matemáticos que proporciona operaciones de adición y sustracción.

Modelado del servicio

Siga estos pasos para modelar el servicio. Consulte Perfiles de configuración de Service Registry para activar WSRR_GOVERNANCE_PROFILE en la consola Web de Service Registry.

  1. Seleccione Business Metadata (Metadatos de negocios) => Business Service View (Vista de servicios de negocios) => Organizations (Organizaciones) y cree una organización con el nombreSample. Haga clic en Sample en el diálogo Governance (Gobernabilidad) y luego haga clic en Govern (Gobernar) para que se vuelva gobernable.
  2. Para crear un objeto genérico llamado MathService que represente el servicio de matemática, en la perspectiva GP Administrator (Administrador de perfil de gobernabilidad), seleccione Business Metadata (Metadatos de negocios) => Business Service View (Vista de servicio de negocios) => Business Services (Servicios de negocios). Cree un servicio de negocios llamado MathService. En el diálogo Details (Detalles), haga clic en Edit Relationships (Editar relaciones), agregue Sample a la relación Owning Organization (Organización propietaria) de MathService y haga clic en Finish (Finalizar).
  3. Haga clic en Edit Classification (Editar clasificación), seleccione Governance Profile Taxonomy (Taxonomía de perfil de gobernabilidad) => Business Domain (Dominio de negocios) => Finance (Finanzas) y agréguelo a MathService.wsdl para indicar que el servicio de matemática se aplica a la industria financiera.
  4. Ahora es necesario desarrollar la interfaz del servicio de matemática, MathInterface.wsdl. MathInterface.wsdl define el portType WSDL (ver SampleWSDLs.zip). Hay dos operaciones, add_X_to_Y y subtract_X_from_Y, que representan las operaciones matemáticas de adición y sustracción.
  5. Publique MathInterface.wsdl seleccionando Sevice Documents (Documentos de servicio) => WSDL Documents (Documentos WSDL) para cargar MathInterface.wsdl. Automáticamente se crean Math (en adelante, Math(PT)) como PortType de una derivación lógica y Math (en adelante, Math(SI)) como Service Interface de un objeto genérico; Math(SI) tiene una relación Authoritative WSDLS con MathInterface.wsdl y una relación Interface Declarations con Math(PT).

    Seleccione Business Metadata (Metadatos de negocios) => Governance Service View (Vista de servicio de gobernabilidad) => Service Interfaces (Interfaces de servicio) y haga clic en Math(SI) para ver las dependencias en la vista Details (Detalles) de los metadatos.

  6. Ahora es necesario volver gobernable la Service Interface y cambiar el estado a la fase de modelado. En la pestaña Governance (Gobernabilidad) de Math(SI), seleccione Initiate Interface Life Cycle de la lista Initial state transitions (Transiciones de estado iniciales) y haga clic en Govern (Gobernar). El estado de gobernabilidad de Math(SI) pasa al estado Specify. Sobre la base del análisis de la directiva de gobernabilidad del Listado 1, sabemos que el ciclo de vida de Math(SI) está autorizado a seguir la máquina de subestados InterfaceLifecycle. Sobre la base de la directiva de gobernabilidad del Listado 2, Math(SI) satisface la condición previa de la transición ApproveInterface, por lo que es posible hacer clic en Transition (Transición) para cambiar el estado de gobernabilidad a Published, como se puede ver en la figura 6. El estado de gobernabilidad de MathInterface.wsdl es también Published porque está en el mismo grupo de gobernabilidad que Math(SI).
    Figura 6. Cambio de estado de la interfaz de servicio a Published (Publicada)
    Cambio de estado de la interfaz de servicio a Published (Publicada)

Ensamblado del servicio

Siga estos pasos para ensamblar el servicio:

  1. Desarrolle el enlace del servicio de matemática, MathBinding.wsdl. MathBinding.wsdl define el enlace WSDL, que importa MathInterface.wsdl (ver SampleWSDLs.zip).
  2. Publique MathBinding.wsdl en Service Registry como se indica en el paso 5 mencionado anteriormente. Como MathInterface.wsdl ya existe en Service Registry, la relación de importación será suficiente y la publicación de MathBinding.wsdl se realizará con éxito. Automáticamente se crean MathSoapBinding(en adelante,MathSoapBinding(B)) como enlace de una derivación lógica yMathSoapBinding(en adelante,MathSoapBinding(SB)) como enlace de servicio de un objeto genérico;MathSoapBinding(SB) tiene una relación Authoritative WSDLS con MathBinding.wsdl, una relación Binding Declarations con MathSoapBinding(B) y una relaciónAssociated Interface con Math(SI).

    Seleccione Business Metadata (Metadatos de servicio) => Governance Service View (Vista de servicio de gobernabilidad) => Service Bindings (Enlaces de servicio) y haga clic en MathSoapBinding(SB) para ver las dependencias en la vista Details (Detalles) de los metadatos.

  3. El ciclo de vida de Service Binding también está autorizado a seguir la máquina de subestados InterfaceLifecycle. Vuelva gobernable MathSoapBinding(SB) y realice la transición del estado de gobernabilidad a Published, como se indica en el paso 6 mencionado anteriormente.
  4. Agregue Math(SI) a la relaciónGoverned Service Interface de MathService. El ciclo de vida de Business Service está autorizado a seguir la máquina de subestados ServiceLifecycle, que se pudo observar en la directiva de gobernabilidad. (Consulte las muestras en Generalidades del perfil de gobernabilidad de Service Registry). Vuelva MathService gobernable, y realice la transición del estado de gobernabilidad a Assemble (Ensamblar), como se puede ver en la figura 7, para indicar que el servicio está completamente ensamblado.
    Figura 7. Cambio de estado del servicio de negocios a Assemble (Ensamblar)
    Cambio de estado del servicio de negocios a Assemble (Ensamblar)

Implementación del servicio

Siga estos pasos para implementar el servicio:

  1. Desarrolle el extremo del servicio de matemática. MathService.wsdl define el extremo WSDL, que es la dirección SOAP para acceder al servicio de matemática. MathService.wsdl importa MathBinding.wsdl (ver SampleWSDLs.zip). Es posible usar los WSDL de muestra proporcionados para su descarga o consultar la especificación WebServices Description Language (WSDL) Version 2.0 Part 1: Core Language para obtener más información acerca de la escritura de WSDL.
  2. Publique y clasifique MathService.wsdl. Publique MathService.wsdl en Service Registry como se explicó anteriormente. Automáticamente se crean MathService como servicio de una derivación lógica y MathService(en adelante, MathService(SV)) como versión de servicio de un objeto genérico. Agregue una clasificación Test a MathService.wsdl, como se puede ver en la figura 8, para indicar que el servicio de matemática se implementa en un servidor de aplicaciones de un entorno de prueba.
    Figura 8. Agregación de una clasificación de Prueba al WSDL
    Agregación de una clasificación de Prueba al WSDL
  3. El ciclo de vida de Service Version está autorizado a seguir la máquina de subestados ServiceVersionLifecycle sobre la base de las directivas de gobernabilidad. Vuelva MathService(SV)(ver figura 9) gobernable, y realice la transición del estado de gobernabilidad a Service Version Deploy (Implementar versión de servicio) (ver figura 10) para indicar que el servicio de matemática ha sido implementado.
    Figura 9. Seguimiento de Service Version a ServiceVersionLifecycle
    Seguimiento de Service Version a ServiceVersionLifecycle
    Figura 10. Cambio de estado de la versión de servicio a Service Version Deploy
    Cambio de estado de la versión de servicio a Service Version Deploy

    Si MathService.wsdl no está clasificado como Test, cuando ejecute la transición del estado de gobernabilidad Service Version Assemble al estado de gobernabilidad Service Version Deploy, observará el error que aparece en la figura 11 debido a que MathService(SV) debería tener al menos un WSDL de extremo relacionado con una clasificación Test. Es posible obtener este WSDL de extremo relacionado a partir de la directiva de gobernabilidad ServiceVersionLifecycle - ServiceVersion - ApproveForDeploymentPolicy.

    Figura 11. Error de transición de estado
    Error de transición de estado
  4. Agregue MathService(SV) a la relaciónRealizing Governed Services de MathService. Luego, realice la transición del estado de gobernabilidad de MathService a Deploy (Implementar).

Gestión del servicio

Siga estos pasos para gestionar el servicio:

  1. Clasifique MathService.wsdl. Una vez que el servicio de matemática esté funcionando correctamente en el entorno de prueba, es posible implementarlo en un entorno de producción para un uso real. Elimine la clasificación Test y agregue la clasificación Production para MathService.wsdl.
  2. Gobierne Service Version y Business Service. Realice la transición del estado de gobernabilidad de MathService(SV) a Service Version Manage y el de MathService a Managepara indicar que el servicio de matemática ha sido usado en la práctica y está entrando en la fase de gestión.
  3. Cuando el servicio de matemática esté desinstalado, realice la transición del estado de gobernabilidad de MathService a Service Retired y el de MathService(SV) a Service Version Retired. Tenga presente que la transición de MathService se debe realizar en primer lugar. Si la secuencia se invierte, aparecerá un error al ejecutar la transición de MathService(SV)(figura 12). Las directivas de gobernabilidad tienen una restricción que indica que la transición de MathService(SV) únicamente se puede ejecutar cuando su Business Service relacionado,MathService, se encuentre en el estado Service Retired.
    Figura 12. Error de transición de estado
    Error de transición de estado

Uso de Service Registry ALE para la gobernabilidad de ciclos de vida

Es posible integrar Service Registry a otros productos de IBM para gobernar los metadatos a través de sus ciclos de vida, desde el tiempo de diseño hasta el tiempo de ejecución. Service Registry ALE V6.2 consta Service Registry V6.2 e IBM Rational® Asset Manager V7.1, que trabajan en conjunto para gobernar el ciclo de vida del servicio desde su creación hasta su consumo. En esta sección se describirá cómo usar Service Registry ALE y, en especial, cómo configurar la sincronización y la integración entre Service Registry y Rational Asset Manager a fin de implementar la gobernabilidad de metadatos a lo largo de todo el ciclo de vida.

Configuración de la sincronización

La configuración de la sincronización se efectúa en Rational Asset Manager. Elija una Community (Comunidad), como, p. ej.,WSRR ALE, y cree una nueva conexión con un servidor de Service Registry, como se puede ver en la figura 13. Use la siguiente información para crear la conexión:

  • URL: URL de servidor de Service Registry.
  • Login (Inicio de sesión) y Password (Contraseña): necesarios para Service Registry con seguridad.
  • Type (Tipo): Publish (Publicar) permite la sincronización desde RAM hacia Service Registry; Synchronize (Sincronizar) es la sincronización en dirección inversa (de Service Registry a RAM); Publish and Synchronize (Publicar y sincronizar) soporta ambas direcciones.

Después de la configuración, haga clic en Test Connection (Probar conexión) para asegurarse de que los cambios hayan surtido efecto.

Figura 13. Nueva conexión con un servidor de Service Registry en Rational Asset Manager
Nueva conexión con un servidor de Service Registry en Rational Asset Manager

Uso de Service Registry ALE en tiempo de diseño

Rational Asset Manager gestiona la información de los activos reutilizables, especialmente en el tiempo de diseño. Siga estos pasos para implementar una solución ALE en el tiempo de diseño.

  1. A modo de ejemplo, desarrolle un servicio AddressBook que sea usado para almacenar y buscar direcciones. En la consola Web de Rational Asset Manager, envíe el activo AddressBook con un WSDL de servicio de artefacto llamado AddressBook.wsdl (ver SampleWSDLs.zip). Para obtener más información sobre los conceptos de activos y artefactos, consulte la parte 1 de esta serie. El activo tiene todos los detalles relevantes del servicio AddressBook, lo que indica que el servicio está completamente desarrollado.
  2. Haga clic en Publish to service registry (Publicar en registro de servicio) para sincronizar el activo AddressBook desde Rational Asset Manager hacia Service Registry, como se puede ver en la figura 14. Tenga presente que solamente los activos de la comunidad WSRR ALE configurados para su sincronización se pueden publicar en Service Registry. Además, la sincronización se ejecuta para un solo activo y de forma manual (no automáticamente o para múltiples activos a la vez). Como Service Registry es un repositorio de metadatos de tiempo de ejecución, los metadatos deberían ser gestionados de manera estricta y cuidadosa.
    Figura 14. Sincronización de un activo desde RAM hacia Service Registry
    Sincronización de un activo desde RAM hacia Service Registry

    Haga clic para ver una versión ampliada de la figura 14.)

  3. Seleccione los artefactos que se publicarán, compruebe el destino y agregue clasificaciones en la página Categorize (Clasificar), busque y seleccione los metadatos en Service Registry en la página Associate y luego publique AddressBook.wsdl. Rational Asset Manager hace una copia local de los sistemas de clasificación después de la primera sincronización desde Service Registry, por lo que ahora se pueden agregar clasificaciones. El ciclo de vida del perfil de gobernabilidad es un sistema de clasificación en Service Registry. Seleccione y agregue State/Interface Life Cycle/Published, como se puede ver en la figura 15.
    Figura 15. Agregación de clasificaciones cuando se publica el activo desde Rational Asset Manager a Service Registry
    Agregación de clasificaciones cuando se publica el activo desde Rational Asset Manager a Service Registry
  4. Una vez que la sincronización se haya completado correctamente, abra la consola Web de Service Registry para ver los nuevos metadatos creados: un objeto genérico AddressBook como RationalAssetManagerAsset(en adelante, AddressBook(RAMA)) representa el activoAddressBook en Rational Asset Manager; un documento WSDL AddressBook.wsdl se corresponde con el artefacto AddressBook.wsdl seleccionado en Rational Asset Manager; otros objetos genéricos como AddressBook, AddressBookBinding,AddressBookPort y AddressBookService son generados de manera automática cuando se publica el documento WSDL. La figura 16 muestra los detalles de AddressBook(RAMA).
    Figura 16. Detalles de AddressBook(RAMA)
    Detalles de AddressBook(RAMA)

Las siguientes son algunas sugerencias generales de sincronización desde Rational Asset Manager hacia Service Registry en tiempo de diseño:

  • Use los sistemas de clasificación de Service Registry V6.2 durante la sincronización de un activo.
  • Proporcione la función de búsqueda de metadatos en Service Registry y de agregación de relaciones al activo.
  • Después de la sincronización, el activo se corresponde con un objeto genérico, los artefactos se corresponden con los documentos y la relación de activos y artefactos es asignada a la relación agregada en el objeto genérico.

Uso de Service Registry ALE en tiempo de ejecución

Service Registry gestiona información de los metadatos, especialmente en el tiempo de ejecución, como la búsqueda dinámica del servicio o la gobernabilidad del servicio. En el tiempo de ejecución, el servicio pasa por las fases de prueba, de producción y, finalmente, de retirada. En Service Registry, Service Version sigue siendo gobernada a través de Service Version Deploy, Service Version Manage y Service Version Retired respectivamente.

La sincronización desde Service Registry hacia Rational Asset Manager se puede implementar de forma manual o automática en un momento programado. Para implementar la sincronización manualmente, abra la consola Web de Rational Asset Manager y haga clic en Synchronize (Sincronizar) respecto de un servidor de Service Registry configurado. Los resultados de la sincronización aparecerán como se puede ver en la figura 17.

Figura 17. Sincronización desde Service Registry hacia RAM
Sincronización desde Service Registry hacia RAM

Haga clic para ver una versión ampliada de la figura 17.)

Para implementar la sincronización automáticamente en un momento programado, es necesario establecer el momento usando Synchronization schedule (Programación de sincronización) durante la configuración (ver figura 13).

Después de la sincronización desde Service Registry hacia Rational Asset Manager, se crea el otro activo AddressBooken la comunidad WSRR ALE de Rational Asset Manager. En la página General Details (Detalles generales), que se puede ver en la figura 18, BsrURI representa la única ID en Service Registry; Link (Vínculo) nos dirige a los correspondientes metadatos AddressBook(RAMA) en la consola Web de Service Registry; y Publish by (Publicar por) se relaciona con el activo AddressBook enviado en el tiempo de diseño. Usando este método, no solo se integran los metadatos en Rational Asset Manager y Service Registry, sino que, además, se los relaciona en el tiempo de ejecución y de diseño.

Figura 18. Detalles de AddressBook desde Service Registry hacia Rational Asset Manager
Detalles de AddressBook desde Service Registry hacia Rational Asset Manager

Asimismo, es posible sincronizar en este momento otros metadatos que no existen en Rational Asset Manager. Por ejemplo, MathInterface.wsdl, MathBinding.wsdl y MathService.wsdl de Service Registry se publican en Rational Asset Manager como tres activos. En la página General Details (Detalles generales) de un activo (como el activo MathBinding.wsdl que aparece en la figura 19), se obtienen BsrURI, Governance State, Governance Profile Life Cycle y las relaciones correspondientes, así como un vínculo que se conecta con los metadatos originales en la consola Web de Service Registry. De esta forma, los metadatos gestionados en Service Registry se pueden reutilizar en el repositorio de tiempo de diseño de Rational Asset Manager.

Figura 19. Detalles de MathBinding.wsdl desde Service Registry hacia Rational Asset Manager
Detalles de MathBinding.wsdl desde Service Registry hacia Rational Asset Manager

En conclusión, la sincronización desde Service Registry hacia Rational Asset Manager en el tiempo de ejecución comprende los siguientes elementos:

  • Un documento WSDL de Service Registry se corresponde con un activo en Rational Asset Manager;
  • El activo anteriormente sincronizado desde Rational Asset Manager hacia Service Registry se vuelve a publicar en Rational Asset Manager, y el activo republicado establece una relación Publish by (Publicar por) con el activo original en Rational Asset Manager;
  • Una relación de documentos en Service Registry es asignada a una relación de activos;
  • Es posible sincronizar un ciclo de vida de gobernabilidad en Rational Asset Manager;
  • Si se elimina un documento en Service Registry, también se elimina el correspondiente activo en Rational Asset Manager en la siguiente sincronización.

Resumen

En este artículo se analizaron el ciclo de vida y las directivas de gobernabilidad definidos en el perfil de gobernabilidad de Service Registry, se presentó un escenario para demostrar su uso y se hizo una introducción a Service Registry ALE en cuanto a la gestión de metadatos integrados respecto de los ciclos de vida del tiempo de diseño y del tiempo de ejecución entre Service Registry y Rational Asset Manager.


Descargar

DescripciónNombretamaño
Sample WSDL filesSampleWSDLs.zip3KB

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere, Rational
ArticleID=966708
ArticleTitle=Integración de repositorios de metadatos IBM, parte 2: Gobernabilidad del ciclo de vida de los metadatos en WebSphere Service Registry and Repository
publish-date=02032010