BEA Tuxedo. Introducing the BEA Tuxedo System

Transcription

1 BEA Tuxedo Itroducig the BEA Tuxedo System BEA Tuxedo Release 7.1 Documet Editio 7.1 May 2000

2 Copyright Copyright 2000 BEA Systems, Ic. All Rights Reserved. Restricted Rights Leged This software ad documetatio is subject to ad made available oly pursuat to the terms of the BEA Systems Licese Agreemet ad may be used or copied oly i accordace with the terms of that agreemet. It is agaist the law to copy the software except as specifically allowed i the agreemet. This documet may ot, i whole or i part, be copied photocopied, reproduced, traslated, or reduced to ay electroic medium or machie readable form without prior coset, i writig, from BEA Systems, Ic. Use, duplicatio or disclosure by the U.S. Govermet is subject to restrictios set forth i the BEA Systems Licese Agreemet ad i subparagraph (c)(1) of the Commercial Computer Software-Restricted Rights Clause at FAR ; subparagraph (c)(1)(ii) of the Rights i Techical Data ad Computer Software clause at DFARS , subparagraph (d) of the Commercial Computer Software--Licesig clause at NASA FAR supplemet ; or their equivalet. Iformatio i this documet is subject to chage without otice ad does ot represet a commitmet o the part of BEA Systems. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, BEA Systems DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE SOFTWARE OR WRITTEN MATERIAL IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. Trademarks or Service Marks BEA, ObjectBroker, TOP END, ad Tuxedo are registered trademarks of BEA Systems, Ic. BEA Builder, BEA Coect, BEA Maager, BEA MessageQ, BEA Jolt, M3, esolutios, elik, WebLogic, ad WebLogic Eterprise are trademarks of BEA Systems, Ic. All other compay ames may be trademarks of the respective compaies with which they are associated. Itroducig the BEA Tuxedo System Documet Editio Date Software Versio 7.1 May 2000 BEA Tuxedo Release 7.1

3 Cotets 1. BEA Tuxedo System Fudametals For More Iformatio What Is the BEA Tuxedo System Features of the BEA Tuxedo System Aatomy of the Cliet/Server Model Characteristics of Cliet/Server Architecture Differeces Betwee 2-Tier ad 3-Tier Cliet/Server Architectures Cliet/Server Variatios to Suit Your Needs How the BEA Tuxedo System Fits ito the Cliet/Server Model What Are Cliets, Servers, ad Services i a BEA Tuxedo Eviromet What Is a BEA Tuxedo Cliet What Is a BEA Tuxedo Server What Are BEA Tuxedo Services Services Provided by the BEA Tuxedo System Admiistrative Services Applicatio Processig Services BEA Family of Products BEA Tuxedo System Architecture Basic Architecture of the BEA Tuxedo System What You Ca Do Usig the ATMI What Are the BEA Tuxedo Messagig Paradigms What Is Coversatioal Commuicatio How the EvetBroker Works What Types of Evets Are Reported How Are Evets Reported What Is Queue-based Commuicatio Itroducig the BEA Tuxedo System iii

4 Usig Applicatio Queues What Is Request/Reply Commuicatio What Is Sychroous Messagig What Is Asychroous Messagig What Is Usolicited Commuicatio What Are Nested ad Forwarded Service Requests Nested Requests Forwarded Requests How the BEA Tuxedo System Processes Messages What Are the Beefits of Service Request Processig What Are Typed Buffers Characteristics of Buffer Types Usig the MIB Types of MIB Users Classes, Attributes, ad States i the MIB BEA Tuxedo Applicatio Processig Services What Is Data Compressio What Is Data-depedet Routig Uses of Data-depedet Routig Example of Data-depedet Routig with a Horizotally Partitioed Database Example of Data-depedet Routig with Rule-based Servers Example of Data-depedet Routig with Distributed Applicatio What Are Ecodig ad Decodig of Data What Is Data Ecryptio What Is Data Marshallig What Is Load Balacig Assigig a Load Factor What Is Message Prioritizatio What Is Meat by Namig Namig Services Advertisig Services Namig Evets BEA Tuxedo Admiistrative Services iv Itroducig the BEA Tuxedo System

5 3. Three Ways of Viewig the BEA Tuxedo System Ifrastructure Basic BEA Tuxedo System Ifrastructure Maagemet View: Usig Admiistrative Tools Available BEA Tuxedo System MIBs Usig the BEA Admiistratio Cosole Browser Requiremets Beefits of Usig the BEA Admiistratio Cosole Explorig the Mai Meu of the BEA Admiistratio Cosole Usig the Cofiguratio Tool What Is the Tree Usig the Power Bar Maagig Operatios Usig the MIB Types of MIB Users Classes, Attributes, ad States i the MIB Usig Commad-Lie Utilities Cofigurig Your Applicatio Usig Commad-lie Utilities Operatig Your Applicatio Usig Commad-lie Utilities Maagig System Evets Usig EvetBroker What Is a Evet Subscribig to a Evet Types of Evets Differeces betwee System ad Applicatio-specific Evets BEA Tuxedo Admiistrative Services Maagig Applicatio Queues Usig qmadmi to Admiister Applicatio Queues Usig tmcofig to Modify Your Cofiguratio Maagig Your Cofiguratio Creatig the Cofiguratio File Makig Permaet Cofiguratio Chages Maagig Your Cofiguratio Dyamically Performig Dyamic Operatios Usig tmadmi(1) Commoly Used tmadmi Commads Sample Output from the tmadmi Commad Itroducig the BEA Tuxedo System v

6 Maagig a Distributed Applicatio Cetrally Maagig Security Selectig Security Optios Settig Up Security Startig Up ad Shuttig Dow your Applicatio Maagig Trasactios Coordiatig Operatios with a Trasactio Maager Server (TMS) Trackig Participats with a Trasactio Log (TLOG) Maagig Workstatios Developmet View: What You Ca Do Usig the ATMI Ru-Time System View: Usig Tools i Differet Cofiguratios Ru-Time System Capabilities What Is a Sigle-machie Cofiguratio What Is a Multiple-machie (Distributed) Cofiguratio What Is a Multiple-domai Cofiguratio Features of a Multiple-domai Cofiguratio What Is a BEA Tuxedo BRIDGE What Is the Role of the Bulleti Board ad Bulleti Board Liaiso What Are Cliets ad Servers What Is the Distiguished Bulleti Board Liaiso (DBBL) What Are the Domais Admiistrative Tools What Are IPC Message Queues Whe to Use Sigle Server, Sigle Queues (SSSQ) Whe to Use Multiple Server, Sigle Queue (MSSQ) Sets What Are the Workstatio Hadler ad Workstatio Listeer How a Workstatio Cliet Coects to a Applicatio What Is the User Log (ULOG) How Is the ULOG Created Example of a ULOG Message Where the ULOG Resides Itegratig the BEA Tuxedo Product Family i a Eterprise System BEA Product Itegratio BEA Product Suite vi Itroducig the BEA Tuxedo System

7 Maiframe Coectivity: Usig BEA elik Compoets of the BEA elik Product Suite BEA elik for Maiframe - TCP/IP for MVS (for IMS ad CICS) BEA elik for Maiframe - SNA BEA elik for Maiframe - OSI TP Iteret Access: Usig BEA Jolt Compoets of BEA Jolt Developig ad Maagig Applicatios: Usig BEA Maager BEA Maager Compoets Compoets of the BEA Tuxedo Product Olie Trasactio Processig: Usig the Core BEA Tuxedo System Eablig Scalability: Usig BEA Tuxedo Domais Features of BEA Tuxedo Domais What Is a Domai What Is a Domais Gateway What Are Domai Gateway Types BEA Tuxedo Domais Compoets Storig Messages ad Service Requests: Usig BEA Tuxedo /Q Usig the Message Queuig Server Storig ad Forwardig Messages BEA Tuxedo /Q Capabilities Workstatio Coectivity: Usig BEA Tuxedo Workstatio Workstatio Compoets Developig Cliet-Server Architecture Usig WebLogic Eterprise Developig ad Maagig Distributed Java-based Applicatios: Usig BEA WebLogic Server WebLogic Server Implemetatios Advatages of Usig BEA WebLogic Server Itroducig the BEA Tuxedo System vii

8 viii Itroducig the BEA Tuxedo System

9 CHAPTER 1 BEA Tuxedo System Fudametals What Is the BEA Tuxedo System Aatomy of the Cliet/Server Model How the BEA Tuxedo System Fits ito the Cliet/Server Model What Are Cliets, Servers, ad Services i a BEA Tuxedo Eviromet Services Provided by the BEA Tuxedo System BEA Family of Products For More Iformatio May resources are available to help you uderstad the BEA Tuxedo system. The followig books, white papers, ad presetatios provide iformatio about cliet/server architecture, buildig ad maagig distributed busiess applicatios, ad usig the BEA Tuxedo system to build ad maage eterprise applicatios: Adrade, Jua, M. Carges, T. Dwyer, ad S. Felts, The Tuxedo System - Software for Costructig ad Maagig Distributed Busiess Applicatios. Readig, Massachusetts: Addiso-Wesley Publishig, Edwards, Jeri, with D. DeVoe, 3-Tier Cliet/Server at Work. New York: Joh Wiley & Sos, Ic., April Edwards, Jeri, D. Harkey, R. Orfali, The Essetial Cliet/Server Survival Guide. New York: Joh Wiley & Sos, Ic., May Itroducig the BEA Tuxedo System 1-1

10 1 BEA Tuxedo System Fudametals Hall, Carl, Buildig Cliet/Server Applicatios Usig Tuxedo - Desigig ad Buildig Cost-Effective, High Performace Cliet/Server Applicatios Usig Tuxedo. Wiley Computer Publishig. Lee, Rich, BEA Tuxedo Essetials. Preseted at the BEA User s Coferece i New Orleas, La., February, MacBlae, Rady, Maagig your BEA Tuxedo Applicatios Eve Over the Iteret. Preseted at the BEA User s Coferece i Sa Jose, Ca., May MacBlae, Rady, Tuxedo s Maagemet Iformatio Base. Preseted at the BEA User s Coferece i Sa Fracisco, Ca., February BEA Tuxedo: The Programmig Model (White Paper) BEA Tuxedo ad the Compoet Software Model (White Paper) Iter-Applicatio Trasactio Processig with BEA Tuxedo Domais (White Paper) Reliable Queuig Usig BEA Tuxedo (White Paper) What Is the BEA Tuxedo System The BEA Tuxedo system is a middleware product that distributes applicatios across multiple platforms, databases, ad operatig systems usig message-based commuicatios ad, if desired, distributed trasactio processig. Middleware is used with cliet/server applicatios to distribute processig amog multiple servers, maage distributed trasactios, ad itegrate multiple database platforms. Middleware systems are sometimes kow as o-lie trasactio processig or OLTP systems. The BEA Tuxedo system is a mature product based o over 15 years of developmet from a diverse group of techology compaies icludig AT&T, UNIX System Laboratories (USL), Novell, ad BEA Systems, Ic. It is both a developmet platform ad a executio platform. The BEA Tuxedo system serves as a extesio to the operatig system. 1-2 Itroducig the BEA Tuxedo System

11 What Is the BEA Tuxedo System The BEA Tuxedo system provides the followig: A idustry stadard for the creatio ad cetral admiistratio of distributed o-lie trasactio applicatios i a heterogeeous cliet/server eviromet. Ease of use for applicatio developers, who do ot eed to kow all the details about server locatios, routig, or platforms used. I a BEA Tuxedo applicatio, these aspects of a program are trasparet. The fudametal uderpiigs for creatig, maagig, ad maitaiig reliable, high performace, easily maaged distributed systems. Features of the BEA Tuxedo System Admiistrative Features The BEA Tuxedo system offers may features to accommodate the eeds of the admiistrator, architect, ad programmer of a applicatio. Password security ad access cotrol security Password security allows applicatio desigers to cotrol access by requirig passwords at iitializatio time (autheticatio). Further cotrol is available through authorizatio, a meas of restrictig access to certai applicatio services to cliets that have bee give explicit permissio ad that have autheticated idetities. System evets otificatio The BEA Tuxedo system provides details about system evets, such as servers dyig ad etwork failures. Whe a evet is posted by cliets or servers, the EvetBroker looks up all the subscribers to that evet ad takes appropriate actios, as determied by each subscriptio. The MIB (Maagemet Iformatio Base) A admiistrative iterface that eables you to moitor, cofigure, ad tue your applicatio through your ow programs. It is a implemetatio-idepedet maagemet database defied as a set of FML attributes, which allows you to query or chage iformatio. Web-based admiistratio A graphical user iterface, available through the World Wide Web, for the cofiguratio ad cotrol of BEA Tuxedo applicatios. Itroducig the BEA Tuxedo System 1-3

12 1 BEA Tuxedo System Fudametals Architectural Features Distributed services Allow trasparet access to applicatio ad/or system services located o differet hardware platforms. Fast, coectioless commuicatios Cliets coect to a bulleti board rather tha to servers, thus improvig system performace. Scalability You ca quickly scale your applicatio to match varyig system load demads because services ad servers ca be replicated ad distributed easily. You ca set thresholds programmatically to eable the BEA Tuxedo system to spaw ew servers or to shut dow servers automatically. Server trasparecy The directory of services o the bulleti board maps service ames to servers; cliets do ot eed to be aware of server idetity. Programmig Features Commuicatio techiques The Applicatio Programmig Iterface (API) for the BEA Tuxedo system is a superset of X/Ope s XATMI iterface called the Applicatio to Trasactio Moitor Iterface or ATMI. The BEA Tuxedo ATMI is a rich set of commuicatio techiques for writig distributed applicatios. Distributed Trasactio Processig (DTP) Allows work beig doe throughout a distributed applicatio to be atomically completed a essetial characteristic of ay OLTP system. Typed buffers Provide trasparet hadlig of applicatio data across heterogeeous platforms. X/Ope TX compliace The BEA Tuxedo system coforms to the X/Ope iterface stadard for trasactio demarcatio. X/Ope XA compliace The BEA Tuxedo system coforms to the X/Ope iterface stadard for trasactio database systems (called resource maagers). As a result, you ca mix ad match databases withi oe applicatio while maitaiig data itegrity. See Also Services Provided by the BEA Tuxedo System o page 1-12 BEA Family of Products o page Itroducig the BEA Tuxedo System

13 Aatomy of the Cliet/Server Model Aatomy of the Cliet/Server Model I cliet/server architecture, cliets, or programs that represet users who eed services, ad servers, or programs that provide services, are separate logical objects that commuicate over a etwork to perform tasks together. A cliet makes a request for a service ad receives a reply to that request; a server receives ad processes a request, ad seds back the required respose. Characteristics of Cliet/Server Architecture Asymmetrical protocols There is a may-to-oe relatioship betwee cliets ad a server. Cliets always iitiate a dialog by requestig a service. Servers wait passively for requests from cliets. Ecapsulatio of services The server is a specialist: whe give a message requestig a service, it determies how to get the job doe. Servers ca be upgraded without affectig cliets as log as the published message iterface used by both is uchaged. Itegrity The code ad data for a server are cetrally maitaied, which results i cheaper maiteace ad the protectio of shared data itegrity. At the same time, cliets remai persoal ad idepedet. Locatio trasparecy The server is a process that ca reside o the same machie as a cliet or o a differet machie across a etwork. Cliet/server software usually hides the locatio of a server from cliets by redirectig service requests. A program ca be a cliet, a server, or both. Message-based exchages Cliets ad servers are loosely-coupled processes that ca exchage service requests ad replies usig messages. Modular, extesible desig The modular desig of a cliet/server applicatio eables that applicatio to be fault-tolerat. I a fault-tolerat system, failures may occur without causig a shutdow of the etire applicatio. I a fault-tolerat cliet/server applicatio, oe or more servers may fail without stoppig the whole system as log as the services offered o the failed servers are available o servers that are still active. Aother advatage of modularity is that a cliet/server applicatio ca respod automatically to icreasig or decreasig system loads by addig or shuttig dow oe or more services or servers. Itroducig the BEA Tuxedo System 1-5

14 1 BEA Tuxedo System Fudametals Platform idepedece The ideal cliet/server software is idepedet of hardware or operatig system platforms, allowig you to mix cliet ad server platforms. Cliets ad servers ca be deployed o differet hardware usig differet operatig systems, optimizig the type of work each performs. Reusable code Service programs ca be used o multiple servers. Scalability Cliet/server systems ca be scaled horizotally or vertically. Horizotal scalig meas addig or removig cliet workstatios with oly a slight performace impact. Vertical scalig meas migratig to a larger ad faster server machie or addig server machies. Separatio of Cliet/Server Fuctioality Cliet/server is a relatioship betwee processes ruig o the same or separate machies. A server process is a provider of services. A cliet is a cosumer of services. Cliet/server provides a clea separatio of fuctios. Shared resources Oe server ca provide services for may cliets at the same time, ad regulate their access to shared resources. Differeces Betwee 2-Tier ad 3-Tier Cliet/Server Architectures Every cliet/server applicatio cotais three fuctioal uits: Presetatio logic or user iterface (for example, ATM machies) Busiess logic (for example software that eables a customer to request a accout balace) Data (for example, records of customer accouts) These fuctioal uits ca reside o either the cliet or o oe or more servers i your applicatio. Which of the may possible variatios you choose depeds o how you split the applicatio ad which middleware you use to commuicate betwee the tiers. I 2-tier cliet/server applicatios, the busiess logic is buried iside the user iterface o the cliet or withi the database o the server i the form of stored procedures. Alteratively, the busiess logic ca be divided betwee the cliet ad server. File servers ad database servers with stored procedures are examples of 2-tier architecture. 1-6 Itroducig the BEA Tuxedo System

15 Aatomy of the Cliet/Server Model I 3-tier cliet/server applicatios, the busiess logic resides i the middle tier, separate from the data ad user iterface. I this way, processes ca be maaged ad deployed separately from the user iterface ad the database. Also, 3-tier systems ca itegrate data from multiple sources. Figure Tier ad 3-Tier Cliet/Server Models Itroducig the BEA Tuxedo System 1-7

16 1 BEA Tuxedo System Fudametals Cliet/Server Variatios to Suit Your Needs Cliet/server architecture ca accommodate the eeds of each of the followig situatios: Small shops ad laptops The cliet, the middleware software, ad most of the busiess services operate o the same machie. We recommed this approach for oe-perso busiesses such as a detist s office, a home office, ad a busiess traveler who frequetly works o a laptop computer. Small busiesses ad corporate departmets A LAN-based sigle-server applicatio is required. Users of this type of applicatio iclude small busiesses, such as a medical practice with several doctors, a multi-departmet corporatio, or a bak with several brach offices. I this type of applicatio, multiple cliets talk to a local server. Admiistratio is simple: security is implemeted at the machie level ad failures are detected easily. Large eterprises Multiple servers that offer diverse fuctioality are required. Multiple servers ca reside o the Iteret, itraets, ad corporate etworks, all of which are highly scalable. Servers ca be partitioed by fuctio, resources, or databases, ad ca be replicated for icreased fault tolerace or ehaced performace. This model provides a great amout of power ad flexibility. How well you architect your applicatio is critical to this cliet/server model. You may eed to partitio work amog servers, or desig servers to delegate work to other servers. 1-8 Itroducig the BEA Tuxedo System

17 How the BEA Tuxedo System Fits ito the Cliet/Server Model How the BEA Tuxedo System Fits ito the Cliet/Server Model The BEA Tuxedo system fits ito the middle of the cliet/server model. I a BEA Tuxedo applicatio, cliets log i ad request services offered by a applicatio. The BEA Tuxedo system offers these services through a trasparet bulleti board. The bulleti board cotais a directory advertisig services. I a bakig applicatio, for example, the bulleti board might advertise deposit, withdrawal, ad iquiry services. The BEA Tuxedo system the fids a server (for example, at the appropriate brach or district office) that ca provide the requested services. Figure 1-2 Cliets ad Servers i a Sample Bakig Applicatio The precedig figure shows the primary buildig blocks of a BEA Tuxedo applicatio: Cliets programs that collect iput from users, seds requests through the BEA Tuxedo system to servers, ad the collects the replies from servers ad delivers them to the users. Itroducig the BEA Tuxedo System 1-9

18 1 BEA Tuxedo System Fudametals Servers programs that ecapsulate the busiess logic ito a set of services that defie the applicatio. Middleware comprises all the distributed software eeded to support iteractios betwee cliets ad servers. It is the medium that eables a cliet to obtai a service from a server. Middleware icludes: API fuctios used by the cliet (to issue requests ad receive replies) ad the server (to issue replies) ad messagig paradigms used to trasmit cliet requests ad server resposes over a etwork. Middleware does ot iclude ay of the followig: the user iterface o the cliet, applicatio logic, ad services provided by servers. I this sample BEA Tuxedo applicatio at a bak, cliets (cash machies ad tellers) make requests, ad servers (at brach ad district offices) provide services ad resposes. For example, a customer may use a cash machie to fid out how much moey is available i his persoal checkig accout. The cash machie (a cliet) calls the server to get the balace. The server receives the request, retrieves the balace, ad seds the iformatio to the cash machie. See Also Aatomy of the Cliet/Server Model o page 1-5 What Are Cliets, Servers, ad Services i a BEA Tuxedo Eviromet o page Itroducig the BEA Tuxedo System

19 What Are Cliets, Servers, ad Services i a BEA Tuxedo Eviromet What Are Cliets, Servers, ad Services i a BEA Tuxedo Eviromet This topic describes a cliet, server, ad services i a BEA Tuxedo eviromet. What Is a BEA Tuxedo Cliet A cliet is a program that collects a request from a user ad passes that request to a server capable of fulfillig it. It ca reside o a PC or workstatio as part of the frot ed of a applicatio. It ca also be embedded i software that reads a commuicatio device such as a ATM machie from which data is collected ad formatted before beig processed by BEA Tuxedo servers. To be a cliet, a program must be able to ivoke the BEA Tuxedo libraries of fuctios ad procedures kow collectively as the Applicatio to Trasactio Moitor Iterface, or ATMI. The ATMI is supported i several laguage bidigs. A cliet jois a BEA Tuxedo applicatio by callig the ATMI cliet iitializatio routie. Oce it has joied a applicatio, a cliet ca defie trasactio boudaries ad call ATMI fuctios that eable it to commuicate with other programs i your applicatio. The cliet leaves the BEA Tuxedo applicatio by issuig a ATMI termiatio fuctio. By joiig a applicatio oly whe ecessary ad leavig it oce the appropriate task is complete, a cliet frees BEA Tuxedo system resources for use by other cliets ad servers. Whe buildig a distributed applicatio, you must determie how iformatio is gathered ad preseted to your busiess for processig. You have complete cotrol over where ad whe to call ATMI fuctios, depedig upo your busiess logic ad rules. Your program ca joi oe BEA Tuxedo applicatio, perform some tasks ad leave, ad the joi a differet BEA Tuxedo applicatio to perform aother task. If you are usig a multicotexted applicatio, your cliet ca perform tasks i more tha oe applicatio without leavig ay of them. Itroducig the BEA Tuxedo System 1-11

20 1 BEA Tuxedo System Fudametals What Is a BEA Tuxedo Server A BEA Tuxedo server is a process that oversees a set of services, dispatchig them automatically for cliets that request them. A service, i tur, is a fuctio withi a server program that performs a particular task eeded by a busiess. A bak, for example, might have oe service that accepts deposits ad aother that reports accout balaces. A server at this bak might receive requests from cliets for both services. It is the server s job to dispatch each request to the appropriate service. Service fuctios implemet busiess logic through calls to database iterfaces such as SQL ad, possibly, calls to the ATMI to access additioal services, queues, ad other resources. The servers o which these services reside the reply to the cliets or forward cliet requests to a ew service. What Are BEA Tuxedo Services A service is a module of applicatio code that performs a task. Services are compiled ad lik edited to form executable servers. Services Provided by the BEA Tuxedo System The BEA Tuxedo system offers may services to help you streamlie ad admiister your applicatio. Admiistrative Services The BEA Tuxedo system provides services for the followig admiistrative tasks: Applicatio queue maagemet Cetralized applicatio cofiguratio Distributed applicatio maagemet 1-12 Itroducig the BEA Tuxedo System

21 Services Provided by the BEA Tuxedo System Dyamic applicatio recofiguratio Evet maagemet Security maagemet Startup ad shutdow of a applicatio Trasactio maagemet Workstatio maagemet Applicatio Processig Services The BEA Tuxedo system provides services that eable you to implemet the followig fuctioality i your applicatio: Data compressio Data-depedet routig Data ecodig Data ecryptio Data marshallig Load balacig Message prioritizatio Service ad evet amig Itroducig the BEA Tuxedo System 1-13

22 1 BEA Tuxedo System Fudametals BEA Family of Products BEA offers the followig family of products. This Product BEA elik BEA Jolt BEA Maager Provides A suite of coectivity products that allow you to seamlessly itegrate BEA Tuxedo distributed applicatios with eterprise applicatios A BEA Tuxedo cliet API i Java A package of admiistrative tools for a BEA Tuxedo or WebLogic Server applicatio The BEA Tuxedo system cosists of four compoets: Core BEA Tuxedo system Domais /Q Workstatio The core BEA Tuxedo product eables you to build high-performace, missio-critical, ad reliable distributed applicatios. It provides the framework for buildig scalable 3-tier cliet-server applicatios i heterogeeous, distributed eviromets. Domais exteds the BEA Tuxedo cliet/server model to provide trasactio iteroperability across separately admiistered BEA Tuxedo applicatios. /Q allows reliable queueig of requests. Workstatio offers full cliet support for a wide variety of operatig systems allowig applicatios to use remote cliets that do ot eed a full BEA Tuxedo implemetatio. BEA WebLogic Eterprise BEA WebLogic Server A leadig applicatio server family of products providig busiesses ad orgaizatios that deped o missio-critical applicatios with the advatages of Commo Object Request Broker Architecture (CORBA)-compliat ad Eterprise Java Beas (EJB) programmig models, combied with the power, robustess, ad prove reliability of the BEA Tuxedo system. A Java-applicatio server for developig, itegratig, deployig, ad maagig large-scale, distributed Web, etwork, ad database applicatios 1-14 Itroducig the BEA Tuxedo System

23 CHAPTER 2 BEA Tuxedo System Architecture Basic Architecture of the BEA Tuxedo System What Are the BEA Tuxedo Messagig Paradigms How the BEA Tuxedo System Processes Messages BEA Tuxedo Applicatio Processig Services BEA Tuxedo Admiistrative Services Basic Architecture of the BEA Tuxedo System The followig figure illustrates the basic architectural elemets of a BEA Tuxedo system: exteral iterfaces to the system, the ATMI layer, the MIB, BEA Tuxedo system services, ad the system s iterface with stadards-compliat resource maagers. Itroducig the BEA Tuxedo System 2-1

24 2 BEA Tuxedo System Architecture Figure 2-1 The BEA Tuxedo System Basic Architecture As show i this illustratio, the BEA Tuxedo system cotais the followig parts. Architectural Part Exteral iterface layer Descriptio This layer cosists of iterfaces betwee the user ad the system. It icludes both tools for applicatio developmet, such as Simple Network Maagemet Protocol (SNMP) agets, ad tools for admiistratio, such as the BEA Admiistratio Cosole. The BEA Admiistratio Cosole ad SNMP agets ca iteract with stadard maagemet cosoles. Thus a user ca maage a BEA Tuxedo system ad a etwork cofiguratio from oe cosole. I additio, applicatio architects ad developers ca build their ow admiistrative tools or applicatio- or market-specific tools o top of the MIB. 2-2 Itroducig the BEA Tuxedo System

25 Basic Architecture of the BEA Tuxedo System Architectural Part ATMI (Applicatio to Trasactio Moitor Iterface) Messagig paradigms MIB (Maagemet Iformatio Base) BEA Tuxedo Services (admiistrative services ad applicatio processig services) Resource Maager Descriptio The iterface betwee a applicatio ad the BEA Tuxedo system. The ATMI ad the BEA Tuxedo system implemet the X/Ope DTP model of trasactio processig. A abstract eviromet, the ATMI supports locatio trasparecy ad hides implemetatio details. As a result, programmers are free to cofigure ad deploy BEA Tuxedo applicatios to multiple platforms without modifyig the applicatio code. Differet models of trasferrig messages betwee a cliet ad a server. Examples iclude request/respose mode, coversatioal mode, evets ad usolicited otificatio. The Maagemet Iformatio Base (MIB) is a iterface that eables users to program ad admiister a BEA Tuxedo system easily. MIB operatios eable you to perform all maagemet tasks (moitorig, cofigurig, tuig, ad so o). The MIB allows you to perform oe task to oe object at a time or to build tool kits with which you ca batch tasks ad/or objects. (For iformatio about available MIBs, see Available BEA Tuxedo System MIBs o page 3-3.) Services ad/or capabilities provided by the BEA Tuxedo system ifrastructure for developig ad admiisterig applicatios. The applicatio processig services available to developers iclude: data compressio, data-depedet routig, data ecodig, load balacig, ad trasactio maagemet. The admiistrative services iclude: cetralized applicatio cofiguratio, distributed applicatio maagemet, domais partitioig, dyamic recofiguratio, evet ad fault maagemet, IPC message queues, ad workstatio maagemet. (For iformatio o admiistrative services, see the topic titled: Three Ways of Viewig the BEA Tuxedo System Ifrastructure o page 3-1.) A software product i which data is stored ad available for retrieval through applicatio-based queries. The resource maager (RM) iteracts with the BEA Tuxedo system ad implemets the XA stadard iterfaces. The most commo example of a resource maager is a database. Resource maagers provide trasactio capabilities ad permaece of actios; they are the etities accessed ad cotrolled withi a global trasactio. Itroducig the BEA Tuxedo System 2-3

26 2 BEA Tuxedo System Architecture See Also BEA Tuxedo Admiistrative Services o page 2-44 BEA Tuxedo Applicatio Processig Services o page 2-31 What You Ca Do Usig the ATMI The Applicatio to Trasactio Moitor Iterface (ATMI), the BEA Tuxedo API, is a iterface for commuicatios, trasactios, ad maagemet of data buffers that works i all eviromets supported by the BEA Tuxedo system. It provides the coectio betwee applicatio programs ad the BEA Tuxedo system. The ATMI is a simple iterface for a comprehesive set of capabilities. It implemets the X/Ope DTP model of trasactio processig. Figure 2-2 Usig the ATMI The ATMI library offers you a variety of fuctios for defiig ad cotrollig global trasactios i a BEA Tuxedo applicatio. Global trasactios eable you to maage exclusive uits of work spaig multiple programs ad resource maagers i your 2-4 Itroducig the BEA Tuxedo System

27 What You Ca Do Usig the ATMI distributed applicatio. All work i a sigle trasactio is treated as a logical uit, so that if ay oe program caot complete its task successfully, o work is performed by programs i the trasactio. Most ATMI fuctios support differet commuicatio styles. These fuctios kit together distributed programs by eablig them to sed ad receive data. All ATMI fuctios sed or receive data i typed buffers. Followig is a list of ATMI fuctios (for C ad COBOL bidigs), ad the tasks they perform. The fuctios are grouped by task. Table 2-1 Usig the ATMI Fuctios For a Task Related to Use This C Fuctio Or This COBOL Fuctio To Cliet membership tpchkauth(3c) TPCHKAUTH(3cbl) Check whether autheticatio is required tpiit(3c) TPINITIALIZE(3cbl) Have a cliet joi a applicatio tpterm(3c) TPTERM(3cbl) Have a cliet leave a applicatio Buffer maagemet tpalloc(3c) N/A Create a message buffer tprealloc(3c) N/A Resize a message buffer tpfree(3c) N/A Free a message buffer tptypes(3c) N/A Get a message type ad subtype Message priority tpgprio(3c) TPGPRIO(3cbl) Get the priority of the last request tpsprio(3c) TPSPRIO(3cbl) Set the priority of the ext request Request/Respose commuicatios tpcall(3c) TPCALL(3cbl) Iitiate a sychroous request/respose to a service tpacall(3c) TPACALL(3cbl) Iitiate a asychroous request (faout) tpgetrply(3c) TPGETRPLY(3cbl) Receive a asychroous respose tpcacel(3c) TPCANCEL(3cbl) Cacel a asychroous request Itroducig the BEA Tuxedo System 2-5

28 2 BEA Tuxedo System Architecture For a Task Related to Use This C Fuctio Or This COBOL Fuctio To Coversatioal commuicatios tpcoect(3c) TPCONNECT(3cbl) Begi a coversatio with a service tpdisco(3c) TPDISCON(3cbl) Abormally termiate a coversatio tpsed(3c) TPSEND(3cbl) Sed a message i a coversatio tprecv(3c) TPRECV(3cbl) Receive a message i a coversatio Reliable queuig tpequeue(3c) TPENQUEUE(3cbl) Equeue a message to a message queue tpdequeue(3c) TPDEQUEUE(3cbl) Dequeue a message from a message queue Evet-based commuicatios tpotify(3c) TPNOTIFY(3cbl) Sed a usolicited message to a cliet tpbroadcast(3c) TPBROADCAST(3cbl) Sed messages to several cliets tpsetusol(3c) TPSETUNSOL(3cbl) Set usolicited message call-back tpchkusol(3c) TPCHKUNSOL(3cbl) Check the arrival of usolicited messages N/A TPGETUNSOL(3cbl) Get a usolicited message tppost(3c) TPPOST(3cbl) Post a evet message tpsubscribe(3c) TPSUBSCRIBE(3cbl) Subscribe to evet messages tpusubscribe(3c) TPUNSUBSCRIBE(3cbl) Usubscribe to evet messages 2-6 Itroducig the BEA Tuxedo System

29 What You Ca Do Usig the ATMI For a Task Related to Use This C Fuctio Or This COBOL Fuctio To Trasactio maagemet tpbegi(3c) TPBEGIN(3cbl) Begi a trasactio tpcommit(3c) TPCOMMIT(3cbl) Commit the curret trasactio tpabort(3c) TPABORT(3cbl) Roll back the curret trasactio tpgetlev(3c) TPGETLEV(3cbl) Check whether i trasactio mode tpsusped(3c) TPSUSPEND(3cbl) Susped the curret trasactio tpresume(3c) TPRESUME(3cbl) Resume a trasactio Service etry ad retur tpsvriit(3c) TPSVRINIT(3cbl) Iitialize a server tpsvrdoe(3c) TPSVRDONE(3cbl) Termiate a server tpservice(3c) N/A Prototype for a service etry poit N/A TPSVCSTART(3cbl) Get service iformatio tpretur(3c) TPRETURN(3cbl) Ed a service fuctio tpforward(3c) TPFORWAR(3cbl) Forward request Dyamic advertisemet Resource maagemet tpadvertise(3c) TPADVERTISE(3cbl) Advertise a service ame tpuadvertise(3c) TPUNADVERTISE(3cbl) Uadvertise a service ame tpope(3c) TPOPEN(3cbl) Ope a resource maager tpclose(3c) TPCLOSE(3cbl) Close a resource maager See Also Note: The use of ATMI trasactio maagemet fuctios is optioal. Usig the ATMI to Hadle System ad Applicatio Errors o page 2-28 i Admiisterig a BEA Tuxedo Applicatio at Ru Time Itroducig the BEA Tuxedo System 2-7

30 2 BEA Tuxedo System Architecture What Are the BEA Tuxedo Messagig Paradigms The followig table describes the BEA Tuxedo messagig paradigms available to applicatio developers. Table 2-2 BEA Tuxedo Messagig Paradigms BEA Tuxedo Messagig Paradigm Coversatioal commuicatio Evet-based commuicatio Queue-based commuicatio Request/reply commuicatio Usolicited messagig Descriptio Service request mode ivolvig multiple 2-way iteractios betwee a cliet ad a dedicated server Publish/subscribe mode Guarateed delivery mode Service request mode that ca be sychroous (processig waits util the requester receives the respose) or asychroous (processig cotiues while the requester waits for the respose) Commuicatio from ay cliet or server to ay cliets that were ot requested or expected by those cliets 2-8 Itroducig the BEA Tuxedo System

31 What Is Coversatioal Commuicatio See Also What Is Coversatioal Commuicatio o page 2-9 How the EvetBroker Works o page 2-10 What Is Queue-based Commuicatio o page 2-13 What Is Request/Reply Commuicatio o page 2-14 What Is Usolicited Commuicatio o page 2-17 What Are Nested ad Forwarded Service Requests o page 2-18 What Is Coversatioal Commuicatio Coversatioal commuicatio is the BEA Tuxedo system implemetatio of a huma-like paradigm for exchagig messages betwee cliets ad servers. I this form of commuicatio, a virtual coectio is maitaied betwee the cliet ad server. Just as i a coversatio betwee two people, a umber of messages pass back ad forth betwee the two etities util a coclusio is reached. Over the course of the commuicatio, both sides remember the poit (or state) of the coversatio so that relatively log operatios, such as ad hoc queries, reports, ad file trasfers, ca be supported. Coversatioal servers are available by default, but more ca be spawed automatically if eeded. The BEA Tuxedo system provides a Applicatio Programmig Iterface (API) that ca be used to create coversatios i applicatios; specifically to coect cliets to servers, to sed ad receive messages, ad to ed the coversatio. Coversatios ca be ested but performace may be degraded as a result of doig so. Coversatios may cotai either trasactios or service requests as appropriate. Although a coversatioal service ca make service calls ad establish coversatios, those service calls ad coversatios caot be forwarded. A coversatio ca be withi the scope of, ad cotrolled by a trasactio. Itroducig the BEA Tuxedo System 2-9

32 2 BEA Tuxedo System Architecture Figure 2-3 Coversatioal Commuicatio See Also Usig Coversatioal Commuicatio o page 1-11 i Tutorials for Developig a BEA Tuxedo Applicatio How the EvetBroker Works The BEA Tuxedo EvetBroker provides a commuicatio paradigm i which a arbitrary umber of suppliers ca post messages for a arbitrary umber of subscribers. Because cliet ad server processes that use the EvetBroker commuicate with oe aother based o a set of subscriptios, this paradigm is kow as publish-ad-subscribe commuicatio. The EvetBroker acts like a ewspaper delivery perso who delivers ewspapers oly to customers who have paid for a subscriptio Itroducig the BEA Tuxedo System

33 What Types of Evets Are Reported Figure 2-4 Postig ad Subscribig to a Evet Evet geerators (either cliets or servers) iform the EvetBroker of chages ad problems as they occur. This process is called postig a evet. The EvetBroker the matches the ame of the evet to a evet ame associated with a list of subscribers, ad otifies each subscriber o the list of the evet. See Also What Types of Evets Are Reported o page 2-11 How Are Evets Reported o page 2-12 Usig Evet-based Commuicatio o page 1-14 i Tutorials for Developig a BEA Tuxedo Applicatio What Types of Evets Are Reported The BEA Tuxedo system supports two differet types of evet reports: System Evet reports provide details about BEA Tuxedo system evets, such as servers dyig, ad etwork failures. Whe a evet is posted by cliets or servers, EvetBroker matches the posted evet s ame to subscriber s of the same evets ad takes appropriate actio determied by each subscriptio. Reports of User Evets or Applicatio Defied Evets allow applicatio programs to post evets whe certai criteria are met. A bakig applicatio, for example, might post a evet for withdrawals over a certai limit. Itroducig the BEA Tuxedo System 2-11

34 2 BEA Tuxedo System Architecture How Are Evets Reported The EvetBroker provides publish-ad-subscribe fuctioality. A process registers a subscriptio with the EvetBroker, idicatig iterest i a particular evet. Subsequetly, wheever the EvetBroker is otified by aother process that the specified evet has occurred, the EvetBroker reports the occurrece to ay process that has subscribed for this evet. Figure 2-5 Evet-based Messagig The EvetBroker uses several mechaisms for publishig (that is, issuig otices of) evets: Disk-based queuig Asychroous service calls Userlog etries Usolicited messages System commads 2-12 Itroducig the BEA Tuxedo System

35 What Is Queue-based Commuicatio What Is Queue-based Commuicatio The BEA Tuxedo system offers a queue-based architecture kow as /Q for applicatios that require persistet storage of data. The /Q compoet allows ay cliet or server to store messages or service requests i queues ad guaratees that ay stored request is set through the trasactio protocol to esure safe storage. BEA Tuxedo system queues ca be ordered as Last I First Out (LIFO) or First I First Out (FIFO), or o the basis of time or priority. A collectio of queues is admiistered ad referred to as a sigle etity kow as a queue space. Figure 2-6 Queue-based Messagig Usig Applicatio Queues Applicatio queues are appropriate if you must commuicate i a time-idepedet fashio. Time-idepedece is a characteristic of programs that operate idepedetly from oe aother ad do ot eed to sychroize their commuicatios simultaeously. Time-idepedet programs sychroize by leavig messages for each other i applicatio queues. Messages ca be dequeued i ay of several orderig schemes, such as first-i, first-out (FIFO) order, priority order, or time-based order. BEA Tuxedo cliet ad server programs ca equeue messages ad dequeue messages from queues. More tha oe cliet ad server ca access the same queue. Itroducig the BEA Tuxedo System 2-13

36 2 BEA Tuxedo System Architecture To use a applicatio queue, your program must ame the queue to be accessed ad the queue space i which it resides. Your applicatio ca use more tha oe queue space ad each space ca cotai more tha oe message queue. Because applicatio queues reside o a disk, the availability of stored messages is guarateed eve after machie failures. To determie whe the use of applicatio queues is appropriate, you eed to determie whe time-idepedet sychroizatio occurs i your busiess, for example, i fillig orders. Orders ca be equeued to disk ad depedig o specific order criteria, such as items or shipmet locatio, placed i differet queue spaces. Withi each queue space, you ca determie additioal criteria, such as cost, state, ad so o. See Also Usig Queue-based Commuicatio o page 1-15 i Tutorials for Developig a BEA Tuxedo Applicatio What Is Request/Reply Commuicatio To implemet request/reply commuicatio, the BEA Tuxedo system uses IPC message queues. Queues are the key to coectioless commuicatio. Each server is assiged a Iter-Process Commuicatio (IPC) message queue called a request queue ad each cliet is assiged a reply queue. Therefore, rather tha establishig ad maitaiig a coectio with a server, a cliet applicatio ca sed requests to the server by puttig those requests o the server s queue, ad the check ad retrieve messages from the server by pullig messages from its ow reply queue. The request/reply model is used for both sychroous ad asychroous service requests as described i the followig topics Itroducig the BEA Tuxedo System

37 What Is Request/Reply Commuicatio What Is Sychroous Messagig I a sychroous call, a cliet seds a request to a server, which performs the requested actio while the cliet waits. The server the seds the reply to the cliet, which receives the reply. Figure 2-7 Sychroous Request/Reply Commuicatio Itroducig the BEA Tuxedo System 2-15

38 2 BEA Tuxedo System Architecture What Is Asychroous Messagig I a asychroous call, the BEA Tuxedo cliet does ot wait for a service request it has submitted to fiish before udertakig other tasks. Istead, after issuig a request, the cliet performs additioal tasks (which may iclude issuig more requests). Whe a reply to the first request is available, the cliet retrieves it. Figure 2-8 Asychroous Request/Reply Commuicatio See Also Usig the Request/Respose Model (Sychroous Calls) o page 1-7 i Tutorials for Developig a BEA Tuxedo Applicatio 2-16 Itroducig the BEA Tuxedo System

39 What Is Usolicited Commuicatio What Is Usolicited Commuicatio The BEA Tuxedo system offers a powerful commuicatio paradigm called usolicited otificatio. Whe usolicited otificatio occurs, a BEA Tuxedo cliet receives a message that it has ever requested. This capability makes it possible for applicatio cliets to receive otificatio of applicatio-specific evets as they occur, without havig to request otificatio explicitly i real time. Usolicited messages ca be set to cliet processes by ame (tpbroadcast) or by a idetifier received with a previously processed message (tpotify). Messages set via tpbroadcast ca origiate either i a service or i aother cliet. You ca target a arrow or wide audiece. You ca sed a message with or without guarateed delivery to a idividual cliet through poit-to-poit otificatio (tpotify), or you ca sed iformatio to a group of cliets (tpbroadcast). For example, a server may alert a sigle cliet that the accout about which the cliet is iquirig has bee closed. Or, a server may sed a message to all the cliets o a machie to remid the users that the machie will be shut dow for maiteace at a specific time. Ay process that wats to be otified about a particular evet (such as a machie beig shut dow for maiteace) ca register a request, with the system, to be otified automatically. Oce registered, a cliet or server is iformed wheever the specified evet occurs. This type of automatic commuicatio about a evet is called usolicited otificatio. Because there is o limit to the umber of cliets ad servers that may geerate evets ad receive usolicited otificatio about such evets, the task of maagig this category of commuicatio ca become complex. The BEA Tuxedo system offers a tool for maagig usolicited otificatio called the EvetBroker. Itroducig the BEA Tuxedo System 2-17

40 2 BEA Tuxedo System Architecture Figure 2-9 Usolicited Notificatio Messagig See Also Usig Usolicited Notificatio o page 1-13 i Tutorials for Developig a BEA Tuxedo Applicatio What Are Nested ad Forwarded Service Requests Nested Requests A powerful feature of the BEA Tuxedo system is that it allows services to act as cliets ad call other services. Nestig is limited to two levels, which works particularly well i a 3-tier cliet/server architecture, that is, a system that comprises a presetatio logic layer, a busiess logic layer, ad a database layer. I such a system, the presetatio layer is used to formulate a request for a particular busiess fuctio that ivolves oe or more queries to a database. Because estig is limited to two levels, it does ot degrade performace Itroducig the BEA Tuxedo System

41 What Are Nested ad Forwarded Service Requests Figure 2-10 Nested Service Requests Beefit of Nested Requests Oe beefit of usig ested requests is that doig so eables you to keep your code small ad reusable, such that each piece performs a limited task. However, if the services i your system are distributed across several servers, ested requests ca lead to poor performace. While a ested request is beig processed, the origial service (that is, the service that issued the ested request) must wait for a respose before cotiuig. Util a respose is received, the origial service caot process aother request. As a result, messages ca get backed up i the request queue for the server o which this service resides. Example of a Nested Service Request A customer uses a cash machie to trasfer moey from her savigs accout to her checkig accout. A BEA Tuxedo applicatio performs the work ecessary to trasfer the moey. First, o behalf of the customer, the cliet issues a request for a service called TRANSFER, ad the request is placed o a queue for a server that provides that Itroducig the BEA Tuxedo System 2-19

42 2 BEA Tuxedo System Architecture service. Next, the TRANSFER service requests two other services, WITHDRAW ad DEPOSIT, which are processed by a secod server. The WITHDRAW ad DEPOSIT services retur resposes to the TRANSFER service. Fially, TRANSFER seds a respose to the cliet s respose queue. Whe the cliet retrieves the respose from the queue, the system displays a message o the scree of the cash machie, otifyig the customer that the trasfer is complete. Forwarded Requests Oe alterative to estig service requests is called request forwardig. Istead of processig a cliet s request, a service ca pass the request to aother service. The secod service, also, ca either process the request or pass it to aother service. Figure 2-11 Forwarded Service Requests 2-20 Itroducig the BEA Tuxedo System

43 How the BEA Tuxedo System Processes Messages There is o limit to the umber of times a request ca be forwarded. Because a service that forwards a request does ot eed to wait for a reply from the service receivig the request, forwardig, ulike estig requests, does ot block servers. Forwardig, however, is ot supported by the X/OPEN protocol X/ATMI, which may be a problem i some applicatios. See Also Usig Forwarded Calls o page 1-10 i Tutorials for Developig a BEA Tuxedo Applicatio Usig Nested Calls o page 1-9 i Tutorials for Developig a BEA Tuxedo Applicatio How the BEA Tuxedo System Processes Messages All commuicatio withi the BEA Tuxedo system is accomplished by trasferrig messages. The BEA Tuxedo system passes service request messages betwee cliets ad servers through operatig system Iter-Process Commuicatios (IPC) message queues. System messages ad data are passed betwee operatig system-supported memory-based queues of cliets ad servers i buffers. I the BEA Tuxedo system, messages are packaged i typed buffers, buffers that cotai both message data ad data idetifyig the types of message data beig set. Itroducig the BEA Tuxedo System 2-21

44 2 BEA Tuxedo System Architecture Figure 2-12 Processig a Request A cliet uses a ATMI fuctio to request a service by ame. A amig facility is used to check the MIB to determie whether the specified service is curretly available. The BEA Tuxedo system uses a automatic routig optio to map messages that meet specific criteria (message value) to a specific server. This is called data-depedet routig. If messages use data-depedet routig, the system uses the data i the buffer for the routig algorithm. This algorithm provides a method of selectig a group of servers that ca process the service request. To avoid burdeig a few servers with may requests while leavig other servers that advertise the same services idle, the BEA Tuxedo system maitais a set of metrics i the MIB that help it distribute service requests evely across all servers. This practice is called load balacig. A local service request may be prepared for a selected server ad equeued o that server s queue with a predefied priority. This practice is called service prioritizatio. Oce the service request is o the server, the ru-time system retrieves the message i priority order. The message is dispatched to the appropriate service ad processed. The the results are retured to the cliet queue. BEA Tuxedo system-provided software offers features that a applicatio ca automatically ad routiely use durig message processig. These features iclude: data ecodig ad decodig, data compressio ad decompressio, trasactioal 2-22 Itroducig the BEA Tuxedo System

45 How the BEA Tuxedo System Processes Messages cotext settig, ad security processig, to ame a few. I additio, the BEA Tuxedo system software ivokes applicatio busiess logic by dispatchig a service fuctio ad passig it to the appropriately preprocessed buffer. The service routie is executed ad returs a reply (also a typed buffer). The ru-time system prepares the reply for the cliet by ecodig the message automatically: it packages the data i such a way that it ca be trasmitted betwee machies o which differet types of byte orderig are used, allowig data to cross etwork ad platform boudaries. The system the seds the message to the cliet. This process is called data ecodig. The ru-time system o the cliet retrieves the reply message, decodes it if ecessary, ad delivers the FML buffers (or buffers of aother message buffer type) to package the applicatio data. Type validatio, ecodig, routig, ad load balacig are performed as required. Service requests ca be performed sychroously or asychroously. Remote requests travel through the local BRIDGE to the remote machie, where the remote BRIDGE simply acts as a cliet ad the request is processed as if the cliet ad server were o the same machie. The BRIDGE provides stadard data ecodig/decodig ad uses stadard etwork trasports to commuicate. BRIDGEs look like ordiary local servers to cliets ad servers. Itroducig the BEA Tuxedo System 2-23

46 2 BEA Tuxedo System Architecture What Are the Beefits of Service Request Processig Coectioless processig This processig, coupled with direct cliet/server commuicatio, reduces the overhead associated with establishig a coectio. Reduced etwork traffic Service requests ivoke potetially complex services o remote machies, sedig oly the miimum data required ad receivig miimal results. See Also What Are the BEA Tuxedo Messagig Paradigms o page 2-8 What Are Typed Buffers o page 2-24 What Are Typed Buffers All ATMI fuctios sed or receive data usig typed buffers. The BEA Tuxedo system hadles traslatios ad data coversios betwee dissimilar machies. By usig buffers, BEA Tuxedo programs avoid the eed to traslate data that crosses differet platforms with differet data represetatios. A buffer is a memory area that serves as a logical cotaier for data. Whe a buffer cotais o metadata (that is, o iformatio about itself), the it is a utyped buffer. Whe a buffer icludes metadata such as iformatio that ca be stored i it (for example, a type ad subtype, or strig ames that characterize a buffer), the it is a typed buffer. Typed buffers ca be trasmitted over ay etwork, o ay operatig system, with ay protocol supported by the BEA Tuxedo system. They ca also be used o platforms with differet data represetatios. As a result, the use of typed buffers facilitates the tasks of traslatio ad data coversio betwee dissimilar machies Itroducig the BEA Tuxedo System

47 What Are Typed Buffers The BEA Tuxedo system supports five sorts of typed buffers: STRING VIEW CARRAY FML XML You assig buffer types i the ENVFILE parameter defied i the MACHINES sectio of the cofiguratio file. Assigig or overridig them i the ENVFILE parameter i the SERVERS sectio of the cofiguratio file ca make them uavailable to processes that require them. Defiitios of the various types of message buffers are provided i the descriptio of tm_typesw i tuxtypes(5) i BEA Tuxedo File Formats ad Data Descriptios Referece. It is to your advatage to chage tm_typesw so it cotais oly buffer types specifically eeded by a give server. Characteristics of Buffer Types Whe you use ATMI commuicatio fuctios, your applicatio must first use tpalloc to get a buffer from the system, specifyig its size, type, ad optioally subtype. The BEA Tuxedo system recogizes ad processes the buffer type, so that your data is trasmitted over ay type of etwork, protocol, ad operatig system supported by the BEA Tuxedo system. The followig table describes the differet types of buffers available i a BEA Tuxedo eviromet. Itroducig the BEA Tuxedo System 2-25

48 2 BEA Tuxedo System Architecture Table 2-3 Buffer Types Characteristics This Typed Buffer CARRAY Is Defied As Follows Character array type is a collectio of characters that is hadled opaquely: Characters are ot iterpreted i ay way. No subtypes are specified. Your applicatio must specify the buffer legth for CARRAY message buffers used as iput to ATMI fuctios. Ad Is Used for Data that will ot be iterpreted by the BEA Tuxedo system ad for which data-depedet routig, ecodig, or decodig is ot required Itroducig the BEA Tuxedo System

49 What Are Typed Buffers This Typed Buffer Is Defied As Follows Ad Is Used for FML Field Maipulatio Laguage (FML) is a data structure that stores tagged values. Values are typed, may be specified more tha oce, ad vary i legth. The FML buffer is a abstract data type used i operatios to create, modify, delete, or access fields. I your program, you access or update a field i the fielded buffer by referecig the idetifier, ad the FML fuctio provides for a ru-time traslatio of the field s locatio ad data type, ad performs the operatio. Oe iterface to FML uses 16 bits (FML16) for field idetifiers ad legths of fields; the other uses 32 bits (FML32). The 16-bit versio allows for up to approximately 8000 uique fields, character strigs, ad arrays of up to 64,000 bytes, ad similar legths for the etire buffer. The 32-bit iterface allows for millios of uique fields ad buffer legths of up to two billio bytes. The fuctioality of the two iterfaces is idetical. The power of FML is i its flexibility. The size of the buffer ca vary, depedig o the eeds of the applicatio for each message. Character fields may also vary i legth, so wasted space is avoided. Fielded buffers offer data idepedece to the applicatio. Whe writig a applicatio, you do ot eed to kow how or where the data is stored withi a fielded buffer. FML provides associative field access, so you simply specify a field by ame ad its value is retured. FML also cotais coversio fuctios, so that you ca store or retrieve a field i a particular data format, regardless of the uderlyig storage type. FML buffers also support storage of more tha oe value for a field. The variable legth format of fielded buffers allows for multiple field occurreces to be stored ad retrieved. Fielded buffers provide a coveiet way to trasfer a collectio of fields, perhaps differet with each message, from a cliet to a server ad back, or to store fields i a applicatio queue. We recommed usig FML, particularly if the iterface betwee cliets ad servers may chage. Commuicatios Creatig, modifyig, deletig, or accessig fields durig operatios STRING A set of o-ull characters edig with a ull character. The data type is character ad the legth is determied by coutig characters i the buffer util reachig the ull character. No subtype is specified. C programs Itroducig the BEA Tuxedo System 2-27

50 2 BEA Tuxedo System Architecture This Typed Buffer VIEW XML (Extesib le Markup Laguage) Is Defied As Follows A VIEW is simply a C structure or a COBOL record that has a associated defiitio of which fields ad their types appear i the record i which order. This buffer is used for fixed collectios of data elemets, or structures or records; its subtype is used to specify the record format ame. VIEW records are flat data structures. They do ot support structures withi other structures, or do they allow arrays of structures or poiters. They support itegral data types such as log iteger, character, ad decimal. VIEWS are provided as a way to use C structures ad COBOL records with the BEA Tuxedo system. The BEA Tuxedo ru-time system uderstads the record format based o the view descriptio read at ru time. Whe allocatig a VIEW, your applicatio specifies a buffer type of VIEW ad a subtype that matches the ame of the view. The ru-time system ca do the followig: Determie how much space is eeded, based o structure size, so the applicatio eed ot specify buffer legth Compute how much data to sed i a request or respose, ad hadle ecodig ad decodig whe a message is trasferred betwee differet machie types XML buffers eable BEA Tuxedo applicatios to use XML for exchagig data withi ad betwee applicatios. BEA Tuxedo applicatios ca sed ad receive simple XML buffers, ad route those buffers to the appropriate servers. All logic for dealig with the XML documets, icludig parsig, resides i the applicatio. A XML documet cosists of: a sequece of characters that ecode the text of a documet ad a logical structure of the documet ad meta-iformatio related to the structure. The XML parser i the BEA Tuxedo system performs autodetectio of character ecodigs, character code coversio, detectio of elemet cotet ad attribute values, ad data type coversio. Data-depedet routig is supported for XML buffers. Ad Is Used for C structures ad COBOL records used with a BEA Tuxedo applicatio XML documets ad datagrams Data iterchage betwee humas ad machies, such as from a Web server to a user s browser Data exchage betwee applicatios, or from machie to machie 2-28 Itroducig the BEA Tuxedo System

51 Usig the MIB See Also Customizig a Buffer o page 3-28 i Programmig a BEA Tuxedo Applicatio Usig C Usig the MIB The MIB programmig iterface eables you to maage operatios i the BEA Tuxedo system easily. Specifically, it allows you to moitor, cofigure, ad tue your applicatio through your ow programs. The MIB ca be defied as: A implemetatio-idepedet maagemet database defied as a set of FML attributes A programmig iterface that eables you to query the BEA Tuxedo system (that is, to obtai iformatio from the system through a get operatio) or to update the BEA Tuxedo system (that is, to chage iformatio i the system through a set operatio) at ay time usig a set of ATMI fuctios. Examples of these fuctios iclude tpalloc, tprealloc, tpgetrply, tpcall, tpacall, tpequeue, ad tpdequeue. See Also MIB(5) i BEA Tuxedo File Formats ad Data Descriptios Referece Types of MIB Users o page 2-30 Classes, Attributes, ad States i the MIB o page 2-30 Itroducig the BEA Tuxedo System 2-29

52 2 BEA Tuxedo System Architecture Types of MIB Users The MIB defies three types of users: system admiistrators, system operators, ad others. The followig table describes each type. Type of User Applicatio admiistrator System operator Other Characteristics Perso resposible for keepig a applicatio ruig successfully. The admiistrator is authorized to use all admiistrative tools ad all MIB admiistrative capabilities. The admiistrator cofigures, maages, ad modifies a ruig productio applicatio. Moitors ad reacts to the daily operatio of a productio applicatio. The operator moitors statistics about a ruig applicatio, sometimes reactig to evets ad alerts by takig actios such as bootig servers or shuttig dow machies. A operator does ot recofigure a applicatio, add servers or machies, or delete machies. People or processes (such as custom programs) that may eed to read the MIB but are ot authorized to chage the applicatio. Classes, Attributes, ad States i the MIB Classes are the types of etities, such as servers ad machies, that make up a BEA Tuxedo applicatio. Attributes are characteristics of the objects i a class: idetity, state, cofiguratio parameters, ru-time statistics, ad so o. There are a umber of attributes that are commo to MIB operatios ad replies, ad commo to idividual classes. Every class has a state attribute that idicates the state of the object. The state of a object is either retur to the user or ew, chaged state, if you are ivokig a operatio o the MIB to chage a object s state Itroducig the BEA Tuxedo System

53 BEA Tuxedo Applicatio Processig Services Idepedet of classes is a set of commo attributes that are defied i the MIB(5) referece page. These attributes cotrol the iput operatios, commuicate to the MIB what the user is tryig to do, ad/or idetify to the programmer some of the characteristics of the output buffer that are idepedet of a particular class. BEA Tuxedo Applicatio Processig Services The BEA Tuxedo system offers the followig applicatio processig services: Data compressio Data-depedet routig Data ecodig Data ecryptio Data marshallig Load balacig Message prioritizatio Service ad evet amig What Is Data Compressio Data compressio is the process of shrikig a applicatio buffer so it ca be trasmitted more quickly across a etwork or to a remote domai. By settig a maximum size for a applicatio buffer, you ca make sure that compressio is triggered automatically for applicatio buffers that match or exceed a specified size. Whe the buffer arrives at its destiatio, its data is decompressed, that is, restored to its origial size. Data compressio, performed before files are shipped betwee machies, improves etwork performace. Itroducig the BEA Tuxedo System 2-31

54 2 BEA Tuxedo System Architecture The process of compressio ehaces security slightly because it ivolves scramblig the data. Note: Data compressio also occurs frequetly durig ecryptio. Figure 2-13 Data Compressio What Is Data-depedet Routig The BEA Tuxedo system uses a operatio called data-depedet routig to eable a cliet to sed requests for the same service to multiple copies of that service. Which copy of the service evetually accepts ad processes the request is determied by the data i the request message. Oce a admiistrator has set up data-depedet routig for a applicatio, cliet requests ca be routed automatically to servers based o the data i the requests. Whe a applicatio icludes multiple copies of the same service, each copy is assiged a uique purpose, just as the first volume of a multivolume ecyclopedia cotais etries that begi withe the letter A. A list of all copies of the service, alog with idetifyig iformatio about the purpose of each, is kept i a set of routig tables i the BEA Tuxedo bulleti board. Whe the system receives a cliet request, it fids a idetifyig strig i the request message ad searches the routig tables i the bulleti board for the same strig. O the basis of this match, the system idetifies the appropriate server to which it ca forward the cliet request. Note: The bulleti board routig tables ca be modified as ecessary Itroducig the BEA Tuxedo System

55 What Is Data-depedet Routig Uses of Data-depedet Routig Data-depedet routig is useful whe cliets issue service requests to: Horizotally partitioed databases Rule-based servers Distributed Applicatio A horizotally partitioed database is a iformatio repository that has bee divided ito segmets, each of which is used to store a differet category of iformatio. This arragemet is similar to a library i which each shelf of a bookcase holds books for a differet category (for example, biography, fictio, ad so o). A rule-based server is a server that determies whether service requests meet certai, applicatio-specific criteria before forwardig them to service routies. Rule-based servers are useful whe you wat to hadle requests that are almost idetical by takig slightly differet actios for busiess reasos. A distributed applicatio cosists of oe or more local or remote cliets that commuicate with oe or more servers o several machies liked through a etwork. A cliet (or server actig as a cliet) issues a request for a particular service. The address of the request is determied by data (carried i the same buffer that coveys the request), idetifyig the server that ca fulfill the request. More tha oe server may be able to do so. The BEA Tuxedo system selects a server to receive the request by matchig the data to the routig criteria provided i the bulleti board. Itroducig the BEA Tuxedo System 2-33

56 2 BEA Tuxedo System Architecture Example of Data-depedet Routig with a Horizotally Partitioed Database Suppose two cliets i a bakig applicatio issue requests for the curret balace i two accouts: Accout 3 ad Accout 17. If data-depedet routig is beig used i the applicatio, the the BEA Tuxedo system performs the followig actios: 1. Gets the accout umbers for the two service requests (3 ad 17). 2. Checks the routig tables o the BEA TUXEXDO bulleti board that show which servers hadle which rage of data. (I this example, server 1 hadles all requests for accouts 1 through 10; server 2 hadles all requests for accouts 11 through 20.) 3. Seds each request to the appropriate server. Specifically, the system forwards the request about Accout 3 to server 1, ad the request about accout 17 to server 2. The followig figure illustrates this process. Figure 2-14 Data-depedet Routig with a Horizotally Partitioed Database 2-34 Itroducig the BEA Tuxedo System

57 What Is Data-depedet Routig Example of Data-depedet Routig with Rule-based Servers A bakig applicatio icludes the followig rules: Customers ca withdraw up to $500 without eterig a special password. Customers must eter a special password to withdraw more tha $500. Two cliets issue withdrawal requests: oe for $100 ad oe for $800. If data-depedet routig is eabled to support the withdrawal rules, the the BEA Tuxedo system performs the followig actios: 1. Gets the amout specified for withdrawal i the two service requests ($100 ad $800). 2. Checks the routig tables o the BEA Tuxedo bulleti board that show which servers hadle request for the amout beig requested. (I this example, server 1 hadles all requests to withdraw amouts up to $500; server 2 hadles all requests to withdraw amout over $500.) 3. Seds each request to the appropriate server. Specifically, the system forwards the request for $100 to server 1 ad the request for $800 to server 2. The followig figure illustrates this process. Figure 2-15 Data-depedet Routig with Rule-Based Servers Itroducig the BEA Tuxedo System 2-35

58 2 BEA Tuxedo System Architecture Example of Data-depedet Routig with Distributed Applicatio The followig diagram shows how cliet requests are routed to servers. I this example, a bakig applicatio called bakapp uses data-depedet routig. bakapp has three server groups (BANK1, BANK2, ad BANK3) ad two routig criteria (Accout ID ad Brach ID). The services WITHDRAW, DEPOSIT, ad INQUIRY are routed usig the Accout_ID field; the services OPEN ad CLOSE are routed usig the Brach_ID field. Figure 2-16 Sample Bakig Applicatio Usig Routig Criteria 2-36 Itroducig the BEA Tuxedo System

59 What Are Ecodig ad Decodig of Data I the precedig diagram, requests are routed as idicated i the followig table. Withdrawals, Deposits, Iquiries, ad Opeigs or Closigs of the Followig Accouts... Numbers for braches 1 4 Numbers for braches 5 7 Numbers for braches 8 10 Are Routed to... Bak1 Bak2 Bak3 What Are Ecodig ad Decodig of Data Ecodig ad decodig eable messages with differet data represetatios (for example, byte orderig or character sets) to be trasferred betwee machies. The BEA Tuxedo system accomplishes this by ecodig ad decodig data to a machie-idepedet represetatio for trasmissio. It employs, by default, the XDR algorithm, which ca be customized by replacig the BEA Tuxedo system fuctios with user-writte fuctios. Ecodig ad decodig are used oly betwee machies ad oly whe a remote machie uses a data represetatio other tha the oe used o the local machie. Ecodig ad decodig allow machies with differet data architectures to operate withi a heterogeeous BEA Tuxedo system. Programmers ca maage data i represetatios atural to their ow eviromets. The BEA Tuxedo system uses buffer types to determie the type of fields cotaied i a message, ad to perform the mappig required for codig tasks. This mappig is ot performed by ustructured buffer types such as X_OCTET ad CARRAY. Thus, developers usig X_OCTET ad CARRAY buffers are free to deploy i mixed-machie eviromets. Itroducig the BEA Tuxedo System 2-37

60 2 BEA Tuxedo System Architecture What Is Data Ecryptio Ecryptio is the act of covertig a message ito a coded format that is uitelligible to users. Whe a ecrypted message arrives at its destiatio, it is decrypted, that is, coverted back to its origial format. Figure 2-17 Data Ecryptio Ecryptio does ot icrease the umber of bits i the data, but it adds processig time to the task of sedig a message. Because data is compressed durig ecryptio, however, lost processig time may be bought back, sice less data is beig set across the etwork. Whe data is compressed, there is also a moderate boost to security, because the data is somewhat scrambled durig compressio. What Is Data Marshallig Data marshallig is a method of hadlig iformatio through the laguage-based TxRPC (X/Ope-TxRPC) offered by the BEA Tuxedo system. TxRPC is a set of protocols for remote procedure calls that supports global trasactios. Though a TxRPC call looks like a local procedure call, whe a C fuctio is called, the argumets passed to the fuctio are packaged so they ca be set to a server that performs the work of the called fuctio. This argumet packagig is called marshallig. A fuctio s argumets are marshalled or packaged i a way that allows them to cross etwork ad platform boudaries, ad the umarshalled at their destiatio before beig passed to the ivoked remote procedure, ready for use Itroducig the BEA Tuxedo System

61 What Is Load Balacig This process is trasparet to the cliet (the callig program) ad the server (the remote procedure). The marshallig ad umarshallig routies are geerated automatically by the BEA Tuxedo Iterface Defiitio Laguage (IDL) compiler. A IDL compiler takes a descriptio of a set of RPCs ad geerates routies, called stubs, for the cliet ad server programs. These stubs cotai marshallig ad umarshallig logic, as well as the commuicatio logic that allows a cliet ad server to exchage marshalled data. Figure 2-18 Data Marshallig What Is Load Balacig Load balacig is a techique used by the BEA Tuxedo system for distributig service requests evely amog servers that offer the same service. This avoids overburdeig some servers while leavig others idle or ifrequetly used. Before sedig a request to a service routie, the system idetifies all servers capable of hadlig the request ad selects the oe most appropriate for maitaiig a balaced load across all the servers i the cofiguratio. Itroducig the BEA Tuxedo System 2-39

62 2 BEA Tuxedo System Architecture Assigig a Load Factor Load refers to a umber assiged to a service request based o the amout of time required to execute that service. Loads are assiged to services so that the BEA Tuxedo system ca uderstad the relatioship betwee requests. To keep track of the amout of work, or total load, beig performed by each server i a cofiguratio, the admiistrator assigs a load factor to every service ad service request. A load factor is a umber idicatig the amout of time eeded to execute a service or a request. O the basis of these umbers, statistics are geerated for each server ad maitaied o the bulleti board o each machie. Each bulleti board keeps track of the cumulative load associated with each server, so that whe all servers are busy, the BEA Tuxedo system ca select the oe with the lightest load. You ca cotrol whether a load-balacig algorithm is used o the system as a whole. Such as algorithm should be used oly whe ecessary, that is, oly whe a service is offered by servers that use more tha oe queue. Services offered by oly oe server, or by multiple servers i a MSSQ (multiple server sigle queue) do ot eed load balacig. The LDBAL parameter for these services should be set to N. I other cases, you may wat to set LDBAL to Y. To determie how to assig load factors (i the SERVICES sectio of UBBCONFIG), ru a applicatio for a log period of time ad ote the average time it takes to perform each service. Assig a LOAD value of 50 (LOAD=50) to ay service that takes roughly the average amout of time. Ay service takig loger tha average should have a LOAD>50; ay service takig less tha the average should have a LOAD< Itroducig the BEA Tuxedo System

63 What Is Message Prioritizatio Figure 2-19 Load Balacig What Is Message Prioritizatio Priorities determie the order i which service requests are dequeued by a server. Priority is assiged by a cliet to idividual services ad ca rage from 1 to100, where 100 represets the highest priority. All services are assiged a startig priority of 50. A server s startig priority ca be chaged durig applicatio cofiguratio. Oce you have defied your set of services, you ca assig the appropriate priorities to them. For example, your busiess may require that some services have a relatively high priority of 70, which meas those services are dequeued before those with the lower priority of 50. I the followig illustratio, a server offers services A (with a priority of 50, B (with a priority of 50), ad C (with a priority of 70). Itroducig the BEA Tuxedo System 2-41

64 2 BEA Tuxedo System Architecture Figure 2-20 Prioritizatio of Messages A request for service C is always dequeued before a request for A or B due to the higher priority of C. Requests for A ad B have equal priority. This feature is useful i applicatios i which ot all requests are equally urget or importat. A starvatio prevetio mechaism prevets low-priority messages from waitig edlessly o the queue. Every teth message is dequeued i FIFO (first i first out) order regardless of priority; the first through the ith messages are dequeued i order of priority. What Is Meat by Namig The BEA Tuxedo system uses three amig devices: service ames, message queue ames, ad evet ames. Names ca be ay words or alphaumeric strigs, as log as they do ot begi with a period (. ). Because admiistrative servers use the BEA Tuxedo system ifrastructure, system ad applicatio resources must be clearly distiguished. Namig Services Whe services are amed, a applicatio compoet ca locate aother compoet through a ame. Names ca be simple words (such as deposit ) or alphaumeric strigs (such as deposit2 ). Names should be selected o the basis of the scope of the 2-42 Itroducig the BEA Tuxedo System

65 What Is Meat by Namig applicatio ad a map that cotais the global picture of the relatioships amog applicatio compoets. These maps or services are like the pages i a telephoe book for applicatio compoets. Whe a BEA Tuxedo system server is activated, the bulleti board (the dyamic part of the MIB) advertises the ames of its services. Service ames are associated with a server s physical address so that requests ca be routed to that server. Names that programmers use i their applicatios are completely locatio trasparet. Whe a cliet program asks for a service by ame, the BEA Tuxedo system cosults its ame registry i the bulleti board. The ame registry provides the iformatio ecessary to covert the strig ame (for example, TICKET) to a machie ame ad the physical address of a server that advertises that service. The BEA Tuxedo system the seds the request to the appropriate server. Figure 2-21 Locatig a Service by Name Advertisig Services The BEA Tuxedo system uses two admiistrative servers to coordiate the distributio of iformatio o the bulleti board to all active machies i the applicatio: DBBL The Distiguished Bulleti Board Liaiso server propagates global chages to the MIB ad maitais the static part of the MIB. The DBBL coordiates the state of differet machies ivolved i a applicatio. Oly oe DBBL exists for a etire applicatio. It ca be migrated to other machies for fault resiliecy. BBL The Bulleti Board Liaiso server maitais the bulleti board. A BBL resides o every active machie i a applicatio. The BBL coordiates chages to the local MIB ad verifies the itegrity of applicatio programs active o its machie. Itroducig the BEA Tuxedo System 2-43

66 2 BEA Tuxedo System Architecture Namig Evets The BEA Tuxedo system offers a publish-ad-subscribe mechaism: cliets ad servers ca dyamically register or uregister a stadig request to receive alerts (or messages) whe a particular evet occurs. Other cliets ad servers post user-defied or system evets as they occur i the applicatio. Whe a cliet or server o loger eeds to be otified about a particular evet, the relevat subscriptio ca be cacelled. See Also How the EvetBroker Works o page 2-10 BEA Tuxedo Admiistrative Services A set of system servers provides the followig admiistrative services eeded by the BEA Tuxedo system: Applicatio queue maagemet Cetralized applicatio cofiguratio Distributed applicatio maagemet Dyamic applicatio recofiguratio Evet maagemet Security maagemet Startup ad shutdow of a applicatio Trasactio maagemet Workstatio maagemet Note: For iformatio o admiistrative services, see the topic, Three Ways of Viewig the BEA Tuxedo System Ifrastructure o page Itroducig the BEA Tuxedo System

67 CHAPTER 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Basic BEA Tuxedo System Ifrastructure Maagemet View: Usig Admiistrative Tools BEA Tuxedo Admiistrative Services Developmet View: What You Ca Do Usig the ATMI Ru-Time System View: Usig Tools i Differet Cofiguratios Basic BEA Tuxedo System Ifrastructure The BEA Tuxedo system provides a ifrastructure for the efficiet routig, dispatchig, ad maagemet of applicatio service requests, evet postigs ad otificatio, ad applicatio queues. This ifrastructure ca be explored from three perspectives: Admiistrative or maagemet perspective Ecompasses a variety of tools available to maage your applicatio. Developmet (usig the ATMI) perspective Ecompasses those tasks you ca perform usig the ATMI. Cliets request services through the ATMI. Server Itroducig the BEA Tuxedo System 3-1

68 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure programs group several services, which are ivoked accordig to the rules defied by the ATMI. Applicatio desigers costruct cliet ad server programs by likig the BEA Tuxedo ru-time system with their applicatio code. BEA Tuxedo ru-time system view Ecompasses sigle, distributed, ad multiple domai cofiguratios. Maagemet View: Usig Admiistrative Tools The BEA Tuxedo System MIB cotais all the iformatio ecessary for the operatio of a applicatio. The MIB is desiged to be programmable, so that you ca write custom admiistrative programs. Admiistrative tools are costructed aroud the MIB ad provide differet types of iterfaces to it. These tools iclude the followig: BEA Admiistratio Cosole a Web-based tool used to moitor a applicatio, ad to dyamically cofigure it. BEA Tuxedo admiistrative servers servers that automate most of the maagemet tasks for a distributed applicatio, such as amig services ad evets, startig up ad shuttig dow a applicatio, dyamically recofigurig a applicatio, ad so o. BEA Tuxedo MIB Applicatio Programmig Iterface a set of fuctios for accessig ad modifyig iformatio i the MIB. Commad-lie utilities a set of commads used to activate, deactivate, cofigure, ad maage a applicatio (that is, tmboot, tmshutdow, tmcofig, ad tmadmi, respectively). (See BEA Tuxedo Commad Referece.) EvetBroker a mechaism that iforms admiistrators of faults or exceptioal happeigs. 3-2 Itroducig the BEA Tuxedo System

69 Maagemet View: Usig Admiistrative Tools Figure 3-1 Tools to Admiister Your Applicatio Available BEA Tuxedo System MIBs The Maagemet Iformatio Base comprises a core MIB, which is commo to all applicatios, ad several compoet MIBs, which are optioal. The core MIB, called TM_MIB, defies the parts of a applicatio that are required i every BEA Tuxedo applicatio. It is also used to admiister those parts of a applicatio. TM_MIB defies a BEA Tuxedo system applicatio as a set of classes (for example, servers, groups, machies, domais), each of which is made up of objects that are characterized by various attributes (for example, idetity ad state). Each of the compoet MIBs describes a subsystem of the BEA Tuxedo system. The followig compoets are curretly available: ACL_MIB used to admiister Access Cotrol Lists APPQ_MIB used to admiister applicatio stable-storage queues EVENT_MIB used to cotrol evet otificatio ad the subscriptio request database WS_MIB used to maage Workstatio groups ad processes associated with them Itroducig the BEA Tuxedo System 3-3

70 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Usig the BEA Admiistratio Cosole The BEA Admiistratio Cosole is a graphical user iterface to the BEA Tuxedo system, specifically to the MIB. It is accessed through the World Wide Web. The BEA Admiistratio Cosole makes commo admiistrative fuctios available through a browser. It allows ay user with the curretly available browser to admiister a BEA Tuxedo applicatio. To use the BEA Admiistratio Cosole, perform the followig tasks: 1. Poit your browser to the URL for a machie i your domai o which the Cosole server compoets reside. 2. Iitiate a dowload of Java applets. The applets implemet the Cosole ad establish commuicatio with the server. Browser Requiremets Each release of the BEA Tuxedo system supports the curretly available browsers. Cosult the followig BEA Web site for iformatio about browsers curretly supported by the BEA Admiistratio Cosole. See Also Beefits of Usig the BEA Admiistratio Cosole o page 3-5 Explorig the Mai Meu of the BEA Admiistratio Cosole o page 3-6 Ways to Moitor Your Applicatio o page 2-2 i Admiisterig a BEA Tuxedo Applicatio at Ru Time 3-4 Itroducig the BEA Tuxedo System

71 Beefits of Usig the BEA Admiistratio Cosole Beefits of Usig the BEA Admiistratio Cosole Autheticatio The BEA Admiistratio Cosole forces users to idetify themselves. It prompts the admiistrator for a user ame ad password. This iformatio is commuicated i a ecrypted fashio betwee the browser ad the server, where the user s idetity is the verified. (Much of the server setup is doe durig istallatio, whe server compoets of the Cosole are istalled ad made available to the Web server.) Cotext-sesitive help Cotext-sesitive help is available for all Cosole screes ad tools. You ca request iformatio about ay field or area of a scree simply by draggig a questio mark ico to that field or ay area ad clickig. Ecryptio The data trasferred betwee the server side ad the browser is compressed (56-bit or 128-bit ecryptio) so that o oe ca read it. This makes the system resistat to ayoe tryig to iject false admiistrative protocol messages ito the stream. Firewall readiess The port o which the BEA Admiistratio Cosole server listes ad iteracts with the browser is well defied ad cofigurable; you ca cofigure it to match ports that you wat to allow through your firewall. This capability eables you to do Cosole-based admiistratio through your firewall, if ecessary. Icos The icos used i the BEA Admiistratio Cosole coote state (for example, ot active) or represet particular objects i the applicatio, for example, machies or servers. Java-capable browser The Java browser supports the Java virtual machie that rus the applets ad eables commuicatio. No cliet-side istallatio No istallatio is required o your machie. Poit your browser to the URL for a machie i your domai o which the Cosole server compoets reside. The iitiate a dowload of Java applets. The applets implemet the Cosole ad establish commuicatio with the server. Uiversal secure access From ay Java-capable browser, you ca access the system from aywhere i the world with cofidece that security mechaisms are already i place. Itroducig the BEA Tuxedo System 3-5

72 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Explorig the Mai Meu of the BEA Admiistratio Cosole Whe you first brig up the Web ad ivoke the BEA Admiistratio Cosole, the mai widow is displayed. The mai widow is divided ito four major sectios: MENU BAR A row of frequetly used meus. POWER BAR A row of buttos that provide shortcuts to frequetly used tools, such as Help. TREE A hierarchical represetatio of the admiistrative class objects (such as servers ad cliets) i a BEA Tuxedo system domai. CONFIGURATION TOOL A set of tabbed folders o which you ca display, defie, ad modify the attributes of objects, such as the ame of a machie. 3-6 Itroducig the BEA Tuxedo System

73 Explorig the Mai Meu of the BEA Admiistratio Cosole Figure 3-2 Mai Meu of the Admiistratio Cosole Note: The Power Bar buttos ad some meu items are ot fully displayed uless you are coected to a domai. Usig the Cofiguratio Tool As soo as you start usig the Cofiguratio Tool, the right-had colum dedicated to that tool is populated with tabbed folders i which you eter iformatio eeded for cofiguratio. The tabbed folders i the Cofiguratio Tool area are electroic forms that display ad solicit iformatio about the attributes of a admiistrative object. A set of folders is provided for each admiistrative class of objects (such as machies ad servers). The Itroducig the BEA Tuxedo System 3-7

74 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure umber of attributes associated with a class varies greatly, depedig o the class. Therefore, you may fid aywhere from oe to eight folders displayed whe you ivoke the tabbed folders for a selected object. Whe the Cofiguratio Tool area is populated, aother row of buttos is displayed i the mai widow, below the tabbed folders. These four buttos allow you to cotrol the cofiguratio work doe i the folders. What Is the Tree The Tree, which appears i the left-had colum of the mai BEA Admiistratio Cosole widow, is a hierarchical represetatio of the admiistrative objects that make up a sigle BEA Tuxedo system domai. The BEA Admiistratio Cosole graphically depicts the relatioship betwee each object ad the others by showig its estig level ad paret objects. You ca choose to view a complete Tree (comprisig all cofigurable objects of all types i the domai) or a subset of objects. After you have set up ad activated a domai, the Tree is populated with labeled icos, represetig the admiistrative class objects i your domai. What Is a Admiistrative Object The Tree cosists of a list of classes. Uder each class ame, the Tree provides a list of the objects icluded i that class. For example, suppose your domai icludes two machies (both at SITE1) amed romeo ad juliet. Both machies are listed i the Tree below the ame of the class to which they belog: Machies. Thus they will be listed as follows: Machies SITE1/romeo SITE1/juliet The ame of each object i the Tree is preceded by a ico. Each machie, for example, is represeted by a computer; each cliet, by a huma figure. 3-8 Itroducig the BEA Tuxedo System

75 Explorig the Mai Meu of the BEA Admiistratio Cosole Usig the Power Bar The Power Bar appears ear the top of the mai BEA Admiistratio Cosole widow, immediately below the Meu Bar. The Power Bar is a row of 12 buttos that allow you to ivoke tools for frequetly performed admiistrative operatios. They are labeled with both icos ad ames. The followig table explais the purpose of each butto. Press Stop Refresh Search Activate Deactivate Migrate Logfile Evet Tool Stats Optios CS Help To Iterrupt the curret operatio ad retur cotrol to the admiistrator (who ca the request a ew operatio). Redraw the curret widow to clarify text ad graphics. Look for a particular object class or object i the Tree. Begi the etire BEA Tuxedo system cofiguratio or a selected part of it. Termiate the etire BEA Tuxedo system cofiguratio or a selected part of it. Move a server group or machie to a alterative locatio, or swap the MASTER ad BACKUP machies. Display the ULOG file from a particular machie i the active domai. Moitor system evets. View a graphical represetatio of BEA Tuxedo system activity. Assig parameters for your admiistrative BEA Admiistratio Cosole sessio: (a) specify the locatio of olie documetatio; (b) have objects sorted by ame or class; ad (c) specify view-oly or edit mode as your default workig mode. Get cotext-sesitive help. Click o a desigated area i a BEA Admiistratio Cosole widow. A help widow opes, displayig text about the selected topic. Itroducig the BEA Tuxedo System 3-9

76 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Press Help To Go to the begiig of the Admiistratio topics, so you ca choose iformatio that will be most helpful to you. Maagig Operatios Usig the MIB The AdmiAPI is a applicatio programmig iterface (API) for directly accessig ad maipulatig system settigs i the BEA Tuxedo Maagemet Iformatio Bases (MIBs). You ca use the AdmiAPI to automate admiistrative tasks, such as moitorig log files ad dyamically recofigurig a applicatio, thus elimiatig the eed for huma itervetio. This advatage ca be crucially importat i missio-critical, real-time applicatios. Usig the MIB programmig iterface, you ca maage operatios i the BEA Tuxedo system easily. Specifically, you ca moitor, cofigure, ad tue your applicatio through your ow programs. The MIB ca be defied as: A implemetatio-idepedet maagemet database defied as a set of FML attributes A programmig iterface that eables you to query the BEA Tuxedo system (that is, to obtai iformatio from the system through a get operatio) or to update the BEA Tuxedo system (that is, to chage iformatio i the system through a set operatio) at ay time usig a set of ATMI fuctios. Examples of these fuctios iclude tpalloc, tprealloc, tpgetrply, tpcall, tpacall, tpequeue, ad tpdequeue. See Also MIB(5) i BEA Tuxedo File Formats ad Data Descriptios Referece Types of MIB Users o page 3-11 Classes, Attributes, ad States i the MIB o page Itroducig the BEA Tuxedo System

77 Types of MIB Users Types of MIB Users The MIB defies three types of users: system admiistrators, system operators, ad others. The followig table describes each type. Type of User Applicatio admiistrator System operator Other Characteristics Perso resposible for keepig a applicatio ruig successfully. The admiistrator is authorized to use all admiistrative tools ad all MIB admiistrative capabilities. The admiistrator cofigures, maages, ad modifies a ruig productio applicatio. Perso resposible for moitorig ad reactig to the daily operatio of a productio applicatio. A operator moitors statistics about a ruig applicatio, sometimes reactig to evets ad alerts by takig actios such as bootig servers or shuttig dow machies. A operator does ot recofigure a applicatio, add servers or machies, or delete machies. People or processes (such as custom programs) that may eed to read the MIB but are ot authorized to chage the applicatio. Classes, Attributes, ad States i the MIB Classes are the types of etities such as servers ad machies that make up a BEA Tuxedo applicatio. Attributes are characteristics of the objects i a class: idetity, state, cofiguratio parameters, ru-time statistics, ad so o. There are a umber of attributes that are commo to MIB operatios ad replies ad commo to idividual classes. Every class has a state attribute that idicates the state of the object. The state of a object is either retur to the user or ew, chaged state, if you are ivokig a operatio o the MIB to chage a object s state. Itroducig the BEA Tuxedo System 3-11

78 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Idepedet of classes is a set of commo attributes that are defied i the MIB(5) referece page. These attributes cotrol the iput operatios, commuicate to the MIB what the user is tryig to do, ad/or idetify to the programmer some of the characteristics of the output buffer that are idepedet of a particular class. Usig Commad-Lie Utilities The BEA Tuxedo system provides a set of commads for maagig differet parts of the system. The commads eable you to access commo admiistrative utilities. These utilities ca be used for the followig tasks: Cofigurig your applicatio usig commad-lie utilities Operatig your applicatio usig commad-lie utilities Moitorig your applicatio usig commad-lie utilities Cofigurig Your Applicatio Usig Commad-lie Utilities You ca cofigure your applicatio by usig commad-lie utilities such as the vi text editor. Specifically, you ca use commad-lie utilities to write the cofiguratio file, UBBCONFIG, ad traslate the file from a text format (UBBCONFIG) to a biary format (TUXCONFIG), by ruig the tmloadcf commad. The you are ready to boot your applicatio. You ca dyamically admiister your cofiguratio by addig servers or machies, deletig machies, ad so forth. Updatig TUXCONFIG (the biary file versio), however, does ot update the UBBCONFIG (the text file versio). To sychroize both files, you eed to back them up. To do this, you traslate the biary file back to text by ruig the tmuloadcf commad Itroducig the BEA Tuxedo System

79 Cofigurig Your Applicatio Usig Commad-lie Utilities Note: The UBBCONFIG is geerated ad stored by the applicatio admiistrator i the applicatio directory (APPDIR). Followig is a list of commo commad-lie utilities that you ca use to cofigure your applicatio. tmcofig a commad that eables you to update some cofiguratio file parameters, or MIB attributes, ad add records to some TUXCONFIG sectios while the BEA Tuxedo system applicatio is ruig. tmloadcf a commad that allows you to load the biary TUXCONFIG cofiguratio file. tmuloadcf a commad that allows you to traslate the biary cofiguratio file back to a text versio, so that UBBCONFIG ad TUXCONFIG ca be sychroized. tpacladd, tpaclcvt, tpacldel, ad tpaclmod a set of commads that allow you to create or maage access cotrol lists for applicatios. These commads eable the use of security-related authorizatio features. tpgrpadd, tpgrpdel, tpgrpmod a set of commads that allow you to create ad maage user groups by usig access cotrol lists to authorize access to services, queues, ad evets. tpusradd, tpusrdel, tpusrmod a set of commads that allow you to create ad maage a user database for authorizatio purposes. See Also UBBCONFIG(5) i BEA Tuxedo File Formats ad Data Descriptios Referece Creatig the Cofiguratio File o page 3-22 Makig Permaet Cofiguratio Chages o page 3-24 Itroducig the BEA Tuxedo System 3-13

80 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Operatig Your Applicatio Usig Commad-lie Utilities Oce you have cofigured your applicatio successfully, you ca use the followig commad-lie utilities to operate your applicatio. tmadmi a commad that allows you to cofigure, moitor, ad tue a distributed applicatio. tmboot a commad that allows you to cetrally start up your applicatio servers for a distributed applicatio. tmshutdow a commad that allows you to cetrally shut dow a applicatio program across a distributed applicatio. Maagig System Evets Usig EvetBroker The BEA Tuxedo EvetBroker performs the followig tasks: Moitors evets ad otifies subscribers whe evets are posted via tppost(3c). Keeps a admiistrator iformed of chages i a applicatio by trackig evets. Ehaces evet moitorig by providig a system-wide summary of evets. Provides a mechaism through which a evet ca trigger a variety of otificatio activities. The EvetBroker recogizes over 100 meaigful state trasitios i a MIB object as system evets. The postigs for system evets iclude the curret MIB represetatio of the object o which the evet has occurred, ad some evet-specific fields that idetify the evet that occurred. For example, if a machie is partitioed, a evet is posted with the followig iformatio: The ame of a machie class object (T_MACHINE), with all the attributes of that machie 3-14 Itroducig the BEA Tuxedo System

81 What Is a Evet Some evet attributes idetifyig the evet as machie partitioed You ca use the EvetBroker simply by subscribig to system evets. The, istead of havig to query for MIB records, you ca be iformed automatically whe evets occur i the MIB by receivig FML data buffers represetig MIB objects. See Also What Is a Evet o page 3-15 Subscribig to a Evet o page 3-16 Types of Evets o page 3-17 Usig Evet-based Commuicatio o page 1-14 i Tutorials for Developig a BEA Tuxedo Applicatio What Is a Evet A evet is a state chage or other occurrece i a ruig applicatio that may warrat special attetio from a operator, a admiistrator, or the software. I the EvetBroker, evets are assiged oe of three severity levels: Error, for example, a server has died or a etwork coectio has bee dropped Iformatioal, for example, a state chage has occurred as a result of a process or the detectio of a cofiguratio chage Warig, for example, a cliet has ot bee allowed to joi the applicatio after failig autheticatio Itroducig the BEA Tuxedo System 3-15

82 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Subscribig to a Evet As the admiistrator for your BEA Tuxedo applicatio, you ca eter subscriptio requests o behalf of a cliet or server process through calls to the EVENT_MIB(5). You use tpsubscribe to subscribe to a evet usig the EvetBroker. You may wat to subscribe to Evets A, B, ad C ad request to be iformed whe they occur. Each subscriptio specifies oe of the followig otificatio methods: Cliet otificatio The EvetBroker keeps track of the cliet s iterest i these evets ad a cliet is otified i the form of usolicited otificatio. Some evets are aoymously posted. A cliet ca joi a applicatio, idepedet of whether ayoe else has subscribed, ad post evets to the EvetBroker. The EvetBroker matches these evets agaist its database of subscriptios ad seds a usolicited otificatio to the appropriate cliets. Service calls If the subscriber wats evet otificatios to go to service calls, the the ctl parameter must poit to a valid TPEVCTL structure. Message equeuig to stable-storage queues For subscriptios to stable-storage queues, the queue space, queue ame, ad correlatio idetifier are used, i additio to evetexpr ad filter, whe determiig matches. The correlatio idetifier ca be used to differetiate amog several subscriptios for the same evet expressio ad filter rule, destied for the same queue. Placig messages o the ULOG Usig the T_EVENT_USERLOG class of EVENT_MIB, subscribers ca write system USERLOG messages. Whe evets are detected ad matched, they are writte to the USERLOG. Commad-lie utilities Usig the T_EVENT_COMMAND class of EVENT_MIB, the EvetBroker tracks ad matches evets. Whe a match is foud, it is passed to the commad used whe subscribig to the evet. Note: Notificatio methods are determied by the subscriber process type ad the argumets passed to tpsubscribe Itroducig the BEA Tuxedo System

83 Types of Evets Figure 3-3 Subscribig to a Evet See Also EVENT_MIB(5) i BEA Tuxedo File Formats ad Data Descriptios Referece tpsubscribe(3c) i BEA Tuxedo C Fuctio Referece Types of Evets The BEA Tuxedo system supports two evet types: System Evets provide details about BEA Tuxedo system evets, such as servers dyig, ad etwork failures. Whe a evet is posted by cliets or servers, the EvetBroker matches the posted evet s ame to a list of subscribers for that evet ad takes appropriate actio, as determied by each subscriptio. User Evets or Applicatio-specific Evets allow applicatio programs to post evets whe certai criteria are met. A example is a bakig applicatio that posts a evet for withdrawals over a certai limit. Itroducig the BEA Tuxedo System 3-17

84 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Differeces betwee System ad Applicatio-specific Evets The followig table idetifies the differeces betwee system ad applicatio-specific evets. Table 3-1 Differeces betwee System ad Applicatio-specific Evets Area Evets Evet List Subscriptios Differeces System evets are defied i advace by the BEA Tuxedo system code. For a applicatio, desigers decide which applicatio evets should be moitored. Applicatio programs are writte to: (a) detect whe a evet of iterest has occurred, ad (b) post the evet to the EvetBroker through tppost. A list of the applicatio evet subscriptios is made available to iterested users just as the BEA Tuxedo system provides a list of system evets available to users with EVENTS(5). System evet ames begi with a dot (. ); applicatio-specific evet ames may ot begi with a dot (.). Subscribig to a evet i a applicatio-specific evet broker is similar to subscribig to the BEA Tuxedo System EvetBroker. You subscribe by makig calls to tpsubscribe usig the published list of evets for the applicatio. EVENTS(5) lists the otificatio message geerated by a evet as well as the evet ame (used as a argumet whe tppost is called). Subscribers ca use the wild card capability of regular expressios to make a sigle call to tpsubscribe that covers a whole category of evets Itroducig the BEA Tuxedo System

85 BEA Tuxedo Admiistrative Services BEA Tuxedo Admiistrative Services A set of system servers provides the followig admiistrative services eeded by the BEA Tuxedo system: Applicatio queue maagemet Cetralized applicatio cofiguratio Distributed applicatio maagemet Dyamic applicatio recofiguratio Evet maagemet Security maagemet Startup ad shutdow of a applicatio Trasactio maagemet Workstatio maagemet Itroducig the BEA Tuxedo System 3-19

86 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Maagig Applicatio Queues Queueig eables programmers to write applicatios that commuicate by accessig oe or more queues. Because of the locatio trasparecy of queues, admiistrators ca move queues from oe machie to aother without requirig ay programmig chages. The MIB cosists of a queue device, queue spaces, ad queues (required by a applicatio), ad the BEA Tuxedo system servers that equeue ad dequeue messages from a queue space. Admiistrators ca use the BEA Admiistratio Cosole or commad lie utilities to defie the queue spaces, queues, ad admiistrative servers i the MIB. Usig qmadmi to Admiister Applicatio Queues The commad-lie utility qmadmi allows you to perform all admiistratio fuctios for the applicatio queues i a cofiguratio, that is, settig up the uiversal device list (UDL) ad volume table of cotets (VTOC) that will cotai a queue, defiig queue spaces withi a queue device, ad so o. qmadmi eables you to maipulate the file system. Usig some ru-time moitorig capabilities, you ca see how may messages are i queues or how may headers are i messages. You ca also chage characteristics of queues or messages o queues, delete messages o queues, chage the size of devices, ad so o. I a applicatio you ca have multiple applicatio queue devices, ad ru applicatio queues o multiple machies. Each machie has its ow queue device, so you ca ru qmadmi to moitor ad maage a particular applicatio queue device o each machie. Utility qmadmi Descriptio Provides for the creatio, ispectio ad modificatio of message queues. The ame of the device (file) o which the uiversal device list resides (or will reside) for the queue space may either be specified as a commad lie argumet or through the eviromet variable QMCONFIG. If both are specified, the commad optio is used Itroducig the BEA Tuxedo System

87 Maagig Applicatio Queues Usig tmcofig to Modify Your Cofiguratio The tmcofig commad eables you to browse ad modify the TUXCONFIG file ad its associated etities, ad to add ew compoets (such as machies ad servers) while your applicatio is ruig. Whe you modify your cofiguratio file (TUXCONFIG o the MASTER machie), the tmcofig commad: Updates the TUXCONFIG file o all machies i the applicatio that are curretly booted. Propagates the TUXCONFIG file automatically to ew machies as they are booted. Rus as a BEA Tuxedo system cliet. Note: Refer to the tmcofig, wtmcofig(1) ad TM_MIB(5) i BEA Tuxedo Commad Referece ad BEA Tuxedo File Formats ad Data Descriptios Referece for iformatio o the sematics, rage values, ad validatio of cofiguratio parameters. Itroducig the BEA Tuxedo System 3-21

88 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Maagig Your Cofiguratio The cofiguratio of ay applicatio is primarily cotrolled by the creatio ad maiteace of a cofiguratio file, or UBBCONFIG file. Maagig your cofiguratio ivolves the followig tasks: Creatig the cofiguratio file to suit your applicatio eeds Makig permaet cofiguratio chages by updatig the UBBCONFIG file Chagig your cofiguratio while the applicatio is ruig Creatig the Cofiguratio File Applicatio cofiguratio data is maitaied i the UBBCONFIG, a ordiary text file o the MASTER machie. The cofiguratio file (UBBCONFIG) is a repository that cotais all the iformatio ecessary to boot a applicatio, such as lists of its resources, machies, groups, servers, available services, ad so o. Oce writte, the UBBCONFIG file is compiled ito a biary file, TUXCONFIG. (If you are developig a multi-domai applicatio, you must provide a cofiguratio file for each domai i the applicatio.) A applicatio caot ru without a cofiguratio file. The UBBCONFIG file cosists of eight sectios, five of which are required for all cofiguratios: RESOURCES, MACHINES, GROUPS, SERVERS, ad SERVICES. The RESOURCES ad MACHINES sectios must be the first ad secod sectios, respectively (as illustrated i the followig diagram). GROUPS must be ahead of SERVERS ad SERVICES Itroducig the BEA Tuxedo System

89 Creatig the Cofiguratio File Figure 3-4 UBBCONFIG File RESOURCES (required) cotais system-wide parameters that describe the applicatio as a whole MACHINES (required) cotais logical ames ad types of physical machies GROUPS (required) associates servers with resource maagers ad machies SERVERS idetifies each server i the applicatio SERVICES idetifies each service, ad specifies priority, loadig, ad so o NETWORK cotais cofiguratio data for LAN eviromets ROUTING cotais data-depedet routig tables NETGROUPS allows for multiple BRIDGEs per machie Your particular cofiguratio determies which sectios of the UBBCONFIG file are required. Oce you have writte your UBBCONFIG file, you must compile it ito a biary file called TUXCONFIG. You ca geerate your TUXCONFIG file by ruig the the tmloadcf(1) commad or by usig the BEA Admiistratio Cosole. See Also How to Create a Cofiguratio File o page 3-2 i Settig Up a BEA Tuxedo Applicatio Itroducig the BEA Tuxedo System 3-23

90 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Makig Permaet Cofiguratio Chages To make permaet cofiguratio chages, the admiistrator ca use a text editor to update the cofiguratio parameters i the UBBCONFIG file, ad use the tmloadcf utility to load the text file ito the biary TUXCONFIG file used by the BEA Tuxedo system. Whe the applicatio is started, tmboot loads TUXCONFIG ito shared memory to establish the bulleti board, propagatig the chages to remote machies if ecessary. Figure 3-5 Cofiguratio Maagemet 3-24 Itroducig the BEA Tuxedo System

91 Maagig Your Cofiguratio Dyamically Maagig Your Cofiguratio Dyamically Admiistrators ca use the BEA Admiistratio Cosole or the BEA Tuxedo system commad-lie utilities to recofigure applicatios dyamically, adjustig parameters to respod to varyig system loads while the system is ruig. A revised TUXCONFIG file is propagated automatically to all machies i the system as it is updated. However, may RESOURCES parameters caot be chaged while the system is ruig. Examples of tasks you ca do dyamically iclude: addig servers or machies, deletig machies, ad so forth. To esure that the text ad biary versios of your cofiguratio file (UBBCONFIG ad TUXCONFIG, respectively) always match, you eed to back them up ad sychroize them by usig tmuloadcf. This commad traslates the biary file to a text versio. You ca chage most elemets of the system dyamically. You ca, for example, spaw ew servers, add ew machies, or chage time-out parameters. There are, however, a few thigs you caot chage while a system is ruig: Ay parameter i the cofiguratio file that affects the size ad shape of the bulleti board caot be chaged. May such parameters are amed with the prefix MAX, such as the MAXGTT parameter, which specifies the maximum umber of i-flight trasactios allowed withi the BEA Tuxedo system at ay time. The processor ame of a machie withi a particular applicatio caot be chaged. (You ca add ew machies with differet ames but you caot chage the ame of a existig machie.) The values of server executables, assiged to ru o MASTER ad BACKUP machies, caot be chaged. See Also Performig Dyamic Operatios Usig tmadmi(1) o page 3-26 Itroducig the BEA Tuxedo System 3-25

92 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Performig Dyamic Operatios Usig tmadmi(1) Usig the tmadmi(1) commad, you ca perform ay of the followig operatios to a ruig applicatio: Moitor performace by checkig statistics o groups, servers, ad services (bbstats, bbparms) Modify server ad service parameters such as those that chage load values (chageload), susped ad resume services (susped ad resume), advertise ad uadvertise services (advertise ad uadvertise), ad chage the AUTOTRAN time-out value (chagetratime) Boot (boot), cleaup (pclea), ad migratio (migratemach, migrategroup) Commoly Used tmadmi Commads tmadmi provides subcommads that eable you to moitor your ru-time system, tue your applicatio, ad dyamically cofigure your applicatio. Followig is a list of the most commoly used tmadmi commads. (For a comprehesive list of the tmadmi commads, refer to the tmadmi(1) i BEA Tuxedo Commad Referece.) help - provides you with a list of subcommads, their abbreviatio, argumets, ad descriptios. pritserver (psr) prits iformatio for applicatio ad admiistrative servers. pritservice (psc) prits iformatio for applicatio ad admiistrative services. pritcliet (pclt) prits iformatio for the specified set of cliet processes. If o argumets or defaults are set, the iformatio o all cliets is prited Itroducig the BEA Tuxedo System

93 Performig Dyamic Operatios Usig tmadmi(1) Sample Output from the tmadmi Commad >psr Followig is sample output from the tmadmi pritserver (psr) commad, which provides iformatio about applicatio ad admiistrative servers. Figure 3-6 Sample Output from the tmadmi pritserver Commad Prog Name Queue Name Grp Name ID RqDoe Load Doe Curret Service BBL SITE ( IDLE ) AUDITC auditc BANKB ( IDLE ) XFER BANKB ( TRANSFER ) TMS_SQL BANKB1_TMS BANKB ( IDLE ) ACCT BANKB ( IDLE ) TMS_SQL BANKB1_TMS BANKB ( IDLE ) BAL BANKB ( IDLE ) BTADD BANKB ( IDLE ) BALC BANKB ( IDLE ) TLR tlr1 BANKB ( IDLE ) TLR tlr1 BANKB ( WITHDRAWAL ) TLR tlr1 BANKB ( IDLE ) TLR tlr1 BANKB ( IDLE ) TLR tlr1 BANKB ( IDLE ) TLR tlr1 BANKB ( IDLE ) TLR tlr1 BANKB ( IDLE ) TLR tlr1 BANKB ( IDLE ) TLR tlr1 BANKB ( IDLE ) TLR tlr1 BANKB ( IDLE ) > See Also How a tmadmi Sessio Works o page 2-13 i Admiisterig a BEA Tuxedo Applicatio at Ru Time Usig Commad-lie Utilities to Moitor Your Applicatio o page 2-10 i Admiisterig a BEA Tuxedo Applicatio at Ru Time Itroducig the BEA Tuxedo System 3-27

94 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Maagig a Distributed Applicatio Cetrally Eve if your BEA Tuxedo applicatio is large ad complex, you ca perform all ru-time admiistrative fuctios from oe MASTER machie. You ca do so usig the BEA Tuxedo system-supplied commad-lie utilities, or the BEA Admiistratio Cosole, or through your third-party admiistratio tools used with the BEA Maager product. From the MASTER machie, you ca cofigure your applicatio, iitiate start-up ad shutdow, ad perform admiistrative tasks durig rutime. All other machies ca query the MASTER machie. From the MASTER machie, you have cotrol over cofiguratio, fault maagemet, security, moitorig, ad performace. You ca use the followig two methods to make chages to your system while it is ruig: The BEA Admiistratio Cosole a graphical user iterface (GUI) to the commads that perform admiistrative tasks, icludig dyamic system modificatio The tmadmi commad a shell-level meta-commad that eables you to ru 50 subcommads for performig various admiistrative tasks, icludig dyamic system modificatio Because it is a graphical user iterface, the BEA Admiistratio Cosole is simpler to use tha the tmadmi commad iterpreter. If you prefer usig a GUI, brig the BEA Admiistratio Cosole up o your scree as soo as you are ready to begi a admiistrative task. Graphics ad olie help provided with the BEA Admiistratio Cosole guide you through ay task you eed to perform. The followig illustratio shows how you ca use the tmadmi commad or the BEA Admiistratio Cosole to cotrol a ru-time applicatio. All operatios ca be performed from the MASTER machie. The utilities directly affect the bulleti board o the MASTER machie, ad updates are distributed to other bulleti boards automatically Itroducig the BEA Tuxedo System

95 Maagig a Distributed Applicatio Cetrally Figure 3-7 Cetralized Cotrol of a Distributed Applicatio See Also Usig the BEA Admiistratio Cosole o page 3-4 Performig Dyamic Operatios Usig tmadmi(1) o page 3-26 Itroducig the BEA Tuxedo System 3-29

96 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Maagig Security Admiistrators ca cofigure applicatios with appropriate levels of security provided by the BEA Tuxedo system. Icremetal levels of autheticatio ad authorizatio ca be used to defie access to a applicatio. Levels ca vary from o autheticatio for highly secure eviromets, to a password or a access cotrol list (ACL) that filters who ca use services, post a evet, ad equeue or dequeue a message o a queue. With a ACL, ot oly is a user autheticated whe joiig a applicatio, but permissios are checked automatically whe attempts are made to access applicatio etities, such as services. Whe a ACL is created for a resource, users ot icluded o the list are deied access to the resource. Resources uprotected by a ACL are accessible by ay cliet who successfully jois the applicatio. Resources uprotected by a ACL with the MANDATORY_ACL security optio specified, are deied for ay cliet who jois the applicatio. A applicatio ca be cofigured so that all servers (except AUTHSVR, the BEA Tuxedo admiistratio server) have restricted access to shared resources, such as shared memory ad message queues. Whe a cliet jois a applicatio, AUTHSVR provides a autheticatio service that verifies whether the user has the correct autheticatio level (i the MIB). This service is trasparet to the programmer. See Also Selectig Security Optios o page 3-31 Settig Up Security o page 3-32 Admiisterig Security o page 2-1 i Usig BEA Tuxedo Security Programmig Security o page 3-1 i Usig BEA Tuxedo Security 3-30 Itroducig the BEA Tuxedo System

97 Selectig Security Optios Selectig Security Optios The followig are the security optios provided by the BEA Tuxedo system: No autheticatio Cliets do ot have to be verified before joiig a applicatio. Applicatio Password A sigle password is defied for a etire applicatio ad cliets must provide the password to joi the applicatio. User-level Autheticatio I additio to a applicatio password, each cliet must provide a valid user ame ad applicatio-specific data such as a password to joi the applicatio. Optioal Access Cotrol List (ACL) Cliets must provide a applicatio password, a user ame, ad a user password. If there is o ACL associated with a user ame, permissio is grated. This practice eables a admiistrator to cofigure access for oly those resources that eed more security; ACLs eed ot be cofigured for services, queues, or evets that are ope to everyoe. Madatory Access Cotrol List (ACL) Cliets must provide a applicatio password, a user ame, ad a user password. This level is similar to optioal ACL, but a access cotrol list must be cofigured for every etity (such as a service, queue, or evet) that users ca access. If madatory ACLs are beig used ad there is o ACL for a particular etity, permissio for that etity is deied. Lik-Level Ecryptio Users of BEA Tuxedo System Security ca establish data privacy for messages movig over the etwork liks that coect the machies i a BEA Tuxedo applicatio. The BEA Tuxedo system ecrypts data before sedig it over a etwork lik ad decrypts it as it comes off the lik. Three levels of security are offered: 0-bit (o ecryptio), 56-bit (iteratioal), or 128-bit (US ad Caada). Public key ecryptio Cosists of message-based ecryptio ad message-based digital sigature. Message-based ecryptio reveals user data oly to desigated recipiets. With message-based digital sigature, a sedig process must prove its idetity, ad bid that proof to a specific message buffer. Ay third party ca verify the sigature s autheticity. Udetected tamperig is impossible because a digital sigature cotais a cryptographically secure Itroducig the BEA Tuxedo System 3-31

98 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure checksum computed o the etire cotets of a buffer. A digital sigature also cotais a tamper-proof stamp based o the origiatig machie s local clock. Auditig Collects, stores, ad distributes iformatio about operatig requests ad their outcomes. Settig Up Security The type of admiistrative work ad/or programmig you must do to set up security for your applicatio depeds upo the security optios that you choose. Admiistratively, you eed to cofigure the MIBs usig either the BEA Admiistratio Cosole or the commad-lie utilities. You ca also build your ow security mechaisms. To do so, set the applicatio security level to User-Level Autheticatio ad specify a applicatio service that performs autheticatio i the BEA Tuxedo MIB. To eable autheticatio ad authorizatio, admiistrators must cofigure the followig i the MIB: AUTHSVR server Idetity ad passwords of authorized users Access cotrol lists used o services, queues, ad/or evets 3-32 Itroducig the BEA Tuxedo System

99 Startig Up ad Shuttig Dow your Applicatio Startig Up ad Shuttig Dow your Applicatio To start a applicatio, you eed to perform the followig tasks as stated i Admiisterig a BEA Tuxedo Applicatio at Ru Time. 1. Set the eviromet variables as described i How to Set Your Eviromet o page Create the tuxcofig file as described i How to Create the TUXCONFIG File o page Propagate the BEA Tuxedo software as described i How to Propagate the BEA Tuxedo System Software o page Create a TLOG device, (if required) as described i How to Create a TLOG Device o page Start tliste at all sites (MP eviromets) as described i How to Start tliste at All Sites o page Boot the applicatio as described i How to Boot the Applicatio o page 1-9 To shut dow a applicatio, you eed to perform the followig task. Ru tmshutdow o the MASTER machie as described i How to Shut Dow Your Applicatio o page 1-11 Itroducig the BEA Tuxedo System 3-33

100 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Maagig Trasactios A powerful feature of the BEA Tuxedo system is the ability to maage trasactios for database applicatios that support the XA-iterface. Trasactios simplify the writig of distributed applicatios. They allow your applicatio to cope more easily with a large set of problems that ca occur i distributed eviromets, such as machie, program, ad etwork failures. I a distributed architecture, a local machie ivolved i a trasactio ca commuicate with a remote machie which may, i tur, commuicate with aother remote machie. The commuicatio ad the work doe by the remote machies is part of the trasactio, ad itegrity must be maitaied. Keepig track of distributed trasactio processig (DTP) ca be a complex task because the system must maitai eough iformatio about a trasactio to be able to roll it back (that is, to udo it) at ay momet. Figure 3-8 Trasactio Maagemet To keep track of the participats i a trasactio, the BEA Tuxedo system creates a trasactio log. To maitai the state of a applicatio as represeted by the cotets of the computer s memory, the BEA Tuxedo system uses oe or more Resource Maagers (a collectio of iformatio ad processes for accessig it, such as a database maagemet system). To coordiate all the operatios performed ad all the modules affected by a trasactio, the BEA Tuxedo system uses a Trasactio Maager (TM), which directs the actios of the RMs. Together, TMs ad RMs maitai the atomicity of a distributed trasactio Itroducig the BEA Tuxedo System

101 Maagig Trasactios Coordiatig Operatios with a Trasactio Maager Server (TMS) The BEA Tuxedo Trasactio Maager (TM) is resposible for coordiatig global trasactios ivolvig system-wide resources. Local resource maagers (RMs) are resposible for idividual resources. The trasactio maager server (TMS) begis, commits, ad aborts trasactios ivolvig multiple resources. The server uses a embedded SQL iterface to the RM to read ad update the database accessed by the server group. The TMS ad RMs use the XA iterface to perform all or oe of the resource work i a global trasactio. Trackig Participats with a Trasactio Log (TLOG) A global trasactio is logged i the trasactio log (TLOG) oly whe it is i the process of beig committed. The TLOG records the reply from the global trasactio participats at the ed of the first phase of a 2-phase-commit protocol. A TLOG record idicates that a global trasactio should be committed; o TLOG record is writte for those trasactios that are to be rolled back. I the first phase, or pre-commit, each Resource Maager must commit to performig the trasactio request. Oce all parties commit, trasactio maagemet commits ad completes the trasactio. If either tasks fails because of a applicatio or system failure, both tasks fail ad the work performed is udoe or rolled back to its iitial state. The TMS that coordiates global trasactios uses the TLOG file. Each machie should have its ow TLOG. See Also Note: Customers usig the Domais feature should ote that the Domais gateway performs the fuctios of the TMS i Domais groups. However, Domais uses its ow trasactio log cotaiig iformatio similar to that i the TLOG, i additio to Domais-specific iformatio. Usig Trasactios o page 1-18 i Tutorials for Developig a BEA Tuxedo Applicatio Cofigurig Your Applicatio to Use Trasactios o page 5-1 i Settig Up a BEA Tuxedo Applicatio Itroducig the BEA Tuxedo System 3-35

102 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Maagig Workstatios Workstatio cliets eed eough of the BEA Tuxedo system software to package the iformatio associated with a request. They ca the sed that iformatio to a system that supports all the BEA Tuxedo system software, icludig ATMI fuctios ad etworkig software. The admiistrator cofigures oe or more Workstatio Listeers (WSLs) to be ready for coectio requests from Workstatio cliets. Each WSL uses oe or more associated Workstatio Hadlers (WSHs) to hadle the cliet s workload. Each WSH maages multiple workstatios, multiplexes all commuicatio with a particular workstatio over a sigle coectio. Figure 3-9 Hadlig Workstatio Cliets A machie ca the hadle thousads of workstatio cliets. A admiistrator ca defie several WSLs i a domai to distribute ad balace the workstatio commuicatio load across multiple machies Itroducig the BEA Tuxedo System

103 Developmet View: What You Ca Do Usig the ATMI From a programmig perspective, all cliet ATMI programmig iterfaces are supported for workstatio cliet developmet. Developmet View: What You Ca Do Usig the ATMI The Applicatio to Trasactio Moitor Iterface (ATMI), the BEA Tuxedo API, provides a iterface for commuicatios, trasactios, ad maagemet of data buffers that works i all eviromets supported by the BEA Tuxedo system. It defies the iterface betwee applicatio programs ad the BEA Tuxedo system. The ATMI offers a simple iterface for a comprehesive set of capabilities. It implemets the X/Ope DTP model of trasactio processig. Figure 3-10 Usig the ATMI The ATMI library offers you a variety of fuctios for defiig ad cotrollig global trasactios i a BEA Tuxedo applicatio. Global trasactios eable you to maage exclusive uits of work spaig multiple programs ad resource maagers i a distributed applicatio. All the work i a sigle trasactio is treated as a logical uit, Itroducig the BEA Tuxedo System 3-37

104 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure so that if ay oe program caot complete its task successfully, o work is performed by ay programs i the trasactio. Most ATMI fuctios support differet commuicatio styles. These fuctios kit together distributed programs by eablig them to exchage data. All ATMI fuctios sed or receive data i typed buffers. Followig is a list of ATMI fuctios (for C ad COBOL bidigs), grouped by the type of task they perform. Table 3-2 Usig the ATMI Fuctios For a Task Related to Use This C Fuctio Or This COBOL Fuctio To Cliet membership tpchkauth(3c) TPCHKAUTH(3cbl) Check whether autheticatio is required tpiit(3c) TPINITIALIZE(3cbl) Have a cliet joi a applicatio tpterm(3c) TPTERM(3cbl) Have a cliet leave a applicatio Buffer maagemet tpalloc(3c) N/A Create a message buffer tprealloc(3c) N/A Resize a message buffer tpfree(3c) N/A Free a message buffer tptypes(3c) N/A Get a message type ad subtype Message priority tpgprio(3c) TPGPRIO(3cbl) Get the priority of the last request tpsprio(3c) TPSPRIO(3cbl) Set the priority of the ext request Request/Respose commuicatios tpcall(3c) TPCALL(3cbl) Iitiate a sychroous request/respose to a service tpacall(3c) TPACALL(3cbl) Iitiate a asychroous request (faout) tpgetrply(3c) TPGETRPLY(3cbl) Receive a asychroous respose tpcacel(3c) TPCANCEL(3cbl) Cacel a asychroous request 3-38 Itroducig the BEA Tuxedo System

105 Developmet View: What You Ca Do Usig the ATMI For a Task Related to Use This C Fuctio Or This COBOL Fuctio To Coversatioal commuicatios tpcoect(3c) TPCONNECT(3cbl) Begi a coversatio with a service tpdisco(3c) TPDISCON(3cbl) Abormally termiate a coversatio tpsed(3c) TPSEND(3cbl) Sed a message i a coversatio tprecv(3c) TPRECV(3cbl) Receive a message i a coversatio Reliable queuig tpequeue(3c) TPENQUEUE(3cbl) Equeue a message to a message queue tpdequeue(3c) TPDEQUEUE(3cbl) Dequeue a message from a message queue Evet-based commuicatios tpotify(3c) TPNOTIFY(3cbl) Sed a usolicited message to a cliet tpbroadcast(3c) TPBROADCAST(3cbl) Sed messages to several cliets tpsetusol(3c) TPSETUNSOL(3cbl) Set usolicited message call-back tpchkusol(3c) TPCHKUNSOL(3cbl) Check the arrival of usolicited messages N/A TPGETUNSOL(3cbl) Get a usolicited message tppost(3c) TPPOST(3cbl) Post a evet message tpsubscribe(3c) TPSUBSCRIBE(3cbl) Subscribe to evet messages tpusubscribe(3c) TPUNSUBSCRIBE(3cbl) Usubscribe to evet messages Itroducig the BEA Tuxedo System 3-39

106 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure For a Task Related to Use This C Fuctio Or This COBOL Fuctio To Trasactio maagemet tpbegi(3c) TPBEGIN(3cbl) Begi a trasactio tpcommit(3c) TPCOMMIT(3cbl) Commit the curret trasactio tpabort(3c) TPABORT(3cbl) Roll back the curret trasactio tpgetlev(3c) TPGETLEV(3cbl) Check whether i trasactio mode tpsusped(3c) TPSUSPEND(3cbl) Susped the curret trasactio tpresume(3c) TPRESUME(3cbl) Resume a trasactio Service etry ad retur tpsvriit(3c) TPSVRINIT(3cbl) Iitialize a server tpsvrdoe(3c) TPSVRDONE(3cbl) Termiate a server tpservice(3c) N/A Prototype for a service etry poit N/A TPSVCSTART(3cbl) Get service iformatio tpretur(3c) TPRETURN(3cbl) Ed a service fuctio tpforward(3c) TPFORWAR(3cbl) Forward request Dyamic advertisemet Resource maagemet tpadvertise(3c) TPADVERTISE(3cbl) Advertise a service ame tpuadvertise(3c) TPUNADVERTISE(3cbl) Uadvertise a service ame tpope(3c) TPOPEN(3cbl) Ope a resource maager tpclose(3c) TPCLOSE(3cbl) Close a resource maager Note: The use of ATMI trasactio maagemet fuctios is optioal Itroducig the BEA Tuxedo System

107 Ru-Time System View: Usig Tools i Differet Cofiguratios See Also Usig the ATMI to Hadle System ad Applicatio Errors o page 2-28 i Admiisterig a BEA Tuxedo Applicatio at Ru Time Creatig a BEA Tuxedo Cliet o page 1-2 i Tutorials for Developig a BEA Tuxedo Applicatio Creatig a BEA Tuxedo Server o page 1-4 i Tutorials for Developig a BEA Tuxedo Applicatio Usig Typed Buffers i Your Applicatio o page 1-6 i Tutorials for Developig a BEA Tuxedo Applicatio What Are the BEA Tuxedo Messagig Paradigms o page 2-8 What Is Meat by Namig o page 2-42 Ru-Time System View: Usig Tools i Differet Cofiguratios The BEA Tuxedo system provides tools to create, moitor, ad maage both processes ad the commuicatio that occurs betwee processes i a give applicatio. You ca use the basic processes ad messagig paradigms i may differet cofiguratios. Each cofiguratio falls ito oe of the followig ru-time categories: Sigle machie applicatio Oe or more local or remote cliets commuicate with oe or more servers residig o the same machie. Distributed applicatio across multiple machies Oe or more local or remote cliets commuicate with oe or more servers residig o several machies i oe domai. Multiple-domai applicatio Two or more domais commuicate with each other. Itroducig the BEA Tuxedo System 3-41

108 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Ru-Time System Capabilities The followig table lists the BEA Tuxedo system fuctioality available i a sigle-machie applicatio, a distributed applicatio, ad a multiple-domai applicatio. Table 3-3 Fuctioality Available i Differet Types of Cofiguratios Available Fuctioality Sigle-machie Cofiguratio Multiple-machie (Distributed) Cofiguratio Multiple-domai Cofiguratio ATMI X X X Messagig paradigms X X X Admiistrative Parts: Bulleti Board (BB),Bulleti Board Liaiso (BBL), TLOG, UBBCONFIG, ULOG, TUXCONFIG Distiguished Bulleti Board Liaiso (DBBL) Bridges X X X X X X X Domais processes: DMADM, GWADM, GWTDOMAIN (for TDomais), dmloadcf, dmuloadcf, ad DMCONFIG, DMTLOG ad BDMCONFIG X Applicatio processes: cliets, servers, ad services X X X Queuig X X X Trasactio maagemet X X X Evet maagemet X X Security maagemet X X X 3-42 Itroducig the BEA Tuxedo System

109 What Is a Sigle-machie Cofiguratio What Is a Sigle-machie Cofiguratio A sigle-machie cofiguratio cosists of oe or more local or remote cliets that commuicate with oe or more servers residig o a sigle machie ruig oe or more busiess applicatios. Eve though it may iclude multiple applicatios, this type of cofiguratio is cosidered a sigle domai because it is admiistered as a sigle etity. All the maaged elemets (services, servers, ad so o) of all the applicatios i this cofiguratio are defied i ad cotrolled from oe BEA Tuxedo cofiguratio file. The basic parts of a sigle-machie cofiguratio whe istalled ad ruig o a sigle machie are illustrated i the followig diagram. Figure 3-11 A Sigle-machie BEA Tuxedo Cofiguratio Itroducig the BEA Tuxedo System 3-43

110 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Table 3-4 Parts of a Sigle-machie Cofiguratio Sigle-machie Part Bulleti Board (BB) Bulleti Board Liaiso (BBL) Cliets Message queues Messagig paradigms Servers Workstatio Hadler (WSH) Workstatio Listeer (WSL) ULOG (User Log) Descriptio A shared memory segmet that holds cofiguratio ad dyamic iformatio for the system. It is available to all BEA Tuxedo processes. A BEA Tuxedo admiistrative process that moitors both the data stored i the bulleti board (icludig ay chages made to it) ad all applicatio programs. Executable programs that periodically request services through the BEA Tuxedo system. (Cliet programs are ormally writte by customers.) Commuicatio betwee cliets ad servers is performed through operatig-system supported, memory-based message queues. Differet models of trasferrig messages betwee a cliet ad a server. Examples iclude request/respose mode, coversatioal mode, evets, ad usolicited commuicatio. Executable programs that offer amed services through the BEA Tuxedo system. (Server programs are ormally writte by customers.) A multi-cotexted gateway process o a server that maages service requests from Workstatio cliets (that is, cliet processes ruig o remote sites). A server process ruig o a applicatio site that listes for ad distributes coectios from Workstatio cliets (cliet process ruig o a remote site). A file i which error messages are stored. See Also How to Create a Cofiguratio File o page 3-2 i Settig Up a BEA Tuxedo Applicatio 3-44 Itroducig the BEA Tuxedo System

111 What Is a Multiple-machie (Distributed) Cofiguratio What Is a Multiple-machie (Distributed) Cofiguratio A distributed-domai (or multiple-machie) cofiguratio cosists of oe or more busiess applicatios ruig o multiple machies. Although it icludes multiple machies, this type of cofiguratio is cosidered a sigle domai because it is admiistered cetrally as a sigle etity. I other words, all the elemets (services, servers, machies, ad so o) of all the applicatios o all the machies i this cofiguratio are defied i, ad cotrolled from, oe BEA Tuxedo cofiguratio file. As a busiess grows, applicatio developers may eed to orgaize differet segmets of the busiess by sets of fuctioality that require admiistrative autoomy but allow sharig of services ad data. Each fuctioality set defies a applicatio that may spa oe or more machies, ad that is admiistered idepedetly from other applicatios. Such a fuctioally distict applicatio is referred to as a domai. The ames of domais frequetly reflect the fuctioality provided. Whe domais have ames such as marketig ad research ad developmet, it is easy for customers to fid the applicatios they eed. Itroducig the BEA Tuxedo System 3-45

112 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure The basic parts of a cofiguratio distributed across multiple machies are illustrated i the followig diagram. Figure 3-12 Distributed Applicatio Table 3-5 Parts of a Distributed Cofiguratio Multiple Machie Part BRIDGES Descriptio BEA Tuxedo system-supplied servers withi a domai that sed ad receive service requests betwee machies, ad route requests to local servers (literally, to local server queues) Itroducig the BEA Tuxedo System

113 What Is a Multiple-machie (Distributed) Cofiguratio Multiple Machie Part Bulleti Board (BB) Bulleti Board Liaiso (BBL) Cliets Distiguished Bulleti Board Liaiso (DBBL) Message queues Messagig paradigms Servers Workstatio Hadler (WSH) Workstatio Listeer (WSL) ULOG (User Log) Descriptio A shared memory segmet that holds cofiguratio ad dyamic iformatio for the system. It is available to all BEA Tuxedo processes. A BEA Tuxedo admiistrative process that moitors both the data stored i the bulleti board (icludig ay chages made to it), ad all applicatio programs. Executable programs that periodically request services through the BEA Tuxedo system. (Cliet programs are usually by customers.) A process dedicated to makig sure that the BBL server o each machie is alive ad fuctioig correctly. This server rus o the Master machie of a domai ad commuicates directly with all admiistratio facilities. Commuicatio betwee cliets ad servers is performed through operatig-system supported, memory-based message queues. Differet models of trasferrig messages betwee a cliet ad a server. Examples iclude request/respose mode, coversatioal mode, evets, ad usolicited commuicatio. Executable programs that offer amed services through the BEA Tuxedo system. (Server programs are ormally writte by customers.) A multi-cotexted gateway process o a server that maages service requests from Workstatio cliets (that is, cliet processes ruig o remote sites). A server process ruig o a applicatio site that listes for ad distributes coectios from Workstatio cliets (cliet processes ruig o remote sites). A file i which error messages are stored. Itroducig the BEA Tuxedo System 3-47

114 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure A cofiguratio that rus o more tha oe machie requires platform iteroperability ad server trasparecy. Platform iteroperability meas that your applicatio ca rely o itermachie commuicatios eve whe differet machies are ruig differet operatig systems, without code customizatio. Server trasparecy meas that a cliet ca access a server without specifyig its locatio. The locatios of servers are recorded i the bulleti board ad accessed as eeded. As a result, servers ca be moved, dropped, or added to a applicatio dyamically, without eedig to chage the applicatio itself. The DBBL ad BRIDGE servers support these requiremets of a distributed-domai cofiguratio. See Also How to Create the Cofiguratio File for a Multiple-machie (Distributed) Applicatio o page 3-3 i Settig Up a BEA Tuxedo Applicatio Distributig Applicatios Across a Network o page 6-1 i Settig Up a BEA Tuxedo Applicatio Creatig the Cofiguratio File for a Distributed Applicatio o page 7-1 i Settig Up a BEA Tuxedo Applicatio Settig Up the Network for a Distributed Applicatio o page 8-1 i Settig Up a BEA Tuxedo Applicatio Maagig the Network i a Distributed Applicatio o page 4-1 i Admiisterig a BEA Tuxedo Applicatio at Ru Time 3-48 Itroducig the BEA Tuxedo System

115 What Is a Multiple-domai Cofiguratio What Is a Multiple-domai Cofiguratio A multiple-domai cofiguratio cosists of two or more domais that commuicate with each other. Each domai may be either a sigle-machie cofiguratio or a multiple-machie cofiguratio. Iter-domai commuicatio is achieved through a highly asychroous multitaskig gateway that processes outgoig ad icomig service requests to or from all domais. Multiple BEA Tuxedo domais ca be coected, allowig cliets i oe domai trasparet access to services physically located i remote domais. Each domai ca share services ad data, but is admiistered separately. The BEA Tuxedo system provides differet types of gateways to accommodate various etwork trasport protocols. Followig are the differet types of Domais gateways: The BEA Tuxedo Domais (TDomais) gateway provides iteroperability betwee two or more BEA Tuxedo applicatios through a specially desiged TP protocol that flows over etwork trasport protocols such as TCP/IP. The BEA elik for Maiframe-OSI TP gateways provides iteroperability betwee BEA Tuxedo applicatios ad other trasactio processig applicatios that use the OSI TP stadard. OSI TP is a protocol for distributed trasactio processig defied by the Iteratioal Stadards Orgaizatio (ISO). The BEA elik for Maiframe-SNA gateway provides iteroperability betwee cliets ad servers i a BEA Tuxedo domai ad cliets ad servers i a MVS/CICS or MVS/IMS eviromet i remote SNA domais. It also coects a local BEA Tuxedo domai to multiple SNA etworks. The BEA elik for Maiframe-TCP for CICS is a gateway coectivity feature that makes it possible for o-trasactioal tasks withi BEA Tuxedo regios to access services provided by CICS applicatio programs ad vice-versa. It eables a BEA Tuxedo domai to commuicate via the TCP/IP etwork trasport protocol to a CICS eviromet. The BEA elik for Maiframe-TCP for IMS is a gateway coectivity feature that provides trasparet commuicatios betwee cliet ad server trasactios i a IMS system ad a BEA Tuxedo domai, a CICS system, or aother IMS system. The TOP END Domai Gateway (TEDG) provides iteroperability betwee BEA TOP END systems ad BEA Tuxedo domais. Itroducig the BEA Tuxedo System 3-49

116 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure The basic parts of a multiple-domai cofiguratio are illustrated i the followig diagram. Figure 3-13 Multiple-domai Cofiguratio 3-50 Itroducig the BEA Tuxedo System

117 What Is a Multiple-domai Cofiguratio Table 3-6 Parts of a Multiple-domai Cofiguratio Multiple-domai Part BRIDGES Bulleti Board (BB) Bulleti Board Liaiso (BBL) Cliets Distiguished Bulleti Board Liaiso (DBBL) Descriptio BEA Tuxedo system-supplied servers withi a domai that sed ad receive service requests betwee machies, ad route requests to local servers (literally, to local server queues). A shared memory segmet that holds cofiguratio ad dyamic iformatio for the system. It is available to all BEA Tuxedo processes. A BEA Tuxedo admiistrative process that moitors both the data stored i the bulleti board (icludig ay chages made to it), ad all applicatio programs. Executable programs that periodically request services through the BEA Tuxedo system. (Cliet programs are ormally writte by customers.) Esures that the BBL servers o each machie are alive ad fuctioig correctly. This server rus o the Master machie of a applicatio ad commuicates directly with ay admiistratio facility. Domais tools: DMADM, GWADM, GWTDOMAIN, dmloadcf, dmuloadcf, ad DMCONFIG DMADM-the Domais admiistrative server GWADM-the gateway group admiistrative server that registers with the DMADM server to obtai cofiguratio iformatio used by the gateway group GWTDOMAIN-the gateway process that provides coectivity to remote gateway processes (for TDomais) dmloadcf -traslates the DMCONFIG file to a biary BDMCONFIG cofiguratio file dmuloadcf-traslates the BDMCONFIG cofiguratio file from the biary represetatio ito ASCII DMCONFIG-the Domais cofiguratio file Message queues Commuicatio betwee cliets ad servers is performed through operatig-system supported, memory-based message queues. Itroducig the BEA Tuxedo System 3-51

118 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Multiple-domai Part Messagig paradigms Servers Workstatio Hadler (WSH) Workstatio Listeer (WSL) ULOG (User Log) Descriptio Differet models of trasferrig messages betwee a cliet ad a server. Examples iclude request/respose mode, coversatioal mode, evets, ad usolicited commuicatio. Executable programs that offer amed services through the BEA Tuxedo system. (Server programs are ormally writte by customers.) A multi-cotexted gateway process o a server that maages service requests from Workstatio cliets (that is, cliet processes ruig o remote sites). A server process ruig o a applicatio site that listes for ad distributes coectios from Workstatio cliets (cliet processes ruig o remote sites). A file i which error messages are stored. See Also What Is a Sigle-machie Cofiguratio o page 3-43 What Are the Domais Admiistrative Tools o page 3-57 How to Create the Cofiguratio File for a Multiple-domai Applicatio o page 3-4 i Settig Up a BEA Tuxedo Applicatio 3-52 Itroducig the BEA Tuxedo System

119 Features of a Multiple-domai Cofiguratio Features of a Multiple-domai Cofiguratio A cofiguratio that icludes more tha oe domai requires platform iteroperability ad server trasparecy: Platform iteroperability meas that your applicatio ca rely o itermachie commuicatios eve whe differet machies are ruig differet operatig systems, without code customizatio. Server trasparecy meas that a cliet ca access a server without specifyig its locatio. The locatios of servers are recorded i the bulleti board ad accessed as eeded. As a result, servers ca be moved, dropped, or added to a applicatio dyamically, without eedig to chage the applicatio itself. What Is a BEA Tuxedo BRIDGE A BEA Tuxedo BRIDGE is a server, provided by the BEA Tuxedo system, for sedig ad receivig service requests betwee machies, ad routig requests to local server queues. Each BRIDGE eables a etwork coectio to be created with every other BRIDGE i the system. Network coectios are established as eeded ad the maitaied idefiitely. BRIDGEs are hidde servers, that is, they are started ad stopped automatically, as eeded, without a explicit cofiguratio etry. Messages are asychroously set across these persistet etwork coectios. No etwork coectio overhead is icurred for idividual messages. Itroducig the BEA Tuxedo System 3-53

120 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Figure 3-14 Usig BRIDGEs i a Multiple-machie (Distributed) Applicatio See Also Settig Up the Network for a Distributed Applicatio o page 8-1 i Settig Up a BEA Tuxedo Applicatio Creatig the Cofiguratio File for a Distributed Applicatio o page 7-1 i Settig Up a BEA Tuxedo Applicatio 3-54 Itroducig the BEA Tuxedo System

121 What Is the Role of the Bulleti Board ad Bulleti Board Liaiso What Is the Role of the Bulleti Board ad Bulleti Board Liaiso The bulleti board (BB) is a memory segmet i which all the applicatio cofiguratio ad dyamic processig iformatio is held at ru time. It provides the followig fuctioality: Assigs service requests to specific servers. Whe a service is called, the bulleti board looks up servers that offer the requested service. Based o this iformatio, ad ay data-depedet routig criteria, the bulleti board places the request data o the request queue of a valid server. Maitais dyamic iformatio about the state of a applicatio, such as how may requests are waitig o a give server s queue ad how may requests have bee processed. Provides server locatio trasparecy, allowig a applicatio to be developed idepedetly of deploymet. Therefore, developmet ad deploymet costs are miimized. Supports service ame aliases, allowig multiple ames to be assiged to the same service. This capability is useful for costructig iterpreters, such as gateways. The bulleti board liaiso (BBL) is a BEA Tuxedo server that performs periodic health checks of the bulleti board ad coordiates fuctios of all parts of the system. Itroducig the BEA Tuxedo System 3-55

122 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Figure 3-15 Bulleti Board ad Bulleti Board Liaiso What Are Cliets ad Servers Cliets A cliet is a program that collects a request from a user ad passes that request to a server capable of fulfillig it. It ca reside o a PC or workstatio as part of the frot ed of a applicatio gatherig iput from users. It ca also be embedded i software that reads a commuicatio device such as a ATM machie from which data is collected ad formatted before beig processed by BEA Tuxedo servers. Servers A BEA Tuxedo server is a process that oversees a set of services ad dispatches services automatically for cliets that request them. A service, i tur, is a fuctio withi the server program that performs a particular task eeded by a busiess. A bak, for example, might have oe service that accepts deposits ad aother that reports accout balaces. A server at this bak might receive requests from cliets for both services. It is the server s job to dispatch each request to the appropriate service Itroducig the BEA Tuxedo System

123 What Is the Distiguished Bulleti Board Liaiso (DBBL) What Is the Distiguished Bulleti Board Liaiso (DBBL) The Distiguished Bulleti Board Liaiso (DBBL) is the server that makes it possible to distribute a applicatio across multiple machies. The DBBL esures that the bulleti board liaiso (BBL) server o each machie is alive ad fuctioig correctly. The DBBL rus o the MASTER machie of a applicatio ad commuicates directly with all admiistratio facilities. The DBBL esures that cofiguratio ad service addressig iformatio is replicated to the bulleti board o each machie i the cofiguratio. Servers located o remote machies are accessed through the BRIDGE o the local machie. Servers o the local machie are accessed directly. All local commuicatios are performed through high performace operatig system message queues. Remote commuicatios are performed i two phases. First, service requests are forwarded to a remote machie through the (local) BRIDGE. Secod, whe a request reaches the remote machie, operatig system messages are used to sed the request to the appropriate server. What Are the Domais Admiistrative Tools To build a multiple-domai cofiguratio, you eed to itegrate your existig BEA Tuxedo applicatio with other domais. You eed to esure iteroperability across domais, preserve access to services o all domais, ad accept service requests from all domais. You ca perform these fuctios through a highly asychroous multitaskig gateway that processes outgoig ad icomig service requests to or from all domais. To use the gateway, you must add etries for domai gateway groups ad gateway servers to the TUXCONFIG file. The followig illustratio shows the tools provided by the BEA Tuxedo system for settig up ad maitaiig a multiple-domai cofiguratio. Itroducig the BEA Tuxedo System 3-57

124 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Figure 3-16 Domais Admiistrative Tools Domais Tool dmadmi(1) DMCONFIG(5), BDMCONFIG dmloadcf ad dmuloadcf Descriptio A commad that allows you to cofigure, moitor, ad tue domai gateway groups dyamically. Use this commad to update the BDMCONFIG file while a applicatio is ruig. The commad acts as a frot-ed process that traslates admiistrative commads to service requests to the DMADMIN service, a geeric admiistrative service advertised by the DMADM server. The DMADMIN service ivokes the validatio, retrieval, or update fuctios provided by the DMADM server to maitai the BDMCONFIG file. All Domais cofiguratio iformatio is stored i a biary file called the BDMCONFIG file. You ca create ad edit the text versio of the Domais gateway cofiguratio file, DMCONFIG, with ay text editor. You ca update the compiled BDMCONFIG file while the system is ruig. dmloadcf reads the DMCONFIG file, checks the sytax, ad optioally loads a biary BDMCONFIG cofiguratio file dmuloadcf traslates the BDMCONFIG cofiguratio file from biary to text format 3-58 Itroducig the BEA Tuxedo System

125 What Are IPC Message Queues Domais Tool DMADM(5) GWADM(5) GWTDOMAIN(5) BDMCONFIG Descriptio A Domais admiistrative server that eables you to maage a Domais cofiguratio at ru time. DMADM provides a registratio service for gateway groups. This service is requested by GWADM servers as part of their iitializatio procedure. The registratio service dowloads the cofiguratio iformatio required by the requestig gateway group. The DMADM server maitais a list of registered gateway groups, ad propagates to these groups ay chages made to the cofiguratio. A gateway admiistrative server that supports ru-time admiistratio of a specific gateway group. This server registers with the DMADM server to obtai the cofiguratio iformatio used by the correspodig gateway group. GWADM accepts requests from DMADMIN to obtai ru-time statistics or to chage the ru-time optios of the specified gateway group. Periodically, GWADM seds a I-am-alive message to the DMADM server. If o reply is received from DMADM, GWADM registers agai. This process esures the GWADM server always has the curret copy of the Domais cofiguratio for its group. A gateway process that receives ad forwards messages from cliets ad servers i all coected domais (for TDomais). The biary versio of the cofiguratio file for a multiple-domai cofiguratio. What Are IPC Message Queues The BEA Tuxedo system uses IPC message queues to support commuicatio betwee processes that are executed o a particular machie. IPC message queues are trasiet memory areas, typically provided by the uderlyig operatig system, used for commuicatio betwee cliets ad servers. By default, each server has its ow IPC message queue o which to receive requests ad replies, referred to as a Sigle Server, Sigle Queue (SSSQ). If you prefer, however, you ca override the default ad Itroducig the BEA Tuxedo System 3-59

126 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure assig multiple servers to read from the same queue. This arragemet is referred to as Multiple Servers, Sigle Queue (MSSQ). You ca use both SSSQ ad MSSQ sets i the same applicatio. Servers ca be assiged to either type of queue. Whe to Use Sigle Server, Sigle Queues (SSSQ) To uderstad how SSSQ sets work, cosider a aalogy that ca be foud i your supermarket, where there may be several checkout lies. Each lie is like a separate queue i which customers wait for a clerk at oe register, who determies how fast that lie is serviced. If a delay is itroduced by oe perso, each subsequet perso is also delayed o that lie, but the delay has o effect o other lies. This scheme ca be used to load balace ad throttle work across several servers offerig differet kids of services. Customers with relatively small requests ca be processed by a server with a separate queue, thus speedig throughput by guarateeig available cycles or registers for small requests. Whe to Use Multiple Server, Sigle Queue (MSSQ) Sets The MSSQ scheme offers additioal load balacig through IPC messagig, which is offered by the operatig system. Oe queue is accommodated by several servers offerig idetical services at all times. If the server queue to which a request is set is part of a MSSQ set, the message is dequeued to the first available server. Thus load balacig is provided at the idividual queue level. Whe a server is part of a MSSQ set, it must be cofigured with its ow reply queue. Whe the server makes requests to other servers, the replies must be retured to the origial requestig server; they must ot be dequeued by other servers i the MSSQ set. I may applicatios, Multiple Server, Sigle Queue (MSSQ) sets ca play a importat role. They are ideal whe you eed to miimize the total waitig time for services. If it is uacceptable for a service request to wait while a server capable of fulfillig that request remais idle, MSSQ sets should be used Itroducig the BEA Tuxedo System

127 What Are IPC Message Queues We recommed usig a MSSQ set i the followig situatios: Service turaroud time is paramout. You have a reasoable umber of servers (betwee 2 ad 12). Servers offer idetical sets of services. The messages ivolved are reasoably sized (less tha 75% of the queue size). You ca cofigure MSSQ sets to be dyamic so they automatically spaw ad reduce servers based upo a queue load. Note: For fault tolerace, you should always use MSSQ sets with two or more servers. A MSSQ set is iappropriate whe log messages are beig passed to services. Log messages ca cause a queue to be exhausted. Whe a queue is exhausted, either oblockig seds fail or blockig seds block. We recommed agaist usig a MSSQ set i the followig situatios: Buffer sizes are large eough to exhaust oe queue. You have a large umber of servers. (You ca compromise by usig a few MSSQ sets.) Each server offers differet services. Example To cosider how MSSQ sets work, cosider a aalogy that ca be foud i your bak, where several tellers performig idetical services hadle a sigle lie of customers. The ext available teller always takes the ext perso i lie. I this sceario, each teller must be able to perform all customer services. I a BEA Tuxedo eviromet, all servers set up to share a sigle queue must offer the idetical set of services at all times. The advatage of MSSQ sets is that they offer a secod form of load balacig at the idividual queue level. Itroducig the BEA Tuxedo System 3-61

128 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure What Are the Workstatio Hadler ad Workstatio Listeer The Workstatio compoet exteds the availability of a ative BEA Tuxedo applicatio to cliets that reside o workstatios. With this compoet, workstatios eed ot be withi the admiistrative domai of the applicatio. The followig figure shows a applicatio with two Workstatio cliets (WSC). Oe cliet is ruig o a UNIX system workstatio, while the other cliet is ruig o a NT workstatio. Both WSCs are commuicatig with the applicatio through the Workstatio Hadler (WSH) process. Iitially, both joied by commuicatig with the Workstatio Listeer (WSL). The Workstatio defies a eviromet i which cliets ca access the services of a applicatio through a surrogate hadler process. Figure 3-17 BEA Tuxedo Applicatio with the Workstatio Compoet 3-62 Itroducig the BEA Tuxedo System

129 What Are the Workstatio Hadler ad Workstatio Listeer The programmig eviromet o a Workstatio is determied by the operatig system of the machie. A Local Area Network (LAN) provides a coectio to the admiistrative domai of the applicatio, affordig greater flexibility i the choice of hardware ad software platforms o which you ca deliver applicatio services. How a Workstatio Cliet Coects to a Applicatio A workstatio cliet coects to a applicatio i the followig way. Figure 3-18 WSC Coectig to a Applicatio Itroducig the BEA Tuxedo System 3-63

130 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure What Is the User Log (ULOG) The user log (ULOG) is a file to which all messages geerated by the BEA Tuxedo system error messages, warig messages, iformatio messages, ad debuggig messages are writte. Applicatio cliets ad servers ca also write to the user log. A ew log is created every day ad there ca be a differet log o each machie. However, a ULOG ca be shared by multiple machies whe a remote file system is beig used. The ULOG provides a admiistrator with a record of system evets from which the causes of most BEA Tuxedo system ad applicatio failures ca be determied. You ca view the ULOG, a text file, with ay text editor. The ULOG also cotais messages geerated by the tliste process. The tliste process provides remote service coectios for other machies. Each machie, icludig the master machie, should have a tliste process ruig o it. How Is the ULOG Created A ULOG is created by the BEA Tuxedo system wheever oe of the followig activities occurs: A ew cofiguratio file is loaded. A applicatio is booted. Example of a ULOG Message The followig is a example of a ULOG message gumby!simpserv : LIBTUX_CAT:262: std mai startig A ULOG message cosists of two parts: a tag ad text Itroducig the BEA Tuxedo System

131 What Is the User Log (ULOG) The tag cosists of the followig: A 6-digit strig (hhmmss) represetig the time of day (i terms of hour, miute, ad secod) The ame of the machie (as retured, o UNIX systems, by the uame - commad) The ame ad process idetifier of the process that is loggig the message. (This process ID ca optioally iclude a trasactio ID.) Also icluded is a thread ID (1) ad a cotext ID (0). Note: Placeholders are prited i the thread_id ad cotext_id field of etries for sigle-threaded applicatios. (Whether a applicatio is multithreaded is ot apparet util more tha oe thread is used.) The text cosists of the followig: The ame of the message catalog The message umber The BEA Tuxedo system message The Tag Idicates The Text Idicates The message was writte ito the log at approximately 12:15 P.M. The machie o which the error occurred was gumby. The message was logged by the simpserv process, which has a process ID of The thread ID is 1. The cotext ID is 0. The message came from the LIBTUX catalog. The umber of the message is 262. The message itself reads as follows: std mai startig. Note: For more iformatio about a message, ote its catalog ame ad umber. With this iformatio, you ca look up the message i the appropriate catalog. Itroducig the BEA Tuxedo System 3-65

132 3 Three Ways of Viewig the BEA Tuxedo System Ifrastructure Where the ULOG Resides By default, the user log is called ULOG.mmddyy (where mmddyy represets the date i terms of moth, day, ad year) ad it is created i the $APPDIR directory. You ca place this file i ay locatio, however, by settig the ULOGPFX parameter i the MACHINES sectio of the UBBCONFIG file Itroducig the BEA Tuxedo System

133 CHAPTER 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System BEA Product Itegratio Maiframe Coectivity: Usig BEA elik Iteret Access: Usig BEA Jolt Developig ad Maagig Applicatios: Usig BEA Maager Olie Trasactio Processig: Usig the Core BEA Tuxedo System Eablig Scalability: Usig BEA Tuxedo Domais Storig Messages ad Service Requests: Usig BEA Tuxedo /Q Workstatio Coectivity: Usig BEA Tuxedo Workstatio Developig Cliet-Server Architecture Usig WebLogic Eterprise Developig ad Maagig Distributed Java-based Applicatios: Usig BEA WebLogic Server Itroducig the BEA Tuxedo System 4-1

134 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System BEA Product Itegratio The BEA product family facilitates ed-to-ed itegratio of heterogeeous hardware ad software eviromets allowig busiesses to create eterprise-wide trasactio processig systems. BEA products eable compaies to ejoy the beefits of robust missio-critical applicatios with the flexibility of distributed cliet/server computig. Compliat with all leadig idustry stadards, BEA products eable developers to build, deploy, maage, ad coect eterprise-wide applicatios o more tha 70 platforms. These products also provide complete itegratio with market-leadig applicatio developmet tools, systems maagemet solutios, ad legacy applicatios. Amog ope middleware vedors, BEA provides the oly complete, ed-to-ed eterprise middleware solutio that icludes leadig trasactio processig compoets, a Web applicatio server, ad messagig products. BEA Product Suite The BEA product suite icludes the followig: BEA elik is a family of coectivity products that seamlessly itegrate BEA Tuxedo distributed applicatios with maiframe applicatios. BEA Jolt provides Iteret access ad complete JAVA developmet support. Jolt takes requests from JAVA-eabled cliets ad traslates them ito BEA Tuxedo applicatio calls. BEA Maager provides tools for admiistratio. BEA Tuxedo system comprises four compoets: l BEA Tuxedo core product The most widely deployed trasactio middleware for buildig high-performace, missio-critical, ad reliable distributed applicatios. It provides the idustry leadig middleware framework for buildig scalable 3-tier cliet-server applicatios i heterogeeous, distributed eviromets. 4-2 Itroducig the BEA Tuxedo System

135 BEA Product Itegratio l BEA Tuxedo Workstatio provides full support for cliets o Widows, OS/2, Mac, UNIX, ad other platforms, allowig applicatios to use remote cliets that do ot eed a full BEA Tuxedo implemetatio. l l BEA Tuxedo Domais exteds the BEA Tuxedo cliet/server model to provide trasactio iteroperability across domais. BEA Tuxedo /Q allows cliets ad servers to store messages or service requests for guarateed processig. BEA WebLogic Eterprise eables you to build, deploy, ad maage compoet-based solutios o a prove platform. Based o the power, robustess, ad demostrated reliability of the BEA Tuxedo system, BEA WebLogic Eterprise brigs together the best of idustry stadards, such as Commo Object Request Broker Architecture (CORBA) ad Eterprise Java Beas (EJB). With the power of compoet-based programmig, these tools eable you to create a complete productio-ready eterprise solutio. BEA WebLogic Server is a Java-applicatio server that eables you to develop, itegrate, deploy, ad maage large-scale, distributed Web, etwork, ad database applicatios. Itroducig the BEA Tuxedo System 4-3

136 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System Figure 4-1 Itegratio of BEA Products Maiframe Coectivity: Usig BEA elik The BEA elik family of products offers seamless trasactioal applicatio-to-applicatio iteroperability betwee BEA Tuxedo applicatios ad IBM CICS ad IMS applicatios, as well as OSI trasactio moitors. This iteroperability is trasparet to both ed users ad applicatio programmers. Native APIs ad TP moitors are used o both sides of the iterfaces. See Also Compoets of the BEA elik Product Suite o page Itroducig the BEA Tuxedo System

137 Compoets of the BEA elik Product Suite Compoets of the BEA elik Product Suite BEA elik for Maiframe - TCP/IP for MVS (for IMS ad CICS) BEA elik for Maiframe - SNA BEA elik for Maiframe - OSI TP Itroducig the BEA Tuxedo System 4-5

138 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System BEA elik for Maiframe - TCP/IP for MVS (for IMS ad CICS) The BEA elik for Maiframe - TCP/IP gateway rus o the BEA Tuxedo system ad advertises services that are available o the IBM system, either i CICS regios or uder IMS. O the maiframe, the TCP/IP for MVS commuicatios stack is used by either the BEA elik for Maiframe - TCP/IP for CICS or the BEA elik for Maiframe - TCP/IP for IMS gateways to read requests from the BEA Tuxedo system ad forward them to local routies. Buffer data represetatio coversios ad buffer layout mappigs are cofigurable at the BEA elik gateway. This gateway is uidirectioal ad otrasactioal. Figure 4-2 BEA elik for Maiframe - TCP/IP 4-6 Itroducig the BEA Tuxedo System

139 Compoets of the BEA elik Product Suite BEA elik for Maiframe - SNA With BEA elik for Maiframe - SNA, a gateway o the BEA Tuxedo system maps ATMI protocols to LU6.2/PU2.1 protocols. This mappig allows routies o the maiframe to use CPIC or APPC fuctios to receive data from the BEA Tuxedo system ad forward that data to local routies, or to iitiate requests to services i the BEA Tuxedo system. Buffer data represetatio coversios ad buffer layout mappigs are cofigurable at the BEA elik gateway. BEA elik for Maiframe - SNA is fully trasactioal ad bidirectioal. Figure 4-3 BEA elik for Maiframe - SNA Itroducig the BEA Tuxedo System 4-7

140 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System BEA elik for Maiframe - OSI TP The BEA elik for Maiframe - OSI TP product is similar to the BEA elik for Maiframe - SNA product. Both are built o the BEA Tuxedo Domais architecture, ad provide trasparet trasactioal bidirectioal access through gateway processes, which traslate betwee the XATMI protocol ad the protocol of the foreig TP system which, i this case, is OSI TP. Figure 4-4 BEA elik for Maiframe - OSI TP 4-8 Itroducig the BEA Tuxedo System

141 Iteret Access: Usig BEA Jolt Iteret Access: Usig BEA Jolt BEA Jolt allows BEA Tuxedo cliets to be writte i the Java laguage, thus makig such cliets available through the Iteret or itraets. The product cosists of two mai compoets: the Jolt Class Library ad the Jolt Repository. Both compoets ca be used with BEA Tuxedo applicatios that are ot writte i Java. With BEA Jolt, you ca create secure, scalable trasactios, over the Iteret, betwee cliets ad severs. Figure 4-5 BEA Jolt See Also Compoets of BEA Jolt o page 4-10 Itroducig the BEA Tuxedo System 4-9

142 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System Compoets of BEA Jolt BEA Jolt cosists of a Java Class Library ad a API betwee Java cliets ad the BEA Tuxedo system. It provides several compoets for creatig Java-based cliet programs that access BEA Tuxedo services ad for eablig secure, reliable access to servers iside corporate firewalls: Jolt Server Oe or more Jolt servers liste for etwork coectios from cliets, traslate Jolt messages, multiplex multiple cliets ito a sigle process, ad submit ad retrieve requests to ad from BEA Tuxedo applicatios ruig o oe or more BEA Tuxedo servers. Jolt Class Library for Java The Jolt Class Library cosists of Java class files that implemet the Jolt API. These classes eable Java applicatios ad applets to ivoke BEA Tuxedo services. The Jolt Class Library provides fuctios for maagig, retrievig, ad ivokig commuicatio attributes, otificatios, etwork coectios, trasactios, ad services. Jolt Repository A cetral Jolt Repository cotais defiitios of BEA Tuxedo system services. These Repository defiitios are used by Jolt at rutime to access BEA Tuxedo services. Usig the Repository Editor, you ca test ew ad existig BEA Tuxedo services idepedetly of the cliet applicatios. You ca export services to a Jolt cliet applicatio or uexport services by hidig the defiitios from the Jolt cliet. Jolt Iteret Relay The Jolt Iteret Relay is a compoet that routes messages from a Jolt cliet to a Jolt Server Listeer (JSL) or Jolt Server Hadler (JSH). This tool elimiates the eed for the JSH ad the BEA Tuxedo system to ru o the same machie as the Web server. The Jolt Iteret Relay cosists of the Jolt Relay (JRLY) ad the Jolt Relay Adapter (JRAD). The separatio of BEA Jolt ito these compoets permits the trasactioal ad Iteret compoets of cliet/server applicatios to be implemeted separately with the security ad scalability required for large-scale Iteret ad itraet services Itroducig the BEA Tuxedo System

143 Developig ad Maagig Applicatios: Usig BEA Maager Developig ad Maagig Applicatios: Usig BEA Maager BEA Maager is a itegrated set of software products that provides a complete eviromet for developig, maagig, itegratig, ad deployig BEA Tuxedo applicatios usig idustry stadard SNMP techology. Figure 4-6 BEA Maager Itroducig the BEA Tuxedo System 4-11

144 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System BEA Maager Compoets Table 4-1 Purpose of BEA Maager Compoets. BEA Maager Compoet BEA Maager Aget Coectio BEA Maager Aget Itegrator BEA Maager Aget Developmet Kit BEA Maager Log Cetral Purpose Exposes the BEA Tuxedo Maagemet Iformatio Base (TMIB) to a stadard SNMP Maagemet Cosole (for example, OpeView, NetView, Tivoli, BMC). Iformatio ca the be viewed ad maaged easily through the cosole as a cosolidated picture of the eterprise eviromet. Solves the problem caused by ruig multiple SNMP agets o the same maaged machie. It allows multiple SNMP agets ad subagets from ay vedor to operate o the same machie ad to appear as a sigle SNMP aget to the SNMP Maagemet Cosole. Eables developers to build their ow SNMP agets to moitor ad cotrol BEA Tuxedo (ad o-tuxedo) applicatios, ad ay other specialized software or hardware. A cetralized log maagemet system that cosolidates log messages from distributed machies to a sigle machie for viewig, filterig, ad maagig. You ca select the evets to be set to a SMNP Maagemet Cosole. Compoets of the BEA Tuxedo Product BEA Tuxedo core product BEA Tuxedo Domais BEA Tuxedo /Q BEA Tuxedo Workstatio 4-12 Itroducig the BEA Tuxedo System

145 Olie Trasactio Processig: Usig the Core BEA Tuxedo System Olie Trasactio Processig: Usig the Core BEA Tuxedo System The BEA Tuxedo system is a developmet platform that eables you to create applicatios that mix ad match hardware platforms, databases, ad operatig systems to fit your busiess eeds. The BEA Tuxedo system provides a foudatio for cliet/server architecture, request/respose ad coversatioal commuicatios iterfaces, trasactio support, ad admiistratio for a distributed applicatio. The BEA Tuxedo system provides all the features ad beefits of a high-ed Olie Trasactio Processig (OLTP) system, icludig scalability, high performace, missio-critical reliability, ad stadards support. Figure 4-7 Architecture of a Basic BEA Tuxedo System As show i this illustratio, the BEA Tuxedo system cotais the followig parts. Itroducig the BEA Tuxedo System 4-13

146 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System Architectural Part Exteral iterface layer MIB (Maagemet Iformatio Base) Admiistratio Cosole ATMI (Applicatio to Trasactio Moitor Iterface) Descriptio This layer cosists of iterfaces betwee the user ad the system. It icludes both tools for applicatio developmet, such as Simple Network Maagemet Protocol (SNMP) agets, ad tools for admiistratio, such as the BEA Admiistratio Cosole. The BEA Admiistratio Cosole ad SNMP agets ca iteract with stadard maagemet cosoles. Thus a user ca maage a BEA Tuxedo system ad a etwork cofiguratio from oe cosole. I additio, applicatio architects ad developers ca build their ow admiistrative tools or applicatio- or market-specific tools o top of the MIB. The Maagemet Iformatio Base (MIB) is a iterface that eables users to program ad admiister a BEA Tuxedo system easily.mib operatios eable you to perform all maagemet tasks (moitor, cofigure, tue, ad so o). The MIB allows you to perform oe task to oe object at a time or to build tool kits with which you ca batch tasks ad/or objects. (For iformatio regardig the differet parts of the MIB, see Available BEA Tuxedo System MIBs o page 3-3.) A Web-based graphical user iterface for maagig BEA Tuxedo applicatios. The iterface allows you to eter ad modify data i the MIB. The BEA Admiistratio Cosole makes these tools available through a Web browser. The server-side compoets of the BEA Admiistratio Cosole reside o oe of the machies i your BEA Tuxedo domai. To use the Cosole, you must eter the URL of the server ad dowload a set of Java applets, which implemet the Cosole. The Cosole eables ay user with a supported browser to admiister the BEA Tuxedo system. The iterface betwee a applicatio program ad the BEA Tuxedo system. The ATMI ad the BEA Tuxedo system implemet the X/Ope DTP model of trasactio processig. A abstract eviromet, the ATMI supports locatio trasparecy ad hides the details of implemetatio. As a result, programmers are free to cofigure ad deploy BEA Tuxedo applicatios without modifyig the applicatio code Itroducig the BEA Tuxedo System

147 Eablig Scalability: Usig BEA Tuxedo Domais Architectural Part BEA Tuxedo Services (admiistrative services ad applicatio processig services) Resource Maager Descriptio Services ad/or capabilities commo to the BEA Tuxedo system ifrastructure for developig ad admiisterig applicatios. The applicatio processig services available to developers iclude: trasactios, messagig paradigms, type validatio, load balacig, data-depedet routig, service prioritizatio, data ecodig, marshallig, ad compressio, ad reliable queueig, The admiistrative services iclude: distributed trasactio processig, security maagemet, service amig, distributed applicatio admiistratio, cetralized applicatio cofiguratio, dyamic recofiguratio, ad domais partitioig. A software product i which data is stored ad available for retrieval through applicatio-based queries. The resource maager (RM) iteracts with the BEA Tuxedo system ad implemets the XA stadard iterfaces. The most commo example of a resource maager is a database. Resource maagers provide trasactio capabilities ad permaece of actios; they are the etities accessed ad cotrolled withi a global trasactio. See Also BEA Tuxedo System Architecture o page 2-1 Eablig Scalability: Usig BEA Tuxedo Domais Domais exteds the BEA Tuxedo system cliet/server model to provide trasactio iteroperability across TP domais. This extesio preserves the cliet/server model ad the ATMI iterface by makig access to services o a remote domai (ad service requests from a remote domai) trasparet to both the applicatio programmer ad the user. Domais makes this possible through a highly asychroous multitaskig gateway that processes service requests to ad from remote domais. Itroducig the BEA Tuxedo System 4-15

148 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System Figure 4-8 Multiple-domais Eviromet 4-16 Itroducig the BEA Tuxedo System

149 Eablig Scalability: Usig BEA Tuxedo Domais Features of BEA Tuxedo Domais BEA Tuxedo Domais provides the followig features: Aliasig capability A admiistrator ca map the service ames used by a remote applicatio to the service ames used by a local applicatio, allowig easy itegratio of applicatios that use differet amig schemes. Availability Multiple etwork addresses ca be defied for a remote domai. A admiistrator ca specify a backup domai for a set of services. Scalability ad modular growth Applicatio programmers ca structure their applicatios for modularity, isolatio of failures, ad idepedet growth. Iteroperatio with other TP applicatios ca be achieved easily by addig a descriptio of the iterfaces (that is, services) betwee a remote applicatio ad the Domais cofiguratio. Security The access cotrol list (ACL) facility restricts access to local services from a particular set of remote domais. The security feature also provides a structurig capability for defiig differet views of the exported services available to remote domais. Trasparecy ad idepedece Applicatios are completely uaware of service distributio. Cliet applicatio programmers eed ot kow the implemetatio chages made to a service, the locatio of a service, or etwork addresses. A service ca be available o the same machie as a cliet, o aother machie i the local domai, or o a remote domai. See Also What Is a Domai o page 4-18 What Is a Domais Gateway o page 4-18 What Are Domai Gateway Types o page 4-19 BEA Tuxedo Domais Compoets o page 4-20 Itroducig the BEA Tuxedo System 4-17

150 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System What Is a Domai A domai cosists of a BEA Tuxedo applicatio ruig oe or more busiess applicatios. A sigle domai is defied i oe cofiguratio file ad is admiistered as a sigle etity. What Is a Domais Gateway A Domais gateway (GWTDOMAIN) is a server provided by the BEA Tuxedo system that eables access to ad from remote domais. A Domais gateway rus as a Multiple-Server, Sigle-Queue set (MSSQ) i which each gateway uses a commo request queue ad has its ow reply queue. I additio, Domais provides two gateway admiistrative servers. GWADM eables ru-time admiistratio of the Domais gateway group. DMADM, a Domais admiistrative server, eables ru-time admiistratio of Domais cofiguratio iformatio. Domais gateways support the followig fuctioality: Admiistratio A gateway ca be booted or shut dow exactly as ay other BEA Tuxedo server. Ru-time admiistratio is provided through a admiistrative server, DMADM. Usig DMADM, applicatio admiistrators ca chage the domai cofiguratio file ad tue the performace of a gateway group. ATMI coversatioal model Applicatio programs ca establish coversatios with programs ruig i aother domai. Remote domais ca establish coversatios with coversatioal services offered by local servers. ATMI request/respose model Applicatio programs usig the BEA Tuxedo system ca request services from applicatios ruig i aother domai. Also, remote applicatios ca request services from local servers. No chages are required to the applicatio programs. Multi-domai iteractio Gateways ca commuicate with multiple domais of the same type Itroducig the BEA Tuxedo System

151 What Are Domai Gateway Types Multi-etwork support Gateways ca commuicate with other domais through a variety of etworks such as Etheret ad Novell. However, a gateway is limited by the capabilities of the etworkig library to which it is liked. I other words, a gateway typically supports a sigle type of etwork. Trasactio maagemet Applicatio programs ca iteroperate with other domais withi a trasactio. The gateway coordiates the commitmet or rollback of trasactios ruig across domais. Typed buffer support Gateways ca perform ecodig ad decodig operatios for all typed buffers defied by the applicatio. What Are Domai Gateway Types Commuicatio amog domais is maaged through a set of processes called gateways. The BEA Tuxedo system offers the followig types of domai gateways to accommodate differet commuicatio protocols: BEA Tuxedo (TDomais) Domais provides iteroperability betwee two or more BEA Tuxedo applicatios through a specially desiged TP protocol that flows over etwork trasport protocols such as TCP/IP. BEA elik for Maiframe-OSI TP provides iteroperability betwee BEA Tuxedo applicatios ad other trasactio-processig applicatios that use the OSI TP stadard. OSI TP is a protocol for distributed trasactio processig defied by the Iteratioal Stadards Orgaizatio (ISO). BEA elik for Maiframe-SNA allows BEA Tuxedo cliets ad servers to operate with cliets ad servers i a MVS/CICS or MVS/IMS eviromet i remote SNA domais. It also coects to multiple SNA etworks from the local BEA Tuxedo domai. BEA elik for Maiframe-TCP/IP for MVS (for CICS) provides gateway coectivity that makes it possible for o-trasactioal tasks withi BEA Tuxedo regios to access services provided by CICS applicatio programs ad vice-versa. It eables a BEA Tuxedo domai to commuicate, via the TCP/IP etwork trasport protocol, to a CICS eviromet. (A BEA Tuxedo domai is the BEA Tuxedo applicatio defied i a sigle cofiguratio file.) Itroducig the BEA Tuxedo System 4-19

152 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System BEA elik for Maiframe-TCP/IP for MVS (for IMS) provides gateway coectivity eablig trasparet commuicatios betwee cliet ad server trasactios i a IMS system ad a BEA Tuxedo domai, a CICS system, or aother IMS system. BEA TOP END Domai Gateway (TEDG) provides iteroperability betwee TOP END systems ad BEA Tuxedo domais. The TEDG supports fully trasactioal bidirectioal message passig ad queueig betwee TOP END ad BEA Tuxedo systems. Figure 4-9 Domai Gateway Types BEA Tuxedo Domais Compoets BEA Tuxedo Domais icludes the followig compoets: A domai gateway A BEA Tuxedo system program that eables access to ad from remote domais. There are four gateways: l TDomais provides iteroperability betwee two or more BEA Tuxedo applicatios through a specially desiged TP protocol that flows over etwork trasport protocols such as TCP/IP Itroducig the BEA Tuxedo System

153 Storig Messages ad Service Requests: Usig BEA Tuxedo /Q l l l BEA elik for Maiframe-OSI TP provides iteroperability betwee BEA Tuxedo applicatios ad other trasactio processig applicatios that use the OSI TP stadard. BEA elik for Maiframe-SNA eables BEA Tuxedo cliets ad servers to operate with cliets ad servers i a MVS/CICS, MVS/IMS, or AS/400 eviromet i remote SNA domais. It also coects to multiple SNA etworks from the local BEA Tuxedo SNADOM. BEA TOP END Domai Gateway (TEDG) provides iteroperability betwee TOP END systems ad BEA Tuxedo domais. A gateway admiistrative server(gwadm(5)) A BEA Tuxedo program that eables ru-time admiistratio of a particular domai gateway group. A domai admiistrative server(dmadm(5)) A BEA Tuxedo program that eables ru-time admiistratio of the cofiguratio iformatio required by domai gateway groups. A admiistrative iterface A iterface for the cofiguratio ad ru-time admiistratio of the iformatio required by domai gateways for iteroperatio with other domais. Storig Messages ad Service Requests: Usig BEA Tuxedo /Q The BEA Tuxedo /Q extesio allows cliets ad servers to store messages or service requests for guarateed processig. The system guaratees requests are set through the trasactio protocol to esure safe storage. The admiistrative fuctios of BEA Tuxedo /Q provide the admiistrator with a great deal of flexibility i establishig ad maagig queues, ad cofigurig system servers provided with the queued message facility. Itroducig the BEA Tuxedo System 4-21

154 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System Usig the Message Queuig Server A message queuig server (TMQUEUE) allows for trasparet equeueig ad dequeueig of messages. The followig illustratio shows how TMQUEUE works. Figure 4-10 Queueig Messages Usig TMQUEUE qmadmi(1) is used to create the QUEUE SPACE (a set of queues maaged by a queue maager) with oe queue (Queue1). The followig flowchart explais how messages are queued ad dequeued. Figure 4-11 Process of Equeueig ad Dequeueig Messages 4-22 Itroducig the BEA Tuxedo System

155 Storig Messages ad Service Requests: Usig BEA Tuxedo /Q Storig ad Forwardig Messages A forwardig server (TMQFORWARD) dequeues messages ad forwards them to the appropriate servers for processig. This allows trasparet processig of equeued messages by BEA Tuxedo system servers uaware whether the icomig message was set as a ormal request/respose message or through the stable queue. A respose by the server is automatically equeued to a associated reply queue for each message. The followig illustratio shows how the TMQFORWARD server works. Figure 4-12 Storig ad Forwardig Messages usig TMQFORWARD Itroducig the BEA Tuxedo System 4-23

156 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System qmadmi(1) is used to create the QUEUE SPACE with four queues: Queue 1, Queue2, Queue3, ad REPLYQ. The followig flowchart explais how messages are stored ad forwarded. Figure 4-13 Process of Storig ad Forwardig Messages The TMQFORWARD(5) server is eeded oly if queued messages require a service call. For example, a queue may be used (o a BEA Tuxedo cliet or server) for iterprocess commuicatio i which oe process places the message o the queue ad aother removes it. (The call to tpdequeue(3c) ad the use of a reply queue are also optioal.) 4-24 Itroducig the BEA Tuxedo System

157 Storig Messages ad Service Requests: Usig BEA Tuxedo /Q BEA Tuxedo /Q Capabilities /Q makes it possible for a applicatio, withi a global trasactio, to equeue a message i a stable storage area for processig at a later time. /Q provides admiistrators of BEA Tuxedo applicatios with fuctios for processig messages o queues. The ATMI iterface icludes oe fuctio, tpequeue(3c), that allows cliets ad servers to store messages o a particular queue, ad aother, tpdequeue(3c), that allows cliets ad servers to retrieve messages from a particular queue. The qmadmi(1) commad provides admiistrative cotrol of queues ad queued messages. Requests ca be dequeued o the basis of LIFO, FIFO, or time. Withi LIFO ad FIFO, requests ca be dequeued by priority. The queue space is a resource maager that complies with X/Ope s XA iterface to esure data itegrity i a distributed eviromet. Whe the BEA Tuxedo system is used i a eviromet i which a machie, server, or resource is sometimes uavailable or ureliable, as i a wide-area etwork, /Q ca provide cotiuous processig, storig messages util the resources ecessary to process those messages are available. I batch processig of a potetially log-ruig trasactio, you are guarateed that a message will be processed evetually so you do ot have to wait util the trasactio is completed. /Q ca be used for work flow provisioig such that each step geerates a queued request to perform the ext step i a process. Mechaisms such as data-depedet routig ad priority hadlig are kept itact for queue-based requests ad replies. /Q ca be combied with BEA Tuxedo Workstatio to equeue ad dequeue messages from Workstatio cliets. The iterface for this combiatio is available i both the C ad COBOL programmig laguages. Itroducig the BEA Tuxedo System 4-25

158 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System Workstatio Coectivity: Usig BEA Tuxedo Workstatio The Workstatio compoet of the BEA Tuxedo system allows applicatio cliets to be located o remote sites that are ot part of a BEA Tuxedo domai. These remote sites do ot support a admiistratio server, a applicatio server, or a bulleti board. All commuicatio betwee such a cliet ad a applicatio takes place over a etwork. The followig illustratio shows a Workstatio eviromet. Figure 4-14 Coectig Cliets Usig Workstatio Workstatio exteds the beefits of the BEA Tuxedo system to the desktop at rutime, ad for programmig ad admiisterig BEA Tuxedo applicatios. Ru-time advatages iclude: more dyamic coectivity, less admiistrative overhead, greater security as it keeps cliets off the server systems, greater server utilizatio as it offloads CPU cycles ad decreases process cotext switches, ad a smaller footprit. See Also Workstatio Compoets o page Itroducig the BEA Tuxedo System

159 Workstatio Compoets Workstatio Compoets The BEA Tuxedo Workstatio compoets are: Workstatio Cliets Cliets use BEA Tuxedo Workstatio to coect to the BEA Tuxedo system. The BEA Tuxedo system supports multiple Workstatio cliets ruig simultaeously o Widows, Widows NT, UNIX, ad VMS platforms. The ATMI is available to cliets supported by Workstatios. Workstatio Hadler (WSH) A WSH maages oe or more coectios betwee Workstatio cliets ad ative BEA Tuxedo servers, makes surrogate service requests, maages trasactios, ad returs replies. WSH processes are started ad stopped by the WSL. Workstatio Listeer (WSL) A WSL accepts coectio requests from Workstatio cliets ad assigs coectios to a Workstatio Hadler. It also maages the pool of Workstatio Hadler processes, startig ad stoppig them i respose to load demads. Figure 4-15 Workstatio Compoets Itroducig the BEA Tuxedo System 4-27

160 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System Developig Cliet-Server Architecture Usig WebLogic Eterprise WebLogic Eterprise (WLE) provides busiesses ad orgaizatios that deped o missio-critical applicatios with the advatages of CORBA (Commo Object Request Broker Architecture)-compliat ad Eterprise Java Beas (EJB) programmig models combied with the power, robustess, ad prove reliability of the BEA Tuxedo system. The WLE deploymet ifrastructure, based o the BEA Tuxedo system, delivers secure, trasactioal, ad distributed applicatios i a maaged eviromet. Traditioal procedural OLTP fuctios are provided through the WLE ATMI, which is based o the BEA Tuxedo ATMI. Figure 4-16 WebLogic Eterprise BEA WebLogic Eterprise provides compaies with a reliable way to develop e-commerce applicatios that ca be distributed across thousads of local or geographically dispersed computers. BEA WebLogic Eterprise delivers advaced scalability, reliability, ad expadability i a stadards-based product. I a sigle package, BEA WebLogic Eterprise offers customers wide flexibility i developmet models ad programmig laguages, icludig CORBA, Java, C++, C, COBOL, Java 2 Eterprise Editio (J2EE), ad Eterprise Java Beas (EJBs). WLE also eables compaies to deploy their applicatios via a server that ca scale to reliably support 4-28 Itroducig the BEA Tuxedo System

161 Developig Cliet-Server Architecture Usig WebLogic Eterprise millios of olie e-commerce customers. Customers ca mix ad match CORBA objects, BEA Tuxedo services, ad EJB compoets i the same applicatio. I additio, BEA WebLogic Eterprise provides a platform for ed-to-ed Web-to-maiframe itegratio, helpig busiesses to offer a more competitive set of products ad services by haressig their IT ifrastructures i e-busiess iitiatives, istead of stadaloe Web sites. Because BEA WebLogic Eterprise is built o a prove, reliable BEA Tuxedo egie, this product provides all the features ecessary to eable compaies to deliver secure e-commerce solutios rapidly. Figure 4-17 WebLogic Server ad WebLogic Eterprise Itroducig the BEA Tuxedo System 4-29

162 4 Itegratig the BEA Tuxedo Product Family i a Eterprise System Developig ad Maagig Distributed Java-based Applicatios: Usig BEA WebLogic Server BEA WebLogic Server is a Java applicatio server for developig, itegratig, deployig, ad maagig large-scale, distributed Web, etwork, ad database applicatios. BEA WebLogic Server makes it possible to build portable, scalable applicatios that iteroperate seamlessly with other applicatios ad systems. The pricipal advatage of BEA WebLogic Server is the power it brigs to the software developmet cycle. Low-level etwork services for example, sockets are isolated ad hadled automatically by higher level BEA WebLogic Server facilities such as its RichSockets ad coectio pool desig. High-level compoets such as WebLogic Beas ad WebLogic/JDBC provide ehaced JavaBeas ad JDBC developmet services for the WebLogic eviromet. Figure 4-18 BEA WebLogic Server 4-30 Itroducig the BEA Tuxedo System