1 / 34

Chapter 5

Chapter 5. Middleware. Middleware. Software: in context of smart environment Software to provide services to facilitate Rapid development Ease of integration Improved reliability Increased scalability Lies between applications software & platform

judith
Download Presentation

Chapter 5

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. Chapter 5 Middleware

  2. Middleware • Software: in context of smart environment • Software to provide services to facilitate • Rapid development • Ease of integration • Improved reliability • Increased scalability • Lies between applications software & platform • Connectivity software that joins applications thru communication mechanisms creating transparency, scalability, & interoperability

  3. Middleware • Defined by API it provides to applications that use it & by protocols it supports • Should reduce complexities • Of networks, OS, applications • Should provide cross-platform infrastructure • Should improve the system

  4. Overview of Middleware • Understanding of Middleware • Desirable characteristics • Different forms • Advantages/disadvantages • Technologies • Standards • Benefits * Provide a working knowledge base *

  5. Perceive-Reason-Act AI Approach • Use to define characteristics of Middleware • Perceive: sensors • Software to read, store, calibrate, etc. • Reason: AI applications • Software to reason about the environment & provide actions • Act: controllers • To change environment See Figure 5.1, pg. 104 What are the communications requirements?

  6. Needs of System(Figure 5.1) • Interoperability: 2+ entities communicate • Reliability: guarantee delivery • Efficiency: minimize consumption & delivery time • Throughput: lots of data, no bottlenecks • Distributed network: applications not on single computer

  7. Wants of System • Provide for future extensions & contingencies • Scalable • Hot - swappable - don't shut down to change component or application • Secure • Highly available - running, accessible • Fault - tolerant

  8. Desirable Characteristics of System • Simplicity and power: for developers & for API • Natural & seamless extension of development environment: for implementer - so focus stays on application • Flexibility for easy modifications of software - separation of interface from applications • Maintainability • Reusability • Portability

  9. Middleware Architecture • Communication is the focus • Client - server model (Figure 5.3, pg. 107) • 3-tier for much Middleware • Middle tier addition • Increase in number of clients • Better flexibility, maintainability, reusability, scalability

  10. Forms of Middleware • Middleware sits between OS & application • Huge number of products • Vary in "form" • Role, terminology, composition • Overview of key forms • Transaction -- Object • RPC -- Agent • Message -- Database • Web

  11. Transaction Processing • Middle tier of processing routines between system that provides transaction-based services & clients • e.g.: ATM - deposit, withdraw, check balance • See Figure 5.4, pg. 109 • Advantages • Independence of layers, database • Easily customized on all components • Transparency • Mature & well-tested efficient, reliable

  12. Transaction Processing • Disadvantages • Limited scalability - each client (ATM) adds overhead • Older - uses low-level languages • Examples: IBM's CISTP, BEA TUXEDO

  13. Message-Oriented (MOM) • Provides communication between applications on one or more machines; different platforms (Figure 5.5, pg. 109) • Generally asynchronous • Message queuing, persistence (delays), delivery • Peer-to-peer connectivity; agreed upon protocols

  14. Message-Oriented (MOM) • Advantages • Simplifies cross-platform issues; portability • Increased operability, flexibility • Good for event-driven systems • Mature (1980's) • Disadvantages • Asynchronous allows for network overload • Not implemented for some platforms • Example: Oracle, Advanced Queuing, Arjuna Messaging, IBM MQ Series, MS MSMQ

  15. Object-Orientedaka Object-Oriented Brokers (ORB) • Transparent extensions of object-oriented development environment, • Figure 5.6, pg. 110 • Support: interface definition language, O communication mechanisms, O activation/location mechanisms • Facilitate: locating objects & establishing communication - similar to MOM

  16. Object-Orientedaka Object-Oriented Brokers (ORB) • Advantages - Same as MOM • Familiarity with object-oriented environment • Provide for rapid integration • Preserves separation between implementation & interface • Disadvantages • Different ORB's support different levels of service, platforms, certain object-oriented languages • May be difficult to find one that supports all needs • Examples: OMG's CORBA, MS COM/DCOM, Sun's JAVA RMI

  17. Database • Can be complex • Need API access to standard database interfaces • Development connectivity tools & language extensions to facilitate applications to database • Advantages • Standardization, simple • Disadvantages • Not always cross platform • May not support advanced database features • May provide blocking, synchronous connections

  18. Remote Procedure Call (RPC) • Stubs embedded in client-server applications at compile, facilitate calls between client-server (Figure 5.7, pg. 111) • Advantages • Provide consistency of procedure calls locally & remotely • Network transparency of client-server location • Disadvantages • Most are synchronous - forces call-wait scenario, possible blockages • Asynchronous mechanisms add complexity to development • Synchronous - not good for object-oriented or peer-to-peer • Example: Open Group's Dist. Computing Environment

  19. Web Services • Popular - bridge interface gap between application hidden by network security (e.g. firewalls) • Leverages WWW technologies & protocols (Figure 5.8, pg. 112) • XML interface • HTTP communications • New technologies • SOAP - Simple Object Access Protocol • WSDL - Web Services Definition Language

  20. Web Services • Advantages • Ubiquitous nature of web servers/API's • Available software to facilitate development • ASCII-based messages improve troubleshooting • Most corporate systems allow such traffic • Easy transition

  21. Web Services • Disadvantages • Potential security holes (HTTP) • Conversion of data structures to SML is computationally expensive; data structure is larger • Slower • Needs more bandwidth • Examples: Apple's Web Objects, IBM Websphere, MS.NET, Sun's Open Net Environment

  22. Agent-Oriented • Applications: financial management, military logistics, personal information management • Newest: Intelligent software agents • Autonomous, intelligent software entities with ability to perceive environment, reason, act (to accomplish goals) • Tend to be implemented as frameworks

  23. Agent-Oriented • Provide for • Interagent communication • Load balancing • Mobility (move agents between machines) • May include MOM or Object-Oriented Middleware • Examples: HIVE, CMU's RETSINA

  24. Frameworks • Similar to but different from Middleware • Targeted at specific domain • Provide API, user interface, tools for development & management • May provide own middleware services or utilize common ones • Examples: Lotus Notes, MS Office, Transarc's Encina, Cognos, HP's OpenView

  25. Frameworks - Comments • Framework vs. Middleware: not standard, debated • Author distinguishes: • Middleware: invisible, no interface • Framework - provides interfaces • Ubicomp - ubiquitous computing • Numerous initiatives • e.g., Universal plug-and-play

  26. Middleware Standards • Help with functionality, interoperability among implementers • Consortiums (IEEE) - compromise, voluntary • Corporations - de facto standards; market share, influence • e.g., IBM PC; MS Windows

  27. Standards - Examples • COM/DCOM - MS - de facto • Distributed Component Object Model • Communication protocol between objects • IDL - Interface Description Language • CORBA - Object Management Group - consortium • Common Object Request Broker Architecture • Powerful, Widely-used • Uses IDL-to-program language mapping for many object-oriented language; generate skeleton & stub code

  28. Standards - Examples • DCE - Open Group • Distributed Computing Environment • Popular, forms basis of many middleware layers • Set of integrated system service specs.; OS, platform, network independent • Provide: RPC, distributed file system, diskless workstation support

  29. Java Middleware Technologies - Sun Numerous middleware initiatives & support • Supports CORBA • J. Remote Method Invocation (RMI) - CORBA like • J. Message Service (JMS) - provides MOM • J. Web Services Developer Pack (WSDP) - to integrate webservices into J. applications • J. Servlet & J. Server Pages (JSP) - extend server functionality, dynamic content support • J. Jini - adaptive network-centric applications • Disadvantage: One source, one language

  30. Web Service Standards World Wide Web Consortium (WSC) - a leader • HTML, HTTP, SML, SOAP/SMLP, WSDL, others Organization for Advancement of Structured Information Standards (OASIS) • DocBook (documentation), DSML (directory services), ebXML (eBusiness), SAML (security assertion), UDDI (universal description, discover, & integration of web services)

  31. Database Standards • SQL (Structured Query Language) - Oracle • Based on IBM's SEQUEL of 1970's • de facto standard • Are non-standard extensions • ODBC - Open Database Connectivity - MS • middleware database driver: database - applications communication • Vendors: ODBC-compliant database • Sun's JDBC for Javas is ODBC - comp.

  32. Middleware Design Considerations • Complement project, easier to design, develop, & maintain • Interoperability, reliability, efficiency throughput • Secure, dynamic, adaptable, scalable, available, fault-tolerant • Flexible, portable, maintainable, reusable

  33. Middleware Issues • May add unwanted infrastructure to project • Risky when using proprietary middleware (if sole source) • Extensions: Open Source vs. Proprietary • Middleware defined by API & protocols • Be wary of proprietary extensions • Shift from OS/Platform dependence to middleware dependence • Projects look to middleware for services

  34. Middleware Conclusion • See 5.6, pg. 119+ for examples • Middleware provides variety of services • Applicable to Mobile Computing and Smart Environments

More Related