The Job Transfer and Manipulation work was originally designed to support remote off-line processing. It does not, however, set out to in any way standardise "JCL", nor to model in any detail what constitutes "processing".
It recognises the requirement to transmit (transparent) documents to a system for "processing", together with information which will enable that system to correctly dispose of documents resulting from the "processing".
The documents could be traditional JCL, program and data, and the "processing" could involve queueing for a "job-mill" style of activity. On the other hand, the documents could be a letter with enclosures, and the "processing" could be by a human being. A third possibility is trade documents or requests for resupply, and "processing" could involve the immediate scheduling or despatch of a lorry, with the output documents being invoices or management statements or notification of expected arrival times.
JTM is concerned with so-called OSI jobs. These should not be confused with traditional "jobs", processed by a single machine.
The work JTM undertakes, the OSI job, is the movement of documents (files) between open systems, a pause for those documents to be processed by the open systems (transparently to JTM), then the movement of documents resulting from that processing, and so on.
The processing which is being carried out is of no interest to JTM. Its concern is purely with the documents it delivers, and in due course with the delivery of further output documents. The processing can be carried out by a traditional job-mill (in which case one of the documents that JTM delivers will be some form of "JCL"), or by some application-specific process, such as one handling orders and despatch of goods. The processing could even be entirely manual, with a human signal to JTM that output documents are available, and that the work of the OSI job can proceed.
The JTM "architecture" involves the concept of a so-called "initiation agency" typically, but not necessarily representing a human user. This agency determines the possible patterns of document movements which are to occur, the open systems to be used, and where the initial documents are to come from. This is all specified in what is called "a work specification". Understanding JTM is almost entirely a question of understanding the very wide range of activity which can be specified in a work specification.
The work specification is created by the JTM service provider from the parameters of the J-INITIATE service primitive. Thereafter, the JTM service takes full responsibility for progressing the activity. A key feature of the JTM protocol design is that responsibility for progressing a work specification passes from open system to open system. The open system on which J-INITIATE was issued need have no memory of the activity once the first part of it is completed and responsibility passed.
Typically, protocol elements (called Transfer Elements) containing some or all of the information in the work specification are passed around a number of open systems, each of which performs some part of the requested activity providing a document, accepting a document for printing or filing or display to a user, processing one or more documents, and so on.
All JTM activity (service primitives and protocol transfers) is performed within one or more CCR atomic actions. This gives complete protection against application failures and communications failures, resulting in a "no loss, no duplication" guarantee for the requested work.
The JTM Standards recognise not only an initiation agency (defining the work by use of J-INITIATE), but also of agencies accessed by the JTM service (through further service primitives) to enable the work to be carried out. These are described in the following paragraphs.
The JTM "source agency" is accessed by the JTM service provider through the J-GIVE service primitive. This is issued (as a result of requirements in a work specification) to request a named document from the source agency. The source agency typically models a conventional local filestore, but it can also model some running program, an operator being requested to load a magnetic tape, or an FTAM handler obtaining a document remotely. Note that there is no restriction placed by JTM on the open systems where J-GIVE primitives can be issued. Open system A can issue J-INITIATE, intending to process some documents on open system B, but the J-GIVE primitives to obtain the initial documents can be issued on open system A, open system B, or on entirely separate open systems C, D, E, ... . The JTM protocol arranges for the necessary requests and documents to be transferred between systems.
The JTM "sink agency" is accessed by the JTM service provider through the J-DISPOSE service primitive. This is issued to request the agency to dispose of a document supplied by the service (typically obtained by an earlier J-GIVE). This disposal can (depending on the agency) be to a file, to a line-printer, to a plotter, a short message to a user mailbox, an operator message, a signal to a running program, etc. etc. As for J-GIVE, there are no restrictions (subject to authorisation, discussed below) on where J-DISPOSE can be performed.
The JTM "execution agency" is also accessed by the J-DISPOSE service primitive. The difference between this and a sink agency is that the execution agency is able to generate new documents for collection (using J-GIVE), as part of the activity stimulated by J-DISPOSE. This forms the "processing" element within the JTM model.
JTM makes use of the so-called "commitment level" mechanism in CCR primitives. The atomic action containing a J-DISPOSE to a sink or execution agency can either
If AGENCY ACCEPTANCE occurs, then the agency will at some later time (possibly as the result of a human interaction saying, for example, that a lorry has been despatched), issue a J-END-SIGNAL request to inform the JTM service provider that the work is completed. If the agency was an execution agency, J-GIVE primitives can now be issued to collect documents from it, and the work specified by the work specification continues.
The documents produced by an execution agency will in due course be passed to other sink or execution agencies in further J-DISPOSE primitives. Thus JTM supports an arbitrary (unbounded, and potentially infinite) sequence of J-GIVE/J-DISPOSE, J-GIVE/J-DISPOSE activities. (See figure C.1) It should be noted that this is a branching process, with each branch proceeding asynchronously.
The activity requested on J-INITIATE can be performed "off-line" as described above. If, however, the initiation agency demands a CCR commitment level of COMPLETION on the J-INITIATE, then the entire activity is carried out immediately (or not at all) with a suitable response to the J-INITIATE.
The activity requested by the initiation agency in general causes a tree-structure of J-service primitives to be issued, possibly in parallel, possibly sequentially, on many different systems. These primitives are issued as part of one or more atomic actions (depending on the requested commitment level). Some examples appear in clause C.16.
As part of the work specification defined by J-INITIATE, the initiation agency identifies one or more monitor points, and one or more reporting categories. The JTM service generates reports (documents containing JTM specified, formatted, data) when any event in these categories occurs. The categories of reporting include the completion of parts of the work, transfer between systems of responsibility for progressing the work, accounting information, and, most importantly, errors in the specification which prevent further processing. (Such errors can either cause the rest of the work to be abandoned or, depending on what the work specification says, simply suspended for corrective action.)
All requested reports are delivered (using a protocol almost identical to that used for progressing the main work) to the open systems containing the specified monitor points. Two options now exist; either
For each category of report, the responsibility for generating a work specification for delivery and disposal of the report rests with one particular open system in the CCR atomic action tree. This is specified in the JTM protocol specification, and described in the body of this text.
Some reports (for example, those reporting creation of a work specification, transfer of responsibility for it, normal termination) are carried out as part of the main CCR atomic action progressing the work. They are committed only if this action commits, and rolled-back otherwise. In CCR terms, they are part of the bound data of the action.
Other reports (for example, reports of accounting information, reports of attempted security violations, or reports by the open system containing the commitment master of the failure of an atomic action) are issued as separate atomic actions. These reports are committed even if the main atomic action is rolled back.
Following a J-INITIATE, it is possible for the work to progress with no further human interaction. More typically, however, further human interaction will occur in order to
These interactions are also performed by an initiation agency (any initiation agency). The agency again supplies information for a work specification, but the requested work is now one of the operations listed above. The agency again has the choice of setting up "off-line" activity, or (more typically in these cases) of demanding COMPLETION commitment level on the J-INITIATE.
The service primitive submitting a normal work specification is called J-INITIATE-WORK. That requesting display or modification of work specifications is called J-INITIATE-WORK-MAN ("MAN" for MANipulation). That interrogating monitor points is called J-INITIATE-REPORT-MAN. That performing control of transfers is called J-INITIATE-TCR-MAN. ("TCR" stands for "transfer control record"; transfer control is described in C.11.6.)
In all cases of J-INITIATE, the requested activity is described by (some type of) work specification. All types of work specification contain a number of global fields concerned with authorisation, identification, and security. These are formed from J-INITIATE parameters supplemented by information provided by the JTM service provider to form the so-called "OSI job parameters". These parameters are carried in the protocol for all JTM transfers concerned with this work specification, (including report movement) and serve to coordinate the entire activity. These fields of a work specification are described in clause C.9, after introducing some of the concepts.
JTM recognises two sorts of objects which require (world-wide) unambiguous names to be allocated. One of these identifies a JTM implementation. Such names are expected to be (JTM) application-entity-titles as described in the Addressing Addendum to the Basic Reference Model. The second is what JTM calls "user-identification-authority names". These use the same name-space as application-entity-titles, and represent a source of user identifications. Frequently, such user identifications are issued for use within and by a single computer system (open system). In this case a single application-entity-title could cover both roles. In other cases, a single computer system (open system) might have more than one set of user identifications, or, perhaps more commonly, a single set of user identifications might be issued to cover several computer systems (open systems). The world-wide unambiguity of application-entity-titles is ensured by the aims of the work on naming and addressing. World-wide unambiguity of user identifications and of work specification identifications follows from this by incorporating such names into these identifications.
Unambiguous naming mechanisms do not solve the problem of masquerade - a system or user deliberately using the name assigned to some other system or user. Masquerade is prevented by suitable authentication mechanisms. JTM recognises three mechanisms which can be applied to achieve authentication.
The first of these, traditionally applied to user identifications, is the use of passwords or capabilities secret information known only to the authenticator and to the object being authenticated. This mechanism leads to
The conclusion is that direct use of passwords should ideally be restricted to use within a secure zone or on secure lines, and to use where "off-line" activity is not involved.
The second mechanism is to authenticate the source of a communication (its claimed open-system name) on arrival, and then to "trust" known open systems which have been authenticated. This "trust" enables the receiver to accept statements from the sender that user identifications present in the communication have already been authenticated what JTM calls "the already-checked flag". JTM recognises three levels of authentication of a calling system; these levels, and the nature of the application, determine whether such "trust" is to be applied. (The actual open-system names to be "trusted" at each level are configurable in a JTM implementation.) The levels are:
- UNKNOWN - KNOWN - AUTHENTICATED
An "UNKNOWN" open system is the case where the only knowledge of the caller is the caller's own statement in the communication. In some cases (within a single monolithic security zone, or with low protection requirements such as writing to a printer) this can be sufficient. A "KNOWN" open system is the case where the network itself provides an adequate level of security for the application, and provides an authenticated network address which can be used to validate the claimed open-system name. This is the normal level of authentication currently applied to the bulk of non-banking commercial traffic. An "AUTHENTICATED" open system is one where encryption techniques have been applied to ensure that the communication is a tamper-free communication from that open system. The precise lower layer protocols to be used to obtain this highest level of authentication is outside the scope of JTM, and awaits the results of work in progress on security in OSI.
The third mechanism used by JTM is to maintain what it calls an "audit-trace". This is a list of open-system names, each one flagged as AUTHENTICATED, KNOWN, or UNKNOWN. Whenever responsibility for progressing (part of) a JTM work specification is passed from one open system (A, say) to another (B, say), A adds its name to the end of the audit trace as UNKNOWN. On receipt, B can change the flag to AUTHENTICATED or KNOWN. This audit trace is at the heart of all JTM masquerade protection. All "already-checked" flags on user identifications identify the entry in the audit trace which claims to have done the check. Provided a site knows and "trusts" all names in the audit trace back to this point (with an acceptable level of authentication on each one), then the "already-checked" flag on the user identification is acceptable.
In a typical operation, a branch site can "trust" headquarters (but possibly not vice-versa). The branch can validate (locally) a user identification at the time of J-INITIATE, and insert "already-checked" flags. When, some-time later, headquarters passes responsibility for the remains of the work specification back for the performance of J-DISPOSE, the "already-checked" user identification is available to authorise the disposal activity. (Clause C.20 gives an illustration of these mechanisms.)
The audit trace also plays a role in detecting masquerade in the claimed identity of the initiator of a work specification. This is important because of another security feature in JTM. One category of reporting which can be selected is reporting of unauthorised attempts (by some other work specification, B say) to modify this work specification (A, say). Should such an attempt be made, the identity of the initiator of B, the time of submission, and the complete audit trace of B, is reported to the monitor points of A
JTM uses the term "OSI job" for the complete activity specified by a J-INITIATE request.
This is composed of an initial "subjob" which can be a "document movement subjob", a "work manipulation subjob", a "request manipulation subjob", or a "transfer control manipulation subjob". These subjob specifications can contain proformas which specify any type of subjob, and so on.
The open system on which, for a particular OSI job, J-INITIATE occurs is called the "OSI job submission system".
"Manipulation" covers both modification of a work specification (or deletion of reports) and also "display" of a work specification or reports.
The semantics of the work to be carried out by JTM (including the spawning of new work from a proforma) is called a "work specification". The carrying out of the total work is called an OSI job, broken down into OSI subjobs. The JTM PDU carrying details of a work specification, or part of it, (in order to pass responsibility for it to another open system) is called a Transfer Element.
The so-called "OSI job parameters" are described in the following paragraphs.
The "originator identification" is an open-system name (always equal to the first entry in the audit trace, after the initial transfer) and a user identification (containing a user-identification-authority name, which might or might not be the same as the open-system name). This provides a means of identification for reporting and for the security checks described in C.7.4, but is not used in the authorisation of the activity. It is supplied by the JTM service provider at the point of entry.
The "date and time submitted" is the time of the J-INITIATE request, and is supplied by the JTM service provider.
The "OSI job-name" contains a transparent string (any length, any character set) provided by the initiation agency on the J-INITIATE. This is supplemented by a unique reference generated by the open system where initiation occurs, and by additional fields which serve to identify the different parts of the activity when it starts to branch. This so-called "subjob-name-list" is added to as the work proceeds, so that each part of the activity is identified by the path through the tree of activity to it. The names which are added are the so-called "proforma names", described below.
The "audit trace" was described in C.7.3, and forms the basis of the JTM security mechanisms.
The "OSI job monitor" contains a so-called "primary-monitor" specification provided by the JTM service provider at the initiating open system. (Changing this later requires more authorisation than changes to the so-called "secondary-monitors"). Zero one or more secondary monitor specifications are supplied by the agency on J-INITIATE. Each monitor specification gives the reporting categories which are required, and the "open-system name" (the monitor point) to which any resulting reports are to be sent. It also specifies whether reports are to be held by the monitor point (see C.3.1 above), or else gives details of the sink to which a J-DISPOSE is to be issued.
The "security parameters" field is provided on J-INITIATE, and is used to determine the level of security required for JTM communications concerning this work specification. Its values are currently not defined, as they await completion of the work on OSI Security, and the provision of a corresponding parameter in the presentation service or through CASE. Likely values are
This work is, however, immature, and is beyond the scope of JTM.
The "authorisation list" field contains a set of user identifications (or identifications of management another JTM concept see C.10) which can be required for authorisation of the activity. Each element in the list also carries a "validation field" to authenticate it. On the J-INITIATE primitive, this can only be a password, but elements of the "already-checked" variety can be added by the service provider at initiation time, and whenever a password is checked. JTM also allows supplementary authorisation elements to be supplied on J-INITIATE whenever references are made in the work specification to documents to be obtained from sources or sent to sinks.
The "account list" field is exactly analogous to the "authorisation list", and provides account identifications with the same validation mechanisms. These identifications are to be used, if necessary, in accounting (charging) for the activity. Note that the JTM protocol distributes accounting information to monitor points. As with authorisation elements, supplementary account elements can appear with source and sink references.
The "permission list" is the basis of protecting a work specification from unauthorised tampering. This is a list of those user identifications which are authorised to modify (or to inspect) this work specification. Modification of the work specification is restricted (by conforming systems) to work specifications carrying, in their authorisation list, a validated identification corresponding to (or the manager of) one of the identifications in the "permission list".
Two sorts of management are recognised in JTM identifications. These are the management for an open-system and the management for a user-identification-authority. Validation of such identifications proceeds exactly as for user identifications. A validated authorisation for a user-identification-authority management carries all the JTM privileges that any of its users would have. A validated authorisation for an open-system management allows both control of JTM transfers and also modification of any work specifications held at that open system, or containing that open system in the audit trace, or referencing that open system for future activity. Such modifications do not require explicit permissions in the permission list.
The activity which can be requested in a work specification can now be described. This consists of a tree of activity called "subjobs". The tree of activity can be performed as a single CCR atomic action tree, or can be performed with each subjob forming a separate atomic action (depending on the requested commitment level).
For work specifications submitted by J-INITIATE-WORK, the first subjob is a document movement subjob. Such a subjob is essentially simple. It provides two somewhat different facilities.
The first facility enables the initiation agency to
The same document can be sent on more than one J-DISPOSE (the JTM duplication facility).
Each document is specified as a set of document parts (the JTM concatenation facility). Each document part is either provided on the J-INITIATE primitive, or is identified by
The action open system must be either the one where the subjob starts off (the initiation system for the first subjob), or the target, or possibly one of a number of relays, used en route to the target.
The JTM protocol element (carrying the semantics of a work specification) is best modelled as a "bucket". Documents are dropped into it (obtained by J-GIVE) as it moves (possibly through relays) towards the target. At the target, documents for this subjob are removed and sent out using J-DISPOSE. (Some documents can remain, needed for later subjobs.)
The second facility enables the initiation agency to
This form of subjob is particularly useful for either moving all files in some sub-directory, or for collecting all output from a job, when the detailed names of the files/documents is not known. The JTM service provider discovers the names of the actual documents by issuing a J-ENQUIRE to the source agency. This is then followed by a series of J-GIVEs to get the documents. Part of the name of the document in the source agency is used in forming the name of the document for the sink agency.
A subjob is ready for completion when all the J-DISPOSE primitives specified in it have indicated readiness, either by an offer to commit with COMPLETION commitment, or by a later J-END-SIGNAL request from the sink or execution agency. At this point, one or more new subjobs are commenced by the JTM service provider. These subjobs are either conducted as part of the J-DISPOSE atomic action, that is, that of the earlier subjob, or of the J-END-SIGNAL atomic action, a new atomic action. These new subjobs were specified in the original work specification created by the J-INITIATE. This is done by sub-parameters on the J-INITIATE called proformas. Each proforma carries a proforma name, and a further document movement subjob specification exactly as described above.
A work specification contains the specification of the (single) initial subjob, and zero one or more proformas. Each proforma contains the specification of a (single) subjob, together with zero, one or more proformas, and so on, to any depth.
When work on the subjob defined by a proforma begins, the proforma is said to spawn the subjob. Each proforma which spawns at the end of a subjob produces new activity which proceeds independently of (and typically in parallel with) the activity spawned by other proformas. No action is ever taken to obtain documents referenced by inner proformas until they spawn a subjob. The JTM "bucket", however, can contain such documents if they were provided on J-INITIATE.
The discussion so far has concentrated on what is called activity end spawning. It is, however, also possible for an execution agency, prior to completion of its processing, to issue a J-SPAWN primitive to spawn from a named proforma, in order to distribute some documents which are already available. Such an action is called demand spawning. A third option is acceptance spawning, undertaken by the JTM service provider when all J-DISPOSE primitives have given agency acceptance (or higher) commitment level.
There are two further features which support an indefinite (recursive) sequence of JTM activity; the first is a mechanism whereby a proforma, when it spawns a subjob, can specify that a complete copy of the parent proforma (or of one of its "brothers") should form a proforma in the new sub-job. This is called inheritance. The second feature is the so-called hold-list.
The hold-list for each subjob can be present in the proforma at J-INITIATE time, or can, more commonly, be introduced by manipulation, or by the service provider on an error. The hold-list contains zero, one or more hold elements. The presence of a hold element causes the JTM service provider to hold the subjob (when responsibility for it reaches a named open system). The hold element contains
J-INITIATE-WORK-MAN specifies an initial subjob for manipulation (display or modification) of other work specifications. This manipulation work specification is directed at a specific target open system and contains a sequence of operations, to be carried out by the JTM service provider at that open system. The operations are
A J-INITIATE-REPORT-MAN work specification gives a target which is a monitor point, and requests either the display (in a document collected by proformas) or the deletion of reports which have been collected. Authorisation mechanisms are again applied to the activity. (Figure C.2 illustrates some aspects of JTM activity.)
A J-INITIATE-TCR-MAN work specification provides control (subject to authorisation) from any open system of the so-called transfer control records held by any other open system.
The JTM model underlying transfer control is given in the following paragraphs.
At any time, open system A (say) has a number of transfers to make to open system B (say), each one passing responsibility to open system B for the progression of a work specification. The management at open system B requires to exercise some control over these transfers, typical examples being
These requirements are supported by the provision, at system A, of a conceptual data structure called a transfer control record (TCR) governing its transfers to B. If this TCR is unset, A's actions are unconstrained and implementation dependent. If it is set, it contains zero one or more selectors. These selectors are exactly the same as those used in the SELECT operation of a work manipulation to select one or more work specifications, using a variety of the fields in it. (Selection using time waiting and size is also supported.)
Each selector in the transfer control record is, at any moment in time, "occupied" by at most one work specification being transferred. That work specification is one which satisfies the selection requirements. Thus there are never more transfers (initiated by A to B) in progress than the number of selectors, and all the above requirements can be met by suitable setting of the transfer control record selectors.
A work specification submitted by J-INITIATE-TCR-MAN specifies the target system and the transfer control record at that system to be manipulated. This can either be replaced (the "SET" operation), or displayed (the "DISPLAY" operation) in a document for collection by a proforma.
A third operation is available, called the "CHECK" operation. This would, in the example above, be used by system A as an enquiry to system B after a crash of A. It contains the TCR that A is currently about to use to control transfers to B and essentially says "I've been out of commission for a while if this is no longer an appropriate record, you had better change it". (It is a sort of very high-level resynchronisation.)
A transfer control record manipulation enables a transfer control record to be set by either the destination of the transfers which are to be controlled, or by a (suitably authorised) third party.
An example of third party setting of a transfer control record is where a management control centre "A" places transfer control records at a spooling host "B" (acting as a JTM relay) to control transfers to a simple printer controller "C". The TCR contains a "SET-BY" field with the name "A", and hence any subsequent "CHECK" manipulation is sent from "B" to "A", despite the fact that it is transfers to "C" which are being controlled. (See figure C.3.)
In this scenario, the management control centre "A" would support Basic Class JTM, extended by at least the TCR manipulation functionality; the spooling host "B" would support Basic Class JTM extended by at least the TCR functionality; the printer controller "C" would support only Basic Class JTM.
Figure C.4 illustrates a simple use of JTM equivalent to non-standard RJE operation (a small subset of JTM capability).
When errors are detected by an open system attempting to progress an atomic action, the JTM service provider is prepared to take any of three possible actions, selected by flags in the work specification.
The first action is only applicable to errors arising from an attempted J-GIVE (for example, "file does not exist", "insufficient authorisation", and so on). If this action is requested, the CCR diagnostic from the J-GIVE is embedded in the work specification in place of the document, and will in due course be passed to a sink or execution agency in a J-DISPOSE. The main atomic action producing the J-GIVE proceeds normally with a C-READY, but a CCR warning report is included. A JTM report can also be produced if this category of reporting was requested.
The second and third actions are performed by the master of the atomic action when he receives CCR diagnostics on a C-REFUSE. If the second action is requested, a hold element is added to the work specification and there is no further progress until a manipulation has corrected the error and removed the hold. (If the hold expires on time before modification, and if the error persists, the third action see below occurs.) The addition of the hold element ("no progress") is an event which can be selected for reporting.
The third action is to simply abandon the work specification, putting the CCR diagnostic into an "abnormal termination" report.
The JTM Standards are largely concerned with document movement. A "document" can be broadly defined as the contents of a file or part of a file structured information, divorced of any concepts of naming, access structure, or other access-related attributes.
JTM recognises three types of document (structured information) which are fully defined by JTM (semantics and transfer syntax). These are JTM report displays, JTM work displays, and JTM-TCR-displays.
JTM also recognises three document types which are an important part of the use of JTM for general-purpose open working. These are text documents (lines of characters), print documents (lines of characters with "carriage controls") and binary documents (an arbitrary length, unstructured, sequence of bits).
Finally, JTM can request and carry any document which
Full JTM support for such documents requires definition and registration of the datatypes which can be concatenated to form such a document.
Another important feature of JTM is recognition of a "storage support" implementation. An implementation of JTM provides "storage support" for a document type if a J-GIVE, following a J-DISPOSE, for any specific document of that type, results in the identical value being returned. In general, implementations lacking storage support for, for example, BINARY documents, can pad the bit string to a multiple of eight bits.
In the common case, a subjob is commenced by J-INITIATE or by spawning, and responsibility for the associated work specification is passed directly from the initiating or spawning site to the target site by the JTM protocol.
This simple situation is inadequate in four cases
The JTM Standards permit the user (on J-INITIATE) to include JTM relays en route to the target, both for the initial subjob and for subjobs spawned by proformas.
Figure C.5 illustrates the progress of a subjob to its target via a single relay. Documents are collected by J-GIVE at all three systems.
Figures C.6 and C.7 illustrate alternative subjobs which, by use of FTAM, give similar effects, but with different binding times for documents. The differences in the subjobs lie in the specification of the <action open system>, and in the use or non-use of FTAM.
In the initial JTM Standards, an "action open system" obtains documents by use of the J-GIVE service primitive (which may cause use of FTAM). A target open system disposes of documents by use of J-DISPOSE (which may cause use of FTAM).
The provision of a very simple protocol to support communication between a remote agency and the JTM service provider (mirroring the appropriate JTM service primitives) is for future study. Such an extension of JTM would enable simple "peripheral drivers" to operate (using standard protocols) across a local area network to a "box" with no peripherals, but acting as the JTM service provider.
It would also support J-ENQUIRE, J-HOLD, J-END-SIGNAL, and so on, which are not supported by FTAM.
A sequence of JTM service primitives forming a J-INITIATE commitment group appear entirely at a single service access point.
If the commitment level for this group is PROVIDER ACCEPTANCE (the lowest possible), then there need not be any primitives issued at any other service access point until after completion of the J-INITIATE commitment group.
If the commitment level for this group is higher than PROVIDER ACCEPTANCE, then other commitment groups are issued at other service access points while the J-INITIATE commitment group is in progress. All constraints on the time-relationship between the groups at the two or more service access points are fully defined in the CCR Service Definition, or are implicit in the need of the service provider to obtain data (in a J-GIVE response) before delivering it (in a J-DISPOSE indication).
A JTM subjob can involve (for example) a J-INITIATE, a J-DISPOSE and two J-GIVE primitive groups at four different service access points.
Even in the case of COMPLETION commitment, considerable variation is possible in the time sequence of the elements of the primitive groups at the different service access points. Figure C.9 illustrates the possible primitive sequences by a time sequence diagram (see annex A) for the process flow shown in figure C.8.
Note that inclusion of PROVIDER ACCEPTANCE commitment relaxes still further the time constraints on primitive sequences. The particular sequence illustrated could, however, still occur an implementation can always attempt a higher commitment level than that requested.
A more interesting time sequence interaction occurs when a sink agency is given a document and, more or less simultaneously, an execution agency is given a document for processing which causes the execution agency (invisibly to OSI) to access the document disposed of by the sink agency. Note that at this stage the service provider can not have committed to either of the J-DISPOSE primitive groups. The CCR concurrency rules require the document passed to the sink to be made available to the execution agency where this is operating as part of the same atomic action. This case can be important where one document (data, say) is sent to a pervasive file-store, whilst another (the JCL) is passed to a job-mill.
This completes the overview of JTM operation. All the facilities provided revolve around a common core of authorisation, document movement, and proforma spawning. The generality available produces a potentially very powerful system for defining and sustaining cross-network activity with a minimum of human involvement. Two forms of "subsetting" are, however, defined by JTM in order to reduce the initial implementation task.
The first form of subsetting is the so-called JTM Basic Class. This provides a number of restrictions designed to make implementation easier whilst supporting simple activity where A sends a document to B for processing and B returns a resulting document to A.
The Basic Class work specification and corresponding protocol element is a strict subset of the general case. Extended and Basic Class implementations will interwork, provided only that the J-INITIATE ensures that sufficiently restrictive subjobs are passed to Basic Class implementations (see clause C.18).
The initial JTM Standards contain a full service specification, but only a Basic Class protocol specification, with protocol to support extended implementations to follow.
The second form of subsetting is in the nature of agency support provided by an implementation. A particular implementation can provide only for operation as an initiation agency. This is called "Support for JTM OSI job submission". Another implementation can provide only for operation of a particular device as a JTM monitor point. Yet another can support use of one (but perhaps not all) of its printers as a JTM sink agency. Another implementation can support all JTM service primitives by subroutine calls from a user's FORTRAN program (but perhaps not from COBOL). This would be called "JTM support in language xyz". A final example is provision for a human to receive notification of documents for processing, and to signal completion of processing "JTM support for human processing".
The precise details of the interfaces involved in these provisions (so-called "language bindings") is not part of the current JTM work, and will depend on particular implementations. The functionality which is required, however, to sustain claims of "JTM support for ..." is defined in the JTM protocol conformance statements.
A Basic Class implementation supports the issue, on its system, of Basic Class primitives and the processing of Basic Class work specifications.
An extended JTM implementation may also (depending on the additional functionality implemented) support the issue of primitives beyond the Basic Class definition, and/or the processing of work specifications beyond the Basic Class.
A transfer element always represents a datastructure which complies with Basic Class restrictions if it is part of an OSI job initiated by a Basic Class J-INITIATE. An extended J-INITIATE may nonetheless produce an initial transfer element conforming to the Basic Class (and processable by a Basic Class system) if all the extended functionality is within proforma specifications. Equally, a later transfer element may fall within the Basic Class, even if the initial one exceeds the Basic Class.
These properties arise because a Basic Class work specification is permitted to have a transparent proforma list if it is targeted elsewhere.
Figure C.10 shows a Basic Class implementation producing a transfer element exceeding the Basic Class due to spawning from a proforma received in a transfer from an extended implementation.
|J-INITIATE for the OSI job||Possible transfer elements during OSI job||Possible resulting transfer elements|
|Extended||Extended||BASIC or Extended|
|Extended||BASIC||BASIC or Extended|
|A BASIC transfer element can be processed by a Basic Class receiver.|
|An Extended transfer element requires the receiving system to have an extended functionality.|
Table C.1 shows (for a single OSI job) the possible combinations of J-I NITIATE functionality, transfer elements received by an implementation during the OSI job, and resulting transfer elements.
The JTM protocol specification consists of three main parts:
In the Basic Class, the latter specification involves the issue of a single P-DATA within the CCR elements (within a ACSE association). Each document is a separate data value on the single P-DATA. In the extended protocol specification, a document may be transferred as a series of data values on one or more P-DATA. The initial JTM Standards require senders and receivers to support transfer by direct and simple use of P-DATA.
Consider the following example. A user at site A (say) submits a work specification containing one proforma, to execute a job at site B (say), and to return the output to site A. The user has the following usernames allocated to him: username USERA, password PASSA, at site A and username USERB, password PASSB at site B. There are four cases to be considered with respect to which site trusts which. The cases are:
|CASE A:||site A trusts site B, and site B trusts site A;|
|CASE B:||site A trusts site B, but site B does not trust site A;|
|CASE C:||site A does not trust site B, but site B trusts site A;|
|CASE D:||site A does not trust site B, and site B does not trust site A.|
When the work specification arrives at site B, the audit trace will have a single element, that of site A. The status will be "UNKNOWN"; site B uses knowledge of the intervening networks and/or encryption techniques to (possibly) upgrade this to "KNOWN or AUTHENTICATED". Site B has a list of sites it will "trust if AUTHENTICATED", or "trust if KNOWN", or "trust even if UNKNOWN". This determines whether site B trusts site A. The lists are configured by (human) management.
When the (spawned) work specification arrives back at site A, it contains two audit elements, one for site A followed by one for site B. Site A initially determines if it trusts the last site (site B) in the audit trace (as above). If it trusts the last site, it then determines if it trusts the second last site (site A) in the audit trace, based on B's evaluation of UNKNOWN, KNOWN, or AUTHENTICATED and its knowledge of B. If it does not trust the last site, it automatically cannot trust any other site in the audit trace, since an untrustworthy site may have (by definition) tampered with any of the earlier elements in the audit trace, thus making it invalid.
In the general case, the checking site proceeds through the audit trace from the last element to the first element until it comes to a site it doesn't trust. All remaining sites are then not trusted. Trust of each site in the audit trace is thus established.
When the user provides authorisation for the JTM task, he does not provide any password; authorisation elements with "checked indexes" of 1 are added by the JTM service provider for both his local and his remote usernames (USERA and USERB) when the work specification is submitted, giving the authorisation list:
site A USERA 1 site B USERB 1
When the work specification arrives at site B, since site B trusts the (only) site in the audit trace it is willing to accept the authorisation element
site B USERB 1
as providing valid authorisation for itself, i.e. it trusts site A to have validated the user who presented username USERB.
When the (spawned) work specification carrying the output arrives at site A, site A trusts both sites in the audit trace, and therefore knows that USERA was checked previously by itself earlier during the life of the JTM task, (since the "checked index" of 1 can be relied upon to be accurate). It therefore has sufficient authorisation to dispose of the output.
In this example, the checked index only takes the value one, as all password verification is being done at the OSI job submission system.
When the work specification arrives at site B, since site B does not trust site A, it will require the following authorisation element
site B USERB PASSB
before it will process the work specification. The user therefore presents his username and password for site B when submitting the JTM task at site A.
When the (spawned) work specification arrives at site A with the output, site A trusts both sites in the audit trace, and therefore is happy with the following authorisation element
site A USERA 1
as in case A above.
In this case the user needs to include his own password and username for site A when submitting the JTM task, but only the username for site B, giving the following authorisation list:
site A USERA PASSA site B USERB 1
Since site B trusts site A, it does not require a password for executing the job, but site A needs a valid password (PASSA) for disposing of the returned output since it does not trust work specifications coming from site B. Note, however, that although site A does not trust site B, the (human) user at site A has to trust site B not to misuse his (site A) password which he is sending to site B.
The user provides usernames and passwords for both sites A and B, since neither site trusts the other not to masquerade.
If the user always provides usernames and passwords for both sites, the work specifications will always have sufficient authorisation, regardless of whether the sites encountered trust each other or not; the purpose of the trusting mechanisms is to release JTM from the necessity of carrying passwords embedded in its work specifications and to avoid the burden this imposes on human users to remember several passwords.
Table C.2 illustrates this scenario, with some additional assumptions. First, it is assumed that positive authentication mechanisms are in use between sites which have mutual trust, and that the networks used provide a sufficient identification of sites otherwise. Secondly, it is assumed that, in cases where site managements have not yet established mechanisms reflecting trust, a user of the sites will nonetheless trust all sites used by his OSI job with his password for other sites.
|When the WS is sent from Site A to Site B||When the WS is sent from Site B to Site A|
|Authorisation List||Audit Trace||Authorisation List||Audit Trace|
|Both sites trust each other||USERA
|site A AUTHENTICATED||USERA
|site A AUTHENTICATED
site B AUTHENTICATED
|B does not trust A||USERA
|site A KNOWN||USERA
|site A KNOWN
site B KNOWN
|A does not trust B||USERA
|site A KNOWN||USERA
|site A KNOWN
site B KNOWN
|Neither one trusts the other||USERA
|site A KNOWN||USERA
|site A KNOWN
site B KNOWN
This annex contains the definitions appearing in the body of this International Standard, arranged in alphabetical order. Where it conflicts with the body of this International Standard, that takes precedence.
D.1 account identification: Data which can be used in a particular context to identify the account to be debitted with any charges which are levied.
NOTE -- User and account identifications consist of the name of an identification authority together with one of the identifications it issues.
D.2 activity (in an agency): Work performed by an agency, initiated by a service primitive issued to the agency by the JTM service provider; the completion of the activity is indicated by a service primitive issued to the JTM service provider by the agency.
D.3 agency: An abstract description of those functions of a local system environment which are needed to support the JTM service.
D.4 authenticated identification: Data which is known to correctly identify the user or management who requested the work to be performed, either by the use of a password check, or by some other checking mechanism.
D.5 document: A collection of data which forms part of a work specification, and which forms a unit of interaction between the JTM service provider and an agency.
D.6 execution agency: Any part of an open system which initially acts as a sink for documents, but which subsequently acts as a source of related documents produced as a result of processing the earlier documents.
D.7 identification authority: A naming authority which issues identifications; these identifications can determine the capabilities to be made available to a particular authenticated identification (authorisation), or can be used to levy charges (accounting), or both.
D.8 identification authority management identification: The name of an identification authority which, when authenticated, authorises JTM activities related to control of activity initiated by user identifications issued by that authority.
D.9 initial work specification: A work specification created as a result of the issue of an initiation service primitive by an initiation agency.
D.10 initiating identification: An identification provided by the JTM service provider at submission time to identify the initiator of the OSI job.
D.11 initiation agency: That agency which causes a work specification to be created.
D.12 JTM report: Encoded information recording the progress or failure of an OSI job, generated by the JTM service provider, possibly as the result of interaction with an agency.
D.13 level of commitment: A parameter which determines whether operations requested in an atomic action are completed at the time of the atomic action, or are noted (as secure data) for later performance.
D.14 no-retry diagnostic: Information carried by the CCR service on a rollback when an action cannot be completed, and a later retry is not proposed.
D.15 open system management identification: The name of an open system which, when authenticated, authorises JTM activities or charging related to the management of that open system.
D.16 OSI job: The total work on all open systems arising directly or indirectly from an initial work specification.
D.17 OSI job local reference: A reference for an OSI job unique within the OSI job submission system, assigned by that open system.
D.18 OSI job monitors: Open systems to which JTM reports about a particular OSI job are sent.
D.19 OSI job name: A string provided by an initiation agency when omitting an OSI job.
D.20 OSI job submission: The use of the initiation service primitive by an initiation agency for the creation of an initial work specification.
D.21 OSI job submission system: The open system on which OSI job submission occurs.
D.22 OSI subjob (subjob): The total work arising from the processing of a single work specification, including the spawning of further work specifications, but excluding work arising from the processing of these further work specifications.
D.23 proforma: Part of a work specification which specifies further work and is used to form a new work specification as part of the processing of earlier work.
D.24 report manipulation operations: Operations requiring deletion or display of reports held by an open systems nominated as a monitor point by some work specification.
D.25 report manipulation work specification: A work specification containing report manipulation operations.
D.26 report work specification: The type of work specification created by the JTM service provider to move JTM reports; the target open system for these work specifications is one of the OSI job monitors.
D.27 retry-later diagnostic: Information carried by the CCR service on a rollback when an action cannot be completed for reasons which can be transient.
D.28 selector: Data which is used to select zero, one, or more work specifications.
D.29 sink agency: Any part of an open system to which documents can be passed by the JTM service provider as a result of processing a work specification.
D.30 source agency: Any part of an open system which can provide documents for inclusion in a work specification when required by the JTM service provider as a result of processing the work specification.
D.31 spawning: The process of taking the data from a proforma and using it to produce a new work specification.
D.32 spawning control data: Data contained in a proforma which controls the circumstances in which spawning takes place from that proforma.
D.33 top level proforma: A proforma which is not contained within any other proforma.
D.34 transfer control record: A conceptual data structure held by an open system to control the transfer of work specifications and the issue of service primitives.
D.35 transfer manipulation operations: Operations requiring setting, displaying or checking transfer control records.
D.36 transfer manipulation work specification: A manipulation work specification containing transfer manipulation operations.
D.37 update: Data which is used to modify a selected work specification or proforma.
D.38 user identification: Data which can be used in a particular context to identify the user on whose behalf work is being requested.
D.39 warning diagnostic: Information carried by the CCR service on an offer of commitment which reports (usually for a human being) any variations on the expected action or unexpected consequences of the action.
D.40 work manipulation operations: Operations which select one or more work specifications or proformas and request displaying, killing, stopping or modification.
D.41 work manipulation work specification: A work specification containing work manipulation operations.
D.42 work specification: A conceptual data structure within the JTM service provider which specifies in a defined way the work which is to be done.
D.43 work specification identifier: A unique reference for a work specification which includes the name of the OSI job submission system, the identification of the initiating user, the OSI job local reference and the OSI job name; where a work specification was created by spawning, the identifier also contains one or more proforma names.
D.44 work specification transfer: An atomic action by which a work specification is created at the receiving open system and destroyed at the sending open system.