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

1. MicrosoftDistributed COM&Microsoft Transaction Server資四B張克家

2. 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

3. 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

4. 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

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

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

7. 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

8. 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 ----- Automation

9. 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)

10. 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

11. 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

12. Security • Security by configuration

13. 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

14. Security • Per interface security using registry keys

15. 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?

16. Security Authentication Level : • Connection • Call • Default • Packet • Packet Integrity • Packet Privacy

17. Security

18. 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

19. 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)

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

21. 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

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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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); if (SUCCEEDED(hr)) { // Perform the operation. pSales->Add( 1.1, "http://www.example.microsoft.com/mkt/productx/budget.xyz") pSales->Release(); } pMoniker->Release(); } pBC->Release(); }

29. 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")

30. 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

31. 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.

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

33. 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).

34. Threading ModelsMultithreaded 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.

35. Threading ModelsMultithreaded 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.

36. Threading ModelsMultithreaded 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

37. Threading ModelsMultithreaded 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.

38. Threading ModelsMultithreaded 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.

39. 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.

40. 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

41. 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.

42. 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.

43. 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).

44. 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.

45. Microsoft Transaction Server

46. 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.

47. 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.

48. 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.

49. 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.

50. 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.