1 / 25

CS590L Distributed Component Architecture

CS590L Distributed Component Architecture. Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu www.sice.umkc.edu/~leeyu * This presentation is designed based on Michael Stal’s COM+, CORBA, EJB Presentations. Motivation.

elie
Télécharger la présentation

CS590L Distributed Component Architecture

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. CS590L Distributed Component Architecture Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu www.sice.umkc.edu/~leeyu * This presentation is designed based on Michael Stal’s COM+, CORBA, EJB Presentations

  2. Motivation • Driven by the Internet as well as mobile and embedded devices distributed solutions are now considered common place. • However, building distributed applications is a non- trivial task. • Thus, the question is: how can we efficiently build and deploy such applications? • Basic architectural understanding of OO Middleware. • Better leveraging Component Platforms.

  3. Distributed Applications

  4. Services of the Middle Tier • The services in the Middle Tier participate in different kinds of tasks: • They must participate in the workflow of integrated business processes. • They must connect to databases and other backend systems for data storage and service access.

  5. Services of the Middle Tier • Problem: Functionality in the middle tier is always subject to change and adaptation. It is used in unforeseen contexts (from different clients). • Solution: The middle tier should not be structured as a monolithic unit but rather be decomposed.

  6. Component-based Software • Components are the appropriate means for decomposition: • Presentation Tier components: • they typically represent sophisticated GUI elements. • they share the same address space with their clients. • their clients are containers that provide all the resources. • they send events to their containers. • Middle Tier components: • they typically provide server-side functionality. • they run in their own address space. • they are integrated into a container that hides all system details.

  7. Building distributed applications is complex • How to cope with heterogeneity? • How to access remote services in a location-transparent way? • How to handle (de-) marshaling issues? • How to find remote objects? • How to activate remote objects? • How to keep state persistent and consistent? • How to solve security issues? • Synchronous/ asynchronous communication?

  8. Distributed Objects are the answer • What we need is an architecture that ... • supports a remote method invocation paradigm • provides location transparency • allows to add, exchange, or remove services dynamically • hides system details from the developer

  9. Requirements for Distributed Component-based Applications • Transparent, platform-neutral communication. • Activation strategies for remote components. • Non-functional properties such as performance, scalability, Quality of Service. • Mechanism to find and create remote components. • Keeping state persistent and consistent. • Security issues. • Data transformation. • Deployment and configuration.

  10. Component/Container Approach • In order to shield components from the underlying infrastructure specifics, containers are introduced. • Containers: • manage components and notify components about events such as activation, passivation, transactions. • provide components access to services such as transactions, security, persistence. • help to register and deploy components.

  11. Application Servers (Servers+ Containers)

  12. Select the right standard • COM+, Windows DNA 2000, Microsoft. NET or • CCM (Corba Component Model), CORBA 3 or • EJB v2, J2EE Andrew Tanenbaum: “The best thing about standards is that there are so many to choose from“

  13. EJB 2.0 • There are three flavors of enterprise Beans: • A session bean type (mandatory for EJB 1.0 and EJB 1.1 compliant containers) • An entity bean type (mandatory in EJB 1.1 compliant containers) • A message bean type (mandatory in EJB 2.0 compliant containers)

  14. CORBA-3 • In the year 2000 the OMG has published CORBA 3 which offers solutions in the 3 areas: • Internet • Quality of Service • Components • With CORBA 3, the OMG offers a full range of enterprise technologies. • the specification of CCM (Corba Component Model), 11/2001 • Interoperability (COM, EJB) • Portable Object Adapter (POA)

  15. CORBA Architecture

  16. COM+ • First of all: COM+ = COM + Services • COM+ is MTS 3.0 • It is integrated to Windows 2000 • It contains a lot of services such as • Transaction Serrvices (MTS) • Security Services • Synchronization Services • Queued Components • Event Service • COM+ Catalog = RegDB + Registry

  17. COM+ Architecture

  18. Middleware Comparision-1

  19. Middleware Comparision-2

  20. Middleware Comparision-3 IIOP: Internet Inter-Orb Protocol, OTS: Object Transaction Services, JTS: Java Transaction Services, MTS: Microsoft Transaction Services ADSI: Active Directory Service Interfaces JNDI: Java Naming and Directory Interface AMI: Asynch Messaging Interface

  21. Middleware Comparision- 4 UPnP: Universal Plug and Play

  22. Universal Plug and Play • an architecture for pervasive peer-to-peer network connectivity of PCs of all form factors, intelligent appliances, and wireless devices. • a distributed, open networking architecture that leverages TCP/IP and the Web to enable seamless proximity networking in addition to control and data transfer among networked devices in the home, office, and everywhere in between. • MS XP support for UPnP Internet gateways, providing broadband users for online games, videoconferencing and other peer-to-peer services.

  23. JINI/JXTA • Jini: an open architecture that enables developers • to create network-centric services that are highly adaptive to change. • to build adaptive networks that are scalable, evolvable and flexible as typically required in dynamic computing environments. • JXTA: • a set of open, generalized peer-to-peer (P2P) protocols, defined as XML messages, that allow any connected device on the network ranging from from cell phones and wireless PDAs to PCs and servers to communicate and collaborate in a P2P manner. • JXTA peers create a virtual network where any peer can interact with other peers and resources directly even when some of the peers and resources are behind firewalls and NATs or are on different network transports.

  24. References • Henning, Vinoski: Advanced CORBA Programming with C++, Addison- Wesley, • 1999. • Donald Box: Essential COM, Addison Wesley, 1998. • Chappel, Understanding Windows 2000 Distributed Services, Microsoft Press, 2000. • Rofail, Shohoud, COM and COM+, Sybex, 2000. • Buschmann, Meunier, Rohnert, Sommerlad, Stal: Pattern- Oriented Software Architecture - A System of Patterns, Wiley, 1996. • Schmidt, Stal, Rohnert, Buschmann: Pattern- Oriented Software Architecture 2 – • Patterns for Concurrent and Networked Objects, Wiley, 2000. • Gamma, Helm, Johnson, Vlissides: Design Patterns - Elements of Reusable Object-Oriented Software, Addison Wesley, 1995.

More Related