• TMMETADATA(5): Oracle Tuxedo service metadata repository server. It provides one service, .TMMETAREPOS, which uses an FML32 input and output buffer format described in METAREPOS(5)
• tmloadrepos(1): creates or updates the binary metadata repository file and loads it with service parameter information.
• tmunloadrepos(1): displays service information from the Oracle Tuxedo service metadata repository. Output can be optionally specified as plain text format, WSDL format, or C pseudocode
• tpgetrepos(3c): programmatically uses FML32 buffers to output service information from the Oracle Tuxedo service metadata repository
• tpsetrepos(3c): programmatically uses FML32 buffers to add, delete, or update service parameter information to the metadata repository fileOracle Jolt also provides a service repository that allows applications to manually enter Oracle Tuxedo service information, including service names, input and output buffer types, parameter names, parameter data types, the number of times each parameter is expected, and whether each parameter is for input, output, or both. All of which seem very similar to the Oracle Tuxedo service metadata repository. However, there are also some distinct difference as noted in Table 8‑1:
Yes (via tmloadrepos) Programmatic access to the Oracle Tuxedo System Metadata Repository is accomplished through the use of a FML32 buffer format that is very similar to the Oracle Tuxedo MIB format. However, there are also some distinct difference as noted in Table 8‑2:
Table 8‑2 MIB(5) Similarities and Differences
.TMIB in BBL The metadata repository file contains all the service parameter information that is accessed in the Oracle Tuxedo service metadata repository. The tmloadrepos command is used to create a metadata repository file. Metadata repository file service parameter information is input directly from the computer console (standard input) if a repository input file is not specified or from a specified plain text repository input file. For example:The repository_input_file contains service parameter keywords and their associated values. Keywords are divided into two categories: service-level and parameter-level.
Note: The repository_input file uses the following syntax: <keyword><=value> and has the following input conventions:“(” and “)”\ and “\”You can include blank lines in the repository_input file as needed for readability. A new line is preceded by a \ character. To use an actual '\' character it must be written as '\\'.Lines starting with a '#' are interpreted as comment lines. Unlike comments specified via the svcdescription or paramdescription keywords, comments are not stored in the binary repository_file or output by tmunloadrepos.The repository_input file can consist of zero or more service parameter definitions. Each service definition starts with a line beginning with the <service> keyword followed by zero or more lines beginning with one of the other service-level keywords, followed by parameter-level keywords. A particular service-level keyword may not be repeated for a particular service.A service definition must begin with the keyword service<=NAME> or the abbreviation sv<=NAME>. Services using CARRAY, STRING, or XML buffer types can have only one parameter per service. The Oracle Tuxedo service metadata repository service-level keywords are as follows in Table 8‑3:
• service represents the service entry stored in the Metadata Repository.
• tuxservice represents the actual Oracle Tuxedo service name. Two or more service definitions can have the same value as tuxservice.When used together, these two keywords make it possible to have multiple service definitions for one Oracle Tuxedo service. By default, tuxservice has the same value as service service - the service is a synchronous
oneway - the service will not send response to the client
queue - the service is a /Q related application tuxedo - the service is an Oracle Tuxedo originated servicewebservice - the service is a SALT proxy service converted from external Web Service InterfaceIf not specified, tuxedo is the default value.
Note: Do not specify webservice for any Oracle Tuxedo service, webservice is reserved for SALT proxy service only. FML, FML32, VIEW, VIEW32, STRING, CARRAY, XML, X_OCTET, X_COMMON, X_C_TYPE, MBSTRING or other arbitrary string representing an application defined custom buffer type.
Note: The "inbuf" value of each service definition cannot be NULL. FML, FML32, VIEW, VIEW32, STRING, CARRAY, XML, X_OCTET, X_COMMON, X_C_TYPE, MBSTRING or other arbitrary string representing an application defined custom buffer type.
Note: The "outbuf" value of each service definition cannot be NULL for a "service" typed service or a "queue" typed service. FML, FML32, VIEW, VIEW32, STRING, CARRAY, XML, X_OCTET, X_COMMON, X_C_TYPE, MBSTRING or other arbitrary string representing an application defined custom buffer type.
Note: This keyword is mandatory only if one of the following buffer types is used: VIEW, VIEW32, X_COMMON, X_C_TYPE.
Note: This keyword is mandatory only if one of the following buffer types is used: VIEW, VIEW32, X_COMMON, X_C_TYPE.
Note: This keyword is mandatory only if one of the following buffer types is used: VIEW, VIEW32, X_COMMON, X_C_TYPE. For example, XSD_E:Book@http://example.org represents the input buffer is associated with a XML element <Book> defined in the XML namespace “http://example.org”. Send queue space name. Optional for a "queue" typed service. Send queue name. Optional for a "queue" typed service. Reply queue name. Optional for a "queue" typed service. Error queue name. Optional for a "queue" typed service. Receive queue space name. Optional for a "queue" typed service. Receive queue name. Optional for a "queue" typed service. This parameter is optional and specifies a comma-separated list of field tables where the FML or FML32 fields used by this service can be found. The fieldtbls parameter is intended for reference use by application developers.A parameter begins with the keyword <param><=NAME> or the abbreviation <pn><=NAME> followed by a listing of parameter keywords. It ends with another <param> or <service> keyword, or when end-of-file is encountered. The parameters can be listed in any order after <param><=NAME>.
Note: A particular service can specify multiple occurrences of the <param> keyword. That is to say, more than one parameter can exist for a particular service. For example, a parameter with an FML or VIEW buffer.
Note: The parameter type must be consistent with its service buffer type. For example, an FML16 buffer only allow parameters with the following type: byte (char), short, integer, long, float, double, string, carray. All other type parameters are not permitted. See following buffer type/parameter type matching table. in - indicates a parameter that is used for input only.
out - indicates a parameter that is used for output only.
err - indicates a parameter that is used for error output only.
inout - indicates a parameter that is used for both input and output.
inerr - indicates a parameter that is used for both input and error output.
outerr - indicates a parameter that is used for both output and error output.
inouterr - indicates a parameter that is used for input, output and error output.
noacesss - indicates a parameter that must be provided on input but which is not referenced in the server, such as an obsolete parameter or a parameter that must be provided as a filler field in a view.The set of parameters expected on input is those specified with in, inout, inerr, inouterr, or noaccess accessThe set of parameters returned on output is those specified with out, inout, outerr, or inouterr access.The set of parameters returned on error output is those specified with err, inerr, outerr, or inouterr access.
Note: It is not recommended that you use this information if the fieldtbl files have already been defined by indicating field table directories using environment FLDTBLDIR(32) and indicating field table files using environment FIELDTBLS(32)or fieldtbl service-level keyword.
Note: If you configured the fldnum field, you will receive the responding fldid according to the fldnum value instead of the param value. This parameter is optional for view structure members. Legal values are combination of the following options: 'C', 'F', 'L', 'N', 'P', 'S'. Please reference viewfile(5).
Note: This parameter keyword is introduced especially for “servicemode=webservice” typed service definition, i.e. SALT proxy service for outbound call. The parameter value is generated by Oracle SALT wsdlcvt utility from converting an external WSDL file. Do not manually specify or modify this keyword value.
Note: This parameter keyword is introduced especially for “servicemode=webservice” typed service definition, i.e. SALT proxy service for outbound call. The parameter value is generated by Oracle SALT wsdlcvt utility from converting an external WSDL file. Do not manually specify or modify this keyword value. Indicates the beginning of the description of the parameters contained in an embedded FML32 or VIEW32 buffer field. Ends an embedded FML32 or VIEW32 parameter definition of that began with an opening matching left parenthesis '('.As a generally applied Oracle Tuxedo rule, only FML/FML32, VIEW/VIEW32, X_COMMON, and X_C_TYPE typed buffers can specify multiple parameters (due to their information structure). All other typed buffers have only one parameter with the corresponding parameter type. For example, a CARRAY type buffer has only one CARRAY typed parameter to describe the necessary information that it contains. You must follow this rule to define application services.
•
•
• use tmloadrepos(1) to create and enter service parameter information into the metadata repository file.Once the Oracle Tuxedo metadata server is running, the.TMMETAREPOS service is automatically activated. .TMMETAREPOS is an Oracle Tuxedo system service and cannot be modified.Setting up multiple TMMETADATA servers on a particular Oracle Tuxedo node requires adherence to two crucial configuration rules:
• Each TMMETADATA server must be configured to access the same metadata repository file or an exact copy of the file to provide consistent request results. Therefore, it is strongly recommended that a stable version of the metadata repository is made available for multiple TMMETADATA server access.
• Permission settings must be consistently applied (either read only or read/write) for multiple TMMETADATA servers on a particular node.
• For native clients exclusively, tpgetrepos(3c), and tpsetrepos(3c)are used for Oracle Tuxedo service metadata repository access.tpgetrepos(3c) and tpsetrepos(3c) can access the Oracle Tuxedo service metadata repository whether the server is booted or not.
• For remote and native clients, TMMETADATA(5) can be used.