ÍNDICE La evolución de Internet Requerimientos Tecnológicos

Presentación del tema: "ÍNDICE La evolución de Internet Requerimientos Tecnológicos"— Transcripción de la presentación:

0 DESARROLLO RÁPIDO DE APLICACIONES B2B

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

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

3 publicación de contenidos de personas conectadas
Internet 1.0: acceso de datos de forma implícita e intuitiva Explosión en publicación de contenidos 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 Internet Resultado: 130 Millones de personas conectadas Consumidores

4 acceso a servicios de forma implícita e intuitiva
Internet 2.0: acceso a servicios de forma implícita e intuitiva 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 Utility Computing Resultado: La Red trabajando para todas las personas y todas las cosas, de forma permanente

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

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

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

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. The total US Internet economy more than doubled between 1996 and 1997 — $15.5B to $38.8B. By 2001, it is projected to be $350B. Business-to-business e-commerce is expected to account for the largest share of the Internet economy. Intra-business activity will dwarf access providers, content providers, retail, and financial services. The number of US businesses selling their products on the Web will double to 56% during the next year. One out of three households in the US and one out of 30 people on the planet have Internet access. The US has 62% of Internet users currently this will decline to 50% within 2 years. By 2005, 50% of Internet content will be non-English language.

9 El impacto en la Función Informática
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 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 E-Business Currently, the most IT-intense companies of the industrial and information age are financial institutions. They spend about $38,000 per employee on IT, which accounts for perhaps one out of every four expense dollars. Within this $38,000, about one-third is being spent on new technology: e-commerce, business intelligence, CRM, SFA, etc. The new companies of the network age are spending more than one out of two dollars and the non-technology dollars are going toward marketing and communication! Valuation of an enterprise is no longer being based on brick and mortar, revenue, and profits — instead, it is based on the value of the network. As the number of nodes in a network increases arithmetically (added one at a time), the value of the network grows in an explosive compounded manner at least n x n — Metcalfe's law. This can be seen in the valuation of Microsoft, Yahoo, Amazon, and others. The value is in their network well before there is value in revenue and profits. IT spending per employee ranges from a low of about $2,500 to a high of almost $40,000 across sectors. The spread however is tremendous, with finance, insurance, and utility companies now leading the pack at $38,905, $24,387, and $18,867 respectively. At the bottom end are manufacturing ($4,346), metals/natural resources ($4,108), and hospitality/travel ($2,499).

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

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

12 Integración de Aplicaciones
B2B requiere “conectar” las aplicaciones Intra-, inter- empresa Problemá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

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

14 Integración: Opciones de Arquitectura
META Group 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 Message Broker El mayor nivel de integración Soporte on-line: Transacciones síncronas Independencia de Plataforma Database 1 Database 2 File / Document Transfer Database 1 Database 2 Database Replication Adapter CTI Message Transport Format Engine Rule Engine Integration Server

15 S2S: Database (Replication)
Components: External Organization Internet Extranet Private Export Legacy App Fire-wall Fire-wall DBMS DBMS Intranet Replication Database Gateway Database Gateway DBMS Data exchange via database replication 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 Immature Security No end-to-end security VPN for privacy AIP Component Priorities DBMS (ours and/or partners) Database gateway Pros Near-real-time integration Leverages DB technology and skills Cons Too much technology interdependency (common schemas, gateways, DBs) Replication protocols not Internet-friendly Not using Business Logic level knowledge Why are “DBMS (partners and/or ours)” a priority? (NOTE: common to all S2S e-patterns!) Very often a business must mold its own decisions about technology to those decisions already made by significant partners (and design specifically to support options). If the “big fish” says you’ll do it this way, and this makes lots of money, you’ll have to do it this way. Why is the database gateway a priority? Determines Server OS/HW/HA Limits which partner DBMSs can be replicated to Differentiating from other e-patterns: Exporting from the database and then exchanging that file would be S2S File e-pattern Not Recommended We are presenting this S2S e-pattern first because we do not recommend it. Even though it has a moderately high level of integration provided by infrastructure, it is fundamentally based on proprietary replication protocols and technology and acts at the database level thus bypassing application-level integrity checks. Security Only at the transport level (e.g., VPN) Integrity Database-level conflict resolution (bypasses application integrity) Interaction Database replication protocols Transport Mostly private IP, some public IP QoS Multiple queues, prioritization of processing Format Database-level (data schemas must match) Database-level only Workflow Weak Strong Very Weak Application Infrastructure

16 S2S: Database Sourcing Options
External Organization Internet Extranet Private Export Legacy App Fire-wall Fire-wall DBMS Intranet Replication Database Gateway Database Gateway DBMS Data exchange via database replication Hosting Alternative: None User Considerations: Availability Security Best Practice: Not recommended (regardless of sourcing strategy) We do not recommend this e-pattern, and thus don’t recommend specific sourcing alternatives.

17 External Organization Data exchange at file level (e.g., FTP)
S2S: File Components: External Organization File Import Export Legacy App Internet Extranet Private File Exchange Server File Exchange Server Firewall Firewall Data exchange at file level (e.g., FTP) App Server DBMS 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 manufacturers Popularity/Maturity The most common S2S e-pattern FTP protocol is mature, but technology for secure and guaranteed delivery is immature Security Static routes to file exchange server recommended FTP encryption is proprietary AIP Component Priorities Partner’s components Traffic shaper File exchange server Pros Standard Internet protocol: FTP Simple for small-scale integration Cons Difficult to manage at larger scales Difficult to make near real time Batch window shrinking Applications do all the work Why are “Partner’s Components” a priority? (NOTE: common to all S2S e-patterns!) Very often a business must mold its own decisions about technology to those decisions already made by significant partners (and design specifically to support options). If the “big fish” says you’ll do it this way, and this makes lots of money, you’ll have to do it this way. Why is Traffic Shaper (or scheduling discipline) a priority? If you can control the traffic, you don’t have to make certain choices on bandwidth and technology for the network between the parties (e.g., stick with existing private frame network rather than implementing a whole new ATM circuit or depending on the Internet) Why is the File Exchange server a priority? Determines Server OS/HW/HA Differentiating from other e-patterns: Manually downloading files with FTP is P2S Publish This pattern is NOT event-driven, but rather pre-set time or scheduled delivery driven Just because using FTP protocol, does NOT mean you’re doing S2S: File — S2S: Document may use FTP as a transport mechanism as well Security Application or file exchange server level (also private transport) Integrity Application-level or checkpoint with retry through scheduler Interaction Batch file transfer (FTP protocol) Transport Mostly private (IP, SNA), some public IP QoS Time of day scheduling of bulk data movement Format Application-level Application-level only (rare) Workflow Very Weak Strong Application Infrastructure

18 S2S: File Sourcing Options
Segmented Components: External Organization File Import Export Legacy App Internet Extranet Private File Exchange Server File Exchange Server Firewall Firewall Data exchange at file level (e.g., FTP) App Server DBMS Sourcing Alternative: Segmented (using a VAN to run file exchange server hub and spoke delivery topology) User Considerations: Security Robustness Migration from private network VAN to Internet solutions Best Practice: Do not change this e-pattern’s sourcing strategy independently of other S2S e-patterns Very few organizations have turned to the Internet for system-to-system file-transfer functionality alone, as organizations requiring such functionality currently use Value-Added Networks (VANs), which provide sophisticated file-transfer capability, but require closed/proprietary systems. However, many organizations are seeking to implement file-transfer over existing Internet infrastructure (whether outsourced or not) and/or migrate VAN functionality away from the proprietary networks to Internet-based solutions. In doing either, key considerations include: Sourcing Dependency: EDI (S2S Document) may be using the same VAN. Don’t change one without the other. In general, try to get all S2S patterns single sourced. Today this is difficult since only the S2S File and Document patterns have mature outsourcing providers; all those providers are trying (along with new players) to service the S2S Event and Process e-pattern requirements as well. Service level guarantees: No longer using a VAN (or even a single ISP provider) will likely lead to a much more variable service at the network layer, and there will be no single provider to point the finger at. Security: While secure FTP provides some degree of security, current VAN users will find that IP infrastructure lacks the robust security features of VANs. Robustness: Basic FTP lacks much of the feature-functionality (e.g. flexible scheduling, reliability, etc.) that enables it to scale effectively. Watch for fully-functional FTP-based file exchange servers to continue evolving over the next 1-3 years.

19 External Organization Document exchange (e.g., EDI)
S2S: Document Components: External Organization Legacy App Internet Extranet Private Fire-wall Fire-wall EDI Gateway EDI Gateway App Server DBMS Document exchange (e.g., EDI) Key Business Requirement Integrating with a partner using established EDI formats and delivery mechanisms Common Uses Supply chain Popularity/Maturity 2nd most common S2S e-pattern Mature (predates Internet) Not ubiquitous due to complexity and cost Security Traditionally delegated to VANs Nonrepudiation is a key service AIP Component Priorities Partner or VAN components EDI gateway Pros Mature standards, technology, and products Higher-level integration than basic file transfer Cons Expensive and complex to establish Still mostly batch-centric Destabilized by evolving standards (e.g., Internet, XML) EDI: Electronic Data Interchange (standard formatting legislated by standards bodies include X11 and EDIFACT) Why are “Partner and VAN Components” a priority? (NOTE: common to all S2S e-patterns!) Very often a business must mold its own decisions about technology to those decisions already made by significant partners (and design specifically to support options). If the “big fish” says you’ll do it this way, and this makes lots of money, you’ll have to do it this way. Why is the EDI gateway a priority? Determines Server OS/HW/HA Differentiating from other e-patterns: This pattern is NOT event-driven, but rather pre-set time or scheduled delivery driven; event-driven or real time means S2S Event e-pattern Just using the SMTP protocol does NOT mean you’re doing S2S: Document — P2S Collaboration uses SMTP as a transport mechanism as well If you are not using machine-parseable formatting (EDI formats, XML), system to system communication will be impossible — for person readable, see P2S Collaboration Security Integrity Interaction Transport QoS Format Application-level or EDI gateway level (or VAN) Receipt acknowledgments and non-repudiation services Batch file or SMTP messaging transfer Mostly private (IP, SNA), some public IP Time of day scheduling of bulk data movement Transformation engines in EDI gateway Application-level only (rare) Workflow Weak Strong Very Weak Very Strong Application Infrastructure

20 S2S: Document Sourcing Options
Segmented Components: Community External Organization Legacy App Internet Extranet Private Fire-wall Fire-wall EDI Gateway EDI Gateway App Server DBMS Document exchange (e.g., EDI) Hosting Alternative: Segmented (using a VAN to run EDI gateway hub-and-spoke delivery topology) Community hosting (when quantity of partners is large) User Considerations: Security Robustness Migration from private network VAN to Internet solutions Best Practice: Take a case-by-case approach to outsourcing document applications Users selectively choose to outsource S2S Document applications, and the decision depends largely on the number of partners to be integrated as well as the size and newness of the company (legacy with installed EDI network vs. dot-com startup). Companies with EDI have already largely migrated to EDI gateways to provide document interchange for multiple applications; the outsourcing decision in this case comes down to the added degree of performance, flexibility, scale and community coordination that can be provided by the outsourcer (from business and human capital/labor perspectives, not just traditional technology decision points). Smaller, less-established companies and dot-coms are more likely to avoid S2S Document (specifically EDI) and are struggling with less mature e-patterns (specifically S2S Event and S2S Process). As the quantity of trading partners grows, community hosting approaches will provide more business benefit to all parties. There are many (as is common in any quickly expanding category) different names for this kind of hosting, from Extranet Service Provider (see later in this workshop) to Internet market maker, managed trading service (or community or network), etc.

21 External Organization
S2S: Event Components: External Organization DBMS App Server Legacy App Event exchange via queuing (e.g., MQSeries) Fire-wall Integration Transport Get Put Internet Extranet Private Key Business Requirement Near-real-time exchange of business events Common Uses Bank transfers Airline Consortia code sharing Popularity/Maturity Common in certain service verticals (banking, airline travel) Messaging is a mature technology Security Must integrate with application-level security Middleware encryption is still product specific Most firewalls block integration transport protocols 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 standard Cons Requires partners agree on a single integration transport product Hard to manage across business boundaries Why is “Integration Transport” a priority? (NOTE: common to all S2S e-patterns!) Very often a business must mold its own decisions about technology to those decisions already made by significant partners (and design specifically to support options). If the “big fish” says you’ll do it this way, and this makes lots of money, you’ll have to do it this way. Why is “Integration Transport” a priority? Partners must agree May determine Server OS/HW/HA (MSFT yes, IBM no) Differentiating from other e-patterns: This pattern is event-driven, NOT pre-set time or scheduled delivery driven (as S2S: Document and File are) Can use this same infrastructure to provide scheduled file transfers with add-on products Real time EDI is actually this pattern, not S2S Document Further extension of integration services elevates this e-pattern to S2S: Process Security Add-on products (e.g., Candle’s MQSecure) or transport level (VPN) Integrity Guaranteed delivery Interaction Store and forward message queuing Transport Mostly private (IP, SNA), some public IP QoS Prioritization via queuing Format Application-level None Workflow Weak Strong Very Strong Very Weak Application Infrastructure

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

23 Event and process Information exchange
S2S: Process Components: Event and process Information exchange DBMS App Server Legacy App Application Adapters Fire-wall Internet Extranet Private Process Execution Engine IEI Server < > External Organization Key Business Requirement Externalizing business processes to partners Joining a community with established processes Common Uses Supply chain Trading networks Popularity/Maturity Best practice Immature Security Must integrate with application-level security Community trust difficult AIP Component Priorities Integration server Pros Enables rapid partner integration Quickly adapts to business process change Less dependency on partner infrastructure Provides other S2S e-pattern integration options as well Cons 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 The IEI server is designed to send events over business boundaries XML via HTTP transport Security feature enhancements (encryption, authentication) Slimmed-down partner server option Integration servers (more traditional EAI features) were designed with only enterprise integration in mind and lack cross-business features like security We expect these two camps to merge (2002) Why is “Inter-Enterprise Integration (IEI) Server” a priority? Determines Server OS/HW/HA Determines most integration layer components (application adapters, process modeler, etc.) Differentiating from other e-patterns: More than any other S2S e-pattern, this e-pattern provides the greatest flexibility in supporting partner component and business model choices This pattern handles process-driven as well as fire-and-forget events, plus it can handle pre-set time or scheduled delivery as well Prioritization via queuing and scheduling Security Mix of integration server, add-ons, network and application-level Integrity Guaranteed delivery, compensating transactions (ACID without I) Interaction Dynamic configurable (messaging, file transfer, RPC) Transport Mostly public IP, some private IP QoS Format Formatting provided by integration server Sharing of explicit business process models Workflow Weak Strong Infrastructure

24 S2S: Process Sourcing Options
Community Process Execution Engine External Organization Legacy App IEI Server < > Internet Extranet Private Segmented IEI Server < > Application Adapters Firewall Firewall DBMS Event and process Information exchange App Server Hosting Alternative: Segmented Community hosting User Considerations: Business model and partner relationship dynamics (e.g., trading network or COIN versus “big fish” supply chain) Outsourcer capability Security Best Practice: Outsourcing options are emerging to coordinate trading networks, COINs, and supply chains Outsourcers are beginning to emerge to provide S2S Process outsourcing; typically these arise in established community of interest networks (COINs) (e.g. the automotive supply chain) and/or in supply chains NOT dominated by a single “800-lb gorilla” or “big fish” (where one organization is large enough to drive technical and policy standards, such as Wal-Mart). Outsourcers capable of providing both strong IEI services and strong network infrastructure will begin emerging in late 2000 and early 2001 (see technology and products sections for details). META Group describes outsourcers that combine core competencies in multiple areas (IP transport, firewall and VPN management, hosting, PKI, directory, middleware, professional services, and billing) as “Extranet Service Providers”. In the meantime, many community hosting service providers are stronger in networking but light on IEI or vice versa.

25 Integration Layer Architecture: Best Practice = The Message Broker
Logical Architecture 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 Format Engine Rule Engine Adapter Integration Server Message Transport S2S Adapter

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

27 Inter-Enterprise Integration (IEI) Server
DMZ Legacy Firewall App Server DB ERP IEI Server < > 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 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 High cost of development and complexity of administration must be justified by ROI through agility and robustness IEI Server < > Legacy App Server DB ERP Queue Manager File Transfer Firewall Firewall DMZ IEI Server < > Firewall App Server DB ERP App Server DB SCM Abbreviation — ERP Enterprise Resource management system Legacy With rapid globalization and increasing competition in all economy sectors, successful businesses will be increasingly dependent on their capacity to establish efficient cross-business relationships and processes. From an infrastructure perspective, the key technology is cross-business enterprise application integration. Many fundamental technology elements (e.g., message brokering architectures - see OCSS Delta 678, 8 Jul 1998) will be common to intranet application integration (EAI), external integration (IEI - inter-enterprise integration) will justify different implementation practices as well as distinct technology selection and vendor evaluation criteria: IEI Security: Message broker vendors are more or less capable of providing sound end-to-end security services with their solutions. Users should be particularly careful to examine actual (versus planned) message broker security capabilities. Most vendors will have comprehensive vision/marketing statements in this area but often, in fact, modest security capabilities immediately available. Flexible IEI Transport: IEI must dynamically mix batch file transfers and messaging to optimize infrastructure utilization IEI Monitoring and Management Facilities. Users should evaluate message broker vendor monitoring and management facilities for X-EAI based on their capacities to dynamically and selectively insert probes/agents at network, queue manager, broker, application, and user levels. Administrators should be able to turn on/off event generation probes at any level, based on commonly accepted procedures by all parties involved. Research References — OCSS 752, 772, 760

28 Req. para los productos de Integración
META Group 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: Toolkit de desarrollo: Adaptadores y Formatos Adaptadores de Aplicación Soporte de Protocolos de Transporte Servidor de CTI (Computer Telephony Integration) Gateway EDI Servidor de Intercambio de Ficheros Cifrado de Mensajes Motor de Ejecución de Procesos Modelador de Procesos Format Engine Rule Engine Adapter Integration Server Message Transport S2S Adapter Rules Format Transport E-Business Principles Flexibility: Support discrete interfaces Dynamic configuration Clearly separate integration functions (Rules, Format & Transport) Avoid point-to-point (prefer hub and spoke) Buy (not build) where possible Don’t over-engineer! E-Business Issues Legacy Funding Managing 3rd-party integration

29 Mercado de Productos de Integración
Integrated Intra-Enterprise (EAI) & Inter-Enterprise (IEI) Microsoft Extricity webMethods Netfish IPNet Vitria Active Cyclone Strategy CrossWorlds STC ISG/B4I Mercator Neon/IBM Viewlocity iPlanet BEA Compaq Vendor/Products Active Software ActiveWorks BEA eLink ISG Bridges for Islands BRAHMS Compaq BusinessBus Crossworlds Cyclone Commerce Extricity Alliance iPlanet = Netscape's ECXpert plus Sun's Forte Fusion (aka Conductor) EAI Integration Server/Inter-Enterprise Integration Server Partnerships Active Software and NetFish CrossWorlds and IPNet Sterling Commerce and Cyclone Software Oberon and OnDisplay DataChannel MQSI and Extricity IPNet Solutions Mercator Microsoft BizTalk NEON MQSeries Integrator Netfish Technologies XDI STC e*Gate Viewlocity (formerly Frontec) Vitria BusinessWare webMethods B2B Functionality/Robustness Fuente: META Group Dynamic support for file transfer and messaging transport mixes Security Capabilities: Firewall Compatibility. Transparent, dedicated port settings for incoming/outgoing traffic through firewall products. Users should beware of message broker solutions relying on the underlying transport layer (e.g.,standard messaging products or specialized-security implementations such as Candle's MQSecure) Broker, Queue, and User Authentication. Users should consider message broker solutions with integrated public key infrastructure (PKI) schemes carrying authentication/nonrepudiation functions at application, broker, queue, and user levels. Message Encryption. Encryption functions place a significant burden on infrastructure capacities (e.g., server processing of compute-intensive encryption algorithms, high network latencies created by end-to-end processing times), therefore users should be able to activate (selectively and dynamically) encryption functions based on the content, source, and destination of messages as well as prevailing infrastructure performance metrics. Management: Users should evaluate message broker vendors based on their capacities to dynamically and selectively insert probes/agents at network, queue manager, broker, application, and user levels. Evaluation criteria should stress vendor capacity and experience in cross-business transaction systems and understanding of issues associated with setting cross-organizational procedures. 30

30 Iniciativas B2B XML XML  J2EE, W2K HP e-services/e”speak
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 HTML Technology TCP/IP Connectivity Presentation Programmability FTP, , Gopher Innovation Web Pages Browse the Web Web Services Program the Web

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

32 ¿Qué es BizLogic? Definición Framework
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 rendimiento Framework Run-time Herramientas Plantillas Metodología Modeler Autómata Monitor Diseño Ejecución Templates DataBase Comm TimeOuts Test Messages Services XML Parser Simm Tester BizLogic Framework Desarrollo

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...)

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

35 Características Sistema Multitarea sobre Windows NT BizLogic Autómata
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 Monitor DataWare Servicios Mensajes thread TimeOuts Contexto Sesión Autómata Com log Sesiones Gestor de Sesiones BizLogic Autómata

36 = Integration Server 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 Format Engine Format Engine Rule Engine Adapter Integration Server Message Transport S2S Adapter Monitor DataWare Servicios Mensajes Rule Engine = Message Transport TimeOuts Contexto Sesión Autómata Adapter Com log Sesiones BizLogic Autómata Gestor de Sesiones S2S Adapter

37 Metodología de Desarrollo
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 Consola X-25 SC X25 SCM X-28 X CH TCP/IP

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 Modeler SimIRD.xml SimCECA.xml SCM.xml

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

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

41 Metodología: Análisis Funcional
2) Diseño Autómatas: 1 Autómata =  Escenarios Autómata EFy 0: Espera N 2: Fin 1: Envia_P 10002: N / 10003: P 30000: TO / 0 9999: TXKO Autómata XY 200011: 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 / 0 20000: SOK / 10004: Q 30000: TO / 40001: DW1 9999: TXKO / 40001: DW1 20000: SOK / 10002: N 20000: SOK / 40001: DW1 10003: P / 20002: S2 30000: TO / 20003: S3 9999: TXKO / 20003: S3 Autómata Tx 3: Fin 1: Espera_Q 0: Espera Inicio 10004: Q / 0 1: Inicio / 10001: M

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

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

44 Metodología: Análisis Funcional
Especificación Mensajes: Organización Rational ROSE

45 Metodología: Análisis Funcional
Especificación Servicios: Organización Rational ROSE

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

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

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

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

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