1 / 41

NT Component Development Environment for RTR

Dianne Dickerson. Engineering Manager EASE. NT Component Development Environment for RTR. 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)

nicole-bentley
Download Presentation

NT Component Development Environment for RTR

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. Dianne Dickerson Engineering Manager EASE NT Component Development Environment for RTR

  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 Application Server Interoperability Application Server Plus Reliability Availability Interoperability Performance Scalability Reliable Transaction Router ACMSxp

  4. Goals of componentinterface for RTR • Be as transparent as possible: • No direct exposure of the RTR API • 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

  5. Rules that RTR applicationsmust 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 • 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 • 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

  7. Development of faulttolerant MTS/COM+ apps • Application is developed using standard Microsoft tools • “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 • Stubs generate calls for extension interfaces as needed

  8. Database System Database System MTS Application Creationand Installation MTS Application installed and clients setup using standard mechanisms MTS/COM+ Application Client Client MTS/COM+ Application

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

  10. Database System Database System Router Router RTR Facility Facility creation MMC Plug In MTS/COM+ Application Client Client MTS/COM+ Application

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

  12. Database System Database System RouterStub RouterProxy RouterProxy RouterStub RTR Facility Applying RTR to an MTSapplication MMC Plug In MTS/COM+ Application Client Router Client Router MTS/COM+ Application

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

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

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

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

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

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

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

  20. Thank you!

More Related