Message Oriented Middleware (MOM)

Abstract

Table of contents

There are also many ways how Middleware products can be categorized. One division e.g. [3], [4] is as follows: database middleware, remote procedure call (RPC), object request broker (ORB), transaction processing (TP) monitors and message-oriented middleware (MOM). These categories are not always clearly isolated from each other as we'll see later.

Previous reference [3] describes these terms shortly as follows: Database middleware performs only database access and it does not transfer calls or objects. RPC is a method that allows a machine to request service from another machine and ORB "is a tool that passes requests from clients to the object implementations on which they are invoked". TP monitors middleware supports queues that enforce message delivery and finally MOM middleware is an event-driven, asynchronous, non-blocking and message-based communication method that guarantees message delivery.

The term "messaging" most often refers to electronic mail systems. MOM message movers, however, differ radically from mail systems, because they are high-speed, generally connectionless and are usually deployed for concurrently executing applications with a non-blocking sender. Message-queuing middleware (MQM) is a type of MOM that combines a high-speed message mover and a queuing (message storage) service [5].

All MOM products introduced in this presentation are actually MQM products. However term MOM is used here to cover both MQM and MOM terms.

In some cases MOM features are partly included in TP-monitor middleware. One example of this is BEA's [11] TUXEDO [20]. On the BEA's messaging market there was an obvious need to provide customers MOM and ORB products in addition to TP processing middleware. To improve the situation BEA recently acquired from Digital [12] products called "DECmessageQ" for messaging and ObjectBroker. According to BEA TUXEDO, MessageQ and ObjectBroker will enable the mission critical Object Web [21]. Bull [16] has built its Flowbus MOM over TUXEDO [17].

To help MOM related information spread wider an association called MOMA was established. The Message Oriented Middleware Association (MOMA) "is an international not-for-profit association of vendors, users, and consultants dedicated to promoting the use of messaging to provide multi-platform, multi-tier message passing and message queuing services for distributed computing architectures" [22]. MOMA is not a standard-making body, but there are claims that it should be [23].

MOMA [22] announced 11.2.1997 that "its members are cooperating to deliver a conceptual paradigm for messaging and object request broker (ORB) technologies to interface and interoperate within an object-oriented development environment." An example of this kind of interest among MOM vendors was the previously mentioned BEA's DECmessageQ and ObjectBroker contract with Digital [12].

According to Bob Scher, president of MOMA, "this MOMA initiative, endorsing and promoting a framework that enables messaging and ORB technologies to interoperate, represents a major step forward for users and will have a significant influence on the distributed computing industry" [24]. "The collection of features available to users combining messaging and ORB technologies is expected to dramatically improve overall system performance " [24].

In June 1996 Consultants OVUM Ltd [25] published a report entitled 'Ovum Evaluates: Middleware - Message-oriented Middleware' [26]. (" OVUM is an independent research and consulting company offering clear, authoritative advice on IT and telecom market" [25].) In this report many of previously mentioned MOM products and vendors were thoroughly analyzed. Winners (according to OVUM) of that ranking (BEA; DECmessageQ 15 points, Verimation; VCOM 12 points and IBM; MQSeries 10 points [26], [27]) are eagerly referring to this report on details that profit them most.

A list below tells the reader what kinds of MOM features and properties were evaluated and how these total scores were achieved. A list of MOM's common properties is presented in the next chapter.

	MQSeries	DECmessageQ	VCOM
Broadcast / multicast support?	0	1	0
Data format translation	0	1	1
Synchronous and asynchronous processing support?	0	1	1
Queue protected against loss?	1	1	0
Security support?	1	2	1
Automatic load balancing?	0	1	1
Guaranteed delivery score	2	3	2
Deferred delivery?	1	1	1
Dynamic routing?	0	0	0
Transaction processing support	2	1	3
Admin / development / directory	2	1	1
Platform support	1	2	1
Total	10	15	12

MOM products could also be measured by their: functionality, range of platform and network support, cost of ownership, support for programming tools, manageability, ease of installation and upgrade and performance throughput [28].

The selection of MOM product is not a trivial task, because "although the products are feature-rich, the report warns that they differ considerably in the way they deal with message-based communication" and companies should be careful in selecting a product with features they really need [27].

The MOM market is not stabile. For example Covia withdrew its Communications Integrator from MOM market in 1995 and caused a shock for its 60 customer companies. The reason according to OVUM's report [26] was a competition with IBM, the question of company's ownership or poor sales and marketing organization. One of the latest newcomer in MOM market is Microsoft [29], that has now available beta version of Message Queuing Server, code-named Falcon [30], [28].

OVUM tells that MOM vendors in order to be profitable should have a clear strategy for connectivity and because it seems to be missing with companies like ICL [31], Bull [16], SNI and Unisys [32], they will suffer great losses [26].

In addition to OVUM, there are still more top consultants that deal with MOM, including Butler Group [33], Patricia Seybold Group [34], ATB Associates, Aberdeen Group [35], [36], Gartner Group [37], [38], Standish Group [39], etc.

Queuing is a method of passing information indirectly through message queues. Messages are stored in queues until the recipient is ready to read it. Queuing frees the communicating parties from establishing connections with one another and other complexities of communicating directly.

Online messaging is in real time, with message delivery typically occurring in seconds or even sub-seconds. MOM products guarantee delivery of high-value messages e.g. [28].

Applications are isolated from communication networks which makes applications simpler, shields them from network changes, and provides greater network independence.

Queue based processing makes it easy to transparently add servers as the workload increases, providing better load balancing. Asynchronous communication provides also time independence so that programs do not have to execute serially and take turns waiting on each other (non-blocking).

Looser coupling between application elements are ideal for C/S and object-oriented computing, raising new application design possibilities.

Fewer communication channels between computer systems are easier to manage and more efficient.

Messages can be persistent and non-persistent. Valuable messages can be defined as persistent that mean that they are written to non-volatile storage, from where they can be reinstated after a system restart. Non-persistent messages are stored only in memory. The latter method can be sufficient e.g. if the message queue is used only for monitoring purposes.

Message queues can be read as FIFO or priority basis. Queues can be read at the same time they are updated that reduces the concept of batch window time.

Contents of messages can automatically be translated according to recipients needs e.g. [40].

Products from different vendors (e.g., IBM's MQSeries, BEA's DECmessageQ, Verimation's VCOM ) have different APIs and don't easily interoperate with one another [41] and each vendor's products employ proprietary location (directory, naming, and security) services. Sometimes there are, however, gateways that make it possible e.g. IBM's MQSeries to communicate with e.g. DECmessageQ [42] or Falcon [28].

Maintaining the messages queues, the relationships between programs and queues, handling network restarts and moving messages around the network is under responsibility of MQSeries software and a programmer need not to be worried about it.

A queue can be predefined or created dynamically. The latter may be either permanent dynamic or temporary dynamic. A local queue belongs to the same queue manager as the application that is connected to it. A remote queue is owned by a different queue manager. A transmission queue is a special queue used by the queue manager and transmission programs to temporarily store messages destined for a remote queue manager. An alias queue provides an alternate name for a queue. A model queue is not used directly as a queue, but is used as an example when assigning characteristics to a dynamic queue.

Each message queue belongs to a queue manager. The message queue manager is the most important and central object in the MQSeries environment. Queue managers are the system providers of message queuing facilities used by applications. Additionally, queue managers process system commands and manage all message queuing related objects. There must be at least one queue manager on a system.

Distributed queue management is the process of establishing communication between multiple MQSeries queue managers. Applications local to one queue manager can put messages on remote queues owned by another queue manager. Current versions of MQSeries simplify distributed queue management by allowing applications to read only local queues, while allowing them to write to both local and remote queues.

Queue managers on different computing platforms communicate with each other through programs, called message channels. They are made up of two message channel agents (MCAs or movers), consisting of a sender and a receiver and a communication link. MCAs communicate with each other using the MQSeries Message Channel Protocol.

MQSeries provides assured message delivery by moving messages to remote queue managers in groups. Messages that are defined as persistent are never deleted at the transmitting queue manager until their confirmation of receipt at the destination queue manager.

There are four message types in MQSeries.

• Datagrams are one-way messages with no associated reply message to be returned.
• Request messages are used when the sender expects to receive a reply.
• Reply messages are sent in response to request messages.
• Report messages are used to inform an application of some unexpected event.

MQSeries supported languages and platforms can be found in related links [44].

MQI is IBM's message queuing API. Originally published as part of IBM's Open Blueprint [45], the interface consists of the following 11 program calls [46]:

• MQCONN - connects an application to a particular queue manager.
• MQOPEN - opens an MQSeries object, such as a queue, and returns a handle for use in subsequent calls. Handle is the identifier, by which a program knows an MQSeries object or an instance of an MQSeries queue manager [47]. Most resource security checking is performed at this point.
• MQGET - attempts to retrieve messages from a local queue opened earlier for input. MQGET can be used in a blocking or non-blocking fashion.
• MQPUT - writes messages onto local or remote queues that have previously been opened for output.
• MQPUT1 - a sequence of MQOPEN, MQPUT of one message and MQCLOSE.
• MQCLOSE - It gives up access to an MQSeries object and, depending on the options specified, can cause an object such as a dynamic queue and its contents to be destroyed.
• MQDISC - breaks the connection previously established with a particular MQSeries queue manager.
• MQINQ - selectively inquires about a variety of MQSeries object attributes.
• MQSET - allows certain MQSeries object attributes to be set or modified from an application.
• MQCMIT - indicates to the queue manager that the application has reached a syncpoint and that all gets and puts since the last syncpoint are to be made permanent.
• MQBACK - indicates to the queue manager that it should roll-back all gets and puts that have occurred since the last syncpoint.

4.2 Pros and cons of MQSeries

+ MQSeries APIs are easy to use and message queues can be shared.

+ In MQSeries there are also some "hidden extras built in, such as triggers, queue browsing, message removal and good error handling facilities" [26].

+ MQSeries is the primary product against which all other MOM products should be measured [28].

-"OVUM's main concern is that even if IBM is committed to other platforms as to its own, it may still have a problem getting access to competitors' technology to enable those connections" (e.g. Microsoft) [26].

-The administrator needs to be a skilled person, MQSeries functionality is not the same on all platforms and the pricing policy on different platform changes a lot [26].

VCOM provides the application developer with program-to-program both asynchronous (Distribution service) and synchronous (Conversation service) communications services and an application can use these features even simultaneously.

Messages are addressed to programs rather than intermediate message queues as in MQSeries.

VCOM naming and directory methods provide location transparency which relieves the applications developer of the task of tracking the location in the network of communicating applications.

VCOM (picture below) employs two logical names, Partner and Expediter, to identify the two programs involved in information exchange. Partner is the name used by the initiating program A as a logical name for the answering program B. VCOM then translates Partner to Expediter using the table in the transmitting node. Expediter is the name which is communicated across the network and is translated to the program name B in the receiving node. The use of these logical names eliminates the need for the two programs to know the actual names of the computers or their programs [54].

Character translation between character sets based on operating environment and codepage are performed automatically. Applications programmers are not required to perform this function.

VCOM supported languages, platforms and protocols can be found in related links [55].

On asynchronous service VCOM has 7 API calls. They are:

• CALL DSCONS -- Distribution Service Connect (initiator)
• CALL DSCONR -- Distribution Service Connect (responder)
• CALL DSSEND -- Distribution Service Send
• CALL DSRECV -- Distribution Service Receive
• CALL DSRLSE -- Distribution Service Release
• CALL DSRCNS -- Distribution Service Reconnect
• CALL DSPRLS -- Distribution Service Prepare to Release

5.2 Pros and cons of VCOM

+ OVUM -96 ranked VCOM as "the most promising newcomer in the MOM market" [26].

- VCOM development environment has no integration with application development tools such as Visual Basic or PowerBuilder [26].

- The 'directory' could be time consuming and error prone to set up - there are no publish and subscribe facilities [26].

- There are no links to systems management software. Although network monitoring functions are provided, they are fairly basics (polling) and can impose a heavy load on the network [26].

- VCOM provides no fully automated load balancing management software and has no automatic routing on line failure [26].

- As well as MQSeries, VCOM also requires a full-time administrator [26].

6.1 Some fundamentals of DECmessageQ

A message queuing group defines a collection of queues sharing DECmessageQ resources. Each DECmessageQ group is identified by a unique number. This group ID is part of the queue address.

A message queuing group encompasses related applications or components of the same application. Applications can utilize a single or multiple message queuing groups.

A message queue is a resource configured by the application developer and managed by DECmessageQ. All messages sent with DECmessageQ are written to a queue. Each queue defined within DECmessageQ is identified by a number that is part of the queue address.

The application program becomes associated with a queue when it attaches to the DECmessageQ message queuing bus.

Once the application is attached, it becomes the owner of the queue. Only the owner can read messages from the queue. The only exception to this rule is for multireader queues, which can have many owners.

An application program can read messages from multiple queues. When a message is read from a queue, it is moved from the queue into a data buffer defined by the program. Once read, the message no longer exists on the queue.

DECmessageQ software uses primary queue, secondary queue and multireader queue. Primary queue is assigned to each process that attaches to the DECmessageQ message queuing bus. This queue is required by all applications as the "main mailbox" for receiving messages from processes using DECmessageQ. Secondary queue is used by processes as an alternate "mail box" for selected application messages. The order in which queues are scanned for messages is defined by the DECmessageQ selection rules. Multireader queue (MRQ) is used to store messages that can be read by many simultaneous readers, creating a central "mail box" for several applications to retrieve messages.

Message broadcasting is a style of communicating that uses one message sender program and multiple message receiver programs. DECmessageQ Selective Broadcast Services (SBS, OpenVMS only) manages the broadcasting of data between processes and groups of processes.

Message broadcasting increases efficiency by directing messages to many targets with a single call. However, message broadcasting does not support recoverable delivery modes.

DECmessageQ software allows application developers to use message selection criteria when reading queued messages. Message selection enables applications to selectively read messages by their type, class, source, priority or by a combination of selection criteria associated with the message when it was sent.

DECmessageQ supported languages, platforms and protocols can be found in related links [57].

DECmessageQ has following basic APIs to be used [58]:

• pams_attach_q -- attach to the DECmessageQ
• pams_put_msq -- send a message
• pams_get_msg -- read a message
• pams_detach_q -- detach from the DECmessageQ
• pams_locate_q -- obtain a queue address for a queue name

6.2 Pros and cons of DECmessageQ

+ DECmessageQ was the winner of the OVUM's ranking.

- Directory services are weak and not all features are available on all platforms [26].

- OVUM reported [26] that DECmessageQ, before it was sold by Digital, suffered from poor marketing. Hopefully this situation is now better, because BEA acquired the DECmessageQ.

The message queuing middleware 'pipe' is only part of the solutions customers want. There are other dimensions beyond the pipe which implementers must consider. One of them is how to manage MOM. If everything is asynchronous, how does anyone know exactly what is happening in the system, where and when? With queues not connected to particular applications, and with messages themselves being only loosely connected, how do you know if something is about to go wrong? What if a message cannot be delivered; where does it go [40]?

Many third parties provide management solutions for MQSeries. There are at least Candle [59] with product Candle Command Center [60], Boole & Babbage [61] with product MainView [62], BMC [63] with product Patrol for MQSeries [64], Apertus [18] with MQview etc. Candle's Command Center provides you "the information needed to manage MQSeries networks by analyzing queue managers, MQ events, buffer manager, channel manager, log manager and message manager" [60].

VCOM Network could be monitored with an OAPI-based (Operator API) interface. VCOM Network Monitor (VNM) is used for tracking and monitoring a VCOM logical network [54]. Possible alerts from VCOM are observed by VNM but no e.g. SNMP based alert mechanism is available at this moment [65].

Also DECmessageQ has monitor utilities and mechanisms for management.

Although these management issues are very interesting they are not covered with more details in this short seminar presentation.

The MQSeries security information presented here is mainly based on the conference presentation "MQSeries security" that took place in Berlin at Oct 1996 [66]. Explicit references are not, however, mentioned below.

8.1.1 Access to MQSeries

There are several MQSeries commands available for controlling and configuring the Queue Manager. Operating system or MQSeries facilities may be used to control which users may access these commands.

Access to MQSeries applications may be controlled by restricting access to the link libraries and then by restricting access to the compiled and linked executable. Both of these controls are base operating system facilities and are outside the scope of MQSeries.

MQSeries provides access control facilities to control which users may run applications which issue MQCONN API commands.

8.1.2 MQSeries Access Control

Queue Managers use an associated security manager to provide access control services.

MQSeries for MVS/ESA (IBM mainframes) uses MVS standard System Authorization Facility (SAF) interface to an (external) security manager (e.g. RACF by IBM or ACF2 by CA [67]).

The distributed Queue Managers use the Installable Services component of MQSeries - using the Authorization Service - to provide access control for MQSeries resources. MQSeries supplies an Object Authority Manager (OAM) as an authorization service which conforms to the Installable Services interface. The OAM provides a full set of access control facilities for MQSeries including both the access control checking and commands to set, change and inquire on MQSeries access control information. The OAM, like all Installable Services components, could be replaced by any component that conforms to the Authorization Service interface.

When MQSeries checks to see if a user is permitted to access a particular resource, it is the name specified in the MQ API command which is used for the check.

8.1.3 Message Context

The Identity Context consists of the following fields:

• UserIdentifier contains the userid associated with the putting applications.
• Accounting Token is intended to be used by MQSeries applications.
• ApplIdentityData is also application dependant data and it can be used by suitable authorized applications.

The Origin Context consists of the following fields:

• PutApplType indicates the type of the putting application and identifies the environment in which the application was running.
• PutApplName indicates putting application name
• PutDate and PutTime indicate the date and the time

The Passing Context is a concept, where context data associates with one message can be associated with a subsequent message.

8.1.4 Point-to-point Security

Mutual authentication ensures that queue managers are exchanging messages with the intended queue manager. There are two methods available for the provision of such partner authentication:

• Some transport systems provide for partner authentication when a connect is made between the two systems. For instance, many implementations provide session level authentication, called Bind Time Security, to enable mutual authentication of each partner. A similar facility is provided by Secure Socket Layer (SSL) on TCP/IP. This kind of authentication provides proof only of the partner transport and not the partner Queue Managers. In many cases this can be insufficient and many transports or platforms does not support this.
• The Message Channel Agents (MCAs) provide an exit point which enables an authentication process to be carried out. The exit running at this point is user provided and so any desired style of authentication may be provided. As the exit runs as a part of the MCA - and so runs above the transport layer - the exit may be protocol independent and be available for any of the underlying transport mechanisms. The security exits may also control the userid under which the MCA runs and accesses MQSeries resources.

The reason for this obvious design and implementation problems are at least the complexity of the MOM related security features. Security implementation problems were also a main reason why SNMPv2 is still delayed to enter the networking market [1]. There are also difficulties if one tries to connect asynchronous MQSeries to DCE structure. In the case of IPv6 and IPSEC many of these security lacks will be corrected at the system level [68].

Application Level Security consists of:

• Remote Authentication: Even though the context fields provide information to identify the origin of a message, there is no information to prove that the origin data is authentic. What is required is some kind of remote authentication token which prove that the context data is valid.
• Data Integrity: In some instances it is necessary to prove that the message has not been altered while passing between applications.
• Data Confidentiality: It should be possible to encrypt / decrypt transferred messages to hide the contents of that message.
• Non-repudiation: This guarantees that a particular message came from a particular user. Commonly this can be established by using Digital Signatures.

Although these services are not provided as a part of the Queue Manager base functions today, it is still possible to implement these services as a part of MQSeries.

The security structure that relies on MCA exits is not complete. The implementation must not have pre-requisite security products/mechanisms (e.g. DES, DCE, RSA). Also there should be as little security functions as possible in the Queue manager kernel functions- particularly in terms of managing the environment, which should ideally be managed as a part of the overall security management functions.

8.2 Security in VCOM

Data security issues are regarded at Verimation as most important issue in the future releases of VCOM. The security requirements are implemented in two steps: first in Intranet and then in the Internet.

Within Intranet NT users userid's can soon be checked against RACF and also encryption / decryption will be implemented soon. It is not absolutely sure which protocols or algorithms will be utilized in their solution [65].

VCOM Java client can now exchange messages across the Internet but there are no extra security mechanisms available yet. In the next release of VCOM tested Intranet solutions will be implemented also for the Internet JAVA clients [65].

8.3 Security in DECmessageQ

"Queues can be designated as requiring security checking. The administrator sets up the attribute in the configuration file for the queue. If the security signal is set, the security authorization process in DECmessageQ is activated. An access control list must have been set up by the administrator and attached to the queue" [26].

"With DECmessageQ Plus, in addition to the services provided by DECmessageQ, the application can use the Check-security command to check that the process making the request is authorized to access a service" [26].

"With MQSeries Internet Gateway, any Web server machine that supports CGI, such as IBM Internet Connection Server, can provide any Internet-connected Web browser, such as Netscape Navigator, with transparent access to MQSeries applications (picture below). Because the Gateway uses the standard Common Gateway Interface it should also work with other well-known Web servers that support CGI" [69].

The Gateway provides a number of services to the Internet Connection Server. These include:

• management of multiple concurrent users
• data conversion, e.g. ASCII-EBCDIC
• a timely response service to the Web browser client. This provides information about the progress of the asynchronous MQSeries application running locally, or on a remote machine connected to the Web server via the Internet or another network. No other application software is required on the server, but the MQSeries application must interpret HTML-type data requests from the Web browser and generate HTML pages in reply.

Existing MQ applications can use the MQSeries Internet gateway if a customized, Web-aware application component is placed on the application server. This converts between the Web browser's hypertext request and replies, and the application's internal message structure. A server component can coordinate requests to several MQSeries applications and a response to the Web browser. It can also act as a request broker coordinating access to multiple legacy environments.

How to run VCOM or across the Internet is mainly a data security issue and it is shortly covered in the chapter 8.2 Security in VCOM.

In BEA's architecture Internet connections are established via product called BEA Jolt [70]. BEA's future plans can be seen in the next chapter.

Many banks all over world have relied on IBM's MQSeries [71]. Some of those banks and their goals were :

Barclays Bank's [72] goals were to get the goods to market faster, Swedish Nordbanken chose MQSeries to integrate essential applications. Swiss Bank wanted to improve access to its data with MQSeries and Turkish Pamukbank [73] reduced the operating cost and could be a winner in a business by using MQSeries.

The author of this seminar presentation also works in a Finnish Banking group called OKOBANK-group that has very advanced products also for Internet-banking [74], [75] and OKOBANK has, as the first bank in the world, announced how to reach banking services via GSM supplied Short Messages [76]. In OKOBANK there is no MOM products available at this moment but pressure to choose one is continuously growing.

One important question is whether to choose MOM product as a individual product or should it be better to choose / change a whole middleware architecture at the same time? MOM products are mature, as OVUM indicated it, but linking MOM with ORB to be used with forthcoming ObjectWeb is not yet a common reality. So argument could be: "Is it now the right time to buy middleware".

Many customers today are also afraid of being tied to one software vendor. "Once middleware vendor has sold you middleware you are also likely to remain with that vendor for some time and the middleware vendor will thus have the same influence that the hardware manufacturer used to have" [26].

One problem is also a partially missing data security, for instance, when customers want to run MOM across the Internet. This problem has addressed by many MOM vendors and solutions will appear sooner or later. The solutions should, however, easily be integrated to companies existing data security policies and architectures.

There have also been thoughts that asynchronous messaging should be part of web browsing technology [77]. Also SET-implementations [78] perhaps could use asynchronous messaging.

In the future IBM plans to link MQSeries with DCE security services, but also the utilization of underlying operating system security features (other than MVS) will be evaluated. IBM wants to extend MQSeries so that it fully supports wireless communication [26]. IBM is working to use MQSeries as the underlying technology for DSOM that will provide the ORB with asynchronous object inter-communication [26].

BEA's objective (picture above) is to provide integrated Enterprise Object Middleware in the form of a suite of middleware products based on BEA TUXEDO, which includes ObjectBroker and DECmessageQ integration. The Enterprise Object Middleware product (code-named "Iceberg") will support either CORBA-based business objects or BEA TUXEDO services and enable them to interoperate [79], [80].

Verimation plans that future VCOM versions will support more platforms and protocols, improve VCOM interfaces to other middleware products (Oracle Mobile Agent and CORBA?), integrate VCOM with better development tools, improve the performance of VCOM and improve OAPI interface in MVS. Version 3 (next) will probably bring SNMP links to systems management software and VCOM will reroute traffic over an alternative route in the case of faulting communicating link. Support for broadcasting and multi-casting of messages and enhancements of statistics and billing will also be implemented in version 3 [26].

Gartner Group [37], [38] indicates that "all large enterprises will use multiple RPC-like mechanisms and multiple messaging mechanisms at least through 2000 (0.9 probability)" [5].

[2] "Middleware meets the Network" by Steve Steinke, LAN December 1995, vol 10, number 13, p. 56-61

[6] Ranadive Vivek: TIBCO publishing and subscribe middleware, MIDDLEWARE SPECTRA 08/96, vol. 10 report 3

[7] Verimation homepage

[15] MQSeries home page

[18] Apertus Home Page

[19] MQ Edition from Apertus

[20] TUXEDO Home Page

[23] Manchester P.: Standard bodies and middleware, MIDDLEWARE SPECTRA 02/96, vol. 10 report 1

[24] MOMA MEMBERS COOPERATE TO ENDORSE A CONCEPTUAL FRAMEWORK FOR ORB AND MESSAGING INFRASTRUCTURE

[25] OVUM Ltd's Home Page

[27] What's new with DECmessageQ?, DECmessageQ Infocenter, What's New

[29] Microsoft Home Page

[31] ICL's Home Page

[38] Market-visio home page

[39] Enterprise Messaging Technology (EMT), A report by the Standish Group International Inc

[41] Richard Schreiber: How Middleware Technologies Compare, Datamation July 1, 1995

[48] Volvo's Home Page

[59] Candle's Home Page

[63] BMC home page

[65] Meeting with Jan Trydal and Markku Seilola, Verimation, 2.4.1997

[66] Stuart C. Jones: IBM Hursley: MQSeries Security, Presentation in "Transaction & Massaging Congress 96" in Berlin October 96

[68] Timo Aalto: IPv6 Authentication Header and Encapsulated Security Payload

[69] Gateway to the world

[70] BEA JOLT home page

[71] Some MQSeries Banking Customers

[75] Tiesitkö, että voit käyttää internet-yhteyttäsi myös pankkiasioiden hoitoon ?