Mashed Articles

Well, frankly, not a lot. Still, it’s worth heading back to see what people in the 1960s thought the modern era would be like. Touchscreen computing, computers in the classroom, the cashless economy, snooker playing robots… even if the tech sounds familiar, those early implementations were something quite different.

Visit the full Collection at the BBC Archives for a glimpse of what could have been.

IBM recently published an article on the use of WS-ReliableMessaging between WebSphere 6.1 and Axis2. Most interesting I found the part on the Quality of Service of WS-RM:

• Unmanaged non-persistent tolerates network and remote system failures. You can configure Web service applications to use WS-RM with a default in-memory message store. This QoS requires minimal configuration; it is for a single server only and does not support clusters. Although this QoS allows for the re-sending of messages that are lost in the network, failure of a server results in lost messages. The default is unmanaged non-persistent.
  

• Managed non-persistent tolerates system, network, and remote system failures, but state is discarded after the messaging engine restarts. This in-memory QoS option supports clusters as well as single servers. This option uses a messaging engine to manage the sequence state, and messages are written to disk if memory is low. This QoS allows for the resending of messages that are lost in the network, and can also recover from server failure. However, a failure of the messaging engine causes message loss.

• Managed persistent tolerates system, network, and remote system failures. This QoS for asynchronous Web service invocations is recoverable. This option also uses a messaging engine and message store to manage the sequence state. Messages are persisted at the Web service requester server and at the Web service provider server, and are recoverable if the server fails. Messages that have not been successfully transmitted when a server fails can continue to be transmitted after the server restarts.

QoS of WS-RM is actually not part of any standard. Most implementations of WS-RM are non-persistent, in particular Microsoft WCF and Sun’s Metro. And that is in my opinion the major shortcoming of the WS-* story. The WS-RX committee should have made message persistence part of the WS-RM spec and/or the WS-RM Policy spec.

Anyway, IBM has a persistent implementation of WS-RM. And so has SAP: SAP doesn’t even give you the option and uses persistent WS-RM as its default. Well done by SAP, although the SAP implementation is based on an older version of the WS-RM spec (WS-RM 2005/02.)

What I don’t find are reports of the use of persistent WS-RM between stacks of different vendors, e.g. between IBM and SAP. Maybe we’ll need to have a go ourselves one day?

EDIINT AS2 is a very popular B2B protocol. Apart from file transfer, I think this is currently the most popular B2B protocol. Although EDIINT was initially meant to replace EDI over VAN connections by EDI over the INTernet (EDIINT), the AS2 protocol can transport any data in an asynchronous manner.

AS2 provides:

• Firewall friendly as it uses HTTP(S) underneath
• Straightforward: adds a number of HTTP header field and MIME based message structure
• Reliable: send message until you get a 200, duplicates are filtered based on message-id
• Signing: based on S/MIME message structure and PKCS7 signing (self signed certificates are often used in practice)
• Encyption: also leveraging the S/MIME message structure
• Non-repudiation: signed acknowledgement or message receipt, called the Message Disposition Notification
• Any payload: EDI, XML, binary, text
• Many implementations: free commercial versions available at low price and one or two open source implementations

As is typical in B2B scenario’s, AS2 servers are mostly located behind firewalls that only allows inbound connections from well know IP addresses.

AS2 and its family
AS2 has some family: AS1, which goes over SMTP. And a younger brother AS3 which uses FTP as its transport. And now a 4th child joins the family: AS4! AS4 uses uses ebXML messaging v3 as its transport. But what the heck is ebXML?

ebXML
ebXML was an initiative to define *the* new B2B standard for the 21st century: new transport layer, new message definitions, XML schema building blocks, process layer, protocol profiles and so on. ebXML didn’t really take off, mostly because it was considered some sort of threat to the Web Services story. A pitty that the WS-* world and ebXML world weren’t able to come together in 2001. ebXML gained a bit of popularity in some European countries like the Netherlands and Denmark, where it is used on a limited scale.

Work continued very quiet and a new version of the transport layer was released in 2007: ebXML Messaging v3. ebXML Messaging v2 and v3 are actually SOAP over HTTP(s) with some extra whistles.

Conclusion
The feature of AS4 is pulling or polling. Polling is one of the reasons why file transfer is so popular: it is “asymmetric” and allows one side to stay behind a closed firewall. ebMS 3.0 supports polling and AS4 das well. Well done! WS-Polling was a similar initiative in the WS-* world to introduce polling.

But AS4 will not become that popular in my opinion. The spec is rather “heavy” and ebMS 3.0 has very little traction. I’m not aware of any implementation. I would have preferred an extension of AS2 with support for polling, completely independent of the ebMS and WS-* specs. And so we’ll simply continue using file transfer (SFTP, FTPS) as our most popular polling mechanism.

Notes:
- Brik, thanks for pointing me to AS4
- Pictures are from a talk I gave on AS2
- Interesting link for those speaking Dutch: ebXML en ebMS: veilig en betrouwbaar berichten uitwisselen