1 / 80

COMS W4156: Advanced Software Engineering

COMS W4156: Advanced Software Engineering. Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://bank.cs.columbia.edu/classes/cs4156/. Topics covered in this lecture. COM MTS adds component services COM+ adds more component services .NET and Enterprise Services. COM.

Download Presentation

COMS W4156: Advanced Software Engineering

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. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://bank.cs.columbia.edu/classes/cs4156/ COMS W4156

  2. Topics covered in this lecture • COM • MTS adds component services • COM+ adds more component services • .NET and Enterprise Services COMS W4156

  3. COM COMS W4156

  4. Component Object Model (COM) • COM specifies an object (or component) model, and programming and compiler requirements, that enable COM objects to interact with other COM objects • A COM object is made up of a set of data and the functions that manipulate the data • A COM object’s data is accessed exclusively through one or more sets of related functions called interfaces • COM requires that the only way to gain access to the methods of an interface is through a pointer to the interface • Interfaces defined in Microsoft Interface Definition Language (analogous to CORBA IDL, but NOT the same) COMS W4156

  5. Component Object Model (COM) • COM is a binary standard—a standard that applies after a program has been translated to binary machine code • COM methods and interfaces must follow a prescribed in-memory layout • Objects can be written in different languages, including languages that don’t have “objects” COMS W4156

  6. COM Interfaces • COM allows objects to interact across process and machine boundaries as easily as within a single process • Marshalling/demarshalling method parameters and return values across process and machine boundaries handled by operating system (in Windows COM implementation) • COM enables this by specifying that the only way to manipulate the data associated with an object is through an interface on the object • “Interface” here refers to an implementation in code of a COM binary-compliant interface that is associated with an object COMS W4156

  7. COM Interface Based on but Different from C++ Interface • COM uses the word interface in a sense different from that typically used in C++ programming • A C++ interface refers to allof the functions that a class supports and that clients of an object can call to interact with it • A COM interface is a pure virtual definition that carries no implementation • A COM interface refers to a predefined group of related functions that a COM class implements, but a specific interface does not necessarily represent allthe functions that the class supports • Represented as a “vtable” (as in C++) COMS W4156

  8. Vtable Layout Kaiser: COMS W4156 Fall 2007

  9. Calling an Interface Method • With appropriate compiler support (inherent in C and C++), a client can call an interface method through its name, rather than its position in the array • Because an interface is a type, the compiler - given the names of methods - can check the types of parameters and return values of each interface method call • In contrast, if a client uses a position-based calling scheme, such type-checking is not available COMS W4156

  10. COM Clients and Servers • A COM client is whatever code or object gets a pointer to a COM server and uses its services by calling the methods of its interface(s) • A COM server is any object that provides services to clients • These services are in the form of COM interface implementations that can be called by any client that is able to get a pointer to one of the interfaces on the server object COMS W4156

  11. Server vs. Client Views Kaiser: COMS W4156 Fall 2007

  12. Types of COM Server • An in-processserver resides in a dynamic link library (DLL) and runs in the same address space as the COM client • A localserver resides in its own executable (e.g., *.exe file), in a different process but on the same machine as the COM client • A remote server runs on a different machine than the client COMS W4156

  13. COM Processes COMS W4156

  14. Same Machine • For clients and servers on the same machine, the CLSID of the server is all the client ever needs • On each machine, COM maintains a database (using the system registry on Windows) of all the CLSIDs for the servers installed on the system • This is a mapping between each CLSID and the location of the DLL or EXE that houses the code for that CLSID • COM consults this database whenever a client wants to create an instance of a COM class and use its services, so the client never needs to know the absolute location COMS W4156

  15. Different Machines • For distributed systems, COM provides registry entries that allow a remote server to register itself for use by a local client • Applications need know only a server's CLSID, because they can rely on the registry to locate the server • However, COM allows clients to override registry entries and specify server locations COMS W4156

  16. COM vs. DCOM • COM client applications do not need to be aware of how server objects are packaged, whether they are packaged as in-process objects (in DLLs) or as local or remote objects (in EXEs) • Distributed COM (DCOM) is not separate—it is just COM with a longer wire COMS W4156

  17. COM Limitations • Like CORBA: No support for common programming idioms (other than RPC) • Unlike CORBA: Has one “main” implementation - from Microsoft for Windows, so by definition “compatible” • Needs component services: distributed transactions, resource pooling, disconnected applications, event publication and subscription, better memory and processor (threads) management, … COMS W4156

  18. COM + MTS COMS W4156

  19. Microsoft Transaction Server (MTS) • Enables the transactional requirements of each component to be set administratively, so components can be written separately and then grouped together as needed to form a single transaction COMS W4156

  20. What Transactional Requirements? • Many applications write to some database(s) or other data repository(ies) • An application that makes more than one change to a database may want to group those changes into a single unit – called a transaction • The goal is to make sure that either all of those changes take place or that none of them do—a mix of success and failure isn’t possible COMS W4156

  21. What is a Transaction? • “ACID” properties • Atomicity (all or nothing) • Consistency (no integrity constraints violated) • Isolation (no other computation sees intermediate states, more formally = serializability) • Durability (persistence = failure recovery) • Component model frameworks generally only concerned with atomicity and durability COMS W4156

  22. Handling Transactions within One Data Source • If all the data accessed are contained in a single database, the database itself probably provides transactions • The programmer need only indicate when a transaction begins and when it ends • The database will make sure that all data accesses within these boundaries are either committed or rolled back COMS W4156

  23. Handling Transactions Across Multiple Data Sources • The problem gets harder when an application accesses data contained in more than one database or involves other data resource managers such as a message queue • It’s probably not possible for the transaction support built into any one of those systems to coordinate the commitment or roll-back of all data accesses • Need some kind of independent transaction coordinating service COMS W4156

  24. What does the Transaction Coordinating Service do? • Two-Phase Commit • First phase: transaction coordinator asks every resource manager (e.g., database) involved in the transaction if it’s prepared to commit • Second phase: • If every resource manager says yes, then the transaction coordinator tells each one to commit • If one or more of the resource managers involved in this transaction is unable or unwilling to commit (or does not respond within a timeout period), the transaction coordinator tells all of them to roll back the transaction COMS W4156

  25. MTS Executive and Distributed Transaction Coordinator (DTC) • Invisible to a client, client sees just an ordinary COM object exposing some number of interfaces • Executive intercepts every call the client makes on the objects it controls • DTC manages the two-phase commit COMS W4156

  26. MTS Application Structure COMS W4156

  27. Two-Phase Commit • OLE = Object Linking and Embedding COMS W4156

  28. Context Object • Every object involved in a transaction is associated with a context object • If a transaction needs to span the functions of multiple different objects, then same context object coordinates the activities of all of those objects • Allows the transaction semantics to be separated from application code COMS W4156

  29. Automatic Transactions • In traditional transaction systems, the application code indicates when a transaction begins and ends • MTS also supports automatic transactions, allowing business logic to remain unaware of when transactions start and end COMS W4156

  30. Transaction Semantics Defined Declaratively • Transaction semantics declared when components are assembled into an application package • Each component is assigned a transaction attribute, one of four values: • Required • Requires New • Supported • Not Supported COMS W4156

  31. Transaction Options • REQUIRED - The component must execute within the context of a transaction, although it does not care where the transaction context originates • If the caller has a transaction (context object), then the called component will use the existing transaction • If the caller does not have a transaction, then MTS automatically creates a new transaction context for the component COMS W4156

  32. Transaction Options • REQUIRES NEW - indicates that the component must always establish its own transaction context • Regardless of whether or not the calling application has a transaction context, MTS automatically creates a new transaction context object for the component COMS W4156

  33. Transaction Options • SUPPORTED - indicates that the component does not care whether or not there is a transaction context in place • NOT SUPPORTED - indicates that the component cannot support a transaction COMS W4156

  34. Commit or Abort • The component operating on the database can tell the MTS executive when its task is complete • Everything has gone just fine and the transaction is ready to be committed – the component calls IObjectContext::SetComplete (or just returns) • Something has gone wrong, perhaps one attempt to access data resulted in an error, and the entire transaction should be rolled back – the component calls IObjectContext::SetAbort (or just crashes, hangs, etc.) COMS W4156

  35. Coordination of Multi-Component Transactions • Calling SetComplete does not necessarily mean that the transaction will be committed right then • If this component implements all the work required for an entire transaction, then MTS will perform the commit COMS W4156

  36. Coordination of Multi-Component Transactions • But this component may be part of a group of components, all of which collectively participate in a single transaction • Each component will call SetComplete (or terminate) when its work is done, but MTS won’t begin the commit process until all components within the transaction have completed successfully • The code for the component looks the same in either case COMS W4156

  37. And a few other services… COMS W4156

  38. Just-In-Time (JIT) Activation • Also known as deferred activation • When a client makes a call to an object to create an instance, COM provides that client a reference to a context object instead of a reference to the object • Client gets a real reference to the object, and the object is activated, only when client calls a method of that object • Object deactivated when method returns and reactivated when next method called • Deactivated object releases all resources, including locks on data stores • Allows server resources to be used more productively COMS W4156

  39. Object Pooling • Recycling of objects • When a client releases an object that supports object pooling, or such an object is deactivated, instead of destroying that object completely, COM+MTS recycles it • When another client requests or reactivates the same kind of object, COM+MTS gives an instance from the pool • Since these component instances are already loaded in memory (up to maximum size of pool), they are immediately available for use • If you intend to make only one call at a time on a pooled object, it is a good idea to enable JIT activation without object pooling; if you intend to get a reference and make multiple calls on it, using object pooling without JIT activation may result in better performance. COMS W4156

  40. Connection Pooling • Opening and closing connections to a database can be time-consuming • Reuse existing database connections rather than create new ones • A resource dispenser caches resources such as ODBC (Open DataBase Connectivity) connections to a database, allowing components to efficiently reuse them COMS W4156

  41. Role-Based Security • “Role” = a logically related group of users that share the same permissions to access a defined subset of an application’s functionalities • Assign different permissions for different roles on a class, interface or method • Can set either administratively or via programming • Don’t need to write security-related logic into components (but can do so if desired) COMS W4156

  42. So How Does MTS Fit With COM? COMS W4156

  43. MTS Extends COM to 3-tier Architecture COMS W4156

  44. Client-Server Architecture Client Server COMS W4156

  45. 2-tier Architecturewith Basic Component Middleware Client Server Component middleware COMS W4156

  46. 3-Tier Architecturewith Component Services Middleware Document Storage Client Database Application logic components LDAP Component services middleware COMS W4156

  47. COM+ COMS W4156

  48. COM+ Adds More Services COMS W4156

  49. Load Balancing • Scalability: network traffic and number of clients should not affect performance of an application (e.g., response time, throughput) • Load balancing distributes client calls across a server cluster transparently to the application • Components to be load-balanced configured on per-class basis at deployment COMS W4156

  50. COM+ Router • When a client requests a specific component, it first connects to a load balancing router (itself possibly a cluster) • Router polls the cluster application servers for timing data (e.g., every 200ms) • Router chooses a server based on lightest server load and availability COMS W4156

More Related