Microsoft Distributed COM & Microsoft Transaction Server 資四B 張克家

Automation When you design a Object , you have to decide what interface would it have ! But this object can only use by your own program … 2 Solutions : 1.Microsoft pre-define Interfaces , Win32 SDK included! Declare in objidl.h , included by windows.h These Standard interfaces’ IIDs can link with uuid.lib uuid.lib is default library included by Non-MFC program and MFC program links this library through pragma ,too

Automation 2. Automation : IDispatch interface GetTypeInfoCount : support this type information ? GetTypeInfo : return a reference to ITypeInfo interface ITypeInfo can find methods and properties Client can find methods’ name and description GetIDsOfNames : methods call by DISPID , this method will return a DISPID of a method Invoke : Call that object’s method

Automation Many type of parameters need to send and receive , IDispatch only accepts data types as follows: Automation Compatible Types short 16bit signed integer long 32bit signed integer boolean True/False unsigned char 8bit unsigned double 64bit IEEE floating-point number float 32bit IEEE floating-point number int 32bit signed integer

Automation BSTR Length-prefixed string CY 8-byte fixed-point number DATE 64bbit floating-point fractional number of days since 12/30/1899 SCODE Built-in error type that corresponds to HRESULT enum Signed integer IDispatch* Pointer to IDispatch interface (VT_DISPATCH) IUnknown* Pointer to an interface that is not derived from Idispatch (VT_UNKNOWN) SAFEARRAY(typename) Array of any above types Typename* Pointer to any above types

Automation Design a pure automation interface: [ uuid(10000001-0000-0000-0000-000000000001) ] dispinterface Isum { properties: methods: [id(1)] int SUM(int x , int y) }

Automation Using the dispinterface will restrict clients using only the IDispatch interface when they want to access an object The Dual Interface: [ object, uuid(10000001-0000-0000-0000-000000000001), dual] interface ISum : IDispatch { [ id(3)] HRESULT Sum(int x, int y,[out, retval] int* retval) } so ISum now can derivved from IUnknown , we can still use QueryInterface , AddRef and Release

Automation Automation Client in C++ : VARIANT Result; VariantInit(&Result); HRESULT hr=pDispatch->Invoke(dispid,IID_NULL,GetUserDefaultLCID(),DISPATCH_METHOD,&MyParams,&Result,NULL,NULL); if(FAILED(hr)) cout << “pDispatch->Invoke() failed.” <<endl; cout << “2+7=“<<Result.lVal << endl; pDispatch->Release(); -----using C++ to implement IDispatch is a hard work -----

Security DCOM uses the extensible security framework provided by Windows NT Windows NT provides a solid set of built-in traditional trusted-domain security models to noncentrally managed, massively scaling public-key security mechanisms A central part of security framework is a user directory, wich stores the necessary information to validate a user’s credentials (username,password,public key)

Security Most DCOM implements on non-Windows NT platforms provide a similar or identical extensibility mechanism to use what ever kind of security providers is available on that platform Most UNIX implementations of DCOM will include a Windows NT - compatible security provider

Security DCOM can make distributed applications secure without any security-specific coding or design in either the client or the components DCOM stores Access Control Lists for components These Lists can easily be configured using the DCOM configuration tool - DCOMCNFG.EXE or programmatically using the Windows NT registry and Win32 security functions

Security by configuration

Security Programmatic Control over security The components try to access a secured object, such as a registry key, that has a Access Control List on it By choosing different registry keys according to the method that is being called, the components can provide security in a very easy way, yet flexible and efficient way

Per interface security using registry keys

Security DCOM distinguishes between 4 fundamental aspects of security: Access security : call an object ? Launch security : create an object in a new process ? Identity : What is the security principal of the object itself ? Connection policy : Integrity? Privacy? Authentication?

Security Authentication Level : Connection Call Default Packet Packet Integrity Packet Privacy

Security

Security on the Internet Problems : The numbers of user can be orders of magnitude higher than in even the largest company End users want to use the same password for all application they are using, even if they are run by different companies

Security on the Internet Windows NT NTLM authentication protocol - NT4.0 and Kerberos V5 authentication protocol - NT5.0 Distributed password authentication (DPA) - us by MSN and CompuServe Secure channel security services , which implement SSL/PCT By using above methods NT5.0 can support 100,000*1,000,000*n users (directory tree*domain controler*n dcs)

Load Balancing Static Load Balancing - specific components retrieving servers Dynamic Load Balancing - Server load,Network topology Microsoft Transaction Server and Windows NT handles all

Fault Tolerance DCOM provides basic support for fault tolerance at the protocol level When clients detect the failure of a components, they reconnect to the same referral component that established the first connection The referral component has information about which servers are no longer available and automatically provides the client with a new instance of the components running on another machine

Distributed component for fault-tolerance Applications still have to deal with error recovery at higher levels (consistency, loss of information, etc...) Distributed component for fault-tolerance

Ease of Deployment Installation “thin client” : flexibility or ease deployment - The same business components can be run on the server or on the client with a simple change of configuration - The Internet Explorer will automatically update the ActiveX control if there are new version of it -Application can use this support directly ( CoCreateClassFromURL ) without explicitly using a browser

Ease of Deployment DCOM robust versioning support allows servers to expose new functionality while maintaining complete backward compatibility A single server component can handle both old and new clients Once all clients are updated, the component can phase out support for the functionality that is not needed by the new clients

Ease of Deployment Administration - Use DCOM to configure information needed by a client - All Clients connect to a referral component, which contains all the configuration information and returns the appropriate components to each client. Simply changing the central referral component changes all clients

Monikers COM proposes a standard and extensible way of naming objects throughout the system, called a Moniker. A Moniker is a object that identifies another object. These Monikers contain the logic necessary to find a currently running object that they are naming. They can recreate and initialize an object instance in case there is no running instance

Monikers COM defines a standard interface to these naming objects, IMoniker, which can be used to bind to a named-object instance Moniker object keeps the actual object “hidden” from the client

Monikers HRESULT hr=S_OK; IBindCtx* pBC=NULL; hr=CreateBindCtx(NULL, &pBC); if (SUCCEEDED(hr)) { DWORD dwEaten; IMoniker* pMoniker=NULL; // Create the moniker object. hr=MkParseDisplayName(pBC, L"file:\\\\dtwmkt\\mkt\\productx1\\salesQ496.xyz!Summary", &dwEaten, &pMoniker); if (SUCCEEDED(hr)) { // Connect to the actual business object, create and initialize it if neccessary. hr=pMoniker->BindToObject(pBC, NULL, IID_ISalesInfo, &pSales); { // Perform the operation. pSales->Add( 1.1, "http://www.example.microsoft.com/mkt/productx/budget.xyz") pSales->Release(); } pMoniker->Release(); pBC->Release();

Monikers ‘ //Code in VB Dim Sales As Object Set Sales = GetObject("file:\\dtwmkt\mkt\productx1\salesQ496.xyz!Summary") Sales.Add(1.1, "http://www.example.microsoft.com/mkt/productx/budget.xyz")

Monikers File Moniker file: URL Moniker http:, ftp:, gopher: Class Moniker clsid: // Conjunction with other Monikers ProgIDFromCLSID( &clsid, "xyz.activator.1") CreateClassMoniker( clsid, &pmkClass ) MkParseDisplayName( pcb, "\\northamerica\central\employee.doc", &dwEaten, pmkFile ) pmkFile->BindToObject( pcb, pmkClass, IID_IDispatch, &pDisp ) Item Moniker , Pointer Moniker , Anti-Moniker , Composite Moniker

Threading Models Single-Threaded Apartments (STA) Each object live in a thread Each thread must initialize COM using CoInitialize or using CoInitializeEx with COINIT_APARTMENTTHREADED as the second parameter. If a client running on another thread (in another "apartment") wants to call an object in a single threaded apartment, the two threads need to be forcibly synchronized. COM achieves this by marshaling interface pointers across threads. Because the two threads have different stacks, the parameters need to be copied from one stack to the other.

Threading Models Single-Threaded Apartments (STA) access to an object from a different thread is indirect through proxy/stub code

Threading Models Single-Threaded Apartments (STA) The generic synchronization that COM performs on STA is relatively expensive. On each method call across apartments, two window messages need to be sent. On remote calls, two additional thread switches are required on the server side: the RPC thread switches to the apartment thread, calls the method, and switches back to the RPC thread upon completion. ( Additional thread switches are required on the client side).

Threading Models Multithreaded Apartment (MTA) From COM's perspective, a multithreaded apartment (MTA) is an easier model compared to an STA. Incoming RPC calls directly use the thread assigned by the RPC run time. No message pump or hidden window is used for communication between the client and object. The object does not live in any specific thread.

Threading Models Multithreaded Apartment (MTA) Within a process, clients from any thread can directly call any object inside the MTA. (There is only one MTA per process.) Interface pointers between threads do not need to be marshaled. However, an MTA requires extreme caution on the part of the object implementor.

Threading Models Multithreaded Apartment (MTA) Multiple threads can call an object method at the same time. Therefore the object must provide synchronized access to any instance using synchronization primitives like events, mutexes, or semaphores. It must be completely thread safe and reentrant. Although complex to implement, MTA-aware objects offer the possibility of higher performance and better scalability than STA objects

Threading Models Multithreaded Apartment (MTA) A thread that wants to be in a multithreaded apartment must initialize COM by calling CoInitializeEx (NULL, COINIT_MULTITHREADED). If an object is created from this thread (using CoCreateInstance or moniker binds), COM will assume that the object is free-threaded and does not require any synchronization.

Threading Models Multithreaded Apartment (MTA) If multiple clients call this object simultaneously, then each call runs on a different thread. If an excessive number of threads have been created, then COM may block some calls temporarily. If an object makes a call to other object, the calling object can still accept incoming calls. They simply arrive on another thread.

Threading Models COM currently defines three different kinds of apartments that require different assumptions on behalf of the object: Single-threaded apartment, main thread only: all instances are created on the same thread. Single-threaded apartment: an instance is tied to a single thread, and different instances can be created on different threads. Multithreaded apartment: instances can be created on multiple threads, and instances can be called on arbitrary threads.

Threading Models Local Servers: In full control! In-process servers: In (almost) total dependency on their client Customizing threading models: The free-threaded marshaler Please read : http://msdn.microsoft.com/library/backgrnd/html/msdn_dcomarch.htm

Looking to the future:COM+ A publish and subscribe service - Provides a general event mechanism that allows multiple clients to "subscribe" to various "published" events. When the publisher fires an event, the COM+ Events system iterates through the subscription database and notifies all subscribers.

Looking to the future:COM+ An in-memory database, with support for transactions - The IMDB provides an application with fast access to data, without incurring the overhead associated with storing and accessing durable state to and from physical disk. Queued components - Allows clients to invoke methods on COM components using an asynchronous model. Such as model is particularly useful in on unreliable networks and in disconnected usage scenarios.

Looking to the future:COM+ Dynamic Load balancing - Automatically spreads client requests across multiple equivalent COM components. Full integration of MTS into COM - Includes broader support for attribute-based programming, improvements in existing services such as Transactions, Security and Administration, as well as improved interoperability with other transaction environments through support for the Transaction Internet Protocol (TIP).

Microsoft Transaction Server Building robust server applications that can scale to the enterprise is no mean feat. While some developers are capable of creating the necessary infrastructure services to accomplish this, it makes far more sense to provide these services in a standard way. This is exactly what the Microsoft Transaction Server (MTS) does in Windows NT Server. By providing support for scalability, security, transactions, and more, MTS solves a range of fundamental problems, allowing enterprise developers to focus on the business problems at hand. And by offering its services through a remarkably easy-to-use programming model, MTS makes what might be a guru-only technology into a mainstream business tool.

Microsoft Transaction Server

Microsoft Transaction Server Automatic transactions - MTS introduced the innovation of automatic transactions, which allow configuring a component's transactional requirements when that component is deployed. The result is a much greater potential for reuse of business objects built as MTS components.

Microsoft Transaction Server Configurable security - By allowing an administrator to define roles, then specify which interfaces and components can be accessed by clients in each role, MTS greatly simplifies the work required to create secure server applications. Database connection pooling - Components can reuse existing connections to a database rather than recreating new ones, greatly improving application performance and scalability.

Microsoft Transaction Server Support for multiple databases and resource managers - MTS-based applications can access SQL Server?, Oracle, and DB2 databases, as well as other resource managers such as Microsoft Message Queue (MSMQ). Automatic thread support - Application developers can write single-threaded components, then let MTS assign threads to those components as needed.

Microsoft Transaction Server Component state management - Components must give up any in memory state when each transaction ends. This makes it easier to build correct applications while still allowing efficient resource sharing. MTS also provides the Shared Property Manager (SPM) for components that wish to store and later retrieve their in-memory state.

Microsoft Transaction Server Process isolation through packages - Individual applications can be grouped into one or more packages, and each package can run in its own process. This allows greater fault tolerance, since the failure of a single component will bring down only the package that component is part of.

Microsoft Transaction Server Integration with mainframe transactions - Through the COM Transaction Integrator, MTS transactions can initiate and control CICS transactions on IBM mainframes. A broad range of development tools - MTS allows developers to build applications in any of today's popular languages, including Microsoft Visual Basic, Java, C++, Cobol, and others.

Microsoft Message Queue DCOM provides synchronous communication using remote procedure calls, while Web-based applications rely on HTTP. But many distributed applications need the non-blocking, asynchronous communication provided by message queuing. Microsoft Message Queue (MSMQ) provides exactly this kind of service in Windows NT Server. With MSMQ, an application can send messages to another application without waiting for a response (in fact, the target application might not even be running). Those messages are sent into a queue, where they are stored until a receiving application removes them. If a response is expected, the sender can check a response queue at its leisure—there's no obligation to block waiting for a message. Message queuing is a flexible, reliable approach to communication, one that's appropriate for many kinds of applications.

Microsoft Message Queue

Microsoft Message Queue COM-based access - The services of MSMQ can be accessed through a simple interface provided by COM components. This makes it straightforward to send and receive messages from within an ASP script, an MTS-based application, or any software that can use COM.

Microsoft Message Queue Integration with MTS - Because MSMQ supports transactions, MTS-based applications can include the act of sending or receiving a message in a larger atomic unit. All of the operations in that transaction will succeed or fail as a group. Automatic message journaling - If requested, MSMQ will keep copies of messages sent or received by applications. Journals provide audit trails and can also make recovering from some kinds of failure easier.

Microsoft Message Queue Automatic notification - If requested, MSMQ can notify a sending application that messages were (or were not) received and processed correctly. This service lets sending applications know when they can treat messages as delivered or, when failures occur, when they must take corrective action.

Microsoft Message Queue Built-in data integrity, data privacy, and digital signature services - MSMQ can digitally sign and encrypt messages for transfer across the network. This protects messages from being viewed or changed during transmission (even when sent over public networks such as the Internet), and ensures that servers do not receive messages from unauthorized senders.

Microsoft Message Queue Message priority support - MSMQ allows assigning priorities to messages and queues, then routes and delivers messages based on these priorities. Priorities let applications handle the most important messages first.

Microsoft Message Queue Support for multiple platforms - MSMQ is available on many operating systems, including various versions of UNIX, IBM mainframes, and more, through Microsoft partner Level 8 Systems. Level 8 also provides gateways to existing messaging products such as IBM MQ Series.

Putting the piece together