[55] "Arquitectura para facilitar interconexión de Building Blocks en

[55] "Arquitectura para facilitar interconexión de Building Blocks en

Arquitectura para facilitar interconexión de Building Blocks en
Sistemas de Gestión de Redes y Servicios.
Stella Bonino
Gerardo Gándara
Unidad Investigación Desarrollo y Laboratorio, Antel
Montevideo,Uruguay
[email protected]
Unidad Investigación Desarrollo y Laboratorio, Antel
Montevideo,Uruguay
[email protected]
Abstract
En el presente trabajo se presenta un framework orientado
a la construcción de un sistema para la gestión de servicios
brindados por empresas de telecomunicaciones, permitiendo la integración de los mismos en una arquitectura común.
Se propone este enfoque como una estrategia para generar
sistemas basados en Building Blocks 1 , resolviendo el problema de interacción entre ellos a través de un vehículo de
comunicaciones común pudiendo esconder distintos patrones de interoperabilidad (sincrónico, asincrónico, etc).
Dada la abundancia de soluciones (oferta cambiante) que
permiten generar esquemas interoperables y la necesidad
de evaluarlas a través de sistemas concretos es que surge
la necesidad de disponer de una estrategia de trabajo que
achique la distancia entre un diseño lógico neutral y las
múltiples implementaciones que se puedan llegar a llevar a
cabo.
En este sentido se propone diseñar sistemas lógicos apoyados en un framework básico que permita facilitar la implementación en distintas plataformas y posibilitar el reuso
de componentes desarrollados.
INTRODUCCIÓN
Las empresas de telecomunicaciones están afrontando
grandes desafíos y oportunidades como nunca. El escenario
está caracterizado por una competencia creciente, producto
de un nuevo marco de desregulación en general con altas
exigencias del mercado. Se requiere disponer de estructuras
internas de manejo de la información que permitan integrar
los sistemas existentes e introducir en forma eficaz nuevos
servicios con valor agregado en una única arquitectura. La
1
El concepto de “Building Block” esta emparentado con el concepto de “componente”. Implica el encapsulamiento de un conjunto de servicios de granularidad gruesa (Las características de
los Building Blocks se definen en la recomendación GB909 de
TMForum [3])
existencia de una arquitectura integradora favorece la creación de nuevos servicios posibilitando el reuso de servicios
existentes.
En este sentido el área de gestión de redes ha ido evolucionando. Diversos aportes se han realizado, desde la propia
ITU-T a partir de la recomendación M3010 y más recientemente organizaciones como TeleManagement Forum y el
consorcio TINAC. Estás últimas parten del análisis de los
procesos necesarios para llevar a cabo los servicios requeridos y posteriormente se construyen sistemas lógicos
basados en servicios brindados por Building Blocks (diseñados en términos “neutrales” como por ejemplo UML, con
independencia de las tecnologías involucradas). La idea
central de esta arquitectura parte de desacoplar el vínculo
existente entre la lógica que gobierna los procesos y su implementación en “Building Blocks”. La lógica queda expresada en términos de interacciones con servicios (caracterizados por “contratos”) brindados por otros “Building
Blocks”.
MOTIVACIONES
Los sistemas existentes en el área de Gestión de Redes y
Servicios manejan interfaces y tecnologías diversas por lo
que se requiere para la integración de los mismos, adaptarlos a una arquitectura común.
Si bien es cierto que existen muchas tecnologías que resuelven el problema de interoperabilidad, no es menos cierto que las mismas están en constante evolución, brindando
nuevas facilidades y posibilidades.
Desde el punto de vista de la construcción del software, uno
de los problemas mas críticos es la habilidad de manejar
estas nuevas tecnologías. Resulta esencial que las aplicaciones permanezcan estables en el tiempo de forma de
justificar los costos de desarrollo.
Este requerimiento de durabilidad de las aplicaciones posibilitando la incorporación de cambios tecnológicos requiere de cambios en el proceso diseño y desarrollo del software.
En este sentido, surge la idea de diseñar sistemas donde se
pueda desacoplar la lógica del negocio contenida en cada
Building Block de consideraciones vinculadas a la elección
de tecnologías específicas y las distintas formas de manejarlas.
vehículo de comunicaciones común por medio de “Contratos” que se registran a nivel central en un servicio de registro general.
De esta manera se posibilita una estrategia de trabajo que
achica la distancia entre un diseño lógico neutral y las múltiples implementaciones que se puedan llegar a llevar a cabo.
• Existencia de Entorno de Información y datos comunes
Es fundamental en este esquema de interoperabilidad la
existencia de un modelo de información común que permita
la definición de contratos (empleando "tipos de datos" del
sistema) de manera que se pueda hablar un lenguaje común
entre las distintas entidades del sistema.
Para una arquitectura basada en “Building Blocks”, es de
gran valor el disponer de un “framework común” que permita que las implementaciones realizadas se puedan reusar
en el contexto de distintas tecnologías. Esto permitirá derivar rápidamente desde un diseño lógico en términos neutrales a implementaciones concretas.
FRAMEWORK PROPUESTO
Se define una arquitectura del sistema, basada en componentes distribuidos(Building Blocks) y un conjunto de servicios. Existen los servicios propios del negocio y servicios
propios del framework.
En este sentido este framework se apoya en los siguientes
principios fundamentales
• Interfaces definidas a través de “Contratos”
Todas las entidades de software que proveen servicios a
otras entidades lo hacen a través de interfaces denominadas
"Contratos".
Estas interfaces tienen las siguientes características:
o Descripción del servicio provisto
o Metadata usada para describir el contrato y
sus interfaces
o Precondiciones bajo las cuales se brinda el
servicio ( Son condiciones que se deben satisfacer a los efectos de poder invocar el servicio en forma adecuada)
o Postcondiciones las cuales definen el estado
en que queda el sistema luego de invocar el
servicio en forma exitosa (Sin generar excepciones).
o Excepciones que puedan ser generadas. Una
excepción se genera si se satisfacen las precondiciones, pero no se pueden alcanzar las
postcondiciones.
En general los contratos se agrupan en dos categorías. El
primer grupo está constituido por contratos que brindan
servicios propios del negocio. El segundo grupo está constituido por contratos de servicios brindados por el "framework", que apuntan a dar soporte de operación e integración con el resto del sistema.
• Vehículo de comunicaciones común.
Los componentes que brindan servicios específicos del
negocio, son accesibles al resto del sistema a través de un
Descripción de la Arquitectura
Los servicios brindados por las distintas entidades en el
marco de esta arquitectura son accesibles a través de contratos. Las especificaciones de contratos (ContractSpecification) disponen de la metadata asociada al contrato. Se
incluye información de métodos soportados, argumentos,
precondiciones, poscondiciones, excepciones etc.
El alcance del concepto “Contrato“ (Contract) a nivel del
framework, se circunscribe al concepto usual de “Interface”
a nivel de un lenguaje de programación específico. En este
sentido tenemos Contratos (Contract) asociados a sus respectivas especificaciones (ContractSpecification). Los contratos se implementan en plataformas específicas (ContractImplementation) y se agrupan en paquetes o Building
Blocks para gestionar la instalación (deployment) de los
mismos (Ver Figura 1)
BuildingBlock
ContractSpecification
implements
Contract
ContractImplementation
1..*
ContractMethod
Parammeters
MethodException
Condition
Precondition
GeneralException
ConditionException
Postcondition
Figura 1. Punto de Vista Estático
Desde el punto de vista de la ejecución, para que las implementaciones de contratos sean posibles de ser usadas,
deben ser instaladas (deploy) e instanciadas. Cada instancia
(ContractImpInstance) está identificada por un nombre que
la individualiza, y es registrada a nivel central, a los efectos
de que pueda ser ubicada por los usuarios del servicio brindado. Cada instancia de implementación dispone de un des-
criptor del punto de acceso del servicio (ContractImpInstanceDescriptor)(Ver Figura 2). Este descriptor contiene la
información para invocar el servicio. Conceptualmente es la
dirección del servicio a nivel del vehículo común de comunicaciones (o bus de servicios). Es de destacar que el bus de
servicios no es homogéneo por lo que distintos protocolos
pueden ser utilizados. En este sentido, el descriptor del punto de acceso maneja distinta información de acuerdo a la
tecnología subyacente.
Name
identified by Contract Im pInst an ce
l oc ated in
+co ntrac t
Co ntrac t
efectos de “enlazar” distintas plataformas en forma transparente o bien eventualmente cambiar el patrón de interoperabilidad previsto inicialmente por el servicio brindado a través de una implementación de un contrato dado.
Como se puede ver en la Figura 3, pueden existir invocaciones en forma directa entre implementaciones de contratos pertenecientes al mismo nodo. Se ilustran también invocaciones inter-nodo. En estos casos pueden accederse directamente o eventualmente hacer uso de puntos de acceso
alternativo (o gateway) provistos por el propio ServerNode
aludido por la invocación
ServerNode
implements
1
+reference
ContractImplementation
0..*
+g ate wayRe feren ce s
ContractImpInstanceDescriptor
+environment
BuildingBlock
Runtime Environmen t
Figura 2. Punto de Vista de Ejecución
Cada implementación de contrato que implementa un Contrato registrado, se instancia en el contexto de un nodo de
procesamiento o ServerNode conectado al bus de servicios
(Desde el punto de vista de procesamiento distribuido) (Ver
Figura 3). Cada instancia de Implementación de contrato
dispone de una identidad propia y tiene asociado una referencia (caracterizada por un Descriptor asociado de tipo
ContractImpInstanceDescriptor como vimos anteriormente).
B
D
C
A
Punto de acceso alternativo (Gateway)
Punto de Acceso (ContractImpInstanceDescriptor)
Instancia que implementa Contrato (ContractImpInstance)
Server Node. (Agrupamiento lógico de servicios)
Figura 3. Vista de Procesamiento Distribuido
Cada ServerNode maneja un conjunto de puntos de acceso
alternativos (gatewayReferences) que sirven de “pasarela” a
los efectos de alcanzar un servicio brindado a nivel de un
“ServerNode” específico. Este mecanismo se utiliza a los
Servicios del Framework
La arquitectura se caracteriza por la existencia de un conjunto de servicios básicos (del propio framework) que facilitan la operación de los componentes del sistema. Algunos
de estos servicios son:
• Servicio de Registro General. Brinda servicios para
soportar la transparencia en la ubicación de entidades
• Servicio de Invocación. Permite que las entidades puedan invocar servicios provistos por otras entidades de
acuerdo a las reglas del contrato del servicio y las políticas del sistema.
• Seguridad. Mecanismos que posibilitan la autenticación, autorización, accounting y auditoría.
Servicio de Invocación
Uno de los objetivos del uso del servicio de invocación es
ocultar los detalles del procedimiento subyacente involucrado. La tecnología y el modo de invocación son transparentes al desarrollador de la aplicación que especifica una
determinada invocación.
Cada componente que desea invocar un servicio disponible
(Contract) en un componente externo lo hace a través del
servicio de invocación. Se indica la Implementación de
Contrato instanciada y método a ejecutar. Complementariamente se incluyen el conjunto de argumentos requeridos
por el método del contrato especificado.
La existencia del servicio de invocación posibilita entre
otras cosas:
• Validación de credenciales para el acceso a contratos. (Se validan roles de acceso )
• Validación de precondiciones. Se validan las precondiciones estipuladas en el contrato. Si no se
cumplen se genera la excepción correspondiente.
• Log de uso de la interfaz. Es posible hacer un Log
(de las invocaciones realizadas a la interfaz)
Servicio de Registro General
Brinda servicios para soportar la transparencia en la ubicación de entidades. Las entidades registradas que son de
interés desde el punto de vista arquitectónico son: Entradas
que identifican servicios de Información compartida , Componentes, Contratos , Implementaciones de Contratos
etc.(Este servicio solo tiene importancia en la etapa del
descubrimiento de las operaciones)
El servicio de registro mantiene la información de componentes (BuildingBlock) y contratos implementados (ContractImplementation) disponibles en cada componente (Ver
figura 4). A su vez para cada contrato existen las implementaciones de contratos instanciadas (ContractImpInstance) . Cada implementación de contrato instanciado (ContractImpInstance) registrada tiene un identificador que lo
caracteriza. Con este nombre característico se puede referenciar cualquier contrato instanciado del sistema.
En el momento de invocación (usando el servicio de invocación) se configura la solicitud de invocación ("Invocation") referenciado a la implementación del contrato instanciada (ContractImpInstance) y método a invocar (además
de los argumentos requeridos).
Registry
ContractSpecification
ServerNode
Service A
Wrapper
Service B
Runtime
Wrapper
Runtime
Environment
Environment
Proxy Client
Proxy Client
Descriptor
NM1:Network
Manager
Invocation
Object
Figura 5. Invocación
En la figura 5 se muestra la aplicación de la arquitectura a
un sistema genérico. Se pueden ver dos servicios A y B,
pertenecientes a entidades diferentes (cada una de ellas
operando en tecnologías similares o diferentes) y la interacción entre ellos a través de los recursos provistos por la
arquitectura. Los servicios A y B disponen de un entorno de
ejecución (que esconde la tecnología subyacente) y un
“Wrapper” que es responsable de la activación y de la propia invocación del servicio.
IW rapper
located in
implements
Implementación
invok e (Invoc ati on : i) : O bjec t
Contract +contract ContractImpInstance
Contrac tImplem entatio n
+gatewayReferences
identified by
+reference 1
Name
0..*
ContractImpInstanceDescriptor
F ram ework W rapper
invok e (Invoc ati on : i) : O bjec t
IS ervic eA
s ervic eIns tanc e
Figura 4. Registro General
Invoc ation
Es importante destacar que la especificación de la invocación se hace en términos "neutrales" en el sentido de que no
se requieren señalar detalles de tecnologías específicas.
m ethod : S tring = null
param [] : Objec t = null
El registro contiene los detalles de las implementaciones
existentes, como por ejemplo: Tecnología utilizada en la
implementación: ( Ej. EJB o CORBA),la dirección real del
componente (JNDI Name o IOR de CORBA), modo de
invocación (Si la invocación es sincrónica o asincrónica.)
Invoc a bleContra c t
Nota: La meta de este trabajo es abordar específicamente
el problema de implementación de Contratos, registro e
invocación de los mismos. Los temas vinculados a Seguridad y control de transacciones no se encaran aquí.
S ervic eA
OperationA ()
Figura 6. Implementación de Servicios
Desde la perspective del Servidor, el servicio se implementa en una clase que realiza la interfaz del contrato a implementar. La clase que implementa el servicio deriva de una
clase abstracta “ContractImplementation” de manera que
hereda los servicios básicos del framework, que posibilitan
la comunicación con componentes externos. De esta manera
la implementación se realiza en términos “neutrales” en
cuanto a la interoperabilidad con otros componentes. La
implementación está escrita de manera que la comunicación
con otros componentes se realiza a través de la primitiva de
invocación de contratos implementados externos.
El servicio es accesible a través de un Wrapper del framework. El wrapper que posibilita el acceso consiste básicamente en un componente que implementa la interfaz IWrapper que exige la implementación del método performInvocation(Invocation:i ): Object (Ver Figura 6)
El Wrapper sostiene la implementación del servicio. Los
componentes que requieren comunicarse con una Instancia
de Implementación de Contrato (Implementada por ServiceA) lo hacen inicialmente a través de las primitivas del
framework. (Ver Figura 6 )
Desde la perspectiva del cliente, invocar un contrato externo a través del framework implica crear un objeto “Invocation” que contiene todos los detalles de la invocación (ContractImpInstance requerido, método y lista de argumentos
del método). El servicio de invocación es tal que enruta este
requerimiento hacia el Wrapper de la implementación del
contrato. Posteriormente el Wrapper interpreta la invocación y es el encargado de invocar realmente el método deseado en la implementación del servicio. El wrapper invoca
el método finalmente por mecanismos de reflexión. En este
caso se utilizan los mecanismos de reflexión de Java.
Hasta el presente el framework esta implementado en Java
y permite interacciones sincrónicas y asincrónicas entre
servicios implementados en CORBA,J2EE y Clientes externos escritos en Java (usando RMI)
Las interacciones asincrónicas se llevan a cabo utilizando
sistemas de mensajería estándares como JMS y CORBA
Notification Service.
den modelar en forma transparente el uso de interfaces locales o remotas para EJB.
Los servicios corren bajo un entorno de ejecución del framework. El mismo está equipado con un conjunto de dispositivos que implementan cada uno de los patrones de interoperabilidad requeridos, denominados “proxy”. Cada
Proxy es capaz de manejar un patrón de interoperabilidad
específico. El perfil del entorno de ejecución esta dado por
el conjunto de artefactos "Proxy" disponible (Ver Figura 7 )
Por otro lado cada implementación de contrato, caracterizada por un descriptor asociado (obtenible desde el servicio
central de “Registry”), señala el patrón de interoperabilidad
requerido.
En el momento de la invocación se selecciona dinámicamente el “Proxy” adecuado, compatible con la implementación. Este dispositivo es el que finalmente lleva a cabo la
interacción requerida.
En principio el uso de los distintos patrones de interoperabilidad se maneja en forma transparente.
Contract
Name
implements
+cont ract
ContractImplementation
identified by
ContractImpInstance
+environment
RuntimeEnvironment
located in
ServerNode
RuntimeEnvironmentEjb
+ref erence
RuntimeEnvironmentCorba
RuntimeEnvironmentClient
+gatewayRef erences
1
El framework propuesto no maneja explícitamente el control de transacciones. En este sentido depende del potencial
de la tecnología elegida. Por ejemplo los contratos implementados en el contexto de Servidores de Aplicaciones
J2EE se ejecutan en un entorno transaccional provisto por
el propio contenedor de manera transparente.
#resources[]
0..*
0..*
ContractI mpInstanceDescript or
Proxy
+pattern
+pattern
I nteroperabilityPattern
ProxyCorbaAsinc
Patrones de Interoperabilidad.
El framework permite manejar distintos patrones de interoperabilidad a los efectos de procesar las interacciones entre Componentes. Las interacciones pueden ser sincrónicas
o asincrónicas y apoyarse sobre distintas tecnologías. Por
ejemplo, se pueden manejar interacciones asincrónicas apoyadas sobre mensajería JMS (en el caso de J2EE) o el servicio “Notification Service” de la plataforma CORBA. Lo
mismo sucede a nivel de interacciones sincrónicas, podría
usar RMI o IIOP en la plataforma CORBA. Incluso se pue-
ProxyEjbAsinc
ProxyEjbToCorbaSinc
ProxyCorbaSinc
ProxyEjbSinc
ContractImpInstanceDescriptorCorbaSinc
ContractImpInstanceDescriptorCorbaAsinc
ContractImpInstanceDescriptorEjbAsinc
ContractImpInstanceDescriptorEjbSinc
Figura 7. Framework aplicado a Tecnologías Específicas
Cuando no existe una compatibilidad directa entre la implementación del servicio y el entorno de ejecución se utilizan “gateways” en forma transparente. Cada “nodo” conectado al vehículo de comunicaciones común, maneja puntos
de accesos alternativos a los ofrecidos por las implementaciones de servicios. De esta manera la búsqueda de la implementación de un servicio dado tiene en consideración el
perfil del entorno de ejecución invocante, de manera que el
descriptor de la implementación de contrato devuelto sea
compatible con el perfil del entorno de ejecución.
Aunque existe un comportamiento por defecto en lo que
tiene que ver con la elección del patrón de interoperabilidad
(proceso transparente), el Desarrollador aún puede especificar una política que permita forzar la elección de patrones
de interoperabilidad específicos requeridos. Esto se puede
realizar globalmente para el contexto del Entorno de Ejecución o puede llevarse a cabo específicamente para una invocación particular.
DISEÑO NEUTRAL
IAlarmasNML
<<comp_spec>>
ServicioNML
procesarAlarma(alarm : Alarma)
<<ifrFramework>>
ContractImplementation
IMPLEMENTACION
N
<<ifrService>>
ServicioNML
El “framework básico neutral” se extiende para cada tecnología específica, de manera de poder trabajar con la metadata requerida por cada tecnología y patrón de Interoperabilidad. Los conceptos: Contract, ContractImpInstanceDescriptor RuntimeEnvironment y Proxy se extienden para
modelar el entorno de la tecnología específica (como puede
observarse en la figura 7)
Actualmente el framework soporta los siguientes patrones
de Interoperabilidad. Para cada uno se proveen los “Proxyies” y “Wrappers” correspondientes (como implementaciones por defecto)
•
•
•
•
EJB Sincrónico. Wrappers implementados como
EJB Session Bean.
EJB Asincrónico. Wrappers implementados como
Message Driven Bean vinculados a un JNDI Topic.
CORBA Sincrónico. El Wrapper es un servicio
CORBA (que implementa “IWrapper”)
CORBA Asincrónico. El Wrapper es un servicio
CORBA Listener vinculado a un EventChannel
(CORBA Notification Service)
EJEMPLO
A continuación se ilustra con un ejemplo, como se lleva a
cabo la implementación de un servicio correspondiente a un
hipotético sistema de gestión de alarmas de elementos de
red y como se procesa la invocación del mismo desde otra
entidad.
procesarAlarma(alarma : Alarma)
Figura 8. Implementación
En la figura 8 se puede observar la especificación parcial de
un componente que implementa una interfaz determinada
en términos neutrales(utilizando UML). Para implementar
dicho servicio, basta realizar la implementación del mismo
extendiendo la clase abstracta provista por el framework
“ContractImplementation”. De esta manera la implementación del servicio hereda los servicios provistos por el framework (fundamentalmente el servicio de invocación y el
acceso al Registro General).
En la figura 9, se muestra la invocación del servicio. Cliente
y Servidor operan sobre diferentes tecnologías (Application
Server J2EE y Servicio Corba como receptor y productor
de mensajes de alarmas respectivamente). Se puede observar que las referencias a servicios externos dentro de la
implementación del Building Block “invocante”(BB-EML)
están desprovistas de dependencias tecnológicas (Incluso
está escondido el patrón de interoperabilidad utilizado por
el servicio). El Registro General conoce los detalles de la
implementación como por ejemplo si se implementa una
interfaz sincrónica o asincrónica. De esta manera el servicio
de invocación es capaz de enrutar el requerimiento hacia el
destino adecuado .
BB_EML
Permite además lograr diseños neutrales e implementaciones que puedan ser reusadas ante cambios tecnológicos.
BB_NML
ContratoNML
...
{Invocar(ServicioNML,
ProcesarAlarma,alarma)}
...
ServicioNML
ProcesarAlarma()
MDB
ProcesarX
SBProcesarX
Implementa
IWrapper
TopicX
JMS
Invocacion
Asincrona
Invocacion
Sincrona
La experiencia mostró además que la arquitectura propuesta
permitió esconder con facilidad, la aplicación de “Patterns”
para mejorar el rendimiento de Servidores de Aplicaciones,
de manera de obtener implementaciones performantes despojadas del ruido que significaría la inclusión (en el contexto de la propia implementación) de artefactos auxiliares
requeridos para mejorar performance.
Este encare no busca proponer un nuevo framework sino
que pretende que el propio constructor del sistema customize el framework básico de acuerdo a sus necesidades (Especialización) que permitan encapsular problemas de interoperabilidad tecnológicos y la propia configuración requerida por el usuario.
Servicio de Invocacion
Figura 9. Invocación en plataforma J2EE
Este destino puede ser un Session Bean Remoto (caso sincrónico) o un Message Driven Bean asociado a un “Topic”
de mensajería JMS (caso asincrónico) según lo indicado en
el Registro General.
TRABAJOS FUTUROS
A los efectos de mejorar el framework , están previstas varias extensiones para el futuro, como por ejemplo considerar nuevas tecnologías como WebServices y SOAP, además
de incorporar la capacidad de manejar Implementaciones
utilizando ECMA Script. Se plantea la posibilidad de verificación de Precondiciones en tiempo de ejecución utilizando expresiones ECMAScript .
De la misma manera se requiere trabajo adicional en las
áreas de Seguridad y Control de Transacciones .
CONCLUSIONES
Se propone este enfoque como una estrategia para generar
sistemas basados en building blocks, resolviendo el problema de interacción entre ellos a través de un vehículo de
comunicaciones común pudiendo esconder distintos patrones de interoperabilidad (sincrónico, asincrónico, etc.).
Este enfoque permite achicar la brecha entre el diseño neutral y la implementación. La implementación no arranca de
cero. Se aplican los patterns de Wrappers y Contexto de
Ejecución propuestos para la implementación de servicios.
(Utilizando el servicio de registro de contratos propuesto) .
AGRADECIMIENTOS
Los autores desean agradecer a todas las personas que han
contribuido a este artículo. En particular el Grupo de “Interoperabilidad” en el Instituto de Computación de Facultad
de Ingeniería (Universidad de la República, Uruguay), al
Grupo de Comunicaciones que trabaja en el Instituto de
Ingeniería Eléctrica (Facultad de Ingeniería) y a la gente de
Antel (Empresa Nacional de Telecomunicaciones, Uruguay) especialmente el equipo aplicado a la Gestión de Redes y Servicios.
REFERENCIAS
[1] Basic Framework for distributed components interoperability. Stella Bonino, Gerardo Gándara. CSITeA03,
Rio de Janeiro June 2003
[2] TM Forum, TMF 053B. NGOSS ArchitectureTechnology Neutral Specification(Contract Specification)
[3] TM Forum, Generic Requirements for Telecommunication Management Building Block, GB909, Versión 3,
2001.
[4] TMForum, Telecom Operations Map, GB910, Versión
2.1, 2000.
[5] [CIS] TMF045: The Common Information Structure.
TeleManagement Forum, 1999.
[6] [SIM] GB914, TeleManagement Forum, 2000.
[7] Inoue, Lapierre, Mossotto Editors, The TINA Book a
cooperative solution for a competitive world. Prentice
Hall Europe 1999.
[8] Zahavi R., Enterprice Application Integration with
CORBA, OMG Press, 2000.
[9] Ayers D, Professional Java Server Programming,
Wrox, 2000.
[10] Vawter C. y E. Roman, "J2EE vs. Microsoft.NET: A
comparison of building XML-based web services",
2001.
[11] Ritter S., "Enterprise Java Beans: The answers to the
three questions every developer will ask.", 1999.
[12] William C. Goers, Michael R. Brenner; Implementing
a Management System Architecture Framework, OctDec 2000, Bell Labs Technical Journal
[13] James Rumbaugh, The Unified Modeling Langage
Reference Manual, Addison Wesley, 1999.
[14] [GAM95] Erich Gamma, et al. Design Patterns: Elements of Reusable Object Oriented Software.AddisonWesley, 1995.
[15] Floyd Marinescu EJB™ Design Patterns Advanced
Patterns, Processes,and Idioms.
[16] Telecom Network Management With Enterprise JavaBeans™Technology,A Technical White Paper ,Sun
Microsystems.