concepto de integración de servicios
TRANSCRIPT
Concepto de Integración de Servicios
Grupo de Ingeniería TelemáticaDepartamento de Ingeniería de Comunicaciones
Universidad de Cantabria
Arquitecturas de Red para la Integración de Servicios
Alberto Eloy García Gutié[email protected]
Master en Ingeniería de Telecomunicación
Contenidos
EvoluciónEstructuraConvergenciaIntegración
… tecnología… unificada… de redes… de servicios
La EVOLUCION de la “RED”
DesdeDatosUnicastConexiones dedicadasFijoServicios aisladosRouters (SW)Todo vale
HastaMultimedia-multiservicioMulticastADSL, HFC, WLL, Wi-Fi, FTTx, PLC,satellites
MóvilServicios unificados(integrados)
Routers (HW only)Ingeniería de Tráfico
Evolución en las tecnologías
Tecnologías de Cobre
xDSLVectoring <= 100MbpsBondingPhantoming<=200Mbps
------------------------------------Combinado <= 300 Mbps
- G.fast <= 500 Mbps- (1 Gbps - FTTB)
Tecnologías de Cable
DOCSIS 3.0 HFCDown: 400 Mbps (8 canales)Upload: 120 Mbps (4 canales)
PacketCableServicios multimediaHFC + PSTN + TCP/IPSIP + IMS
Tecnologías ópticas
FTTXHome, Building, Curb, Node
PONBroadband, Gigabit-capable,Ethernet
pWDM / WDM-PONEl primer TODO-OPTICO
Tema I: Concepto de Integración de Servicios - 7
(FTTN)
https://www.adslzone.net/foro/fibra-optica.94/analisis-pon-que-es-olt-onu-ont-odn.461996/
Tecnologías WIFI (“Wireless Fixed”) (1)
Tema I: Concepto de Integración de Servicios - 8
Tecnologías WIFI (“Wireless Fixed”) (2)
Tema I: Concepto de Integración de Servicios - 9
Community WIFI HOTSPOT
Bussiness HOTSPOT Operator HOTSPOT
Tema I: Concepto de Integración de Servicios - 10
Evolución en las tecnologíasTema I: Concepto de Integración de Servicios - 11
Evolución de la estructura de la redTema I: Concepto de Integración de Servicios - 12
Tema I: Concepto de Integración de Servicios - 13
Evolución de la red de acceso
Branch and TreeRing and SpurWLD (Wireless Local Drop)
802.11nTDD LTEWIMAXFDD LTE60 GHz
Tema I: Concepto de Integración de Servicios - 14
Evolución de la red de agregaciónTema I: Concepto de Integración de Servicios - 15
Evolución de la red dorsal
Customer Premises
Carrier’s Network
Customer Premises
O / EE / O
10Gbps
Incrementar la capacidad: WDM
Customer Premises
Carrier’s Network
Customer Premises
O / EO / EE / O
E / O
10Gbps
10Gbps Actualmente : 1 Tbps, ADM
Mañana : decenas de Tbps, soliton, optical packet/burst switching
La única limitación: Add Dropping
WDM
Transparent vs. opaque optical networks
Overlay Networks
WDM
SDH
R2
R3
R1
IP
ATMC1
C2C3
C4
Transporte IP, Opción I: IP over ATM
Customer Premises
R
R
R
IP
ATM
SDH
Transporte IP, Opción II: IP over SONET (SDH)
Customer Premises
R
R
R
IP
SDH
Transporte IP, opción III: MPLS
Customer Premises
LSR
LSR
LSR
MPLS
SDH
oher
LSR LSR
MPLS… Hasta cuándo?
Customer Premises
LSR
LSR
LSR
MPLS
SDH (??)
• Quality of Service
• Evolved VPN
• Traffic Engineering, Protection
• Multicast
G-MPLS
La integración no está tan clara!!!
IP and ATM integrationLabel Swapping Paradigm
MPLS
10Gbps
10Gbps
OCX OCX
10Gbps
10Gbps10Gbps
10Gbps
Increasing Capacity Requirements
DWDM Dync Allocation and Control?
ATMC1
C2C3
C4
R2
R3
R1
IP
ATMC1
C2C3
C4
R2
R3
R1
IP
LSR
SDHSDH
Rapid and Predictable RestorationStandard Time Division Multiplexing
SONET/SDHDynamic Allocation and Control?
¿Y qué ocurre en las redes móviles?
Basadas en configuraciones “Backhaul”:MPLS en AccesoRNC / BNC en agregación – LTE en dorsalLTE en dorsal
Tema I: Concepto de Integración de Servicios - 25
Cell Site Gateway Mobile Aggregation Site Gateway
Backhaul vs. FronthaulTema I: Concepto de Integración de Servicios - 26
2G/3G/4GTema I: Concepto de Integración de Servicios - 27
xGTema I: Concepto de Integración de Servicios - 28
IP based core network
IMT-2000UMTS
WLANcellular
GSM
short rangeconnectivity
WirelinexDSL
otherentities
DABDVB
Return channel:
Download channel
Services and Applications
New air interface
Bluetooth, IR, UWB
Eg Hyperlan
Visto en conjuntoTema I: Concepto de Integración de Servicios - 29
Movil /Fijo: se diluyen las fronterasTema I: Concepto de Integración de Servicios - 30
Todo apunta a una misma direcciónTema I: Concepto de Integración de Servicios - 31
4G /
Multi-Hop
CPSeNode
B UTRAN-Evolution (3GPlus)
WLAN
AP
WiMAX
BS
Legacy CS domain
Unified IP Multimedia Network
Common Data Repository Policy
Directory
User Profiles
Service Delivery Framework
eGSN – enhanced GPRS Support Node
PLMN - Public Land Mobile Network
PSTN - Public Switched Telephony Network
xDSL
PSTN
PLMN
other
PLMN
Internet
Intranet
IMS
Common
Session Control
MGW
eGSN
CS – Circuit Switched
IMS – IP based Multimedia Subsystem
MGW – Media Gateway
AP – Access Point
BS – Base Station
CPS – Control Plane Server
Broadband Wireless Access
GERANUTRAN
Convergencia “Fijo-Móvil”: La visión clásica
Convergencia “Fijo-Móvil”: Pre-4G
Source: Telcordia Technologies
¿Convergencia o Evolución?
Convergencia “Fijo-Móvil”: ¿Resultado?
Modelo “aceptado” de “convergencia”
LD
Voi
ce
Cen
trex
Loc
al V
oice
800
CDMA
WiFi
IP TDM
MPLSIMS
Security
Voicemail
Storage
Presence
Messaging
VoIPHosting Call Center
Network
ServicesFr
ame
ATM
TD
M
DeviceDesk phone/
Terminal
LimitedRegulatedDisparate
NumerousNon-regulatedConverged
MobileSIP Phone
PDAPCLimited
Single functionNumerous Multi-function
Wireless Wired
StovepipedVertical
Low Value
ModularHorizontalHigh-value
Source: Verizon, 2007„Layering“ in telecommunications industries
Convergencia vs. Evolución: El punto de vista de las TIC
WPAN radio
Low-tier services
IP
802.11 Radio
Ethernet
Mobile ServiceMiddleware
IP
WLAN Services
3G/4GRadio
WLANradio
WPAN/low-tier radio
2.5G/3G Radio
GSM/GPRS
2.5G/3G Services
3G AccessNetwork
PSTN IP
WPAN networklayer (e.g. Bluetooth)
Generic Radio Access Network
Radio-specific vertically integrated systems withcomplex intetworking gateways
Security QoS VPN ContentDelivery
B3G Services
Radio Independent modular system architecturefor heterogeneous networks
uniformradio API’s
genericnetwork API
uniform serviceAPI (Internet+)
Unified IP-based mobile network
incl supportfor multihop,mcast, etc,
servicefeaturemodules
Convergencia: La importancia de llamarse IP
El negocio de las TIC converge arrastrado
…como consecuencia… los servicios también convergen!
El usuario final como agente activo
El modelo de roles en las TIC está sufriendo también una evoluciónLos usuarios toman el control de determinados servicios:El mercado USA define al usuario como “PROSUMER”El papel activo delos usuarios modifica a todos los niveles:
Los mecanismos de provisión de servicioLos mecanismos de interconexión
Resultado:
Servicios inteligentes
Servicios asistidos (y selfassisted!)
Servicios semánticos : Interfaces para los “Smart Users”
Consecuencia:
El usuario final exige la convergencia de los servicios
Objetivo:
Integración: Todos a IP / WEB
Beneficios de la Convergencia de Servicios
Se mantienen ocultas la heterogeneidad y la complejidadLa variedad de servicios se globaliza/universaliza
(…y las redes… y los dispositivos)
Se da posibilidades a generar plataformas abiertasSe da soporte a nuevas tecnologías / servicios / mercados
Proliferación de Middleware como alternativa a productos finales cerrados
El ciclo de vida de los servicios se ve alterado en positivo:Creación, puesta en valor y entrega en tiempos mínimosLas web/aplicaciones semánticas facilitan el reuso/compartición de templates
42
Integración de servicios (aplicaciones)
Hacer colaborar entre sí a servicios distribuidos, heterogéneosy posiblemente autónomos.Distribución: los diferentes servicios(aplicaciones) pueden (ysuelen) ejecutarse en máquinas conectadas a través de unared:
LAN/VPNInternetCloud
Autonomía: El sistema de integración no puede esperar que elservicio cambie su forma de actuar para facilitar la integración
Servicios heredadosServicios de otros departamentosServicios de otras empresas (B2B)
HeterogeneidadMáquinas: mainframes, servidores (Sun, IBM, HP, etc.), estaciones detrabajo (Compatibles PC, Apple Macintosh, Sun, IBM, HP, etc.)Sistemas operativos: Solaris, HP-UX, AIX, Linux, MacOS, MSWindows(9x, NT, 2000, XP), etc.Redes: TCP/IP, Novell Netware, lenguajes .NET (Visual C# .NET, VisualBasic .NET, Visual C++ .NET), etc.Aplicaciones en distintos lenguajes: Java, C++, Visual Basic, Visual C++,Delphi, COBOL, etc.Distintas arquitecturas de datos: ficheros, bases de datos de distintosmodelos y fabricantes, sitios web,…Distintos esquemas y formatos de datos. Ejemplo:
App A: DIRECCION=“C\ Alcala, 32, 28080 Madrid”.App B: CALLE=“Calle Alcalá” NUM=“32”, CP=“28080”, CIUDAD=“Madrid”.
Integración de servicios (problemas)
Heterogeneidad: RazonesDecisiones de ingeniería
Diferentes personas eligen diferentes soluciones a un mismo problemaRazones de coste
Se compra el tipo de software/hardware que cumpla los requisitos y tenga unprecio razonable
Aplicaciones antiguasNo es posible desecharlas y rehacerlas con las tecnologías más modernasEs preciso seguir utilizándolas hasta amortizar su coste de desarrollo yobtener beneficio
Integración de servicios (problemas)
Integración de Servicios: Modelo de referencia
Integración de PlataformaComunicación de servicios implementados en diferentes máquinas.Independencia de localización, hardware, SO y lenguaje deprogramación.
Integración de DatosIndependencia de arquitectura de almacenamiento.Independencia de heterogeneidades de esquema/formato.
Integración de Aplicaciones / ProcesosCreación rápida de aplicaciones basadas en aplicaciones existentes.Procesos de negocio modelados como flujos.
Integración B2B¿Qué debemos considerar cuando las aplicaciones que se comunicanpertenecen a organizaciones diferentes?
Seguridad, minimizar acoplamiento, estándares sectoriales,…
Integración de Plataforma
70’s: Comunicación de procesos en redSockets
80’s: Tecnologías de invocación de procedimientos remotosSun RPC (Remote Procedure Call)DCE (Distributed Computing Environment)
90’s: Tecnologías de objetos distribuidosCORBA (Common Object Request Broker Architecture)JAVA RMI (Remote Method Invocation)Microsoft DCOM (Distributed Component Object Model).
00’s: Tecnologías de Servicios WebREST (REpresentional State Transfer)SOAP (Simple Object Access Protocol)
10’s: Tecnologías CLOUD
Ejemplo: Integración de Plataforma
Ejemplo: para determinar la prioridad de una incidencia de uncliente, quiero saber cuánto se le factura al cliente.
Comunicación de procesos en redProcesos en diferentes nodos de la red pueden intercambiar datosutilizando APIs de red (e.g. sockets TCP/IP).No importa topología de la red, plataforma hardware, SO o lenguaje deprogramación.Visión de muy bajo nivel. Utilizar desde un programa serviciosproporcionados por programas que se ejecutan en otro nodo es unproceso costoso y “poco amigable”.
Invocación de procedimientos remotosUn proceso expone una serie de operaciones (procedimientos) quepueden ser invocados desde cualquier programa de la red.Las operaciones y sus parámetros se describen en un fichero dedefinición utilizando un lenguaje especial.Para hacer un programa cliente que invoque a un procedimiento remoto,un compilador especial genera un programa llamado “stub” partiendo delfichero de definición.Con el “stub”, el programador del cliente puede invocar el procedimientoremoto de forma muy parecida a la de un procedimiento local(transparencia).El stub es el que realmente recibe la llamada del cliente, envía unmensaje al servidor y recibe la respuesta del mismo.Visión orientada a programación estructurada (paradigma dominante enlos 80), no a programación OO.Tecnología dominante: SUN RPC
Tecnologías de objetos distribuidosConceptualmente muy similar a RPC.Cada nodo de la red puede exponer una serie de objetos.Permiten la invocación de métodos de objetos remotos.Utiliza el paradigma de programación OO (dominante en los 90 y hasta laactualidad).
JAVA RMI. No proporciona independencia del lenguaje de programación(debe utilizarse JAVA).
Por su facilidad de uso ganó gran aceptación en la comunidad JAVA.Sigue siendo un “building block” importante en la arquitectura JEE (Java PlatformEnterprise Edition).
DCOM. Solución propietaria de Microsoft.Muy utilizado en la comunidad Microsoft.Difícil la interoperabilidad con el “resto del mundo” (JAVA).
Tecnologías de objetos distribuidosCORBA
Estandarizado por el OMG (http://www.omg.org). Consorcio constituido por ungran número de empresas (Iona, Borland, HP, IBM, Oracle, Sun, etc.)Las APIs están estandarizadas -> El desarrollador no depende de unfabricante.Existen múltiples implementaciones de distintos fabricantes para lasplataformas y lenguajes más usuales (C++, Java, Ada, COBOL, C, Smalltalk,etc.).El OMG ha estandarizado numerosos servicios CORBA útiles para cualquieraplicación:
Servicio de nombresSeguridadTransacciones
CORBA ha sido y continúa siendo una buena tecnología paraabordar integraciones complejas en intranets
Eficiente y probadoBuen soporte para seguridad, transacciones, comunicación basada eneventos, etc.
Uso en InternetIIOP: Protocolo para permitir que diferentes sistemas que utilicenCORBA se comuniquen a través de TCP/IP.Existen firewalls que no reconocen IIOP
Hay fabricantes que venden proxies de IIOP, pero no todas las empresas quehan adoptado las tecnologías de Microsoft los tienenExisten túneles IIOP sobre HTTP, pero no son óptimos
Microsoft no fabrica implementaciones de CORBAHay terceros que sí lo hacen (ej.: Iona, Borland, etc.), pero no se puedeesperar que todas las empresas que han adoptado las tecnologías deMicrosoft usen CORBA
Servicios Web (1)La Web proporciona un mecanismo de transporte universal, eficiente,robusto, escalable y probado tanto en aplicaciones inter-organizacióncomo intraorganización.Muchas de las tecnologías comentadas hasta el momento fuerondiseñadas antes de la emergencia de la Web o no fueronespecíficamente diseñadas para aprovecharse de ella.Un Servicio Web expone un conjunto de puntos de acceso(endpoints) que pueden ser invocados por procesos externos.Un endpoint puede ser visto normalmente como una operación querecibe ciertos parámetros y devuelve un resultado, quizás efectuandoalguna acción por el camino.Están basados en tecnologías surgidas alrededor de la Web:
Típicamente, los puntos de acceso son accedidos mediante HTTP y susdirecciones se expresan mediante URLs.Las invocaciones y las respuestas de las mismas se codifican típicamentemediante XML.
Suele distinguirse entre dos estilos de servicios web:Servicios web SOAP.
Añaden un nuevo conjunto de protocolos (SOAP) y lenguajes para permitirRPCs y envío de mensajes entre aplicaciones a través de la web.Estandarizados por el W3C.Suelen utilizar HTTP como mecanismo de transporte, pero noobligatoriamente.
Servicios web REST.No añaden nuevos protocolos ni lenguajes: utilizan solamente HTTP 1.1 yformatos como XML para especificar mensajes.Pueden utilizarse para implementar RPCs, pero también dan soporte a unnuevo estilo arquitectónico para diseñar aplicaciones distribuidas (ServiciosWeb REST “puros” o “RESTful Web Services”.