Peer network overview

The Interchange peer network provides a means of connecting multiple instances of Interchange managed by your company or enterprise. A n Interchange instance can range from a one trading engine running on a single processing node, to many trading engines running on multiple clustered machines with many nodes. Each Interchange instance has its own database.

Peers are communities and partners that are linked in a network for the purpose of sharing synchronized trading partner configurations. The messages that peers exchange with each other are related only to the peer network. Trading communities and trading partners separately carry on the usual e-commerce traffic. Peer communities and partners are distinct from trading communities and partners, although peer and trading objects have many similarities. (See Compare peer network and trading network objects.)

Protocols for peer communication

Default protocol for peer exchanges

When you set up a peer network, as described in Configure a peer network, the AS2 protocol is automatically installed as your peer network communication protocol. Axway recommends the use of the default AS2 protocol for peer exchanges, because of its ease of installation and setup.

Alternative protocols for peer exchanges

Interchange additionally supports the use of other protocols for peer exchanges.

The MIME envelope for peer messages has the following special content MIME type: application/x-cyclone-peer-to-peer. If you use a non-default protocol, you must add this peer message content MIME type as a message attribute. Non-default protocols may require additional configuration. Contact Axway for additional information and help with special setup requirements.

Trading protocols supported for peer cloning

When you set up a peer network, you can automatically or manually clone trading and application pickups and deliveries that support any of the following protocols:

  • AS1 (email)
  • AS2 (HTTP)
  • AS3 (FTP, SFTP)
  • AS4 (HTTP)
  • ebXML (HTTP, SMTP)
  • Generic email (SMTP, POP)
  • No packaging (FTP, SFTP, File system, JMS, MQ, WebDav, MLLP)
  • Odette FTP V1 (HTTP)
  • Odette FTP V2 (HTTP)
  • PeSIT
  • RosettaNet 1.1 (HTTP)
  • RosettaNet 2.0 (HTTP)
  • Secure file (HTTP, FTP, SFTP, File system, JMS, MQ, WebDav)

Cloneable objects and their dependent objects

You set up peer networking in order to share object configurations between networks. This topic lists the dependent (or child) objects and attributes that are shared when you clone each of the principal cloneable objects in Interchange.

  • Partner
    • Routing ID
    • Messaging ID
    • Contacts
    • Certificate
    • Properties
    • Trading deliveries
  • Application pickup
    • Transport protocol settings
  • Application delivery
    • Delivery settings
    • Transport settings
  • Trading pickup
    • Transport protocol settings
  • CPA
    • (no dependent objects)

Trading protocol limitations

The following protocols have not yet been validated for cloning in the peer network:

  • cXML
  • X400
  • WebTrader
  • Web Services
  • AS4
  • MQ trading and application pickups in server mode are not supported (only client mode is supported)
  • Pluggable transports and servers

The polling features of transport protocols are not supported for peer cloning.

Example architectures

The following figure shows an example of three trading engine clusters joined in a peer network. The clusters are all under the control of a single company or enterprise. The peer network could be connected through the Internet, a LAN or a WAN.

Example of three trading engines clusters joined in a peer network.

The preceding figure illustrates the inherent flexibility of the peer network and Interchange. Each cluster is a different size and runs on a different operating system. Each cluster has its own database, and each database can be a different type. Geographically, peer clusters can be located in the same building or on different continents.

The messages exchanged in the peer network are called peer messages. There are two types of peer messages:

  • Trading partner configuration messages
  • Ping messages

Peer messages are written in XML. A peer message consists of two parts:

  • Content –The actual ping message or trading partner description.
  • History – Used by the peer network to make sure peer messages are not replicated redundantly across the network.

The MIME envelope for peer messages has the following special content MIME type: application/x-cyclone-peer-to-peer. If you use the "No packaging" or "File system" transports, you must add the peer message content MIME type of application/x-cyclone-peer-to-peer as a message attribute.

Each cluster or Interchange instance is represented by a single peer community. Just as a trading community shares its profile with trading partners, the peer community shares its peer profile with the other peers in the network. The view from within each peer is a single peer community, with peer network partners represented by imported peer partner profiles. The following figure illustrates the peer community and peer partner relationship in a peer network.

Note that the Internet traffic illustrated in the previous two figures represents only the peer messages exchanged between peer clusters and not e‑commerce traffic. Peer messages can consist largely of ping messages exchanged at regular intervals among peers to determine whether peer partners are active. Depending on the configuration, trading partners also are exchanged across the peer network. Each time a trading partner is updated on one instance of the trading engine, the changes can be broadcast to all peers or only to selected peers.

When trading partners are synchronized across the peer network, this enables multiple clusters of trading engines to act together as a single large cluster for trading purposes. The following figure illustrates this type of scaled-up trading network enabled by the peer network. In this example all message traffic is e‑commerce traffic.

While in the previous figure it is possible for both peer clusters to exchange e‑commerce messages with all trading partners, note that only one cluster communicates with one trading partner at a time. While trading partners can be replicated across the peer cluster, trading messages are not. The database for each cluster contains trading message records only for its own cluster, not also for another peer cluster. In the previous figure, if peer cluster B went down, and if both clusters had a common back-end system, peer cluster A would process all messages for all trading partners until cluster B came back up. The peer network has intelligence to make sure that when cluster A sends a business message to a trading partner, the partner’s response acknowledging receipt of the message is returned to cluster A and not another cluster.

Related topics

Related Links