One of the weaknesses in XSLT 1.0 was the very simple set of string manipulation features. In comparison to many popular programming languages, the string functions lacked one very powerful feature, regular expressions. Intel SOA Expressway actually offers this functionality with extension functions for our customer base. In XSLT 2.0, the XSLT working group plugged this hole for everyone in a couple of ways that we’ll look at in this post.

Regular expressions are a very flexible way to match strings or portions of strings based on patterns. These patterns are specified by a special syntax and are unrelated to the patterns used to match nodes in XSLT templates. See the Regular Expression Syntax (http://www.w3.org/TR/xpath-functions/#regex-syntax) section of the XQuery 1.0 and XPath 2.0 Functions and Operators specification for the details of the syntax.

Because regular expressions are so popular, I’ll assume some basic knowledge that’s easy to pick up from the web for the examples in this post. Still, it’s worth pointing out that the regular expression syntax supports some advanced features. There are “greedy” quantifiers (* and +) to match the longest substring possible and “reluctant” versions (*? and +?) to match the shortest substring. Enclosing a portion of the regular expression with parentheses, for example “(123)”, specifies a captured subgroup that can be referenced by number. Finally, as you might expect for a language targeted at processing XML, there are some special matching specifications for Unicode and XML name characters.

Often it’s enough simply to match a regular expression when deciding whether and how to process a node or some text. The matches(string, regex) XPath function
takes a string, attempts to match the regular expression, and returns true if finds any matches.
This function is handy in predicates and in <xsl:choose> and <xsl:if> where a Boolean result is needed to determine the matches.

When converting formats, sometimes it’s useful to change parts of a string that can be found with a regular expression. The replace(string, regex, replacement) XPath
function returns a new string formed by substituting the replacement string for every match to the regular expression. The replacement string itself can refer to portions of the matched substring with numbered variables, such as $1 for the first captured group substring and $0 for the entire substring.

Breaking a string into a sequence of smaller strings is done with the tokenize(string, regex) XPath function. Matches to the regular expression mark the boundary between substrings (tokens) and will not be included in the result. This function is useful for separating strings that are delimited, such as strings of comma separated values. But because tokenize() takes a regular expression, the separator can be much more sophisticated than a simple character.

In order for XSLT to offer more even more flexible regular expression processing than the functions in XPath, the <xsl:analyze-string> instruction can break a string apart much like tokenize() while allowing the stylesheet to process both the matching and non-matching parts. Because it’s an instruction, it can also create nodes to structure the data, which the XPath functions can’t do.

Here’s an example using <xsl:analyze-string> to pull out the current top ten trends from Twitter and build a very simple HTML page. The Twitter API is a RESTful API, which means it returns results in response to an HTTP request on a resource. In this case, we can ask the search API with the URI http://search.twitter.com/trends.json to get the latest top ten trends, which are returned only in JSON format. An example of the returned trends is shown below.

{"as_of":"Fri, 23 Oct 2009 16:15:38 +0000","trends":[
{"name":"Follow Friday","url":"http://search.twitter.com/search?q=%22Follow+Friday%22+OR+%22Its+Friday%22"},
{"name":"#iusuallylieabout","url":"http://search.twitter.com/search?q=%23iusuallylieabout"},
{"name":"Nick Griffin","url":"http://search.twitter.com/search?q=%22Nick+Griffin%22"},
{"name":"Cassetteboy","url":"http://search.twitter.com/search?q=Cassetteboy"},
{"name":"Halloween","url":"http://search.twitter.com/search?q=Halloween"},
{"name":"TGIF","url":"http://search.twitter.com/search?q=TGIF"},
{"name":"Windows 7","url":"http://search.twitter.com/search?q=%22Windows+7%22"},
{"name":"Paranormal Activity","url":"http://search.twitter.com/search?q=%22Paranormal+Activity%22"},
{"name":"Soupy Sales","url":"http://search.twitter.com/search?q=%22Soupy+Sales%22"},
{"name":"#mylasttweetonearth","url":"http://search.twitter.com/search?q=%23mylasttweetonearth"}]}

JSON uses a recursive syntax to represent data objects, which isn’t possible to parse in the general case using regular expressions. But in this case, the data we’re interested in is a list enclosed in the bracket characters “[“ and “]”. We will process the “name”:”value”, “url”:”value” pairs in the list with a regular expression to build a very simple HTML page that lists the top ten trends as links to the Twitter search page for that topic.

The stylesheet below is in the form of a simplified stylesheet module in order to show a self-contained stylesheet.

<html xsl:version="2.0"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Current Twitter Trends</title>
  </head>
  <body>
  <h2>Current Top 10 Twitter Trends</h2>
  <ol>
  <xsl:variable name="trends" select="unparsed-text('http://search.twitter.com/trends.json')"/>
  <xsl:variable name="trendList" select="tokenize($trends, '\[|\]')[2]"/>
  <xsl:analyze-string select="$trendList" regex='\{{.*?:"(.*?)",.*?:"(.*?)"\}}'>
    <xsl:matching-substring>
      <li><a>
        <xsl:attribute name="href" select="regex-group(2)"/>
	  <xsl:value-of select="regex-group(1)"/>
      </a></li>
    </xsl:matching-substring>
  </xsl:analyze-string>
  </ol>
  </body>
</html>

The variable $trends retrieves the current trends from the Twitter search API by calling the unparsed-text() function. We need to use this function because the trends are returned only in JSON format and can’t be parsed directly by the XSLT processor. The $trendList variable uses tokenize() to separate the JSON response into pieces broken by “[“ and “]”. Those pieces are returned as a sequence of strings, which is effectively indexed with the “[2]” filter to get the top ten list.

Next <xsl:analyze-string> uses the involved regular expression “\{{.*?:"(.*?)",.*?:"(.*?)"\}}” to find all the “name”:”value”,”url”:”value” list entries. The name and URL values are captured in capturing groups with the enclosing quotes stripped off. In the <xsl:matching-substring> instruction, list items are built with links showing the trend name, captured in regular expression group 1, and the Twitter search page URL for that trend, captured in regular expression group 2.

The output of the stylesheet for the trends JSON return value shown above is show below.

<?xml version="1.0" encoding="UTF-8"?><html xmlns="http://www.w3.org/1999/xhtml">
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
      <title>Current Twitter Trends</title>
   </head>
   <body>
      <h2>Current Top 10 Twitter Trends</h2>
      <ol>
         <li><a href="http://search.twitter.com/search?q=%22Follow+Friday%22+OR+%22Its+Friday%22">Follow Friday</a></li>
         <li><a href="http://search.twitter.com/search?q=%23iusuallylieabout">#iusuallylieabout</a></li>
         <li><a href="http://search.twitter.com/search?q=%22Nick+Griffin%22">Nick Griffin</a></li>
         <li><a href="http://search.twitter.com/search?q=Cassetteboy">Cassetteboy</a></li>
         <li><a href="http://search.twitter.com/search?q=Halloween">Halloween</a></li>
         <li><a href="http://search.twitter.com/search?q=TGIF">TGIF</a></li>
         <li><a href="http://search.twitter.com/search?q=%22Windows+7%22">Windows 7</a></li>
         <li><a href="http://search.twitter.com/search?q=%22Paranormal+Activity%22">Paranormal Activity</a></li>
         <li><a href="http://search.twitter.com/search?q=%22Soupy+Sales%22">Soupy Sales</a></li>
         <li><a href="http://search.twitter.com/search?q=%23mylasttweetonearth">#mylasttweetonearth</a></li>
      </ol>
   </body>
</html>

The addition of regular expressions is a big step forward in functionality for XSLT 2.0. Not only does it offer simple matching, but also provides very flexible string substitution and breaking capabilities. And last but certainly not least, the analyze-string instruction allows for very sophisticated processing of parts of string, including turning unstructured strings into structured XML data. I’m curious, for those using XSLT 2.0, do you find yourself relying more on the XPath functions or on the XSLT instructions?

Security Policy Designer: The Intel® SOA Expressway gateway now allows relevant teams from architecture, security & operations to design & enforce policy templates that conform to Enterprise requirements

Policy Dashboard: The updated policy dashboard offers a new view of services with visual representation of policies and features to quickly apply policies to other services, functional operations, or application service endpoints . This delivers unprecedented runtime SOA governance capabilities to monitor and manage services in the data center.

Integrated Governance: Making design time and run time SOA Governance seamless across vendor products has been the desired objective of our customers so that existing investments can be re-used across enterprise-wide implementations. With this release, Intel SOA Expressway now integrates with design time governance solutions from Oracle FMW 11g, Software AG Centrasite and IBM Tivoli for a truly integrated web service governance model

Secure Token Service (STS): The new release of Intel SOA Expressway supports IBM Tivoli Access Manager for delegated authentication/authorization, as well as ability to issue, authenticate, and convert CA SiteMinder and Oracle ObSSO session tokens into SAML assertions. This STS standards-based functionality enables customers to leverage their legacy identity infrastructure and proprietary identity tokens for seamless cross-domain single sign on or identity enabled web services to partner systems

Oracle Fusion Middleware 11g Integration: Intel SOA Expressway also offers support for XACML based fine grained authorization using Oracle® Entitlements Server as PDP/PAP (Policy Decision Point/Policy Application Point). The implementation has been validated on Oracle Enterprise Linux. Deployment of Intel’s SOA Expressway security gateway is now the recommended way to apply perimeter security for B2B services deployed on Oracle Fusion Middleware.

XA Support: Intel SOA Expressway fully supports Open Group’s XA Global Transaction standard for fast update of multiple dependent resources. This is useful across many industries including healthcare where updates can be made to aan individual patient record and these updates can be cascaded to other systems with a single transaction call.

Network HSM: Additionally, Intel and Sophos are announcing a joint partnership and plans to support integration of Intel SOA Expressway and Sophos SafeGuard CryptoServer Hardware Security Module. The partnership brings together two market-leading security products, one for SOA security and one for cryptography, into one integrated solution. For certain applications, customers will need to ensure that asymmetric private keys, symmetric keys (configured out-of-band), and passwords are only visible in the clear within a secure cryptographic boundary that is safe from attacker access. Integration with the Sophos SafeGuard CryptoServer provides this secure boundary in a FIPS 140-2 Level 3 key-storage appliance with centralized management. For clear separation of duties compliance, the security administrator responsible for key management is cleanly separated from the administrator responsible for the operation of the network server running Intel SOA Expressway. The combined solution is well positioned for use in highly regulated industries with stringent security regulations like financial payments ( PCS DSS), government agencies (SIPERNet) and healthcare organizations (HIPAA)

Intel and Sophos will jointly present Intel SOA Expressway and SafeGuard CryptoServer at the CARTES 2009 Conference in Paris Nov17. You can learn more about Intel® SOA Expressway here and more about Sophos’ SafeGuard CryptoServer product here.

]]> http://software.intel.com/en-us/blogs/2009/10/21/intel-announces-intel-soa-expressway-r23-and-partnership-with-sophos-for-highly-regulated-secure-soa/feed/ http://software.intel.com/en-us/blogs/2009/10/14/new-intel-soa-expressway-for-healthcare-release-powers-patientprovider-community-exchange-at-newark-beth-israel-medical-center/ http://software.intel.com/en-us/blogs/2009/10/14/new-intel-soa-expressway-for-healthcare-release-powers-patientprovider-community-exchange-at-newark-beth-israel-medical-center/#comments Wed, 14 Oct 2009 13:30:39 +0000 Joshua Painter (Intel) http://software.intel.com/en-us/blogs/2009/10/14/new-intel-soa-expressway-for-healthcare-release-powers-patientprovider-community-exchange-at-newark-beth-israel-medical-center/ It’s been about a year and half since we first released Intel® SOA Expressway for Healthcare, which is a purpose-built, easy-to-deploy integration appliance for connecting islands of information together to enable a secure, high-performance, best-of-breed health information infrastructure. We have now begun shipping release 2.2, which contains a number of new feature enhancements.

• Healthcare Quick Start Kit: prebuilt modules, workflows and data transformation maps to reduce learning curve and improve developer productivity.
• Improved Microsoft Windows Support: new deployment options that take advantage of Windows installer technology make it simple to automate deployment and installation of SOA Expressway across a cluster of servers. In addition, we’ve beefed up support for command line scripting (CLI) on windows to enable even more flexible product configuration and administration using automated scripting tools.
• Reliable Messaging and Replay: advanced support for configuring guaranteed delivery options for sending and receiving of health data.
• Hardened Appliance Form-factor: In partnership with Dell, we now offer a 1U high-performance hardware appliance with tamper-resistant features not available anywhere else.
• Virtualization: Since Intel SOA Expressway is software it supports a variety of hardware virtualization technologies. We’ve now made that even easier by making the product available as a Virtual Appliance in the VMWare Virtual Appliance Marketplace

So is this just another integration engine for healthcare? Well, I’ll give you three examples why this product is different:

1. Intel SOA Expressway for Healthcare lets you extend your legacy Health IT. Because rip-and-replace is never an option, we’ve designed an integration appliance that is easily-deployed as an overlay to your existing Healthcare I.T. applications, databases, even interface engines. Intel SOA Expressway lets you extend your legacy environment by quickly assembling data from a diverse set of proprietary applications and databases into higher-value, standardized information services layer.

2. Intel SOA Expressway for Healthcare is a highly integrated appliance. It performs message transformation, mediation and routing, and security in a lightweight, tightly integrated, high performance runtime. Intel’s approach addresses the high-cost, poor performance and low flexibility of the software “suite” approach to integration, which typically require a substantial investment in an entire stack of separate products to meet even simple integration needs.

3. Intel SOA Expressway for Healthcare is future-proofed. Most integration products today are focused on micro-level integration, simply moving health data from point-to-point, which actually contributes to information silos, adding cost and complexity to a healthcare information environment. Unlike these products which provide a thin veil of standards support at the edge of the product, Intel SOA Expressway for Healthcare has “designed-in” healthcare standards deep within the product to enable healthcare interoperability, not just point-to-point integration.

Intel SOA Expressway maximizes value from your “legacy” investment while “future-proofing” IT infrastructure -- all at breakthrough cost. The value is clear, whether you are looking to build a backbone for a state or national Health Information Exchange; a B2B Hub for high-volume, secure message processing; or even a provider looking for an inexpensive health information gateway to efficiently exchange healthcare information inside hospitals and with health information networks.

Recently, Intel SOA Expressway was selected by Newark Beth Israel Medical Center (NBI), 600+ bed teaching hospital in New Jersey to power the launch of its first comprehensive electronic health information exchange, which will offer a shared clinical data repository to its partner institutions, physicians, other care givers and patients. Intel collaborated with healthcare portal solutions provider IGI to create a next generation solutions for hospitals and IDNs, enabling healthcare providers to securely exchange patient information at the point of care — key to providing better services and reducing integration costs. View the on-demand webinar here.

IGI is an active Intel systems integrator partner that provides an Affiliated Physician and Patient portal solution that enables uniform access to a broad range of services such as referrals and care coordination, e-prescribing, instant access to labs, claims and medication history, as well as a comprehensive virtual patient record. The integration between IGI ORBIT® and Intel® SOA Expressway for Healthcare provides an efficient, scalable, SOA based solution that connects and translates data as it moves across a healthcare network. IGI ORBIT utilizes Intel SOA Expressway to retrieve data for portal display from a variety of hospital systems including EHR, EMR, database, or HL7 based sources, providing the fastest, simplest way for to enable integrated care services and interoperability across a community of participants.

For more information visit the Intel SOA Expressway for Healthcare website here.

In XSLT 2.0, the working group expanded sorting in a couple of ways. First, sorting now sorts sequences of any items, rather than just nodesets. The input sequence can hold any type of items, including a mixture of types. The only restriction is that items must compare using the rules for the “lt” and “gt” comparisons, which are restricted to comparing similar types. So you can’t sort a mixture of strings and integers, for instance, but you could sort a mixture of numeric types. Actually, even this restriction can be worked around with the data-type attribute in <xsl:sort> by specifying a text or numeric sort, although that may not produce results similar to a comparison of like types.

There are also a couple of new places in a stylesheet where sorting can be done. In addition to <xsl:apply-templates> and <xsl:for-each>, <xsl:for-each-group> can have <xsl:sort> as its first instruction to change the processing order of the groups. Without a sort, the groups are processed in order of first appearance in the sequence. With a sort, the groups are first sorted according to the sort key then processed in that order.

The new <xsl:perform-sort> instruction causes a sort to be done anywhere in the stylesheet, returning a sorted sequence at that point. This is generally most useful when initializing a variable value because <xsl:sort> can already change the processing order of applying templates and iterating over items and groups.

Although not a new feature in XSLT 2.0, sorting is more general and usable in more situations than in 1.0. Sorting remains a powerful high-level feature of the XSLT language.

Perhaps the biggest simplification feature in XSLT 2.0, grouping refers to assigning items in a sequence into groups based on some criteria, typically items with the same value. Grouping in XSLT 1.0 was difficult, relying on some tricky XSLT programming. Search for the “Muenchian method” if you are unfamiliar with how this was done previously, or see what Steve Meunch has to say about it.

The XSLT working group addressed this complexity by introducing the very easy to use xsl:for-each-group instruction. You can specify the grouping criteria to use on a sequence of items, the processor will assign the items to groups, then for each group, it will execute the body of the xsl:for-each-group instruction.

Let’s look at an example before looking at the details of this instruction. Suppose we’re formatting for easier viewing the transaction details returned in a SOAP response from a hypothetical financial accounts web service. An example response is shown below.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<getTransactionsResponse>
<transactions>
  <transaction>
    <account>123-456</account>
    <amount>32.10</amount>
    <date>09/22/2009</date>
  </transaction>
  <transaction>
    <account>123-789</account>
    <amount>45.23</amount>
    <date>09/22/2009</date>
  </transaction>
  <transaction>
    <account>123-789</account>
    <amount>64.00</amount>
    <date>09/21/2009</date>
  </transaction>
  <transaction>
    <account>123-456</account>
    <amount>24.97.00</amount>
    <date>09/21/2009</date>
  </transaction>
</transactions >
</getTransactionsResponse >
</soapenv:Body>
</soapenv:Envelope>

Now we can group the transactions by account as follows:

<xsl:for-each-group select=”//transaction” group-by=”account”>

Or we can group by date as follows:

<xsl:for-each-group select=”//transaction” group-by=”date”>

This example showed grouping by like value. The “group-by” attribute specifies the value to use to assign an item to a group. These grouping values are called grouping keys, and the key specification is an XPath expression, so there’s a lot of flexibility in assigning items to groups.

When iterating through the groups, two new functions return the current grouping key, current-grouping-key(), and a sequence of the items in the current group, current-group(). For the example above, we can output an HTML table for each account using these functions to get the headings and table data values:

<xsl:for-each-group select=”//transaction” group-by=”account”>
<table>
Account: <xsl:value-of select=”current-grouping-key()”/>
<tr>
    <th>Date</th>
    <th>Amount</th>
</tr>
<xsl:for-each select=”current-group()”>
 <tr>
  <td><xsl:value-of select=”date”/></td>
  <td><xsl:value-of select=”amount”/></td>
</tr>
</xsl:for-each>
</table><p/>
</xsl:for-each-group>

Besides grouping by value, it’s possible to group adjacent items, group items that immediately follow a particular item, and group items that immediately precede a particular item. The last two forms of grouping are limited to sequences of nodes and use the group-starting-with and group-ending-with modes. These grouping modes are most useful for processing text-centric XML, where the input document is primarily free flowing text, such as the text of book or play, with elements indicating formatting and some structure information.

From this basic introduction to grouping, I hope it’s obvious that there’s a great deal of power and flexibility built in to this feature. This post has really just scratched the surface. Grouping can be combined with sorting, and for-each-group instructions can be nested to group on multiple levels. As a starting point to learn more, the XSLT 2.0 specification has several good grouping examples.

In XSLT 1.0, XPath expressions could return a node-set, which was simply a list of nodes with no duplicates and sorted in document order. The W3C working group decided this was too limiting and in XLST 2.0 introduced a generalization of the concept, the sequence. A sequence is essentially a list of items, where the items can be nodes or any atomic type as discussed in my previous post. Sequences can hold a mixture of item types, but in typical use they hold one type of value, such as only nodes or only strings. Unlike node-sets, sequences can also hold duplicates and retain the order of the items put into the sequence, but for backwards compatibility with node-sets, XPath expressions selecting nodes return a sequence of nodes with duplicate nodes removed and sorted into document order.

All data processed in a stylesheet and in XPath expressions is held in a sequence, even if the sequence holds just one value. That’s a useful concept, because all arguments to functions are sequences, which lets functions operate on lists and return lists. As a convenience, sequences with a single value can be written as just the value.

In a stylesheet, sequences can be created by the stylesheet instruction. That instruction creates a sequence by evaluating an XPath expression in its select attribute. Say the stylesheet needs to select holdings in a portfolio returned in a SOAP message:

<xsl:sequence select=”soap:body/portfolio/holding”/>

In effect, this instruction works very similarly to xsl:copy-of, except that for nodes, xsl:sequence returns the original nodes selected rather than a copy. This could be important for efficiency in some situations.

Sequences can be manipulated with a few new operators. The comma (,) operator joins sequences, and positional predicate notation can index and return an item in a sequence. For example, (“Sponsors”, “of”, “Tomorrow”)[3] results in a sequence holding the single item “Tomorrow”. The union (“|”), intersection (“intersect”), and difference (“except”) operators perform set operations on sequences of nodes. Finally, the range operator, to, constructs sequences of consecutive integer values. For example, (1 to 5) returns the sequence (1, 2, 3, 4, 5). This can be combined with the comma operator to build a sequence of different ranges, such as (1 to 5, 15 to 20).

Rounding out the sequence support, several new functions manipulate sequences, offering the capabilities you would expect for manipulating lists, such as inserting items, removing items, taking subsequences, indexing items, and reversing a sequence. Interestingly, there’s a distinct-values() function that return a sequence with duplicates removed. Although the union operator also removes duplicates, it is limited to operating on nodes, whereas distinct-values() removes duplicates of any type of item in a sequence.

Sequences are now at the heart of XPath and XSLT. By replacing the node-set with the sequence, the W3C has opened the doors to processing lists of any types of items in just about any place, whether XPath expression or XSLT instruction. The W3C didn’t sacrifice backwards compatibility with node-sets when selecting sequences of nodes, easing the transition of existing stylesheets to XSLT 2.0. New operators and functions offer all the useful capabilities expected for manipulating lists. The sequence is really a fundamental improvement to XSLT.

One of the first improvements to XSLT we had to consider when designing our new processor is the rich type system. Actually, the types are at the core of XPath 2.0, and XSLT 2.0 builds upon that foundation.

In XSLT 1.0, values and the results of XPath expressions were very weakly typed, essentially limited to nodes, strings, and floating point numbers that could be pretty freely used interchangeably. For example, the value of an attribute could be compared to either a number or a string, like “@foo = 1”, and the processor would do any conversions necessary to compare the values.

Now, while this freewheeling use of data has been preserved, it’s possible to declare the specific type of values, using types defined by XML Schema. Most significantly, individual data values can be declared as a particular atomic type, such as floats, integers, strings, and even time and date types. (See http://www.w3.org/TR/xpath20/#id-types)

When an XSLT 2.0 processor is schema-aware, it can operate on the values of nodes with the types declared in a schema. So for the attribute example above, it is now possible to precisely compare the attribute’s value as a string, integer, or floating point number as appropriate. Processors are not required to be schema-aware, which means that all nodes are essentially treated as string values, but there ways around that.

In a stylesheet, variables and parameters now have an additional type declaration attribute, “as”. For example, you can declare a variable as an integer as shown below:

<xsl:variable select=”@foo” as=”xs:integer”/>

Declaring types like this has definite benefits. Developers benefit from processor detection of errors when values are used in incorrect or incompatible ways. Performance can benefit from more efficient execution, due to executing optimized code for the data type and by doing fewer conversions. You can still write the XSLT 1.0 way and get the correct behavior, but you lose the benefits of the stronger typing offered by XSLT 2.0.

The new types offer many advantages over the limited types in XSLT 1.0 while allowing for backwards compatible behavior. The W3C did an excellent job of improving this aspect of the language while being largely backwards compatible. It certainly reduces the learning curve when stepping up to XSLT 2.0 and allows gradual adoption of the stronger typing.

For those who have made the transition, do you use the new types, or have you stayed with the weaker typing? Why? I’m curious about this because as you'll see in later posts, there are lots of other great features in XSLT 2.0, and I have wondered if it’s easy to overlook the new type support.

There is one good security argument for this situation, it's hard to trust just any old identity provider when the entry bar is very low as it technically is for OpenID. This is fairly easy to overcome via simple cooperation between the major OpenID providers. There is however obviously a business driver to maintaining control over identities, the associated profile data has value.

Facebook is notable here because earlier this year it took the step to act as a relaying party for other OpenID providers. This case is particularly interesting because the nature of Facebook means that most profile data is automatically generated rather than being teased from users in exchange for service use, so the usual downside of not getting profile data as part of being a relaying party were not that important and there was upside in community appreciation and perhaps a few more accounts. Lets hope the other sites can follow by finding their own ways of creating business value from adding OpenID relaying party support.

Well, we really haven’t. At the time, we announced that the Intel SOA Expressway product would become the single solution for XML and service oriented architecture (SOA) needs. (See this page on the Intel website: http://software.intel.com/en-us/articles/intel-xml-software-products/) The functionality of the XML Software Suite has been wrapped into SOA Expressway, so although we no longer have a standalone library product, the capabilities and performance of those libraries continue to power the XML processing needs of SOA applications.

As part of the continuing evolution of SOA Expressway and its XSLT support, we have been busy developing an XSLT 2.0 processor. The development team has made fantastic progress in a short time. In fact, our processor is approaching beta level and will be available in beta form when ready.

Is there interest in another standalone XSLT 2.0 processor? Perhaps, but Intel believes there’s more value for now in tightly integrating this and other XML features into Intel SOA Expressway. Stay tuned for more about our XSLT 2.0 progress!

• Cross-enterprise Document Media Interchange or XDM
• Cross-Enterprise Document Sharing, specifically the XDS.b profile
• Patient Identifier Cross-reference or PIX - HL7 v3

Each year, the IHE Interoperability Showcase provides the opportunity to view actual demonstrations of IHE interoperability as applied to real-world healthcare scenarios. One of those scenarios demonstrated the sharing of encounter summaries and related documents across the network of affiliated healthcare providers (participants in the showcase) via the IHE XDS profile. However, the registration system used lacked the native infrastructure to share documents with the XDS domain. By simply directing their HL7 v2.3.1 feed to Expressway, XDS Medical Summaries (HL7 v3 CDA R2 / CCD documents) were created and submitted to the local document repository. Expressway was able to easily accomplish this by:

1. Utilizing it's large mapping libraries (HL7v2.x to HL7 v3 CDA) to convert the native HL7 v2.3.1 feed to the XDS Medical Summary.
2. Utilizing the IHE Patient Identity Workflow (PIX/PDQ) to augment the Medical Summary with a patient ID recognized by the XDS domain.
3. Sending the augmented Medical Summary to the IHE XDS workflow, which securely sent the document to the XDS repository over TLS.
4. Additionally, the IHE ATNA workflow was able to provide audit information of key steps to an audit server.

Other healthcare scenarios during the Showcase focused on radiology. One participant in this scenario was Sorna and their Reviewer product, which is used to transfer radiological exams to portable media. However, in order to create XDM compliant media, additional content, specifically, diagnostic reports (HL7v3 CDA compliant document) and metadata about the reports (XML document) were needed. Other participant's systems in the radiology demonstrations could generate diagnostic report content, but lacked capability to produce it in a format compliant with the XDM profile. One of those was TSG's iView, application, which generates diagnostic reports but only in PDF format. Another was Philips XIRIS 7.3 product, which was also able to encapsulate their reports but using HL7. Expressway was again able to provide the necessary infrastructure by accepting these reports, parsing them, and creating the appropriate XDS documents which were then forwarded Sorna, simply by utilizing native adapters, translation maps, and IHE components inside Expressway.

Intel SOA Expressway for Healthcare is a high-performance health information gateway from Intel, that simplifies healthcare information interoperability. It provides a configuration-centric solution to integrate islands of health data and ensure data privacy, delivers out-of-the box support for healthcare data standards, and enables healthcare organizations to service-enable their legacy Healthcare IT to interoperate with the entire healthcare enterprise. Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

Intel is one of many vendors who deliver products to the healthcare marketplace which provide IHE profile support to address concrete, critical interoperability issues in healthcare. Intel SOA Expressway for Healthcare is software middleware that enables support for IHE profiles at the infrastructure layer, which provides implementers greater flexibility and control in building solutions for information sharing. The two example below can help to clarify what is meant by "infrastructure layer" interoperability.

1) An EHR application can understand HL7v2.5, but is not able to query and retrieve clinical documents from a community HIE that has adopted the IHE profile XDS (Cross Enterprise Document Sharing). Expressway can enable this use case without requiring any changes to the EHR application.

2 ) A hospital wishes to publish and share encounter summaries with a network of affiliated physicians. Expressway can facilitate this by simply redirecting the HL7v2.x message feed from the hospital interface engine. In addition to IHE profile support, Intel has spent several years developing pre-defined maps from all major version of HL7 2.x to HL7v3 based data formats. This reduces the time and cost spent integrating systems.

In both of these examples, there is a need to leverage existing investments in legacy whilst recognizing that more flexible, scalable architectures and standards are required going forward. Expressway fulfills an integration function as part of an infrastructure layer, which permits healthcare providers to approach interoperability in a manner and at a pace that is more consistent with their own strategy, rather than a vendor roadmap or one department's legacy applications.

Moreover, an integration approach to healthcare interoperability is a key enabler towards "intrinsic interoperability", which is the ultimate goal of standards. Renowned SOA expert and author Thomas Erl wrote that "software programs that are not interoperable need to be integrated. Therefore, integration can be seen as a process that enables interoperability. " In Healthcare, organizations such as IHE as well as standards bodies like HL7 and OMG (through HSSP) are making great progress towards realizing this vision. If they are successful, then the need for integration should begin to gradually go away.

For next years Showcase, there is already discussion within IHE about plans for a new showcase category for interoperability "infrastructure" based on middleware solutions like Intel SOA Expressway for Healthcare.

If you are looking for more information on Expressway's support for IHE profiles, I would encourage you to visit Joe Welsh's new blog at: http://software.intel.com/en-us/blogs/author/joe-welsh/

Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

The cost of Medicaid and Medicare has been written about often as government budgets are re-evaluated and the new administration takes root.  With econonmic times being what they are the number of beneficiaries are increasing in an already overburdened system of service to US state and local communities.

In response to concerns over rising costs, complex processes and fragile systems the Federal Centers for Medicare and Medicaid Services (CMS) developed the MITA Framework.  MITA stands for Medicaid Information Technology Architecture.  It is an integrated business, data, application and technology architecture built on SOA principles and best practices.  MITA is a strategy and a blueprint for establishing integrated business and IT transformations in State medicaid programs to tackle the issue of rising costs, complex business processes and fragile systems.  A key challenge when implementing any kind of enterprise transformation and associated SOA project is how to crawl, walk and the run in the rollout of the implementation.  The MITA framework proposes a multi-stage maturity model and many states are assessing how to progress through the stages of maturity.

To help states progress from where they are to the necessary and desired states proposed by MITA, Intel, Oracle and Initiate have come together and assembled a webinar series on approaches to go from MITA theory and recommendations to specific implementations.  This webinar series covers the essential elements of MITA relevant technology stack and how to apply common service oriented best practices with the right software foundation to achieve breakthroughs in key business processes like Fraud Prevention and Chronic Disease management.  The webinars discuss in detail the business drivers, technical architectures, and deployment patterns on how to evolve State Medicaid and Medicare systems.

I hope you get a chance to dig in to the webinars and see how SOA best practices and the right technology mix can make a big difference in US healthcare.  You can register for the entire series on demand here.

Until next time,

Joe

There is no doubt I am biased here, but when I hear people characterize XML as just "angle brackets" (or compare JSON with XML for that matter), I know they missed the point. For me it's never been about the syntax but about the the joining of two parts of the data processing world so that we could at last seamlessly mix our human languages and those of our machines in an inclusive model that did not discriminate. The implementation of this ideal in XML is far from perfect, but it meets the good enough rule for the vision and that is I think about all we can ask for something so ambitious.

So where to next? I mention services above because they represent phase 2 or what I think of as at least a 3 phase transition in how we think about data. If the merging of semi-structured and structured data with XML was the first phase, then the integration of application data silos via service & resource architectures with XML has to be the second phase and that feels like it is now also nearing completion at least in vision if not in implementation.

My prediction for the third phase has to be the opening of that data to unexpected and ad-hoc use. While I so mean this in the sense of Web 2.0 mash-ups and social networking they are just the surface artifacts of something much bigger. I think we can all feel that, but as yet don't know fully what lurks below the water of this particular iceberg.

If I was a betting man maybe I would put some money on the data portability project having the strongest vision here although it is rather too biased to the social and idealistic at times for my tastes. The software stack they promote is certainly something to note, OpenID, OAuth, RSS, OPML, microformats, RDF, apml, & XMPP, quite a collection if ever I saw one.

In future posts, I plan to discuss:

• Some of these profiles, their importance and impact on interoperability
• Reduced implementation time by using SOA Expressway, especially as an IHE on-ramp
• Ease of using HL7 in SOA Expressway
• Security aspects of SOA Expressway and how ATNA requirements were met
• SOA Expressway Performance Elements
• Traceability within SOA Expressway
• SOA Expressway product extension to support DICOM and other healthcare related protocols

Intel SOA Expressway for Healthcare is a high-performance health information gateway from Intel, that simplifies healthcare information interoperability. It provides a configuration-centric solution to integrate islands of health data and ensure data privacy, delivers out-of-the box support for healthcare data standards, and enables healthcare organizations to service-enable their legacy Healthcare IT to interoperate with the entire healthcare enterprise. Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

The topic was about the need to standardize, and the benefits of standardizing, software services.  There are many IT standards in healthcare and other industries around document structures, data payloads and information sematics.  Yet, there has been marginal progress on standardizing the functional behaviors or architectures which are needed to create, manage and manipulate that data.

What I think is unique and interesting about what Ken has started is a systematic joint collaboration across healthcare standard organizations.  A collaboration which can result in standards and best practices which cover data structures, information semantics, essential software service behaviors, and associated proven architectures. 

I also think the timing is right.  With the passage of the recent U.S. stimulus bill, there will be the funding, the attention, and the priority given to realizing an approach like this into broad adoption.  I believe this since a comprehensive set of standards beyond data representations will be necessary to achieve the U.S. President's goal of an interoperable, electronic healthcare system at a price that makes sense. 

Until next time,

Joe