Web Services Advanced - Thomas Diesler

It was perhaps a little unwise of me to throw myself into this session given how rusty my webservices are. Note to self: read more. This was compounded by the fact that JBoss have, as with so many other functional areas, apparently given this a serious overhaul. In addition it was mentioned that regular "plugfests" were being held with Microsoft to ensure interoperability.

Anyway, battling on, an impressive list of areas were walked through, some of which I will cover in more detail than others. I will revisit this and several other posts later on to provide links to online sources.

1. WS-Security

# Following the OASIS standards: SOAP, Token, REL and SAML (Important for SSO), W3CXML Encryption Signature

This is configured within within ... I need to locate the relevant config file ...

In a little more detail this area includes:

# Strong encryption
# Certificate authentication, signed content and public key infrastructure.
# JAAS integration
# Fine grained operation configuration
# Fine grained message element configuration
# Message expiration
# Interoperability with Microsoft WSE and Sun JWSDP

The key thing here was that this relates to securing the XML payload on the message and not on the transport. The scenario discussed described messages being recieved and stored by a relay for future transmission onto the destination. In this case the data remains secure whilst on the relay, and the transport could be open (HTTP) without breaching security of the data at any stage.

One warning that was given was to always consider the necessity for encryption, and whether it should be supplied within the message or on the transport given that the performance costs are quite different in each case. This overhead is one reason why WS-SEcurity supports fine grained control of message elements, meaning that messages need only be partially encrypted.

2. WS-Addressing

This refers to moving message addressing information out of the headers (as with cookies) and into the message body, making the message aware of its own routing needs. This allows applications to much more easily control message routing through standardised xml tags.

One advantage of this feature that was briefly described was the ability to dynamically assign "reply" and "fault" addresses for messages.

3. Message Transfer Optimization Messaging (MOTM) and XML Optimized Packaging (XOP)

Refering to the ability to encode binary data in base64 format automatically for transmission. Data formats currently supported include JPEG, text/XML, app/XML.

We were told that XOP is configured as a default within JBoss and that put simply, it handles base64 encoding so you don't have to.

4. JAXWS

Towards the end of the session some mention was made for Providers to be implemented as Message or Source. It appears that Source implementations are those that are able to work directly on the message payload, whereas those that are Message get access to the entire XML structure.

JBoss5 is said to be about 80% compliant with this standard at present, whereas JBoss4 is around 20% compliant

5. And Finally ...

Future consideration will be given to back porting the latest webservices technologies into JBoss4, but JBoss are not sure this will be technically possible. Other things being considered for the future include WS-ReliableMessaging and Fast Infoset.

Samples and documentation are high on the agenda. I look forward to these given how rusty my webservices knowledge is.

The key points for me were around the fine grained control of encryption within the message which is transport independent, the ability to work directly on the message payload, and the ability to auto-magically encode binary data.