Wednesday, November 11, 2009

XML Feature Pack, SCA Refresh, and SAML get a date

Yesterday, IBM announced the dates for the XML Feature Pack, a major update to the Service Component Architecture Feature Pack, and SAML support in the WebSphere Application Server.

Borrowing from the announce letter:


New WebSphere® Application Server V7 capabilities promote application innovation and efficient development and management through updated Service Component Architecture (SCA) support, new XML programming model standards, and support for secure, interoperable Web services using SAML1 Token:


  • Key updates to SCA programming model support for composite application assembly and service deployment through the WebSphere Application Server V7 Feature Pack for SCA V1.0.1 Refresh

  • Support for the XSLT 2.0, XPath 2.0, and XQuery 1.0 programming model standards to benefit XML application development scenarios through the WebSphere Application Server Feature Pack for XML

  • Support for OASIS Web Services Security SAML Token Security Profile 1.1 standard delivered in the WebSphere Application Server V7 Fix Pack 7 (7.0.0.7)




XML and SCA will be generally available on November 20th, and SAML will be available on November 13th. Hopefully you can try these out over the holiday season and be ready for deployment next year.

2 comments:

Chris Adkin said...

Hi Andrew,
I hope this isn't a daft question, but, JDom when used with Saxon allows you to use XPATH 2.0, XSLT 2.0 and XQuery. Therefore, what is the use case for using the XML feature pack over JDom ?.
Regards,
Chris

Andrew Spyker said...

Chris,

Sorry for the slow response, but I was away on a long vacation and I wanted to actually try out JDOM before answering what I thought was the answer.

JDOM supports standard JAXP SAXSource/SAXResult under JDOMSource/JDOMResult. The XML FEP supports these JAXP sources as well, so all you need to do is pass your JDOM to the execute.

You'll get a little performance overhead as the JDOM is forced to/from SAX, but it will work. It would be more efficient to use StreamSource/Result on the original bytes if possible.