1. NT Component Development Environment for RTR Engineering Manager EASE Dianne Dickerson

2. Disclaimers  The technology being discussed in this presentation is still under development  There is no commitment from Compaq to deliver this technology (however, we do plan to)  When this technology is delivered in a product, it may appear differently than as presented in this presentation

3. Compaq Application Server Reliability Availability Interoperability Performance Scalability Reliability Availability Interoperability Performance Scalability Application Server Interoperability Application Server Plus Reliable Transaction Router ACMSxp

4. Goals of component interface for RTR  Be as transparent as possible: No direct exposure of the RTR API No direct exposure of the RTR API Expose RTR concepts in ways that are natural to the client and server environments Expose RTR concepts in ways that are natural to the client and server environments  Provide a GUI-based management Customers should not have to use the RTR command line for component RTR applications Customers should not have to use the RTR command line for component RTR applications

5. Rules that RTR applications must follow for fault tolerance  Must not keep state between requests  Must not use node specific information  Must use transactional databases or handle manually replayed transactions  Calls to non-shadowed systems that do updates must not be made on secondary system For example, calls to VISA For example, calls to VISA  Must not make time assumptions (to avoid problems on replays to shadow site)

6. 1st planned release: Component RTR for MTS/COM+  Support the use of RTR within MTS/COM+ applications  Support Windows NT V4 at FCS and Windows 2000 as soon as possible On Windows NT V4 application must handle possible duplicate transactions On Windows NT V4 application must handle possible duplicate transactions  Support the use of VB and C++ using ATL in the development of RTR applications RTR-specific features seen as COM interfaces implemented by server RTR-specific features seen as COM interfaces implemented by server

7. Compaq Application Server Reliability Availability Interoperability Performance Scalability Reliability Availability Interoperability Performance Scalability Application Server Interoperability Application Server Plus Reliable Transaction Router ACMSxp

8. Development of fault tolerant MTS/COM+ apps  Application is developed using standard Microsoft tools “Extension” interfaces are imported from their type libraries (Primary vs Secondary, Manual Transactions) “Extension” interfaces are imported from their type libraries (Primary vs Secondary, Manual Transactions)  Application is installed under MTS  Management interface is used to apply RTR Proxies and stubs are generated to intercept calls between client and server Proxies and stubs are generated to intercept calls between client and server Stubs generate calls for extension interfaces as needed Stubs generate calls for extension interfaces as needed

9. “Extension” interfaces for RTR/MTS applications  These are implemented by the server application to receive information about RTR server state  On Windows NT, type libraries are provided so that Visual Studio users can easily implement these interfaces  Two interfaces: IPrimarySecondary IPrimarySecondary IPossibleDuplicateTransaction (NT V4) IPossibleDuplicateTransaction (NT V4)

10. IPrimarySecondary  Used to inform MTS application server whether or not MTS application is executing as a primary or a secondary  Two methods: NowPrimary - all new transactions will now be primary transactions NowPrimary - all new transactions will now be primary transactions NowSecondary - all new transactions will now be secondary transactions NowSecondary - all new transactions will now be secondary transactions

11. IPossibleDuplicateTransaction  Used to inform an object that the transaction is a possible duplicate transaction  Required to be used on Windows NT V4 since we cannot synchronize the RTR transaction and the MTS transaction  Not required on Windows 2000 - but will remain available For compatibility For compatibility Possible performance improvements Possible performance improvements

12. MTS Application Creation and Installation Client Client MTS Application installed and clients setup using standard mechanisms DatabaseSystem DatabaseSystem MTS/COM+Application MTS/COM+Application

13. Creating facilities  A MMC snapin is used to create RTR facilities  Each node that participates must have “Component RTR for MTS” installed previously  “Component RTR for MTS” executes the required RTR commands on each node of the facility  “Component RTR for MTS” keeps RTR configuration data in a replicated database on two of the router nodes  Following slides show screen shots of a facility being created

14. Notes on the screens  The screens are from a prototype developed last fall  The screens in the actual product will be different (hopefully much better)

29. Facility creation Client Client MMC Plug In DatabaseSystem DatabaseSystem MTS/COM+Application MTS/COM+Application RTR Facility Router Router

30. Enabling an application for RTR  An MTS application from a server node is selected  “Component RTR for MTS” creates the required proxies and stubs  The proxies and stubs are installed on the clients and servers automatically

31. Enabling an application for RTR

39. Applying RTR to an MTS application Client Client MMC Plug In DatabaseSystem DatabaseSystem Router Stub Router Proxy Router Stub MTS/COM+Application MTS/COM+Application Router Router RTR Facility

40. Notes about MTS applications and RTR facilities  Within “Component RTR for MTS” multiple MTS applications can exist within the same RTR facility  “Component RTR for MTS” uses RTR’s data routing capabilities to route messages for applications to the correct server

41. Applying RTR features  Data routing and/or shadowing can be applied to an RTR enabled MTS application  Partitions cannot be shared between MTS applications  If data routing is not used, a single partition is used to handle shadowing for each MTS application  (No screen shots for this yet)

42. Router Stub Fault and disaster tolerance Client Client Application now has no single point of failure MTS/COM+Application Router Router Proxy Router Stub MTS/COM+Application Router DatabaseSystem DatabaseSystem Failure!

43. Fault and disaster tolerance Client Client Application now has no single point of failure MTS/COM+Application Router Router Proxy Router Stub MTS/COM+Application Router DatabaseSystem DatabaseSystem Failure!

44. Fault and disaster tolerance Client Client When failed system returns, missed transactions are played to it MTS/COM+Application Router Router Proxy Router Stub MTS/COM+Application Router DatabaseSystem DatabaseSystem

45. Data routing  Data routing is done on parameters of methods  Each application must define the routing key  The routing key must be identified within each method Done through a GUI interface Done through a GUI interface

46. Data based request routing - setup Client Client Application being configured for data routing MMC Plug In Router Router DatabaseSystem DatabaseSystem Router Stub Router Proxy Router Stub MTS/COM+Application MTS/COM+Application “A-M” “N-Z”

47. Data based request routing - execution Router Stub Client Client MTS/COM+Application Router Router Proxy Router Stub MTS/COM+Application Router DatabaseSystem DatabaseSystem “A-M” “N-Z”“Smith”“Smith” “Webster” “Webster” “Able”“Able” “Bates” “Bates”

48. Possible future directions for component RTR  Support for more RTR features  Interoperability with current RTR applications  Support of other server types ACMS ACMS C++ C++ EJB servers EJB servers  Mixed client and server types  Heterogeneous system support Open VMS, Unix,... Open VMS, Unix,...

49. Clients and servers being considered for Component RTR RTRRTR COM+/MTS Java/EJB Corba ACMS Tuxedo ACMSxp Business Bus Automation COM+/MTS C/C++ Java/JavaBeans Corba ACMSxp

50. Component interoperation  “Component RTR” is part of a more general set of component interoperability tools  These tools work by extracting definitions from servers and generating proxies and stubs from those definitions

51. Compaq Application Server Reliability Availability Interoperability Performance Scalability Reliability Availability Interoperability Performance Scalability ApplicationServerInteroperability Application Server Plus Reliable Transaction Router ACMSxp

52. Full set of clients, servers, and transports being considered IIOP RTR TCP/IP RTR TCP/IP IIOP DCOMDCOM MSMQMSMQ Automation COM+/MTS C/C++ Java/JavaBeans Corba ACMSxp COM+/MTS Java/EJB Corba ACMS Tuxedo ACMSxp Business Bus

53. Contacts  If you are interested in providing requirements or being a field test site please contact: Art Zina - Program Manager Art Zina - Program Manager – 1 978 506 5920 – Art.Zina@compaq.com Rick Seed - Product Manager (Plus) Rick Seed - Product Manager (Plus) – 1 978 506 7411 – Rick.Seed@compaq.com Jerry Hershey - Product Manager (Interop) Jerry Hershey - Product Manager (Interop) – 1 978 506 5872 – Jerry.Hershey@compaq.com

54. Thank you!