1 / 45

7. Legacy Systems 7.1. Integration Levels

7. Legacy Systems 7.1. Integration Levels. System B. System C. System D. System A. Service Interface. Service Interface. Service Interface. Service Interface. Enterprise Service Bus. What we have been discussing. Process Orchestrator. Service Directory. Service Oriented

wendi
Download Presentation

7. Legacy Systems 7.1. Integration Levels

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 7. Legacy Systems7.1. Integration Levels

  2. System B System C System D System A Service Interface Service Interface Service Interface Service Interface Enterprise Service Bus What we have been discussing... Process Orchestrator Service Directory Service Oriented Architecture

  3. Developing new systems • Systems are thought explicitly for enterprise integration • It’s a fundamental concern to provide an external integration interface • That external interface should guarantee: • High granularity in terms of business functions • Autonomy and independence from other services • Clear and Consistent semantics for integration • Security • Ability to be evolved (e.g. versioning) • (Meta-information and Self-documentation) • At the enterprise level, systems much be thought as a whole for wide integration • Standardization and common approach to service development at the entprise • Usage of a Service Bus • Service registration on a common directory

  4. According to this vision, the world looks like…

  5. The “real world”...

  6. BIG BALL OF MUD «While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. (...) A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture. (...)» B. Foote and J. Yoder, "Big Ball of Mud", in Proc. The 4th Pattern Languages of Programming Conference, Monticello, Illinois, USA, Sep. 1997 http://www.laputan.org/mud/mud.html

  7. Ball-of-Mud regarding EAI

  8. Application Types • “Simple Isolated Applications” (silo) • “1-tier application” • The interface may or may not be graphical; in many enterprise applications it’s not User Interface BusinessLogic Data Management

  9. Application Types (2) • 2-tier Applications • Separation between data and business logic User Interface BusinessLogic Database

  10. Application Types (3) • 3-tier Applications • Separation between user interface, business logic and data User Interface Business Logic Database

  11. Thick vs. Thin Clients Thin Client Thick Client Graphical-oriented API Business API Business Logic Business Logic Database Database

  12. Packaged Applications • An application provider supplies customers with an application server capable of supporting a large number of business needs • Most systems need to be heavily customized • Plug-and-play of modules • Integration with other systems is made through custom APIs or adaptors (e.g. Java JCA) • Some examples: SAP, PeopleSoft, Oracle, Baan, Siebel, etc. ERP M1 M2 M3

  13. W E B S E R V I C E GUI Business Logic Database Proxies and Wrappers • Fundamental Concept: Hide the legacy application behind a proxy or a wrapper • Typically, a proxy consists in automatically generated code that maps an existing interface into a more convenient one • A bridge is a form of proxy that connects two different systems • A wrapper consists in a piece of core (or interface) that hides an existing application, allowing it to be seen as an autonomous system • Wrappers are normally “hand coded” • When it’s not an application that is being hidden, but just an interface, that it’s called an adapter (e.g. a simple wrapper that maps a whole application using integration at the user interface level)

  14. Integration Types (Traditional EAI) • Traditionally, EAI focused on Application-To-Application Integration • Démodé: nowadays we use SOA and ESB! • Even so, the learned-lessons are important!

  15. Integration Types • User Interface Level(GUI or not) • Business Methods Level(Application-specific APIs; typically RPC-based) • External Application APIs Level(Integration-specific APIs; CORBA; MOM; “connectors”) • Data Level(Databases, Files)

  16. Screen-Scraping • Integration systems using the user-interface

  17. Screen-Scraping • It can be simple or complex! • Text-based Systems • VT100, IBM 3270 (IBM mainframes), IBM 5250 (AS/400), etc. • In many cases, an operation depends on navigating through several screens and menus. Problem: what to do if an operation fails? • Lack of documentation and consistency • Thick-client systems • It’s easier: you can remove the user interface and interact directly with the business logic • Thin-client systems (web) • Relatively simple • Fragile (web-based interfaces change quickly)

  18. Screen-Scraping (2) • Some problems: • Needs detailed knowledge of the application • In many cases that are “calculated fields” which do not map into the business logic or corresponding databases • Difficult to evolve and maintain • Data extraction procedures: • Static (line/column based) • Dynamic (tag search based, regular expressions, etc.) • As a general rule, it shouldn’t be used while trying to integrate an application into a larger system. (It’s too fragile.)

  19. Integration at the Business Methods Level • Some applications do provide external interfaces that can be used for EAI: • Thick-client applications • Applications thought for distributed systems • Applications thought to be integrated • Thick-client / Distributed Applications • Method granularity problem • Interoperability problem • Documentation problem / reverse engineering • Data integrity problem • Security problem • Application thought for being integrated • Typically CORBA or DCE RPC interfaces • Relatively easy to integrate

  20. External Application APIs Level • “Packaged applications” are thought with integration with mind • ... with modules of the SAME SUPPLIER • In some cases, with modules or applications from other suppliers • Characteristics • Adequate granularity • Correct semantics for security and data consistency • In many cases they use MOM / CORBA(in others: COM/DCOM, Java RMI, XML-RPC, SOAP) • In a lot of cases they use proprietary protocols • In the Windows world... typically DCOM! • Different business areas try to standardize different procedures: • SWIFT: Banking operations • FIX: Financial operations • HL7: Medical Systems • ... Try to keep your system standard-compliant!

  21. Data-level Integration • Two common approaches • Directly accessing the database tables! • Export-Transfer-Import of data (file-based) • Direct access to Database Tables • ODBC, JDBC, or native BD driver • In some cases, there are still non-relational BDs being used! • Dangerous because of possible semantic violations and data inconsistencies • Reverse-engineering / documentation problem • Fragile to changes • Many times, it’s used for data replication among databases • Latency problem • Consistency problem

  22. Data-level Integration (2) • Export-Transfer-Import • It’s quite common to dump a database to file, transform the file in some way, and transfer the data into another system • “FTP-based integration” is quite common • Extremely common in Data-Warehousing • Operational DB  Data Warehouse • Normally, theses systems have temporal deadlines that must be met • 24-h latencies are common • Non-consistent data view throughout the whole system • Relatively secure and even resilient to some (limited) changes

  23. EAI using files

  24. Typical...

  25. IMPORTANT CONCEPT: Evolving Systems!

  26. Phase 1 Phase 2 Phase 3 Progressive Deployment Enterprise Service Bus

  27. Some Warnings... • Avoid introducing new technology when solutions can be created with what you have • Avoid introducing complex and hard-to-maintain processing logic • Avoid creating a fragmented environment where the business logic is distributed throughout the enterprise • Avoid creating tightly coupled channels which fail when the intervening systems change • Minimize the re-development of existing applications while performing enterprise application integration • Pay special care on how performance is affected while doing EAI

  28. Bibliography • Enterprise Integration Patternsby Gregor Hohpe & Bobby Woolf • Chapter 2 • Enterprise Application Integrationby David LinthicumAddison-Wesley, ISBN 0201615835, Dez/1999 • Chapters 1-5 • Service-Oriented Architecture: A Field Guide to Integrating XML and Web Servicesby Thomas Erl • Chapters 8 and 9

  29. 7. Legacy Systems7.2. Brief introduction to JCA

  30. JDBC J2EE

  31. J2EE on a larger world...

  32. Problemas • Sistemas CRM, ERP e legados não são... • Bases-de-dados acessíveis via JODBC • Código Java que suporte APIs Java • Normalmente os fabricantes oferecem adaptadores... • Específicos! • Como é que se pode gerir, de forma uniforme: • Obtenção e gestão de ligações? • (E.g. criação de ligações e connection pooling) • Propriedades transaccionais? • (E.g. propagação transaccional) • Segurança? • (E.g. autenticação e autorização...)

  33. Registados no servidor JNDI do servidor J2EE Java Connector Architecture (JCA)

  34. Java Connector Architecture (JCA) • Especifica um conjunto de contratos e interfaces entre: • O servidor aplicacional e o adaptador • Entre as aplicações cliente (que correm no servidor aplicacional) e o adaptador • ... é semelhante a um “device driver”  • Esses contratos cobrem: • A obtenção e gestão de ligações • A gestão de segurança (autenticação) • Propagação transaccional • Suporte alargado por parte da indústria • Actualmente na versão 1.5 (JCA 1.5) • http://java.sun.com/j2ee/connector/index.jsp

  35. Visão alargada dos contractos

  36. Quem escreve os adaptadores? • Os fabricantes de sistemas alargados que desejem integração transparente dos seus sistemas com J2EE • Programadores que desejem “encapsular” sistemas legados presentes na sua organização num sistema J2EE • No entanto, tal só é tipicamente feito quando o software é reutilizado em diversos componentes (questão de custo vs. benefício)... Os programadores tipicamente utilizam os adaptadores, não os escrevem...

  37. Contratos – Gestão de Ligações • Oferece um API uniforme para obter uma ligação a um EIS (Enterprise Information System) assim como para realizar a sua gestão. • Normalmente, o adapter é responsável por implementar pooling de ligações de forma eficiente. • ConnectionFactory permite criar ligações, Connection representa uma ligação.

  38. Contratos – Gestão de Transacções • Garante a utilização e propagação de contextos transaccionais para o EIS. • Novamente, é responsabilidade do adaptador fazê-lo correctamente • Três níveis transaccionais: • Nulo ou nenhum • Transacções locais (i.e. apenas envolvendo um EIS) • Transacções distribuídas

  39. Contratos – Gestão de Segurança • Permite a um servidor aplicacional ligar-se a um EIS usando um conjunto de credenciais correctas para um determinado “principal” • Username/Password, Certificado X.509, etc. • São suportados dois modos de autenticação: • “Container-managed Sign-on”: as credenciais são pré-configuradas quando é feita a instalação da aplicação. • Configured Identity: todos os recursos são acedidos com a identidade configurada • Principal Mapping: o “principal” que está a utilizar a aplicação é mapeado num “principal” do EIS • Caller Impersonation: o “principal” do servidor aplicacional é o que é utilizado na chamada ao EIS • Credentials Mapping: semelhante ao anterior mas é feito um mapeamento de credenciais • “Component-managed Sign-on”: o programador trata disso no código 

  40. Contratos – Client Connection Interface (CCI) • Permite ao programador transferir e obter informação de um EIS de forma uniforme • Algo semelhante ao interface JDBC – orientado aos dados • O programador não necessita de o utilizar e o adaptador não necessita de o providenciar: é possível utilizar um API definido à medida • O CCI divide-se em quatro partes: • Connection Interfaces: o API para o estabelecimento das ligações • Interaction Interfaces: Controla a execução do EIS • Record/ResultSet Interfaces: Resultados obtidos do EIS • Metadata Interfaces: Permite reflexão sobre metadata do EIS

  41. Exemplo... Ninguém disse que era “fácil” ou “bonito”...

  42. JCA 1.5 • O JCA 1.5 resolve algumas limitações do JCA 1.0. Em particular... • Em JCA 1.0 apenas é possível ter invocações J2EEEIS • Em 1.5 é possível ter um “Message Inflow” em que um EIS envia mensagens assincronamente para uma aplicação J2EE. Essas mensagens são entregues a “messaging beans” correctamente configurados. • Em 1.5 é possível propagar um contexto transaccional no sentido EISJ2EE (Transaction Inflow) • Em JCA 1.0 a gestão do adaptador era pobre... • Em 1.5 é possível gerir o ciclo de vida de um resource adapter: “Lifecycle Management Contract” (iniciar, parar, etc.) • Em 1.5 um resource adapter por pedir ao servidor J2EE para realizar trabalho (e.g. monitorizar a disponibilidade de um certo servidor, de um componente, etc.): “Management Contract” • Toda a gestão de threads associada corresponde ao servidor J2EE, não ao adaptador.

  43. Questão... Compare a utilização de SOA baseada em Web-Services e as especificações WS-* com a abordagem JCA para integração de aplicações num application server. Em particular... há alguma vantagem nesta abordagem versus SOA/WS? ... se SIM, qual ou quais? ... se NÃO, então porque é que se utiliza JCA?

  44. Bibliografia • “J2EE Connector Architecture: Integrating Java Applications with Existing Enterprise Applications” • whitepaper at the Sun’s Developers Network,http://java.sun.com/j2ee/white/connector.html • Dirk Reinshagen, “Connect the enterprise with the JCA”, Parts 1 & 2 • in the JavaWorld Jornal, Nov/2001 and Fev/2002 http://www.javaworld.com/javaworld/jw-11-2001/jw-1121-jca_p.html http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-jca2_p.html

  45. IMPORTANT NOTICE YOU ARE FREE TO USE THIS MATERIAL FOR YOUR PERSONAL LERNING OR REFERENCE, DISTRIBUTE IT AMONG COLLEGUES OR EVEN USE IT FOR TEACHING CLASSES. YOU MAY EVEN MODIFY IT, INCLUDING MORE INFORMATION OR CORRECTING STANDING ERRORS. THIS RIGHT IS GIVEN TO YOU AS LONG AS YOU KEEP THIS NOTICE AND GIVE PROPER CREDIT TO THE AUTHOR. YOU CANNOT REMOVE THE REFERENCES TO THE AUTHOR OR TO THE INFORMATICS ENGINEERING DEPARTMENT OF THE UNIVERSITY OF COIMBRA. (c) 2007 – Paulo Marques, pmarques@dei.uc.pt

More Related