Pipex Applications

Pipex has been used to solve the following kinds of problems:

Send transactions to a web service using XML. Pipex acts as a reliable buffer between the originating application and the web service. Pipex will queue transactions when the web service is down, so that the originating application can keep running when the Internet connection is not available. Or, Pipex can be used to upload transactions to the web service on a scheduled basis, during off-peak hours, for example.

Pass data between applications using quite different file systems. An older legacy mainframe-based system that must interact with newer Windows based application software is one example.

Store incoming transactions from users that only periodically connect to the network. One example is notebook computers used in the field. Pipex will store new orders entered by sales people on their notebooks until they dial in or connect across the Internet. At that time, Pipex will move new orders to a central database, while updating the sales person's notebook with new customer, product and pricing updates.

Replicate database records across a wide area network or the Internet. Pipex supports loosely coupled distributed application systems. Such systems will use considerably less bandwidth than on-line systems or database servers' built-in replication techonlogy. Pipex will support data replication over intermittent dial-up sessions, e-mail attachments or by snail-mailing a diskette or CD.

Pipex is extensible, permitting developers to add new data transports, and message or queue handlers. The possibilities include:
Capturing incoming transactions on a web-site,
Transferring EDI data,
Processing XML transactions,
Maintaining a distributed but real-time inventory.

Pipex Applicability

Pipex technology is most appropriate for message passing when any of the following conditions exist:

• The messaging applications are 'loosely coupled'. That is, message passing is not required in real-time, and some latency, even if less than a second, is acceptable.
• Two or more applications support separate, self-contained, but different data architectures, and some degree of data replication is necessary between them.
• A data architecture exists across mutiple geographic locations.
• Guaranteed delivery of messages is essential.

Pipex technology may not be appropriate in the following situations:

• Simple Internet-based real-time queries from a data base, which can be more simply provided by a web service.
• Data subscription by unidentified nodes is not currently supported. All nodes on a Pipex network must be identified by the network designer.
• Message passing over the open Internet can be performed, but message encryption is the programmer's responsibility. Of course, Pipex can run over a VPN which will provide the necessary encryption. See security for more details.
• Two way messaging can be implemented, but Pipex is most appropriate in integration designs which tolerate message latency or which are loosely coupled.

Learn more about the advanced features of Pipex Message Queue Server.