La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

DESARROLLO RÁPIDO DE APLICACIONES B2B. 1 La evolución de Internet Requerimientos Tecnológicos Producto para el B2B: BizLogic ÍNDICE.

Presentaciones similares


Presentación del tema: "DESARROLLO RÁPIDO DE APLICACIONES B2B. 1 La evolución de Internet Requerimientos Tecnológicos Producto para el B2B: BizLogic ÍNDICE."— Transcripción de la presentación:

1 DESARROLLO RÁPIDO DE APLICACIONES B2B

2 1 La evolución de Internet Requerimientos Tecnológicos Producto para el B2B: BizLogic ÍNDICE

3 2 La evolución de Internet Internet 1.0 Trabajando en la Red Escaparates WEB La batalla por la audiencia Aplicaciones Monolíticas Internet 2.0 La red trabaja para nosotros E-services automatizados La batalla por el cliente E-services modulares combinados en tiempo real Las T.I. como un activo a manejar, contabilizado como activo fijo Las T.I. como un servicio pagando por su uso

4 3 Explosión en publicación de contenidos Internet 1.0: Tecnología: Nomenclatura de datos y ubicación (url) Protocolos de acceso (http) Descripción de Datos (html, MIME) Navegadores de Web Madurez front-end Web Nuevos motores de búsqueda y agregadores Consumidores Resultado: 130 Millones de personas conectadas acceso de datos de forma implícita e intuitiva Internet

5 4 Internet 2.0: Tecnología: Virtualización, brokering de servicios y mercados Protocolos de recursos (monitorización, gestión y seguridad) Proveedores de recursos de computación Proveedores de servicios de aplicación Proveedores de Datos e Información Consumidores Resultado: La Red trabajando para todas las personas y todas las cosas, de forma permanente acceso a servicios de forma implícita e intuitiva Utility Computing

6 5 Plataforma tecnológica global para la composición dinámica, mediación, gestión y acceso a los e-services Internet 2.0: El modelo de E-services Mediación Oferta 3 Oferta 2 Oferta 1 Composición PeticiónServicio Entrega del Servicio Mediación Ensamblaje de Servicios Selección de la mejor oferta basado en los criterios de petición El idioma universal de los e-services Se inicia una petición de servicio Envío de petición de servicio a los ofertantes Respuesta a la petición con ofertas individuales XML

7 6 Ejemplo en Internet 2.0: El Portal de Viajes e-servicereservas e-service servicio meteorológico e-service gestión de viaje e-service reserva de restaurantes e-service reserva de hoteles e-service billetes de avión Nueva Generación de Portales 3 hotel Línea aérea Alquiler vehículos Websites 1 hotel Línea aérea Alquiler vehículos Portales 2

8 7 Internet 1.5: Tecnología: Message Broker Red de Procesos de Negocio Resultado: Provisión de Servicios Integrales a los usuarios y diferenciación por valor añadido Integración Extranet, Internet Inter-Enterprise Integration (IEI) Integración Intranet Enterprise Architecture Integration (EAI) integración inter-empresarial de aplicaciones Internet

9 8 La promesa del Negocio Electrónico B2B El valor de las transacciones del negocio electrónico, aunque sea pequeño con relación a la economía, continuará su crecimiento a un ritmo considerable. Más significativo que la cantidad de dinero de esas transacciones son los nuevos procesos de negocio y los modelos que el negocio electrónico activa.

10 9 El impacto en la Función Informática Bases de Datos EDI Redes Corporativas Entrega de Aplicaciones Trabajo en Grupo Topologías Cliente/Servidor Sistemas de Producción Centros de Datos Seguridad Gestión de Sistemas OLTP Servicios De Escritorio Gestión de documentos e imágenes Paquetes De Aplicación Servidores Unix/NT El valor de la empresa es el valor de su red, más que su cuenta de resultados Ley de Metcalfe: n nodos aumentan nxn el valor de la red

11 10 Ejemplo de Servicio Agregado GESTIÓN COMERCIAL TELEPROCESO DataWarehouse I*NET UNIX HOST Ficha Cliente Simulación Fondo Inversión Contratación Obsequio teatro Crítica Obra TeatroCompra Libro Proceso de Negocio Servicios Propios Servicios Terceros Contratación de Productos Financieros

12 11 Requerimientos Tecnológicos Integración de Aplicaciones Message Brokers Mercado de Productos de Integración Iniciativas B2B META Group

13 12 Integración de Aplicaciones B2B requiere conectar las aplicaciones Intra-, inter- empresaProblemática Flexibilidad: Soporte de los distintos interfaces Configuración dinámica Separación entre las funciones de integración (Reglas, Formato & Transporte) Evitar conexiones punto a punto (preferible hub and spoke) Comprar (no desarrollar) donde sea posible S2S System to System App vs. Infrastructura Nivel de Integración Rules Format Transport

14 13 Integración de Aplicaciones S2S (integración Sistema a Sistema) Fichero(transferencia de ficheros) Fichero(transferencia de ficheros) 2 S S Documentos (edi & ) Documentos (edi & ) $ 2 S S $ Bases de datos(replicación) Bases de datos(replicación) 2 S S Eventos (colas de mensajes) Eventos (colas de mensajes) 2 S S Procesos (integración inter-empresa) Procesos (integración inter-empresa) 2 S S

15 14 Integración: Opciones de Arquitectura La integración puede realizarse a distintos niveles: Transferencia de Ficheros / Documentos Simple, pero de funcionalidad limitada Orientado a Batch Replicación de Base de Datos Mayor acoplamiento, pero difícil mantenimiento, sobre todo cuando hay que integrar más de 2 sistemas Orientado a Batch Message Broker El mayor nivel de integración Soporte on-line: Transacciones síncronas Independencia de Plataforma Database 1 Database 2 Database Replication Database 1 Database 2 File / Document Transfer Adapter CTI Message Transport Format Engine Rule Engine META Group

16 15 S2S: Database (Replication) AIP Component Priorities DBMS (ours and/or partners) Database gatewayPros Near-real-time integration Leverages DB technology and skillsCons Too much technology interdependency (common schemas, gateways, DBs) Replication protocols not Internet-friendly Not using Business Logic level knowledge Key Business Requirement No business requirement should mandate use of this e-pattern Common Uses Leveraging tactical database commonality between closely aligned partners (former subsidiaries, spin-offs, etc.)Popularity/Maturity Not at all common ImmatureSecurity No end-to-end security VPN for privacy Components: Data exchange via database replication DBMS Export DBMS Intranet Replication Fire- wall Database Gateway Database Gateway Internet Extranet Private Legacy App DBMS External Organization

17 16 S2S: Database Sourcing Options Best Practice: Not recommended (regardless of sourcing strategy) User Considerations: Availability Security Hosting Alternative: None Data exchange via database replication DBMS Export DBMS Intranet Replication Fire- wall Database Gateway Database Gateway Internet Extranet Private Legacy App External Organization

18 17 S2S: File Security Static routes to file exchange server recommended FTP encryption is proprietary AIP Component Priorities Partners components Traffic shaper File exchange serverPros Standard Internet protocol: FTP Simple for small-scale integrationCons Difficult to manage at larger scales Difficult to make near real time Batch window shrinking Applications do all the work Key Business Requirement Simple regular (daily) movement of data in batches (bulk) Common Uses Send database extracts to partner data warehouse Receive catalog content from manufacturersPopularity/Maturity The most common S2S e-pattern FTP protocol is mature, but technology for secure and guaranteed delivery is immature Components: DBMS App Server Legacy App File Import Export Data exchange at file level (e.g., FTP) Internet Extranet Private Firewall File Exchange Server External Organization

19 18 User Considerations: Security Robustness Migration from private network VAN to Internet solutions S2S: File Sourcing Options Best Practice: Do not change this e-patterns sourcing strategy independently of other S2S e-patterns Sourcing Alternative: Segmented (using a VAN to run file exchange server hub and spoke delivery topology) Segmented Components: DBMS App Server Legacy App File Import Export Data exchange at file level (e.g., FTP) Internet Extranet Private Firewall File Exchange Server External Organization

20 19 S2S: Document AIP Component Priorities Partner or VAN components EDI gatewayPros Mature standards, technology, and products Higher-level integration than basic file transferCons Expensive and complex to establish Still mostly batch-centric Destabilized by evolving standards (e.g., Internet, XML) Key Business Requirement Integrating with a partner using established EDI formats and delivery mechanisms Common Uses Supply chainPopularity/Maturity 2nd most common S2S e-pattern Mature (predates Internet) Not ubiquitous due to complexity and costSecurity Traditionally delegated to VANs Nonrepudiation is a key service Components: DBMS App Server Legacy App Document exchange (e.g., EDI) Fire- wall Internet Extranet Private EDI Gateway EDI Gateway External Organization

21 20 User Considerations: Security Robustness Migration from private network VAN to Internet solutions Hosting Alternative: Segmented (using a VAN to run EDI gateway hub-and-spoke delivery topology) Community hosting (when quantity of partners is large) S2S: Document Sourcing Options Best Practice: Take a case-by-case approach to outsourcing document applications Components: DBMS App Server Legacy App Document exchange (e.g., EDI) Fire- wall Internet Extranet Private EDI Gateway EDI Gateway Community Segmented External Organization

22 21 S2S: Event Components: AIP Component Priorities Integration transport (ours and/or partners)Pros Can support wide range of processing latency (from near real time to batch) MQSeries is de facto standardCons Requires partners agree on a single integration transport product Hard to manage across business boundaries Key Business Requirement Near-real-time exchange of business events Common Uses Bank transfers Airline Consortia code sharingPopularity/Maturity Common in certain service verticals (banking, airline travel) Messaging is a mature technologySecurity Must integrate with application-level security Middleware encryption is still product specific Most firewalls block integration transport protocols DBMS App Server Legacy App Event exchange via queuing (e.g., MQSeries) Fire- wall Integration Transport Get Put Integration Transport Get Put Internet Extranet Private External Organization

23 22 S2S: Event Sourcing Options Best Practice: Outsourcing not common; expect to evolve to S2S process e-pattern instead User Considerations: Outsourcer capability Security Hosting Alternative: Segmented Community hosting (however, we recommend using S2S process rather than S2S event in this case) DBMS App Server Legacy App Event exchange via queuing (e.g., MQSeries) Fire- wall Integration Transport Get Put Integration Transport Get Put Internet Extranet Private Community Segmented External Organization

24 23 S2S: Process AIP Component Priorities Integration serverPros Enables rapid partner integration Quickly adapts to business process change Less dependency on partner infrastructure Provides other S2S e-pattern integration options as wellCons Full process integration is difficult to design and externalize to partners (event-only is easier) Requires 3rd-party community hosting providers for large scale, but few exist Key Business Requirement Externalizing business processes to partners Joining a community with established processes Common Uses Supply chain Trading networksPopularity/Maturity Best practice ImmatureSecurity Must integrate with application-level security Community trust difficult Components: Event and process Information exchange DBMS App Server Legacy App Application Adapters Fire- wall Internet Extranet Private Process Execution Engine IEI Server IEI Server External Organization

25 24 Event and process Information exchange DBMS App Server Legacy App Application Adapters Firewall Internet Extranet Private Process Execution Engine IEI Server IEI Server S2S: Process Sourcing Options Best Practice: Outsourcing options are emerging to coordinate trading networks, COINs, and supply chains User Considerations: Business model and partner relationship dynamics (e.g., trading network or COIN versus big fish supply chain) Outsourcer capability Security Hosting Alternative: Segmented Community hosting Segmented Community External Organization

26 25 Integration Layer Architecture: Best Practice = The Message Broker Message Transport moves data from the application to broker and vice-versa and to/from partners Format engine translates events from one format to another Rules engine Provides ability to apply business logic to events Application Adapter Forms the bridge between integration layer and application layer S2S Adapter Provides functionality necessary for S2S communication with partners Logical Architecture Format Engine Rule Engine AdapterAdapter AdapterAdapter AdapterAdapter AdapterAdapter Message Transport S2S Adapter

27 26 Integration Layer Technology Options Adapter CTI TP Monitor (synchronous) Messaging Middleware (asynchronous) RPC ORB FTP Rule Engine Compatibility Security H/W or S/W Encryption Channel level or end-to-end Message Transport Format Engine Rule Engine

28 27 Inter-Enterprise Integration (IEI) takes two major forms located in the DMZ: Inter-Enterprise Integration (IEI) takes two major forms located in the DMZ: Application servers to integrate external interactive users Exchange brokers to integrate external applications Application servers and exchange brokers will gradually converge into a single technology platform but will remain distinct from an infrastructure development perspective for through 2003/04 Application servers and exchange brokers will gradually converge into a single technology platform but will remain distinct from an infrastructure development perspective for through 2003/04 Use IEI Servers to integrate several (> 2) custom or packaged applications across businesses Use IEI Servers to integrate several (> 2) custom or packaged applications across businesses Facilitates integration of several applications through a single logical control point (hub-and- spoke) and enables agile EB deployments through dynamic configuration facilities Facilitates integration of several applications through a single logical control point (hub-and- spoke) and enables agile EB deployments through dynamic configuration facilities High cost of development and complexity of administration must be justified by ROI through agility and robustness High cost of development and complexity of administration must be justified by ROI through agility and robustness DMZ Firewall Legacy App Server DB ERP App Server DB SCM Legacy App Server DB ERP Queue Manager File Transfer Firewall Inter-Enterprise Integration (IEI) Server DMZ Legacy Firewall App Server DB ERP IEI Server IEI Server IEI Server

29 28 Req. para los productos de Integración Requisitos de Ejecución: Escalabilidad en el transporte, transformación de formatos y ejecución de reglas Monitorización (Auditoría, Control de versiones, Logging) Adaptadores disponibles Automatización de Procesos Toolkit de Desarrollo de nuevos adaptadores Toolkit de desarrollo para transformadores de formatos Toolkit para Automatización de Procesos Soporte de protocolos de transporte Requisitos de Seguridad: Soporte de estándares Componentes Requeridos: Componentes Requeridos: Toolkit de desarrollo: Adaptadores y Formatos Toolkit de desarrollo: Adaptadores y Formatos Adaptadores de Aplicación Adaptadores de Aplicación Soporte de Protocolos de Transporte Soporte de Protocolos de Transporte Servidor de CTI (Computer Telephony Integration) Servidor de CTI (Computer Telephony Integration) Gateway EDI Gateway EDI Servidor de Intercambio de Ficheros Servidor de Intercambio de Ficheros Cifrado de Mensajes Cifrado de Mensajes Motor de Ejecución de Procesos Motor de Ejecución de Procesos Modelador de Procesos Modelador de Procesos Format Engine Rule Engine AdapterAdapter AdapterAdapter AdapterAdapter AdapterAdapter Message Transport S2S Adapter Rules Format Transport META Group

30 29 Mercado de Productos de Integración Microsoft CrossWorlds BEA Viewlocity Mercator Neon/IBM Functionality/Robustness Strategy iPlanet Compaq Vitria Active STC Netfish IPNet Cyclone Extricity webMethods Integrated Intra-Enterprise (EAI) & Inter-Enterprise (IEI) ISG/B4I Fuente: META Group

31 30 Iniciativas B2B XML J2EE, W2K HP e-services/espeak Microsoft BizTalk OASIS Organization for the Advancement of Structured Information Standards IBM, SUN, Microsoft, Naciones Unidas Normalización, estandarización ebXML SOAP Simple Object Access Protocol Ligero. RPC. Vocabulario XML Microsoft, IBM, SUN -> W3C XML Programmability Connectivity HTML Presentation TCP/IP Technology Innovation FTP, , Gopher Web Pages Browse the Web Program the Web Web Services

32 31 Producto BizLogic ¿Qué es BizLogic? Características Metodología: Ejemplo Práctico

33 32 ¿Qué es BizLogic? Definición BizLogic es un entorno de diseño, desarrollo y ejecución de aplicaciones B2B Plataforma para el desarrollo rápido de aplicaciones de transacciones distribuidas de alto rendimientoFramework Run-time Herramientas Plantillas Metodología BizLogic Framework Desarrollo Templates DataBase Comm TimeOuts Test Messages Services XML Parser Simm Tester Diseño Modeler Ejecución Autómata Monitor

34 33 Características Integración de Aplicaciones orientada a Procesos: Arquitectura de Message Broker Separación Motor de Reglas, Formato y Transporte Especificación formal de procesos: UML Lenguaje de definición de procesos: XML Arquitectura Flexible Independencia de entorno de codificación y la plataforma HW (C++) Independencia del middleware (IP, X25, MQSeries, SNA,...) Independencia del formato de mensajes (XML, HTML, PRICE, ASN-1...)

35 34 Características Metodología orientada a las pruebas Simulación y prototipado rápido Plataforma Operativa Monitorización Seguridad Fault-recovery

36 35 Características Sistema Multitarea sobre Windows NT Las etapas realizan la mayor parte: tratamiento de mensajes Contexto (persistente) de sesión: datos de mensajes y servicios El Autómata concentra la lógica de intercambio de mensajes MensajesServicios Gestor de Sesiones Sesión Autómata Contexto Sesiones log thread DataWare Monitor TimeOuts Com BizLogic Autómata

37 36 Características BizLogic = Message Broker IEI Security Autorización: control de Eventos por autómata Monitor Flexible IEI Transport Etapas transporte síncrono/asíncrono Middleware customizable: TCP/IP, X25, SNA, MQSeries, SOAP IEI Monitoring and Management Facilities MensajesServicios Gestor de Sesiones Sesión Autómata Contexto Sesiones log DataWare Monitor TimeOuts Com BizLogic Autómata FormatEngine Rule Engine AdapterAdapter Message Transport S2S Adapter Format Engine Rule Engine AdapterAdapter AdapterAdapter AdapterAdapter AdapterAdapter Message Transport S2S Adapter =

38 37 Metodología de Desarrollo Ejemplo: Aplicación de BizLogic en un proyecto de carga de tarjetas monedero desde un descodificador de TV: Ejemplo: Aplicación de BizLogic en un proyecto de carga de tarjetas monedero desde un descodificador de TV: El usuario introduce su tarjeta monedero en el descodificador de su televisor y solicita la una carga. La orden llega a una entidad intermedia que atiende las peticiones de los descodificadores por un Servidor de Comunicaciones (SC) y la pasa al Servidor de Carga Monedero (SCM), que encamina la petición a CECA. CECA ejecuta el protocolo de Carga Euro6000 y autoriza la operación, quedando a la espera de confirmación. El descodificador graba la carga en el chip de la tarjeta monedero y confirma si la carga es correcta. El SCM confirma a CECA y guarda en ORACLE los datos de la transacción, dando por concluida la operación. ENTIDAD PASARELA DE PAGO X-28 X CH X-25 SCM Consola SC TCP/IP X25

39 38 Metodología de Desarrollo Diseño de Autómatas La herramienta de modelización BizLogic Modeler permite dibujar los diagramas de estados UML que expresan formalmente el comportamiento de los 3 sistemas, guardando la información en ficheros XML Diagrama de estados del Descodificador. Diagrama de estados de CECA. Diagrama de estados del SCM. Los autómatas contienen la especificación implícita de los mensajes y los servicios SimIRD.xmlSimCECA.xmlSCM.xml Modeler

40 39 Diseño Servidor Utilización de la infraestructura Autómata DataXYServXY herencia Recompilar con los nuevos componentes Mensajes/Servicios XY.xml Copiar ficheros de Autómatas ComX ComY herencia Etapas de comunicaciones

41 40 Metodología: Análisis Funcional Escenario Tx Ok : XY : Tx M( ) Q( ) Escenario EFy Ok : XY : EFy N( ) P( ) Escenario Tx Ok : Tx : EFy : XY M( ) s1( ) N( ) P( ) s2( ) Q( ) dw1( ) TxEFy 2: SimTx 3: SimEFy 1: Protocolo XY 1) Diseño Escenarios: CASOS PARTICULARES

42 41 Metodología: Análisis Funcional Autómata XY : S1KO / 10004: Q 0: Espera_M 1: Servicio_S1 2: Espera_P 3: Servicio_S2 4: Envia_Q 6: Fin 10001: M / 20001: S1 7: Servicio_S3 5: DataWare 40000: DWOK / : SOK / 10004: Q 30000: TO / 40001: DW1 9999: TXKO / 40001: DW : SOK / 10002: N 20000: SOK / 40001: DW : P / 20002: S : TO / 20003: S3 9999: TXKO / 20003: S3 2) Diseño Autómatas: 1 Autómata = Escenarios Autómata EFy 0: Espera N 2: Fin 1: Envia_P 10002: N / 10003: P 2: Fin 30000: TO / : TXKO Autómata Tx 3: Fin 1: Espera_Q 0: Espera Inicio 10004: Q / 0 1: Inicio / 10001: M

43 42 Metodología: Análisis Funcional Organización en Rational ROSE

44 43 Metodología: Análisis Funcional TX.xml EFy.xml XY.xml 3) Generación Ficheros XML: 3) Generación Ficheros XML: Automático: Add-in Rational ROSE Automático: Add-in Rational ROSE Ejemplo XML Ejemplo XML DTD

45 44 Metodología: Análisis Funcional E specificación Mensajes: Organización Rational ROSE E specificación Mensajes: Organización Rational ROSE

46 45 Metodología: Análisis Funcional E specificación Servicios: Organización Rational ROSE E specificación Servicios: Organización Rational ROSE

47 46 Autómata DataXYServXYXY.xml ComX ComY Metodología: Desarrollo Servidor (4) Codificación de Mensajes y Servicios XY (5) Codificación Etapas de Comunicaciones XY SCM SCMPru

48 47 Metodología: Desarrollo Simuladores (6) Codificación Etapas de Comunicaciones Tx, Efy La misma infraestructura para simuladores y servidores ComSimTx ComSimEFy DataXYServXYSimEFy.xml SimTx.xml SCMPru Autómata

49 48 Metodología: Desarrollo de Mensajes Verificación de Autómatas Representación Visual Árbol de Expansión de Estados Modeler

50 49 Metodología: Desarrollo de Mensajes Productividad en el desarrollo de mensajes Simulación de la evolución del protocolo Ficheros de prueba Ficheros de prueba: validación visual Transformación de mensajes entrada/salida Situación del contexto en cada estado Evolución histórica del contexto Tester

51 50 Metodología: Desarrollo de Mensajes Productividad en el desarrollo de mensajes Demo Tester


Descargar ppt "DESARROLLO RÁPIDO DE APLICACIONES B2B. 1 La evolución de Internet Requerimientos Tecnológicos Producto para el B2B: BizLogic ÍNDICE."

Presentaciones similares


Anuncios Google