1 / 57

Application Integration

FinPUG Turku, Finland, 26-Mar-01. Application Integration. Gus Björklund , Wizard, Vice President of Technology, Progress Software. Integration Subjects. Challenges Available Technologies The Progress Way. Integration - The Challenges. Cost effectiveness. Incompatible technologies.

olesia
Download Presentation

Application Integration

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. FinPUGTurku, Finland, 26-Mar-01 Application Integration Gus Björklund, Wizard, Vice President of Technology, Progress Software

  2. Integration Subjects Challenges Available Technologies The Progress Way

  3. Integration - The Challenges Costeffectiveness Incompatibletechnologies LegalBarriers Competitors Languages Expandingmarkets Need forefficiency Legacy infrastructures Speedof light Short-termrelationships Culturaldifferences Countryboundaries Incompatibleapplications Complexity Politics Disintermediation

  4. If it is thathard…

  5. why do it ?

  6. Benefits • Extend functionality of internal systems • Buy and tie • Preserve existing, working (“legacy”) systems • Use alongside new systems • Reduce cost by not replacing • Automate inter-company business processes • Increase efficiency

  7. Integration – Many Technologies COM IIOP EDI POP ONC RPC DCE RPC X.12 DCOM CORBA DCOM EMAIL EJB J2EE Sockets XML ADM SMTP RMI SmartObjects DDE SharedLibraries JavaBeans DLL DCOM HLC

  8. Two Fundamental Integration Approaches • Procedure Calls • Shared component framework • One application calls procedure in another • “Tight” coupling • Send and Receive Messages • Shared messaging framework • One application sends a message to another • “Loose” coupling

  9. Procedure Calls status = createCust (3456, “Smith’s Plumbing”, “1 Velvet Lane”):

  10. Procedure Calls status = createCust (3456, “Smith’s Plumbing”, “1 Velvet Lane”): int createCust (int id, char *name char *address){ return (RET_OK);}

  11. Messages send message Application1 Application2 return reply

  12. What’s In The Message ?

  13. What’s In The Message ? 4:CCUS2:345616:Smith’s Plumbing13:1 Velvet Lane

  14. Integration Subjects Challenges Available Technologies Tightly Coupled Approaches Loosely Coupled Approaches The Progress Way

  15. Component Model • An architecture and framework that enables the construction of modular applications and systems from separately developed pieces • “Plumbing” that allows developers to focus on their application, not on infrastructure.

  16. Variety of Component Plumbing • CICS • COM • CORBA • JavaBeans • Enterprise JavaBeans • San Francisco • Progress ADM, SmartObjects, ICF • etc.

  17. COM Component - DLL is usual Application Interfaces

  18. COM • Microsoft’s component framework and related infrastructure • Enables components to communicate with each other through declared interfaces • Everything MS builds is based on COM

  19. DCOM Client Machine Server Machine Component DCE RPC COM COM Application Network

  20. DCOM • Distributed COM • Adds remote capabilities to COM • Uses DCE RPC for communication

  21. COM+ • What’s already in DCOM, plus the following: • Publish and Subscribe Interface • Queued components • Load Balancing • Integration of MTS (Microsoft Transaction Server

  22. CORBA Architecture Shared Facilities Application Objects Object Request Broker (ORB) Common Object Services

  23. CORBA • “Common Object Request Broker Architecture” • Plumbing to enable object-oriented programs to make remote method calls • Primarily used with C++ programs, although other language bindings exist • CORBA Services incomplete, extras • Attempting to accommodate Java • Dead ?

  24. IIOP Component ORB ORB IIOP Component

  25. IIOP • Internet Inter-ORB Protocol • A protocol that allows CORBA ORBs to talk to each other • objects residing in one ORB call methods of objects in another

  26. EJB Architecture EJB Server Data EJB Container Client Enterprise Bean Other Apps Enterprise Bean Database Server Enterprise Bean

  27. EJB • Server component architecture for Java • Plumbing enables distributed JavaBeans • Powerful programming language • Good component model • Good transaction model • Different language for data access • JDBC and SQL are hard to use • Do-it-yourself clients • Database not included • Good or bad, depending on point of view

  28. Progress ADM/SmartObject Architecture SmartObjects WebSpeed Messenger Web Server AppServer Internet Adapter Firewall GUI Character Java ActiveX User Interface Business Logic Data

  29. Progress ADM/SmartObjects • Progress Distributed Component Architecture • Powerful, easy-to-learn, easy-to-use programming language • Data model integrated with 4GL • Progress database • Multiple client types • Same language at all layers • Presentation • Logic • Data access

  30. BREAK !

  31. 3-Tier Application Architecture Presentation Processing LogicData AccessLogic DatabaseServer Display and browse data Accept input Simple validation Complex validation Calculation Guts of application Data retrieval and update Access Organize Manage data

  32. What’s Wrong With Procedure Calls ? status = createCust (3456, “Smith’s Plumbing”, “1 Velvet Lane”): int createCust (int id, char *name char *address){ return (RET_OK);}

  33. Troubles • If one application blocks or fails, all may be affected • Each application requires knowledge of what data types other applications expect • Version compatibility - hard • Data transformation and routing logic built into each application • Guarantees, quality of service and reliability are your responsibility • Shared resource management sometimes difficult • Different component models incompatible • When you build some, and others build some, these problems hard to control

  34. Integration Subjects Challenges Available Technologies Tightly Coupled Approaches Loosely Coupled Approaches The Progress Way

  35. Messaging • Asynchronous requests, reports, or events that are produced and consumed in enterprise applications • A formal way for programs to exchange data and request services among each other in a loosely coupled way • Many techniques possible

  36. File Transfer • Works – been done for many years • Point-to-point over various protocols • FTP, HTTP, NFS, Floppy Disk ! • But: • No guaranteed delivery • Detecting errors tricky • Operating system compatibility issues • Hardware Architecture compatibility issues • Performance low for small files

  37. Do It Yourself Messaging With Sockets send message Application1 Application2 send back reply

  38. Do It Yourself Messaging With Sockets • Works • Cheap - at first • But: • Guaranteed delivery is hard • Scalability is hard • Socket programming is not easy • Architecture neutrality cumbersome • Security is hard

  39. EDI Application1 Application2 VPN

  40. EDI • Point-to-point messaging • Based on X.12 protocol • Uses VPN • Popular, estalished • But: • Expensive • Individual deals often needed for each link

  41. Connections Multiply

  42. What To Do ?

  43. Message Servers Message Server Subscriber Subscriber Publisher Subscriber Sender Receiver

  44. Message Servers • Don’t connect to every destination • Just connect to server • Message server figures out • Who is supposed to get which messages • How to get them there • Quality of service • What to do if • message cannot be delivered • recipient not connected • system crashes

  45. Oldest Message Server: EMAIL • Easy ! • Most systems already have infrastructure • Client-server architecture • Automatic routing • Protocols universal • POP, SMTP, IMAP • Fairly reliable • But: • Delivery not guaranteed • Error detection difficult

  46. SonicMQ Message Server Internet Internet Headquarters Subsidiary Quotes Catalog Catalog Pricing SonicMQ Cluster SonicMQ Server Shipping SonicMQ Server SonicMQ Server Finance SonicMQ Server Partner SonicMQ Cluster Purchasing SonicMQ Server Availability SonicMQ Server SonicMQ Server Forecasting Quotes Catalog office

  47. XML And Messages XML ArchitectureNeutral Support fromVendors/Consortia/Trading Exchanges Rationalized Form(Human Readable) Schema Standards StandardSchemaRepositories Transformations(XSLT) Query & Manipulation(XPATH, DOM, XQL) Standard Toolkits Adapts toChange

  48. Integration Subjects Challenges Available Technologies Tightly Coupled Approaches Loosely Coupled Approaches The Progress Way

  49. Internet Component Framework New Smart Objects Security Manager Smart Business Object Smart Sender/Receiver Smart B2B Object Dynamic SDO Session Manager ANY Application ContextManager CustomizationManager Business Logic Repository ANY Data Source ANY Client ANY Business Components With Progress ADM and Internet Component Framework (ICF)

  50. Components With Progress ADM and Internet Component Framework (ICF) Tight Coupling: • Quickly build and deploy applications • Reuse existing business logic • Assemble applications using multiple development models • Support all e-business deployment models • Leverage Progress UAA

More Related