Lecture 11: Distributed Systems, Web Technology, Middleware 1
1. Client-Server Systems 2
Why Client-Server Architecture? A convenient way to split responsibilities Implies a logical modularization Improves reuse May improves extendibility Allows combination of multiple technologies. . . 3
Client-Server means. . . Collaboration of two or more software systems through a common interface One software system providing services to others (this role distribution may change at any time) 4
Client-Server does not mean. . . A mandatory network connection between client and server In fact, client and server can reside n n Within the same process In collaborating processes In collaborating systems Somewhere in outer space 5
Client-Server -- complicated. . . Roles may not be “globally” assigned but depend on function Example: Model-View-Controller Architecture n n n Controller: Always client View: Always server Model: Server to Controller, Client to View 6
Client-Server -- complicated. . . Client-Server 7
2. Integration Scenarios 8
Three Organizational Forms … will be analyzed in the following: Simple Business Relationship Distributed Enterprise Virtual Enterprise 9
Case 1: Simple Business Relationship Limited or no processing power at the user / customer site Process fully under control from the service provider site Isolation through a firewall 10
Case 2: Distributed Enterprise Comparable processing power at all sites of the distributed enterprise Process control may be distributed or centralized Geographical / logical separation, but no security barrier 11
Case 3: Virtual Enterprise Comparable processing power at all sites of the virtual enterprise Process control usually distributed Geographical / logical and security separation Communication through public network 12
The Current Communication … between business partners, as found in the industry praxis will be analyzed in the following. n n n Message-based technology CORBA Web technology 13
Message-based Technology (EDI, EDIFACT, Message Queues, etc. ) Advantages n n well established in industry re-use of existing transports (e. g. E-Mail) Disadvantages n n no integration at all limited capabilities complicated handling no process or transaction management 14
CORBA Advantages n n n well established and standardized available for all “serious” platforms very rich service portfolio very good integration support process and transaction management supported through services Disadvantages n requires a common run-time environment 15
Web Technology Advantages n n n very lightweight technology no special run-time software required (at this time) simplified firewall penetration Disadvantages n n n very little integration capability no process or transaction management unreliable 16
Technology Combinations … are shown in the following slides, which support the previously discussed three integration cases best n n n Simple Business Relationship Distributed Enterprise Virtual Enterprise 17
Case 1: Simple Business Relationship Web technology (http-based) CORBA technology (GIOP-based) 18
Case 2: Distributed Enterprise CORBA technology (GIOP-based) or Web technology (http-based) 19
Case 3: Virtual Enterprise CORBA technology (GIOP-based) Web technology (http-based) 20
Ideal Technology Combination Transparent multi-protocol communication n Intra-enterprise support w tightly coupled - IIOP w loosely coupled asynchronous - JMS w loosely coupled synchronous - HTTP/SOAP n Inter-enterprise support w loosely coupled synchronous - HTTP/SOAP Service definition language (SDL) UDDI for Discovery/Registration 21
Process Integration In many cases, a common runtime infrastructure does not exist (e. g. CORBA to CORBA via IIOP) Solution: Introduction of portals who act as information gateways Using self-describing message formats 22
Solution: Portals act as gateway for information and process management communication Portals translate between different integration protocols Portals represent the boundary of an integration domain Portals can provide a perfect encapsulation of the integration domain Portals support security 23
Example: Virtual Enterprise A C B = Portal 24
Example: Virtual Enterprise A Information C B = Portal 25
Example: Virtual Enterprise A Processes C B = Portal 26
3. World Wide Web Technology 27
What is “The Web”? A globally available communication infrastructure build on top of an open network system A totally decentralized information system A system relying almost exclusively on sourcebased navigation techniques A system united by a common transport protocol (http) 28
Why became the Web so popular? Low infrastructure requirements due to very restricted set of transfer formats: n n textual information small set of graphic image formats Information is easy to compose, locate and retrieve – no programming required 29
Web Evolution (1) Hypertext Markup Language developed as a subset of SGML with the ability to link documents across files (on same file system) Development of HTTP to extend hyperlinks across a network (CERN) [at this time no real navigation capability existed] 30
Web Evolution (2) Development of network- and navigationcapable hypertext reader, now called “Web Browser” Development of HTTP-based (hypertext) file server, now called “Web Server” 31
Web Evolution (3) Development of Java as “the language for the Web”, loosely based on C++ syntax and CORBA object model Development of Java Applet technology as shielded executable client (browser) extension Development of “CGI” server execution escape technique Inclusion of FTP capabilities Helper applications 32
Web Evolution (4) Standardized formatting extensions: Cascading Style Sheets (CSS) Standardized definition language: Web Services Definition Language (WSDL) Standardized remote invocation: Simple Object Access Protocol (SOAP) Security extensions 33
Web Communication Characteristics Connectionless Stateless Asymmetric Unreliable Unpredictable Requires only name resolution as higher-level service But imposes a high network load 34
Success Catastrophe Server environment dimensioned for medium-size traffic Steady but reasonable traffic increase, no problem for environment Popular web site publishes link to this site Traffic increases exponentially, server environment cannot keep up: Bad response times, dropped connections Most users turn away dissatisfied – traffic may drop below initial volume…. 35
Web Improvements (client side) Caching in the client application (browser) reduces network load but may present outdated information [user-correctable] Proxy server improve security, allow access filtering and act as global cache (reducing network load substantially, but may also present outdated information [not usercorrectable] 36
Web Proxies Proxy Server 37
Web Improvements (server side) Mirror sites help to achieve geographic load distribution, but rely fully on user-cooperation Cascading servers can improve “response feeling” substantially Cascading servers may be used for automated redirection to mirror sites 38
Simple Web Server Lowest cost Easy to maintain Typical “entry” solution Significant capacity limitation Interference between Web and Application 39
Separate Web and FTP Server Web Server FTP Server Low cost solution for download-centric application domains Increased, but still limited capacity 40
Separate Web and CGI Server Web Server Script Server Low cost solution for application domains requiring significant preprocessing of downloads Distributed load, but still limited capacity 41
Front-End / Back-End Server Web Server (1) Cost-effective solution for processing-intensive application domains Distributed load, but still limited capacity Has growth potential Application Server 42
Front-End / Back-End Server Web Server Application Server (2) Attractive solution with good growth potential Clearly distributed and balanceable load Application server must be Web-enabled Limited to single-site 43
Multi-Stage Server Web Catcher Web Server Application Server Web Server (1) Powerful solution with high growth potential Clearly distributed and balanceable load Separation between Web and Application Multi-site capable Application Server 44
Multi-Stage Server Web Catcher Web Server Application Server (2) Catcher accepts connection and relays to appropriate Web Server establishes session, does any checks if required Web Server may transfer session to different Web Server, if required Final Web Server queues request at Application Server By-request switch of Application Server possible Communication usually handled by Web Server 45
4. The new Buzzword: Web. Services 46
Web. Services Definition still fuzzy In general a higher-level service provided to the client through a Web infrastructure Requires a richer infrastructure than just a Web server Will become the future direction for Webenabled service environments 47
Web. Services – General Idea Make complex and/or heavy-weight services available through a lightweight Web infrastructure Make an even very complex service environment appear like a single, easy set of Web pages Make crossing of computing/integration paradigms easy and transparent 48
XML Data Definition and Exchange Language Flexible, extensible A profile of SGML Syntax (tags) definable through Document Type Definition (DTD) or XMLschema Bound to character data 49
Web. Services – External View Client Web Server 50
Web. Services – Internal View Client (1) Reveal the actual services behind the Web Server facade Identify the internal infrastructure Connection to the Web is still a question 51
Web. Services – Internal View Application System Client Application System (1) Application System Infrastructure Application System 52
Web. Services – Internal View Client (2) Solve the connectivity to the Web by introducing an Integration Server It bridges the gap between Web and internal infrastructure It is responsible for the Web presentation 53
Web. Services – Internal View Application System Client Integration Server Application System (2) Application System Infrastructure Application System 54
Web. Services – Internal View Client (3) Introduce a Business Process Management System into the infrastructure Every Web-visible action should be backed by a business process 55
Web. Services – Internal View Application System Client Integration Server Application System (3) Application System Process Management System Application System 56
Look Inside a Portal Directory Service Application Portal Server (Protocol translation) Message Routing & invocation Process Routing & enactment Application Integration Domain 57
Portal Server Translates between the external and internal message protocol Provides a virtual view of the services available in the integration domain Cooperates with a firewall if necessary Supported protocols: n n n GIOP / IIOP HTTP / XML / SOAP JMS 58
Message Router & Invocation Routes incoming messages to the requested server Supports method or service invocations on the requested server Note: A single request can result in invocations on multiple servers Service requests may be delegated to other portals / domains 59
Process Routing & Enactment Contains a process management (“workflow”) engine Interacts with process engines inside and outside the integration domain Controls the execution of active process instances May have its own process definition and state repository 60
Directory Service Provides look-up service for information, services and resources May be implemented through CORBA services (Naming, Trader, etc. ) or LDAP and UDDI (or any combination) The directory service may have its own information repository 61
Further Services Transactional behavior can be achieved using the Object Transaction Service and implementations of the Activity Specification The Portal Server can act as Web Server, transforming information and invocation results from the integration domain into virtual web pages …. 62
5. Simple Object Access Protocol (SOAP) 63
SOAP Overview Based on XML Uses HTTP as transport protocol (limited) RPC capability Limited to character data No marshalling Message consists of envelope, header and body (“payload”) 64
SOAP Message Envelope Header (optional) Body 65
SOAP Request Message POST /Stock. Quote HTTP/ 1. 1 Host: www. stockquoteserver. com Content-type: text/xml; charset=“utf-8” Content-Length: xxx SOAPAction: “some. URI” <SOAP-ENV: Envelope xmlns: SOAP-ENV=“http: //schemas. xmlsoap. org/soap/envelope/” SOAP-ENV: encoding. Style= “http: //schemas. xmlsoap. org/soap/encoding/”> <SOAP-ENV: Body> <m: Get. Last. Trade. Price xmlns: m=“some. URI”> <symbol>DIS</symbol> </m: Get. Last. Trade. Price> </SOAP-ENV: Body> </SOAP-ENV: Envelope> 66
SOAP Response HTTP/1. 1 200 OK Content-type: text/xml; charset=“utf-8” Content-Length: xxx <SOAP-ENV: Envelope xmlns: SOAP-ENV=“http: //schemas. xmlsoap. org/soap/envelope/” SOAP-ENV: encoding. Style= “http: //schemas. xmlsoap. org/soap/encoding/”> <SOAP-ENV: Body> <m: Get. Last. Trade. Price. Response xmlns: m=“some. URI”> <price>34. 5</price> </m: Get. Last. Trade. Price. Response> </SOAP-ENV: Body> </SOAP-ENV: Envelope> 67
6. Common Object Request Broker (CORBA) 68
CORBA Characteristics Object-oriented client server middleware Based on remote method invocation Perfect encapsulation – only interfaces exposed Location transparent Independent from programming languages and operating systems High performance, high reliability Very broad collection of service offerings 69
CORBA Architecture Server functionality implemented as ordinary programming language object, called “Servant” Interface(s) represented through an “Interoperable Object Reference” (IOR) – sort of a network transparent smart pointer IORs created and managed in the server via the Portable Object Adapter (POA) Client invokes methods by using the IOR 70
CORBA Architektur Server request OR Core POA OR Proxy Client Servant 71
Service Description: IDL (1) Services are defined using the Interface Description Language IDL has mainly C++ syntax (but different keywords) IDL is a specification language, not a programming language (no computational operations) IDL compiler generates all required support components 72
Service Description: IDL (2) WARNING: IDL is case-preserving (Case doesn’t matter, but must always use one spelling): Myinterface M My. Interface M MYINTERFACE module my_module { interface My. Interface : Super. Interface { void example. Oper(in Object the. Object, out String the. String, inout float some. Number) raises (My. Exception); }; }; 73
Portable Object Adapter (POA) Clear separation of: n n CORBA Object Reference Servant Object ID Persistent/Transient CORBA Objects A single Servant may serve multiple Objects local/remote: makes no difference 74
Local vs. Remote Server request OR Core POA Proxy Client request OR Servant 75
POA Policies Life. Span. Policy (persistent / transient) Id. Assignment. Policy (user / system) Id. Uniqueness. Policy (relationship IOR servant) Implicit. Activation. Policy (poa can activate servant) Request. Processing. Policy (active object map / default servant / servant manager) Servant. Retention. Policy (retain or not) Thread. Policy (multithreaded / single-threaded) 76
POA Architecture ORB Root POA Child POA 77
A Word about Threading Default POA Policy: multi-threading (ORB_CONTROLED_MODEL) Critical Applications may need single-threading Threading policies may be mixed in single server Threads might not always be a performance gain! Optimizing: Threadpool 78
Server Architectures (1) Server request OR Core POA OR Proxy Client Servant 79
Server Architectures (2) Default Servant Eliminates run-time creation overhaed Only useful for simple applications No dynamic modifications 80
Server Architectures (3) Servant Activator Servant creation and activation separated Good dynamic behavior Relatively fixed service structure 81
Server Architectures (4) Servant Locator Servant creation and activation overhead outside of server mainstream Very dynamic Implementation may be altered at any time Supports server optimization strategies (e. g. Evictor Pattern) 82
Minimum CORBA Absolute minimum specifikation No dynamic invocations No dynamic skeletons No dynamic Any Very few services Intended for low-footprint embedded systems Suitable to be packed in read-only memory (ROM) 83
Realtime CORBA Full CORBA functionality In addition: Priority management Deadline handling Dynamic Scheduling Exchangeable transports … 84
Advanced CORBA Features Reliable asynchronous invocations Server load balancing Interoperable security protocol Portable interceptors Value Types CORBA Component Model … 85
Load Balancing & Fault Tollerance request OR Locator Daemon Proxy Client 86
CORBA Portable Interceptor Requests processing inside the ORB Core Very powerful mechanism to realize special services or protocols Two kind of Interceptors: n n Request Level Interceptor (server/client) IOR Interceptor “Current” object transports context 87
Interceptor Architecture Client Target Object Request Level Interceptor IOR Interceptor 88
Value Types Transporting only state of Object Local copy of object will be initialized with state Local copy has own identity Value Types are not CORBA objects Operations on Value Types are guaranteed local 89
CORBA Services (1) Naming, Trading Support for location and discovery of services Naming is simple and lightweight Trader provide sophisticated hierarchical organization 90
CORBA Services (2) Event Service Logical bus (Event Channel) Events emitted “blind” Interested parties may subscribe for a specific or all events 91
CORBA Services (3) Messaging Reliable asynchronous invocations Results transmitted via client polling or callback invocations 92
CORBA Services (4) Persistent State Service Provides persistent storage of object state Powerful service for high reliable applications and as starting point for database interfaces 93
CORBA Services (5) Object Transaction Service Provides CORBA Objects with transparent transaction capabilities Supports 2 -Phase Commit Protocol Supports X/Open interfaces Transaction context automatically inserted into requests (via interceptor) 94
References 1. Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e by R. S. Pressman. Copyright © 1996, 2001 R. S. Pressman & Associates, Inc. 2. Core Java 2, Volume 1 – Fundamentals, Cay Horstmann & Gary Cornell 3. Advanced CORBA Programming with C++, Michi Henning & Steve Vinoski, Addison Wesley 4. www. omg. org (OMG Home Page) 95
Скачать презентацию Lecture 11 Distributed Systems Web Technology Middleware 1
a6644d6951dcfdcde4b67e05b18b8637.ppt