Application Integration

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