Lecture 15 Enterprise level Applications The IT

Lecture 15 Enterprise level Applications

The IT Paradox • There is nothing new under the sun …. .

Outline • • • Introduction Maximizing Data Utility in the Enterprise An Alternative Approach (EAI) Enterprise Integration Patterns Enterprise Integration Toolsets

Maximizing Data Utility in the Enterprise • Expansion of the IS domain – especially the rise of Electronic Business – has greatly accelerated the need and the usage of data across and between enterprises • Total Data Availability Means: – Information where you want it – When you need it to be there – In the form and state satisfies your needs • In short, everything that we’ve been taught but never quite been able to achieve

Electronic Business: Ability to co-operatively initiate and complete transactions through the exchange of information over the network, preferably without having to resort to other modes of communication, and possibly without human intervention.

Historical Strategy & Tactics • • Structure the data as flexibly as possible Centralize information wherever possible Leverage data replication Build distributed databases Separate transactional and analytical stores of data Real time processing of data Data cleansing and restructuring • We have eagerly seized on technological advances to do this more cost effectively

The Aim – The One Big Database Data Persistence Access Layer Modules Data Access Modules Data Application Access Layer Modules

Complexity Rules! • Considered in their own terms, all of these approaches were successful • Just the problem became bigger – Domain Complexity – Solution Complexity – Technological Complexity • It keeps changing faster than we can keep up

Even As Enterprisestr. Try to n ol Co Reduce It !!

One Big Database – Not! • In practical terms, it has proven to be impossible to develop and to implement all -inclusive, enterprise wide data models • While the effort should and must continue, additional approaches are required • This is where Enterprise Application Integration (EAI) has a contribution to make •

A Digression – Process & Applications • The role of EAI in the enterprise has been driven by the need to support higher level business processes. Things like – “Straight Through” processing – Customer Self Service – Unified (WEB) Interfaces Offering Multiple Services (Portals) – Greater movement across enterprise boundaries (Electronic Business) • The application of EAI neither exclusively nor primarily a data level focus – Although the end result both depends upon and results in increased data availability • EAI normally makes data more available – and more useful – by “sharing” it among collaborating applications

Multiple Levels Of Integration • Essentially a classification of techniques used for integration between applications or app components – Data Level – Method Level – Application Programming Interface (API) Level – User Interface Level • Data tends to be shared or exchanged regardless of what level integration is occurring • Often, data can not be shared or transferred without understanding the process or application

Application View As Complex As Data View The Enterprise Clients OS 390 EDI Trns Windows NT HTML Partners IIS Cobol Apps SQL Server Java Apps Natural Apps DB 2 CICS Adabas Solaris VB Apps C++ Pivotal Partners VSAM Clients Windows 2000 Suppliers MQ Series SQL Server Oracle SAP CORBA MOM COM FTP RPC HTTP …. . . EDI HL 7 XML SOAP …. .

Electronic Business = Zero-Latency Business {Gartner} The Enterprise Warehouse Mgmt. Order Entry Financials B 2 B Bank B 2 C A 2 A 4) “Please pay for it. ” Logistics B 2 B E-Commerce Portal Call Center 2) “I don’t have it yet!” 1) “I want to buy it. ” 3) “When are you going to get it delivered? ” Parcel Service Customer

Zero or Low Data Latency • Just the old concept of timeliness with an additional twist • Refers to the real time (zero) or near-real time (low) transfer of information between applications • Zero data latency tends to imply transactional solutions, while low data latency or near-real time allows for assured delivery (messaging) options • Low data latency within the enterprise is no longer enough; it must be enabled across the enterprise perimeter

An Affirmation; Modeling the Problem • Adding EAI oriented solutions to the problem of data availability does not reduce the modeling effort required – it intensifies it • Each application view of the data must be defined and understood • Additionally the dependencies involved in sharing and transferring information must be supported • I find that use case modeling, at the level of the interapplication interfaces, is valuable for scoping the problem, and understanding it at a high level

Modes of Integration? A Functional View! Data Consistency Composite Application Multistep Process • Manual or straight-through • Batch or immediate transfers • Multiple processes • Multiple steps • One-way, asynchronous interactions (loosely coupled) • Systems are physically and logically independent flows • Batch or immediate, individual transfers • One business process • Multiple steps • One-way, asynchronous interactions (loosely coupled) • Systems are physically and logically independent § Potential long transactions • Immediate interaction • One business process • One step • Two-way, synchronous interactions (Tightly Coupled) • Systems are physically and logically dependent • Usually a client server (request reply) interaction

Front End versus Back End Integration • Front End Integration – Making Enterprise Resources available by means of tailored interfaces – Managing interaction between the enterprise and the user community – Providing gateways for information to and from enterprise systems • Back End Integration – Integration of various types among different enterprises resources (especially applications) – Back end applications collaborate to complete or realize a business process

Enterprise Integration (Internal & External) Backend Applications Automated Interfaces User Interfaces B 2 B B 2 C A 2 A Trend To XML WEB Services Specialized Application Interfaces Trend To XML

Front End Integration Connected To Multiple Back Ends Order Entry Inventory Wireless Device Presentation & Communications Portal Business Logic Browser Portal DB With Different Middleware Shipping Order Fulfillment “Typical” N-Tier Architecture

Critical Problems For Front End Integration • All the pieces of the n-tier application have to talk to one another • The various components may have different views of the information associated with the transaction • Must manage security (authentication and authorization); and e access to all of the back end resources involved • Typically, units of work must be supported over multiple resources (2 phase commit) • The solution as a whole must perform and scale

Back End Integration Customer Service SAP Order Entry Integration Engine People. Soft Invoicing WMS

Characteristics Of Back End Integration • Connectivity more of an issue at the back end • Complexity of interaction may be greater • Security, while always critical, is more easily managed • Timing is not as much of an issue; near real time is often good enough • Consequently, suitable for multi-step processes • Transactions (units of work) are often reduced in scope • …. . .

Integration: The Enterprise View Web Based Services

Integration Technologies & Techniques • Conventional Techniques – File Transfers & Distributed File Systems, RPC, Teleprocessing Monitors, Database Replication, RJE, Screen Scraping, …. . • Contemporary Techniques – Message Oriented Middleware – Web Enablement (Browser Based) – Distributed Objects – Integration Brokers – Document Centric Integration (XML)

Message Oriented Middleware (MOM) • Products that pass messages from a source to a destination • Fundamentally asynchronous in nature • Based on queues, explicitly or implicitly; requiring programming to load and unload msgs at either end • Rely on assured delivery, rather than transactions • Principally a point-to-point solution …. . • Not a lot of value added features originally …. . • MQ Series, MSMQ, Entire. X Broker, Sonic MQ …. .

MOM Example: MQ Series This diagram from IBM shows MQ Series communicating between two platforms. MQ Series itself manages the flow of msgs between the local queue and the remote queues; and does low level marshalling. The OS on the sending and receiving platforms may vary.

Distributed Objects (really Components) • COM/DCOM , CORBA, and Java RMI/IIOP • Enables processes to invoke methods on external components (perhaps on remote platforms) • Supports Component Based Development (CBD); with access to individual components only via interfaces • Method level, point to point, synchronous integration par excellence • Unmatched flexibility, but complex to implement • Supports strongly typed interfaces

A Trivial Distributed Object Implementation Customer RMI Client RMI Server RMI Interface Customer Account Manager RMI Skeleton RMI Stub Remote Reference Layer RMI Transport Layer Internet Protocol (IP) JDBC Sybase Distributed Objects Customer object calls the Account Manger with an Account ID. Manager retrieves the balance, and returns it to the Customer Object.

Integration Brokers • Use the Broker architectural pattern to implement and manage flows of msgs between apps and resources • Uses a MOM (often a JMS) Messaging Backbone • Have sophisticated capabilities for: – Connecting to applications (connectors or intelligent adapters) – Transforming and augmenting messages (applies business rules) – Content Based Routing • Have an enterprise scale orientation & focus – Connects multiple apps in multi-step integration flows • Offer assured delivery; are not transactional oriented

Broker Architectural Pattern Application API Application Screen Interface Database Integration Broker Directory Service Application Distributed Component Middleware Service Application Interface Object

Integration Brokers - Continued • Provide a number of value added features centered on scalability, reliability, connectivity and graphical implementation tools • Semantically operate very similarly to workflow engines or Business Process Management products • Goal is to engineer a connection between multiple enterprise resources, performing whatever processing necessary to ensure that the connection adheres to business rules • In other words, they implement what is in effect an integrated application, with a minimum of effort • Especially suited for back end integration • Low data latency solution

Simple Integration Broker Implementation

Document Centric Integration • XML Focus - SOAP/Biztalk; X-Bridge; Rosetta Net; …. • Integration through the transfer of XML “documents” between Enterprises, platforms, applications, …. • HTTP or HTTP/S is often used to transmit the documents over TCP/IP connections • Additional protocols or processing standards often used to manage the communication – Defined XML dialects, like Bi. Ztalk, Rosetta Net, eb. XML, …. . • Eliminates much of the technical complexity in communicating between environments and domains

Orchestrator/XML Architecture Rules Transform World Wide Web XML Log XML Replicate/ Aggregate Consumer (e. g. Browser) (e. g. Business Partner) Content Based Routing Gateway Consumer HTTP Consumer (e. g. Browser) XML Style Sheets Service Log XML

The Orchestrator/XML Solutions • Enables customers to dynamically compose new services in order to react to new business requirements • Provides a document driven reaction framework • Enables applications to be integrated in an XML way • Intelligent, flexible & scalable XML Routing Hub – Obtains an XML document – May transform it (based on style sheet) – Route document based on content (Content Based Routing) • Leverages XML-based and distributed-object technologies to provide enterprises with highly configurable and adaptable solution for integrating XML documents

Document Centric Integration: Order Entry Customer A Customer B Customers Submit XML Orders via HTTPS Server Submits Tracking Request & Returns Reply /XML Analyses Document, Transforms It, and Routes It to Services Web & Application Server Orchestrator /XML Java Server Order Tracking Java Server Order Entry Customer C Can configure this as a Web Service Server Redirects Orders To /XML Tamino Audit DB Server Converts & Edits Data, and Forwards It to Order Fulfillment

A Multi Step Integration Process Workflow Engine >> Price Policy Verify Credit (Java) SOAP HTTP/S Credit Bureau Web Service Issue Policy Invoice Policy (COM) Entire. X RPC Check Balance (Natural) Adabas Update Account (Natural) >>

Integration & Web Enablement

N-Tier Application For Product Distribution

Conclusions • Multiple EAI Techniques and Technolgies Available • In order to properly use them, modeling and planning is necessary • Properly used, they can substantially enhance data availability within the enterprise

• • • Task 2 (20%). Problem statement: The University offers a portal to support student access to their marks and to provide reading material for modules. This does not conform to good user interface practice and requires an excessive depth of “clicks” to access content while having an unreasonable response time, especially at peak periods and when accessed from outside the campus You have to: Design an enterprise computing system that would integrate the disparate applications within that university into a coherent whole. This should be a multi-tier architecture which is flexible in its support of various client programs which will handle interaction with users. Within this task you must: Draw a suitable diagram showing the most important software components of your design and how they interact with one another. Include both the components that you will design and build and third party components that will make your solution effective. (5%) List the main objects that would exist in your solution and show any primary keys and several important attributes for each. (5%) Explain how your design will be scalable and continue to work effectively under heavy loading, robust to hardware failure and offer extremely high levels of availability. (5%) Describe how your system would support fail-safe transactions and multiple simultaneous accesses? (5%)

• Task 3 (11%). • Beginning of problem statement: • Embedding database access code into in-memory objects can leave you with a fair few disadvantages. For a start it adds complexity. If your in-memory objects have business logic of their own, adding the database manipulation code is another aspect of complexity. Testing is awkward too, because if your in-memory objects are tied to a database tests are slower to run due to all the database access. You may have to access multiple databases with all those little annoying variations on their SQL. • End of problem statement: • Question: What pattern(s) have to be used to solve described problem? Draw diagrams and write needed code to show the pattern(s) solve the problem. Explain your answer.

• Task 3 (11%). • Beginning of problem statement: • Let’s imagine a company that sells three kinds of products: word processors, databases, and spreadsheets. The rules are that when you sign a contract for a word processor, you can book all the revenue right away. If it's a spreadsheet you can book one third today, on third in sixty days and one third in ninety days. If it's a database you can book one third today, one third in thirty days, and one third in sixty days. There is no basis for these rules other than my own fevered imagination. I'm told that the real rules are equally rational. • End of problem statement. • Question: What pattern(s) have to be used to solve described problem? Draw diagrams and write needed code to show the pattern(s) solve the problem. Explain your answer.