System, method and article of manufacture for universal transaction processing over multiple transaction processing systems6038587Abstract A computer implemented transaction processing system is presented for processing transactions between an application and one or more transaction processors. The system utilizes a first communication link between the application and a transaction processor interoperability component. Then, the system determines which of the one or more transaction processors will process transactions for the application and establishes a communication link between the transaction processor interoperability component and the transaction processor that will process transactions for the application. Then, as the application transmits a transaction from the application to the transaction processor interoperability component, the transaction is formatted by the transaction processor interoperability component for comparability with the transaction processor that will process transactions for the application, and finally transmitting the formatted transaction to the transaction processor that will process transactions for the application. Transactions are processed across multiple TP monitors. Claims What is claimed is: Description FIELD OF THE INVENTION
______________________________________
Public TxMgr interfaces
namespace ISTx {
PUBLIC.sub.-- NAMESPACE
enum CompletionStatus {COMPLETED.sub.-- YES COMPLETED.sub.-- NO,
COMPLETED.sub.-- MAYBE};
//
// Completion Status of Current operations
enum ReportHeuristics {kReportYes , kReportNo};
//
// Flags to pass into Current::commit. If kReportYes is specified,
// all delegated commits will wait for the 2nd phase to complete
// before returning.
enum MinorError {
//
// Minor error returned by Current operations.
//
SubtransactionUnavailable,
//
// Returned when Current::begin is called when there is
// already a current transaction
NoTransaction,
// Returned when there is not a current transaction
//
HeuristicMixed,
//
// Returned from Current::commit when a transaction has
// a mix of commits and rollbacks
//
HeuristicHazard,
//
// Returned from Current::commit when a transaction may have
// a mix of commits and rollbacks
//
NO.sub.-- PERMISSION};
//
// Returned from Current::commit or Current::rollback when
// the caller is not the owner of the transaction
//
//
// Exception thrown by Current Interface
//
class CurrentException
public:
CompletionStatus completed() {return pCompleted;};
//
// Status of action. Currently only YES is ever returned.
//
MinorError minor() {return pMinor;};
//
// Minor error of exception
//
CurrentException() : pCompleted(COMPLETED.sub.-- YES) {};
CurrentException(MinorError aMinor):
pCompleted(COMPLETED.sub.-- YES),
pMinor(aMinor) {};
private:
CompletionStatus pCompleted;
MinorError pMinor;
};
//
// Current interface. All operations may throw a CurrentException
// exception, except where noted.
//
class Current
{
public:
//
virtual void begin() = 0;
//
// Begin the transaction
//
virtual void commit(ReportHeuristics report = kReportYes) = 0;
//
// Commit the transaction
//
virtual void rollback() = 0;
//
// Rollback the transaction (if caller is owner of transaction)
//
virtual void rollback.sub.-- only() = 0;
//
// Mark the transaction to be rolled back at prepare time
// (used if caller is not owner of transaction)
//
virtual char* get.sub.-- transaction.sub.-- name() = 0;
//
// Return ascii, null terminated name of transaction. Returns
// NULL when there isn't a current transaction.
//
};
//
// Return a pointer to the singleton Current object
//
class TxMgrFactory {
public:
static Current* getTxMgr(void);
};
};
Private TXMgr interfaces
namespace ISTxP {
PUBLIC.sub.-- NAMESPACE
enum TransactionsVote {kCommit, kRollback};
enum RegisterOutcome {kSuccess, kAlreadyRegistered,
kNoTransactionStarted};
enum Wait2ndphase {kWaitYes = ISTx::kReportYes,
kWaitNo = ISTx::kReportNo};
enum ExceptionCondition {kNoTransaction, kHeuristicMixed,
kHeuristicHazard};
enum CommitStatus {kOk, kFailed, kHazard};
class TxMgrRcvr{
public:
virtual TransactionsVote prepare () = 0;
virtual CommitStatus commit(Wait2ndPhase wait = kWaitYes) = 0;
virtual void rollback() = 0;
};
class TXMgrX: public ISTx::Current {
public:
TXMgrX();
.about.TXMgrX();
RegisterOutcome registerRcvr(const char* string, TXMgrRcvr*
rcvObj);
void begin();
void commit(ISTx::ReportHeuristics report = ISTx::kReportYes);
void rollback();
void rollback.sub.-- only();
char* get transaction.sub.-- name();
unsigned isTransaction();
void setLogData(const char* rcvrld, char* logData);
};
};
#endif
______________________________________
Admin The admin tool is used to bridge an interface between a human administrator and programmatic interfaces offered by internal classes. The general algorithm is to do the following: get a name context from the user present the user with either an existing or default set of property values for modification store the name context and set of property values This module presents no new objects. Usage Scenarios FIG. 9 illustrates a scenario where the naming context is known in accordance with a preferred embodiment. An initial transaction querying for the name context 901 triggers a get property transaction from the admin tool to the Service resolver 902 which returns the "known" property. Then the admin tool sends out another transaction to get the factory 903 from the interoperability tool. The values are returned from the admin tool to the user 904. Then, a check of the values is initiated by the admin tool 905 and the properties are set in the service resolver 906. FIG. 10 illustrates a case where the naming context is unknown in accordance with a preferred embodiment. An initial transaction querying for the name context 1011 triggers a get property transaction from the admin tool to the Service resolver 1002 which returns a "unknown" property. The user is queried for the factory type 1003. Then the admin tool sends out another transaction using the factory 1003 type to the interoperability tool to get the factory 1004 and to get the defaults from the TP manager 1005. The values are returned from the admin tool to the user 1006 to determine if they meet with user approval. Then, a check of the values is initiated by the admin tool 1007 and the properties are set in the service resolver 1008. PropList The property list classes encapsulate property list handling for various concrete TPInterop classes.
__________________________________________________________________________
IDL
module propList {
// valueList operates on the dynamic portion
// of a property list. A valueList consists of
// "type", or "svcName" and a number of name/value
// pairs that make up the property list.
//
interface valueList {
string getValue(in string name);
//
// Returns the value for a name.
// Memory ownership retained by callee
//
setValue(in string aName, in string aValue);
//
// Sets the value for a name.
// Memory ownership retained by caller.
//
addName(in string aName, in string aValue);
//
// Adds a name and defaultValue
// Memory ownership retained by caller
string writeToString();
//
// All name/values are written to a string.
// Memory ownership passes to caller
readFromString(in string buffer);
//
// All name/values are read from a string
// Memory ownership retained by caller
};
typedef RWHashDictionaryValueSequence;
typedef RWHashDictionaryIteratorValueSequenceIterator;
typedef RWCollectableInt ValueSequenceItem;
//
// Dict of possible values, with room for an int enum for each value
// key is RWCollectableString
// value is ValueSequenceItem
class HelpListItem: public RWCollectable {
public:
HelpListItem(): possibleValues(5) {};
HelpListltem(const char *sh): shortHelp(sh), possibleValues(5) {};
RWCString shortHelp;
ValueSequence possibleValues;
};
typedef RWHashDictionaryHelpList;
typedef RWHashDictionaryIteratorHelpListIterator;
//
// Dict of help list items.
// key is RWCollectableString
// value is HelpListItem
//
class CallMgrHelp {
public:
CallMgrHelp() {};
virtual .about.CallMgrHelp() {};
virtual const ISPropListP::ValueList*getDefaultValueList() const = 0;
//
// return the list of default values for this call mgr
//
virtual HelpList & getHelpList() = 0;
//
// return the help list for this call mgr
//
virtual ReturnCode verifyValueList(constISPropListP::ValueList* aList,
RWCString* offendingValue,
ISError* offendingReason) = 0;
//
// verify the specified valuelist, return error if it is incorrect.
// "offendingValue" is the name of the property that caused the error.
// offendingValue may be NULL to stifle return value
//
virtual RWCString getTPName() const = 0;
//
// return the name used the callMgr with ISInteropP::TPMgrX
//
virtual void verifyItem(const char *propertyName,
const ISPropListP::ValueList* aList,
const char **propertyString,
int checkValue, int *propertyEnum,
RWCString* offendingValue);
//
// Implemented by this base class.
//
// Given a propertyName, returns the propertyString stored in the
// value list. throws an ISError if it can't get the propertyString
// propertyString may be NULL to stifle the return.
//
// If checkValue is TRUE, look up the value & return the value of
// one of the "possibleValues" of the helpListItem for this
propertyName.
// throws an ISError if it isn't in range.
//
// offendingValue is set to the propertyName that caused the error.
//
};
//
// Implementation of CallMgrHelp should be in a file named xxxhelp.cpp,
// with no
// references to external libs or DLLs. The object should be created
with
// the
// following method.
//
// ISInteropP::CallMgrHelp*IScreateCallMgrxxxHelp(RWCString
//®name)
//
//
Code Implementation
TuxCallMgrProperties::TuxCallMgrProperties(): theHelpList(5)
//
// Create help list
//
ISInteropP::HelpListItem*reqItem=flewISInteropP::HelpListItem("Request
Type");
reqItem->possibleValues.insertKeyAndValue(new RWCollectableStri
ng("REQUEST/RESPONSE"), new RWCollectableInt(kReqResp));
reqItem->possibleValues.insertKeyAndValue(new
RWCollectableString("CONVERSATIONAL"), new RWCollectableInt(kConv
));
theHelpList.insertKeyAndValue(new
RWCollectableString("REQUESTTYPE"),
reqItem);
defaultValueList.addName("REQUESTTYPE", "REQUEST/RESPONSE"
);
ISInteropP::HelpListItem* bufItem = new ISInteropP::HelpListItem("Buffer
Type");
bufItem->possibleValues.insertKeyAndValue(
newRWCollectableString("FML"),
new RWCollectableInt(0));
bufItem->possibleValues.insertKeyAndValue(new RWCollectabl
eString("FML32"), new RWCollectableInt(1));
bufItem->possibleValues.insertKeyAndValue(
newRWCollectableString("VIEW"),
new RWCollectableInt(2));
bufItem->possibleValues.insertKeyAndValue(
new RWCollectableString("VIEW32"),new RWCollectableInt(3));
bufItem->possibleValues.insertKeyAndValue(new
RWCollectableString("CARRAY"),new RWCollectableInt(4));
theHelpList.insertKeyAndValue(
newRWCollectableString("BUFFERTYPE");
bufItem);
defaultValueList.addName("BUFFERTYPE","FML");
ISInteropP::HelpListItem*subItem = new ISInteropP::HelpListItem("Buffer
Sub Type");
theHelpList.insertKeyAndValue(
new RWCollectableString("BUFFERSUBTYPE"),
bufItem);
defaultValueList.addName("BUFFERSUBTYPE", "");
ISInteropP::HelpListItem*txItem = new ISInteropP::HelpListItem("Start
Transaction");
txItem->possibleValues.insertKeyAndValue(new
RWCollectableString("IMPLICIT") ,new RWCollectableInt(kImplicit));
txItem->possibleValues.insertKeyAndValue(
new RWCollectableString("NONE"),
new RWCollectableInt(kNone));
theHelpList.insertKeyAndValue(
new RWCollectableString("STARTTRANSACTION"),
txItem);
defaultValueList.addName ("STARTTRANSACTION"; "NONE");
ISInteropP::HelpListItem*svcItem =
new ISInteropP::HelpListItem("Service
Name");
theHelpList.insertKeyAndValue(
new RWCollectableString("SERVICENAME"),
svcItem);
defaultValueList.addName("SERVICENAME", "");
ISInteropP::HelpListItem*lenItem =
new ISInteropP::HelpListItem("Buffer
Length");
theHelpList.insertKeyAndValue(
new RWCollectableString("BUFFERSIZE"),
lenItem);
defaultValueList.addName("BUFFERSIZE", "1000");
};
TuxCallMgrProperties::.about.TuxCallMgrProperties()
{
};
RWCString TuxCallMgrProperties::getTPName()const
{
RWCString name("TPTUX");
return name;
};
const ISPropListP::ValueList*TuxCallMgrProperties::getDefaultValueList()
const
{
return &defaultValueList;
};
ISInteropP::HelpList&Tux:CallMgrProperties::getHelpList()
{
ISInteropP::HelpList&helpList = theHelpList;
return helpList;
};
ISInteropP::ReturnCode TuxCallMgrProperties::verifyValueList(const
ISPropListP::ValueList*aList,
RWCString* offendingValue,
ISError* offendingReason)
{
try{
verifyItem("REQUESTTYPE",aList, NULL, 1, (int *) &reqType,
offendingValue);
int junk;
const char *buf;
verifyItem("BUFFERTYPE",aList,&buf, 1, &junk, offendingValue);
bufferType = buf;
if ((bufferType == "VIEW") .vertline..vertline. (bufferType == "VIEW32"))
{
const char *subbuf;
verifyItem("BUFFERSUBTYPE",aList, &subbuf, 0, NULL,
offendingValue);
bufferSubType = subbuf;
}
verifyItem("STARTTRANSACTION",aList, NULL, 1, (int *) &startTxType,
offendingValue);
const char *name;
verifyItem("SERVICENAME",aList, &name, 0, NULL, offendingValue);
serviceName = name;
const char *size;
verifyItem("BUFFERSIZE",aList, &size, 0, NULL, offendingValue);
verifyBufferSize(size, "BUFFERSIZE");
}
catch(ISError ise) {
memcpy(offendingReason, &ise, sizeof(ISError));
return ISInteropP::kFailure;
}
return ISInteropP::kOk;
void TuxCallMgrProperties::verifyBufferSize(const char *propValue, const
char *propName)
{
if (sscanf(propValue, "% d", &bufferSize) != 1) {
throwISError("ISMGEN", 3001, propName, propValue);
}
}
admin UI code:
//
// Assume user has told us factoryType = "TUXEDO" and
// nameContext = "/accounts/checking/debit"
//
tuxMgr = TpMgr::getCallMgr(factoryType);
// Check the svcResolver for an existing value string.
// if it exists, convert it, else create a new one
// with defaults.
PropList::valueList *aPropList;
SvcResolver->getAttributes(nameContext, aPropList, factoryType);
if (aPropList == NULL)
aPropList = tuxMgr->getDefaultValueList();
}
// get the static help properties
anHPropList = tuxmgr->getHelpList();
// update the values somehow, use helpList if
// needed
// write the values
svcResolver->setAttributes(nameContext, aPropList, factoryType);
__________________________________________________________________________
TP Interoperability TPInterop::TPmgr executes on the gateway and accepts a request along with a description of the destination from front-end clients and delegates them to a specific interoperable object (e.g. TPCICS::CallContext, TPIMS::CallContext, TPTux::CallContext and TPPW::CallContext) according to the destination. Since the whole invocation is carried out in a distributed environment, parameters are passed via Extern::Streamable objects. Externalization referred in this section is based on OMG's Object Externalization Service Specification. Detail Object Model FIG. 11 is a booch diagram of an object model of TPInterop in accordance with a preferred embodiment. TPInterop::CallContext is an abstract base class. All subclasses have to override invoke method, and the method invokeObject on TPInterop::CallMgr 1102. TPInterop::TPmgr 1104 is the interface exported to the application. Since registerCallMgr is specific for TPInterop::CallMgr, TPInterop::TPmgr.sub.-- Ex is used internally. There is only one instance of TPInterop::TPmgr 1104 per process. Each TPInterop::CallMgr object within the process registers itself with TPInterop::TPmgr object. RegisterCallMgr and unregisterCallMgr are the facilities provided by the TPInterop::TPmgr 1104 object. An externalization service is a standard service for streaming objects to and from transport streams, persistent storage, etc. It consists of two main pieces: an abstract Extern::Streamable class 1112 which an application object inherits from, and an abstract Extern::StreamIO class 1110 which the externalization service provides an implementation for. Externalize is called by a TPIterop:TPConversation class 1106 which passes an Extern::StreamIO 1108 subclass object, and the object 1108 is expected to write its state out using the Extern::StreamIO::writeXxx calls 1110. When internalize is called, the object is expected to read its state from the Extern::Streamable object 1112 using the Extern::StreamIO::readXxx calls. The Extern::StreamIO class is similar in function to a C++ iostream class, but uses explicit method calls to read and write data types rather than use operator overloading.
______________________________________
ISInterop
class TPMgr {
public:
TPMgr();
virtual .about.TPMgr();
virtual ISError invoke(CallContext** cxt,
const char* destination,
ISExtern::Streamable*request,
ISExtern::Streamable*Response) = 0;
//
// Call a service indicated by destination. Destination must
// be a valid entry in the service name resolver database.
//
// If cxt is not NULL, it may be set to a returned CallContext
// whose memory is owned by the caller. If cxt is not NULL and
// if no CallContext is returned, *ctx will be set to NULL.
//
// request will be called with either the
// Streamable::externalize.sub.-- to.sub.-- streamor externalize.sub.--
to.sub.-- tokenStream
// methods, depending on the type of service.
//
// response will be called with either the
// Streamable::internalize.sub.-- from.sub.-- streamor internalize.sub.--
from.sub.-- tokenStream
// methods, depending on the type of service.
//
virtual ISError setServiceNameDirectory(const char* aNameDirectory) =
0;
//
// Sets the service name "directory" used to resolve destinations
// on the invoke method.
//
};
class CallContext {
public:
CallContext();
virtual .about.CallContext();
virtual ISError invoke(ISExtern::Streamable*Request,
ISExtern::Streamable*Response) = 0;
//
// Continuation of a service initiated by TPMgr::invoke.
// request and response parameters are handled the same
// as the TPMgr::invoke method.
//
};
Module TPInterop
class CallMgr : public RWCollectable {
public:
CallMgr() {;};
virtual .about.CallMgr() {;};
virtual ISError invokeObject(ISInterop::CallContext**,
const ISPropListP::ValueList*aList,
ISExtern::Streamable*Request,
ISExtern::Streamable*Response) = 0;
};
//
// The object should be created with the following method.
//
// ISInteropP::CallMgr* IScreateCallMgrXxx(void)
//
______________________________________
Major Behavior Description A preferred embodiment provides the application developer with two transaction models: explicit model and implicit model. The syntax of the code using explicit model is similarly to the following code segment: tptxObject.Begin.sub.-- Transaction(); cicsObject.go(request1, response1); cicsObject.go(request2, response2); tptxObject.End.sub.-- Transaction(); In implicit model, invocation of invoke method starts and commits the transaction. The syntax of the code looks as follows: tpinteropMgr.go("debit1", request1, response1); tpinteropMgr.go("debit2", request2, response2); Data and Format Conversion Between Systems The purpose of this section is to identify the data conversion required for a specific TP component, running on the gateway platform and the server platform on which the TP server is running. Little & Big Endian Little and big Endian relates to the format integers (2 or 4 byte) are stored on a specific platform Floating point numbers are stored in different formats, e.g. IEEE.
______________________________________
Big Endian
SUN, HP, RS/6000, Tandem, System/390 systems.
Integer (2 byte)
12
Integer (4 byte)
1234
Little Endian
Intel systems
Integer (2 byte)
21
Integer (4 byte)
4321
______________________________________
ASCII & EBCDIC ASCII and EBCDIC formats relates to the way character data is formatted. The IBM System/390 platform is the only platform that uses the EBCDIC data format.
______________________________________
Gateway Server Endian Data Representation
Platform Platform Conversion Conversion
______________________________________
CICS & IMS
Intel- S/390 Little Endian
ASCII to EBCDIC
(NT, OS/2)
(MVS) to Big Endian
RS.backslash.6000-
S/390 None ASCII to EBCDIC
(AIX) (MVS)
SPARC- S/390 None ASCII to EBCDIC
SUN (MVS)
HP-PA S/390 None ASCII to EBCDIC
7100-HP (MVS)
Pathway
Intel- Tandem Little Endian
None
(NT, OS/2) to Big Endian
RS/6000- Tandem None None
(AIX)
SPARC- Tandem None None
SUN
HP-PA Tandem None None
7100-HP
______________________________________
Tuxedo Note: the Tuxedo workstation service performs internal little and big Endian conversions.
______________________________________
Gateway Server Endian Data Representation
Platform Platform Conversion Conversion
______________________________________
Intel- SUN/HP None None
(NT, OS/2)
RS/6000- SUN/HP None None
(AIX)
SPARC- SUN/HP None None
SUN
HP-PA SUN/HP None None
7100-HP
______________________________________
Externalization The OMG Externalization Service is a standard service for streaming objects to and from transport streams, persistent storage, etc. It consists of two main pieces an abstract Extern::Streamable class which an application object inherits from, and an abstract Extern::StreamIO class which the externalization service provides an implementation for. The Extern::Streamable class provides to methods: externalizeToStream, and internalizeToStream. When externalize is called, an Extern::StreamIO subclass object is passed to the application object, and object is expected to write its state out using the Extern::StreamIO::writeXxx calls. When internalize is called, the object is expected to read its state from the Extern::StreamIO subclass object using the Extern::StreamIO::readXxx calls. The Extern::StreamIO class is similar in function to a C++ iostream class, but uses explicit method calls to read and write data types rather than use operator overloading. The externalization service acts as a bridge between the TP monitor communication buffer and the ORB world. The application object creates a request and reply object. The request object supports the externalize function to create a request buffer for the TP link object, and the reply object supports the internalize function to read the reply buffer. The request and reply object act as a bridge between the ORB world and the TP monitor world--the TP monitor buffers are never seen, but the request and reply objects know the exact order of the data in the buffer. Data Types The following data types are supported: char*, char, octet, short, unsigned short, long, unsigned long, float, double and bool, where both bool and octet are defined as unsigned short. StdStreamIO's data format is OMG Object Externalization Specification compliant. TPStreamIO's data format is different. It does not have data type and data length fields. TPStreamIO is the class used for externalization and internalization at Stage 1A.
______________________________________
IDL
module extern {
typedef void* bufPtr;
interface StreamIO {
// All the following methods should be overwritten.
void writeChar(in char aChar);
void writeOctet(in octet aOctet);
. . .
char readChar();
octet readOctet();
};
interface TPStreamIO : StreamIO {
void setOutputBuffer(in bufPtr aBuffer, in long length);
long getOutputBufferLength();
long getDataLength();
void writeChar(in char aChar);
void writeOctet(in octet aOctet);
. . .
char readChar();
octet readOctet();
};
interface streamable {
void externalize.sub.-- to.sub.-- stream(in streamIO aStream);
void internalize.sub.-- to.sub.-- stream(in streamIO aStream);
};
interface TPStreamIOFactory {
enum streamDestination {RS6000, HP, INTEL, TANDEM, IBM370,
SUNSPARC, POWERPC};
createTPStreamIO(in streamDestination theDestination);
};
______________________________________
TPStreamIO provides methods to set up the buffer pointer, for the reason that Tuxedo needs to use buffer allocated by its own memory allocation APIs. Data Format Conversion Since the Gateway platform and Server platform might be different, and different platforms might have different scheme for data representation, program running on Gateway need converting the data format to be compliant with that of the server platform. The following tables show what operations need to be performed for data conversion based upon different Gateway and Server platform configurations. FIG. 12 is a Booch diagram of externalization processing in accordance with a preferred embodiment. Every Extern::TPStreamIO 1220 object has two internal flags of bool types; they are flagLtoB and flagAtoE. When an Extern::TPStreamIOFactory 1270 is asked to create an Extern::TPStreamIO 1230, it must be given the information about Gateway platform and Server platform. According to the message, it looks up the table and sets the flags of the Extern::TPStreamIO 1230 correspondingly. When the Extern::TPStreamIO 1230 object is asked to write or read, it will check those flags also. The Extern::TPStreamIOFactory 1270 object is a singleton object. Interactive Diagram FIG. 13 illustrates a simple interaction for an application object using a request object to help the TPXXX object build a request buffer, invoke the request and send back the response. CORBA ORE portability To minimize dependencies on the ORB, the concrete implementation of the streamIO objects should be built as stand-alone C or C++ objects, with the ORB implementation classes delegating work to the C++ classes. Non-CORBA ORB portability Most distributed object managers have this notion of object streaming, and there is only so much variation. Using the same technique as for "CORBA ORB portability", any future service, such as an Distributed OLE streaming mechanism, can be used. ISNaming and SvcResolve The OMG naming service is the principal means for objects to locate other objects. The names given to the objects should be easily recognizable and readable within the problem domain of the application. The naming service will map these user-defined "names" to object references. The name-to-object association is called a "name binding". A "naming context" is an object that contains a set of "name bindings" in which each name is unique. Every object has a unique object ID or reference. One or more names can be associated with the same object reference at the same time, however there is no requirement for all objects to be named. Because a naming context is an object, it too can be bound to a name in a naming context. Binding naming contexts to other naming contexts creates a "naming graph". The "naming graph" is a directed graph or tree where the nodes are naming contexts and the leaves are name bindings to non-naming context objects. Given a context in a naming graph a sequence of names can reference an object. ISNaming Naming contexts and names In the OMG Naming service a "name component" is a structure with two attributes, an identifier which includes the object's name string, and a kind which includes a string that is a description of the objects name, ie. file type etc. A name with a single "name component" is called a "simple name", a name with "multiple components" is called a "compound name." Each component except the last is used to name a context; the last component denotes the bound object. The kind attribute for the Name component will be assumed to be NULL and will be omitted from the NameComponent definition. Compound names will simply be defined as a unique string similar to a directory name in common PC files systems, with a"/" character delimiting each substring representing the NameComponent within the compound name. Names are specified without the trailing "/" character, the process of binding a name to a context will be equivalent to the operation of adding the "/" character to the string. The following names BANKING/ RETAIL/ CHECKING/ DEBIT and BANKING/ RETAIL/ CHECKING/ CREDIT refer to bound objects. SvcResolve The SvcResolve class provides a naming service and server for names and objects associated with the TPInterop:: TPMgr. It maintains naming contexts and name-object associations for TPInterop::CallMgr objects and subclasses for this release. Object Model FIG. 14 is a Booch diagram illustrating the relationship between the TPInterop::TPMgr 1400, TPInterop::CallMgr 1410, TPInterop::CallContext 1420 classes and the SvcResolve::Resolver 1420 naming service components.
______________________________________
IDL Classes
module ISNaming {
interface Name {
attribute string name;
};
interface NamingContext {
attribute string name;
attribute popList::valueList currentPropList;
void bind(in Name name, in ObjectRef ref);
void rebind(in Name name, in ObjectRef ref);
void bindWithPropertyList(in Name name,
in SvcResolve::ObjectRef ref,
in propList::valueList p1);
void rebindWithPropertyList(in Name name,
in SvcResolve::ObjectRef ref,
in propList::valueList p1);
void bindContext(in Name name, in NamingContext cxt);
void rebindContext(in Name name, in NamingContext cxt);
void bindContextwithPropertyList(in Name name,
in NamingContext cxt,
in propList::valueList p1);
void rebindContextWithPropertyList(in Name name,
in NamingContext cxt,
in propList::valueList p1);
SvcResolve::ObjectRef resolve(in Name name);
void unbind(in Name name);
NamingContext newContext();
NamingContext bindNewContext(in Name name);
void setPropertyList(in Name name,
in propList::valueList propstring);
void removePropertyList(in Name name,
in propList::valueList propstring);
propList::valueList getPropertyList(in Name name);
};
interface NamingGraph {
NamingContext get.sub.-- context(in NamingContext root.sub.-- cxt,
in string compound.sub.-- name);
void buildGraph(in NamingContext root.sub.-- cxt,
in string compound.sub.-- name);
void destoryGraph(in NamingContext root.sub.-- cxt,
in string compound.sub.-- name);
void bindGraph(in NamingContext cxt,
in string compound.sub.-- name,
in SvcResolve::ObjectRef ref);
void unbindGraph(in NamingContext cxt,
in string compound.sub.-- name,
in SvcResolve::ObjectRef ref);
};
};
module SvcResolve {
interface ObjectRef {
attribute string<512> ref;
};
interface Resolver {
ObjectRef resolveTPServiceDestination(in string name,
out propList::ValueList);
ISNaming::NamingContext locateGlobalNamingContext();
void setGlobalNamingContext(in string cxt);
void addTPServiceDestination(in string name,
in ObjectRef Factory,
in propList::valueList pl);
void deleteTPServiceDestination(in string name);
void changeTPServiceDestination(in string name,
in ObjectRef Factory,
in propList::valueList pl);
};
};
______________________________________
Usage examples and scenarios
__________________________________________________________________________
Names to Object Table
The following table maps name/naming contexts to objects.
Name/Naming Context
Reference
Property List
__________________________________________________________________________
/BANK/RETAIL/CHK/DEBIT
TUXEDO
RequestType=request/response
BufferType=VIEW
startTx=YES
/BANK/RETAIL/CHK/CREDIT
TUXEDO
RequestType=request/response
BufferType=VIEW
startTx=YES
/BANK/COMM/TRADE/BOND/SELL
CICS CICSPGM=CICSAPP
/BANK/COMM/TRADE/BOND/BUY
CICS CICSPGM=CICSAPP
/BANK/RETAIL/SAV/DEBIT
IMS TRANCODE=SAV001TR
/BANK/RETAIL/SAV/CREDIT
IMS TRANCODE=SAV002TR
__________________________________________________________________________
TPInterop::TPMgr Interaction FIG. 15 is a Booch diagram illustrating the Interaction processing in accordance with a preferred embodiment. The TPInterop::TPMgr creates the SvcResolve::Resolver object, (during its initialization or startup). and calls the SvcResolve::Resolver method "setGlobalNamingContext" 1. The Application is activated, and calls the TPInterop::TPMgr method "invoke" with the following parameters as shown at 1501. Name representing the TPInterop::CallMgr application streamable input object. application streamable output object. 2. The TPInterop::TPMgr get the input name representing the TPInterop::CallMgr object as shown at 1502. 3. The TPInterop::TPMgr calls resolveTPServiceDestination on the SvcResolve::Resolver object with the name representing the transaction as an input parameter. The method returns an object reference, and the associated property list as shown at 1503. 4. The TPInterop::TPMgr calls the getCallMgr method with the object reference obtained in 3) to locate the appropriate TPInterop::CallMgr object as shown at 1504. 5. The property list is used as input for the invoke method on the TPInterop::TPCallMgr object as shown at 1505. TPxxx--Typical TP Monitor Model This section describes a typical implementation of a set of TPxxx classes, such as TUXEDO, CICS, etc. Object Model FIG. 16 is a Booch diagram setting forth the architecture of the TP monitor in accordance with a preferred embodiment. IDL A typical implementation of TPxxx classes introduces no new methods, but overrides the abstract class interfaces shown in the object model. Usage Scenarios See the scenario in the overview chapter for an overview, and see the specific TPxxx chapters for specific details. CICS FIGS. 17 and 18 set forth some details of CICS processing in accordance with a preferred embodiment. The purpose of this component is to provide connectivity between the TP inter-operability module and a CICS system running on another computer. Connectivity to CICS is achieved through the CICS LU 6.2 service and the CICS user transaction is invoked via the CICS Program Link interface. The LU 6.2 service allows a client LU 6.2 application (written to the basic LU 6.2 level or using the CPIC interface) to connect to a CICS system running on a server through the CICS LU 6.2 service. A CICS LU 6.2 transaction will be provided by this project to inter-operate with the CICS LU 6.2 service and the client LU 6.2 application. The CICS LU 6.2 transaction will convert the data received from an LU 6.2 client and then perform a CICS Program Link command to invoke the appropriate CICS user application. In FIG. 17, processing commences at 1701 and immediately passes to 1702 to invoke a transaction and connect to a CICS LU 6.2 service. At 1703 a register operation occurs and a get request 1704 to allocate a streamIO, setbuffer, externalize the transaction and obtain the buffer length. Then, at 1705 a LU 6.2 allocate operation is performed and at 1706 a send operation is performed. Finally, at 1707, a put reply is performed to allocate streamIO, internalize the transaction and obtain the buffer length of the transaction. A second invoke operation 1708 is performed in which the first operation is a register operation 1709 which will fail since the transaction is already registered. Then a get request 1710 is performed which initiates a send/recieve 1711 transaction which invokes a put reply 1712 and ultimately an end transaction 1713 which invokes a prepare 1714 transaction and sends a prepare message 1715 which results in a commit 1716 and a syncpoint message 1717 and ultimately an LU 6.2 dealloc 1718. In FIG. 18 processing commences at 1803 where an invoke operation occurs which returns a context object. Then, at 1804 a register operation is performed which fails if there is no transaction. At 1805, a get request is sent and at 1806 an LU 6.2 allocate operation is performed which is followed by an LU 6.2 send/recieve 1807 and a put reply 1808 is used to transmit the transaction to the CICS system. At 1809 another invoke operation is performed and a get request 1810 is utilized to initiate a send/receive transaction 1811 which prepares a message to send 1812 and invokes a send syncpoint message 1801 which results in an LU 6.2 deallocate operation 1802 and a put reply 1813. The CICS Program Link interface requires a program name which is the name of the CICS user application that will be invoked. This program will run under CICS transaction id associated with the user program. The Program Link interface also requires an input and output buffer the so called Commarea. The Commarea is used for both input and output data. The input data will be as a result of the object attributes being streamed and the output data will be the data returned by the CICS user application. The connectivity between the CICS inter-operability module and CICS system will be via LU 6.2. The CPIC interface can be used to perform the LU 6.2 communication using sync level 1 or confirm protocol. Usage Scenarios See the "overview" chapter for a generic interaction diagram. The following are some specific details. Usage Notes In conversational or request/response mode, it is invalid for there to be a NULL request and/or reply object. If there is not a current transaction, the StartTransaction property will be checked. If it is set to yes, a transaction will be committed at the end of a successful LU 6.2 send/receive (request/response mode) or at the end of a conversation (conversational mode) initiated by LU 6.2 allocate. CICS transactions are started implicitly by the first EXEC CICS LINK request. Request/response will always return a nil callContext object. Conversational mode always returns a callContext object, unless the conversation is ended on the LU 6.2 deallocate. Service Parameters The following service parameters are defined:
______________________________________
Name Description Values
______________________________________
Partner Name of CPIC side file
char [8]
Name
Program Name of CICS application
char [8]
Name program
Start Start a transaction when
Implicit, None
Transaction
there isn't a current one
______________________________________
IMS FIGS. 19 and 20 set forth some details of IMS processing in accordance with a preferred embodiment. The processing set forth in these figures corresponds very closely to the processing in FIGS. 17 and 18. The purpose of this component is to provide connectivity between the TP inter-operability module and an IMS system running on another computer. Connectivity to IMS is achieved through the IMS LU 6.2 to LU 6.1 adapter which will place an IMS transaction on the IMS transaction queue. The IMS adapter allows a client LU 6.2 application (written to the basic LU 6.2 level or using the CPIC interface) to connect to an IMS system running on a server through the IMS LU 6.2 to LU 6.2 adapter. Usage Notes With IMS it is not easy to determine when an IMS transaction is started or ended, therefore whether a transaction is started explicitly or implicitly is irrelevant to the IMS transaction on the server side. If there is not a current transaction, the StartTransaction property will be checked. If it is set to yes, the conversation will be ended at the end of a successful LU 6.2 send/receive (request/reply mode) or at the end of a conversation initiated by LU 6.2 allocate. Request/response will always return a nil callContext object. Conversational always returns a callContext object, unless the conversation is ended after the LU 6.2 send/receive. Service Parameters The following service parameters are defined:
______________________________________
Name Description Values
______________________________________
Partner Name Name of CPIC side file
char [8]
TP Name IMS Transaction name
char [8]
______________________________________
Pathway FIGS. 21 and 22 set forth details of Pathway processing in accordance with a preferred embodiment. The processing set forth in these figures corresponds very closely to the processing in FIGS. 17 and 18. The purpose of this component is to provide interoperability between the TP inter-operability module and a Pathway system running on a Tandem computer. Connectivity to Pathway is achieved through the RSC service which runs on the client and server (Tandem) side. The RSC service allows a client application to connect to a Pathway system running on a server through TCP/IP. Usage Notes In conversational mode, to initiate a RscWrite, pass in a NULL reply object. Otherwise for a RscWriteRead a non-NULL response and reply objects are required. If there is not a current transaction, the StartTransaction property will be checked. If it is set to yes, a transaction will be started and committed at the end of a successful RscWrite or RscWriteRead (request/reply mode) or at the end of a conversation initiated by RscBeginSession. Request/response will always return a nil callContext object. Conversational always returns a callContext object, unless the conversation is ended on the RscEndSession. Service Parameters The following service parameters are defined:
______________________________________
Name Description Values
______________________________________
Pathway Name of the application
Char [16]
Server Class
Pathway server class.
Name
RSC INI File
File name for initiation
char [8]
Name parameters
Start Start a transaction when
Implicit, None
Transaction
there isn't a current one
______________________________________
Tuxedo The Tuxedo TP interop component is a concrete implementation of several abstract classes. It supports the following features: Request/response (tpcall) access to Tuxedo services is supported. Conversational (tpconnect) access to Tuxedo services is supported. The Tuxedo TP interop component will run on a machine supporting either native Tuxedo or /WS. The four types of Tuxedo communication buffers, CARRAY, String, VIEW and FML, are supported to facilitate access to transaction demarcation verbs. Usage Scenarios FIG. 23 illustrates Tuxedo request / response transactions within an explicit transaction in accordance with a preferred embodiment. FIG. 24 illustrates a Tuxedo conversational transaction within an implicit transaction in accordance with a preferred embodiment. The processing set forth in these figures corresponds very closely to the processing in FIGS. 17 and 18. Usage Notes In conversational mode, to initiate a tprecv without a previous tpsend, pass in a NULL request object. To initiate a tpsend without a subsequent tprecv, pass in a NULL reply object. If there is not a current transaction, the StartTransaction property will be checked. If it is set to yes, a transaction will be started and committed at the end of a successful tpcall or at the end of a conversation initiated by tpconnect. Request/response will always return a nil callContext object. Conversational always returns a callContext object, unless the conversation is ended on the tpconnect. While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
|
Same subclass Same class Consider this |
||||||||||