1. Middleware
Por:
Oscar Yima
Sebastian Fuentealba
Alfonso Quiroz
23/10/2012 Arquitectura de sistemas 1
2. Middleware - Definición
Middleware es un software que asiste a
una aplicación para interactuar o
comunicarse con otras aplicaciones,
software, redes, hardware y/o sistemas
operativos. Éste simplifica el trabajo de los
programadores en la compleja tarea de
generar las conexiones que son necesarias
en los sistemas distribuidos.
23/10/2012 Arquitectura de sistemas 2
3. Middleware – Detalle técnico
Servicios de middleware son conjuntos de
software distribuido que existen entre la
aplicación y el sistema operativo y los
servicios de red en un nodo del sistema en
la red.
23/10/2012 Arquitectura de sistemas 3
4. Middleware – Utilización
Application Application
API
Middleware (Distributed System Services)
Platform interface Platform interface
Platform Platform
OS OS
23/10/2012 Arquitectura de sistemas 4
5. Middleware - Características
Servicios de middleware proporcionar un
conjunto más funcional de la API de SO y
servicios de red para permitir que una
aplicación.
Búsqueda transparente a través de la red,
proporcionando una interacción con otra
aplicación o servicio.
Ser independientes de los servicios de red.
23/10/2012 Arquitectura de sistemas 5
6. Middleware - Características
Ser confiable y disponible.
Ampliación en la capacidad sin perder su
función.
23/10/2012 Arquitectura de sistemas 6
7. Arquitectura de comunicación
en tiempo real armada
ARMADA proporciona aplicaciones con una
arquitectura de comunicaciones y servicios que
permite garantizar calidad de servicio entre dos
hosts conectados. Para lograr esto, se consideran
tres aspectos:
1. El comportamiento de un componente no debe
afectar o sobrecargar al resto.
2. Diferenciación de servicios: asignando
prioridades a clases de conexiones.
3. Degradación suave en presencia de sobrecarga.
23/10/2012 Arquitectura de Sistemas 7
9. Middleware – Tipos
Procesamiento de transacciones (TP)
monitores.
Las llamadas a procedimiento remoto (RPC)
Message Oriented Middleware (MOM)
Corredores de petición de objetos (ORB)
23/10/2012 Arquitectura de sistemas 9
10. TP Monitors - Demonstración
Cliente
Cliente
Procesamiento
Rutinas
Cliente
Cliente
transacción
transformación
control Base de datos
Cliente
Cliente solicita el tipo de transacción
23/10/2012 Arquitectura de sistemas 10
11. RPC - Demonstración
Application
Server
Application
T T
R R
N N
A A
E E
N N
T T
S S
W W
P P
O O
O O
R Application specific R
R R
K procedure invocations K
T T
and returns
RPC RPC
Stub Stub
23/10/2012 Arquitectura de sistemas 11
13. Middleware Orientado a
Mensajes
MOM (Message Oriented Middleware) es
una infraestructura cliente / servidor que
permite que la aplicación se distribuye a
través de múltiples plataformas
heterogéneas.
Reduce la complejidad de las aplicaciones
que abarcan los sistemas operativos y
protocolos de red al aislarlos de detalles
innecesarios.
23/10/2012 Arquitectura de sistemas 13
14. Middleware Orientado a
Mensajes
Los datos se intercambian por el paso de
mensajes y / o colas de mensajes apoyar
las interacciones síncronas y asíncronas
entre los procesos de computación
distribuida.
El sistema MOM asegura la entrega de
mensajes mediante el uso de colas y
confiables, proporcionando el directorio, la
seguridad y los servicios administrativos
necesarios para apoyar la mensajería.
23/10/2012 Arquitectura de sistemas 14
15. MOM - Demostración
Message
Message
A
A
P M T
T M P
P O R N
N R O P
E A L
L
M
A E
T N M I
I N T
W S C
C S W Queue O P A
A
A P O
R O
A T
T O R
P K R P I
I R K MOM Provider T I O
O I T
N
N
Application A Application B
(Client A) (Client B)
23/10/2012 Arquitectura de sistemas 15
17. MOM - Products
IBM Websphere MQ Series
Sonic MQ
MS MQ
Java Message Queue
23/10/2012 Arquitectura de sistemas 17
18. MOM - Arquitectura, Significancia
Mainframe
J2EE Application
A
P 2 3
P Process C C Listener
L
I Message
C 4
A Process B B Transaction
T
I Message
O
N Process A 6
5 7
8 Listener
A
Q1 Q2 Message
1
Message Message
Middle Layer
0
9 Database
23/10/2012 Arquitectura de sistemas 18
19. Middlewares de las
tecnologías indicadas
Oracle: es un sistema de gestión de base
de datos objeto-relacional (o ORDBMS por
el acrónimo en inglés de Object-Relational
Data Base Management System),
desarrollado por Oracle Corporation
23/10/2012 Arquitectura de Sistemas 19
20. Soluciones que entregan los
Middlewares de Oracle
Arquitectura Orientada a Servicios y Gestión de
Procesos de Negocio
Grid de Aplicaciones para una Eficiencia Extrema
Gestión de Identidad Centrada en las Aplicaciones
Portales Enterprise 2.0, Gestión de Contenido y
Colaboración
Inteligencia de Negocio Generalizada y Soporte
Estratégico para la Toma de Decisiones
23/10/2012 Arquitectura de Sistemas 20
21. Características de los
Middlewares de Oracle
Completo
Integrado
Apto para la conexión en caliente
23/10/2012 Arquitectura de Sistemas 21
22. ¿Por qué hoy en día son necesarios
los Middlewares de Oracle?
Oracle Fusion Middleware 11g es la base de
infraestructuras de aplicaciones de mayor
aceptación hoy en día. Permite a las empresas
crear y utilizar aplicaciones empresariales
ágiles e inteligentes, y al mismo tiempo
potenciar al máximo la eficacia informática
aprovechando plenamente las arquitecturas
modernas de hardware y software.
23/10/2012 Arquitectura de Sistemas 22
23. Tipos de Middleware de Oracle
El mejor rendimiento del sector Oracle WebLogic Suite 11g.
Oracle WebCenter: La plataforma de participación de
usuarios para el negocio social.
Agilidad empresarial superior Oracle SOA Suite 11g.
Oracle Identity Management 11g para los mejores
productos de seguridad y cumplimiento de su categoría.
El diseño y desarrollo más unificado Oracle JDeveloper 11g.
Herramientas punteras para la creación de aplicaciones
empresariales con funciones completas.
23/10/2012 Arquitectura de Sistemas 23
26. ¿¿Preguntas??
¡¡Gracias!!
23/10/2012 Arquitectura de sistemas 26
Notas del editor
Transaction Processing Monitors (TP Monitors) Provide tools and technology to develop and deploy distributed applications. Remote Procedure Calls (RPC) Enables the logic of an application to be distributed across network. Program logic on remote systems can be executed as simply as calling a local routine. Message Oriented Middleware It provides program-to-program data exchange, enabling the creation of distributed applications. MOM is analogous to email in the sense it is asynchronous and requires the recipients of messages to interpret their meaning and to take appropriate action. Object Request Brokers 1. Enable the objects that comprise an application to be distributed and shared across heterogeneous networks RMI).
Transaction processing (TP) monitor technology provides the distributed client/server environment the capacity to efficiently and reliably develop, run, and manage transaction applications. TP monitor technology controls transaction applications and performs business logic/rules computations and database updates. Use of TP monitor technology is a cost-effective alternative to upgrading database management systems or platform resources to provide this same functionality. TP monitor technology does this by multiplexing client transaction requests (by type) onto a controlled number of processing routines that support particular services. Clients are bound, serviced, and released using stateless servers that minimize overhead. The database sees only the controlled set of processing routines as clients. TP monitor technology maps numerous client requests through application services routines to improve system performance. The TP monitor technology (located as a server) can also take the application transitions logic from the client. This reduces the number of upgrades required by these client platforms. In addition, TP monitor technology includes numerous management features, such as restarting failed processes, dynamic load balancing, and enforcing consistency of distributed data. TP monitor technology is easily scalable by adding more servers to meet growing numbers of users. TP monitor designs allow Application Programming Interface s (APIs) to support components such as heterogeneous client libraries, databases and resource managers, and peer-level application systems. TP monitor technology supports architecture flexibility because each component in a distributed system is comprised of products that are designed to meet specific functionality, such as graphical user interface builders and database engines
Remote Procedure Call (RPC) is a client/server infrastructure that increases the interoperability , portability, and flexibility of an application by allowing the application to be distributed over multiple heterogeneous platforms. It reduces the complexity of developing applications that span multiple operating systems and network protocols by insulating the application developer from the details of the various operating system and network interfaces--function calls are the programmer's interface when using RPC. In order to access the remote server portion of an application, special function calls, RPCs, are embedded within the client portion of the client/server application program. Because they are embedded, RPCs do not stand alone as a discreet middleware layer. When the client program is compiled, the compiler creates a local stub for the client portion and another stub for the server portion of the application. These stubs are invoked when the application requires a remote function and typically support synchronous calls between clients and servers. RPC increases the flexibility of an architecture by allowing a client component of an application to employ a function call to access a server on a remote system. RPC allows the remote component to be accessed without knowledge of the network address or any other lower-level information. Most RPCs use a synchronous, request-reply (sometimes referred to as "call/wait") protocol which involves blocking of the client until the server fulfills its request.
An object request broker (ORB) is a middleware technology that manages communication and data exchange between objects. ORBs promote interoperability of distributed object systems because they enable users to build systems by piecing together objects- from different vendors- that communicate with each other via the ORB. The implementation details of the ORB are generally not important to developers building distributed systems. The developers are only concerned with the object interface details. This form of information hiding enhances system maintainability since the object communication details are hidden from the developers and isolated in the ORB. ORB technology promotes the goal of object communication across machine, software, and vendor boundaries. The relevant functions of an ORB technology are - interface definition location and possible activation of remote objects communication between clients and object It is the responsibility of the ORB to provide the illusion of locality, in other words, to make it appear as if the object is local to the client, while in reality it may reside in a different process or machine. Thus the ORB provides a framework for cross-system communication between objects. This is the first technical step toward interoperability of object systems. The next technical step toward object system interoperability is the communication of objects across platforms. An ORB allows objects to hide their implementation details from clients. This can include programming language, operating system, host hardware, and object location. Each of these can be thought of as a "transparency,"1 and different ORB technologies may choose to support different transparencies, thus extending the benefits of object orientation across platforms and communication channels. An additional, newly-emerging ORB model is Remote Method Invocation (RMI); this is specified as part of the Java language/virtual machine. RMI allows Java objects to be executed remotely. This provides ORB-like capabilities as a native extension of Java.
A MOM provides its own set of API that extend over multiple platforms and network protocols. A MOM increases the interoperability, portability, flexibility of an application by allowing it to be distributed.
A MOM provides its own set of API that extend over multiple platforms and network protocols. A MOM increases the interoperability, portability, flexibility of an application by allowing it to be distributed.
In this diagram, the Client A sends a message on a temporary store (the queue) from where the Client B picks up the message. MOM API needs to be present on both the clients. A Provider is a software which provides an environment, an API and services for efficient messaging.
Flow of Events 0. The User enters some Data. The Data is passed on to the middle layer component which translates it in a text/XML format and puts on the queue Q1. The listener process on the Mainframe application listens to the message and passes on to Process C (for example). Process C in turn formats the input and puts into the queue C. The Listener configured for the queue C listens to the message and passes it on to the transaction. The transaction in turns generates the response and forwards to the queue B. The message from queue B is received by process B which in turns passes it to process A. Process A does the necessary action on it and puts message in queue A. The Listener configured for queue A listens the message and passes it to the transaction. The transaction inputs the data into the database. Process A also passes the data to the queue Q2. A listener on the Middle layer listens to the message on Q2 and formats it. This message is then passed to the user.