Most of you are familiar with deploying Intel® SOA Expressway as a xml gateway for protecting your SOAP and REST services. I wanted to blog about another very interesting use case where SOA Expressway acts as a Secure Token Service (STS) for a lightweight client requestor.
XSLT 2.0 and to some extent 1.0 are powerful languages when it comes to transforming documents and even for performing some tasks. But, as is often the case, to do something odd or unusual can often be impenetrable or just plain difficult. One of the advantages of using Intel® SOA Expressway is that most of the extension functions we have written to make configuration easier for BPEL based workflow are also available to the XSLT developer.
Many enterprises have invested in Oracle* Fusion Middleware for their SOA implementations, sometimes along with other SOA enabled applications such as Web 2.0, Content Management, Business Process Management, etc. As applications are born from this stack of software you start to realize (or further realize) the importance of the total management lifecycle for this new type of application suite. These demands can grow significantly, especially if you've attemped to deliver many at once, often called 'Big Bang SOA'.
Altova is well known for it's flagship product XMLSpy - as anyone who has worked extensively with XML data can tell you. However, they have an entire suite of product offerings, one of which is MapForce. As described on it's website:
If you are a web services developer and you build a new SOA system, you probably choose HTTP as a transport. However, sometimes you should support legacy systems that use other protocols for information exchange, for example, FTP. There are several technical nuances to be addressed in this case.
If client sends data over HTTP, you may analyze it and reply with error code if it’s incorrect. If client uploads data by FTP, how will you notify him that you can’t accept it?
Okay, this is my first post and I want to jump straight in with a neat little method of authentication which is often used when Intel® SOA Expressway is deployed as a Service Gateway. It also gives you the ability to be agnostic to whether you’re dealing with SOAP or REST XML patterns in your messaging.
Generally in these blogs I’m going to assume a little bit of familiarity with Intel® SOA Expressway and Intel® Services Designer but if you’re curious to know more or a noob then drop me a comment and I’ll fill you in on the extra detail.
A typical Healthcare Information Exchange (HIE) accepts data from an array of disparate sources. Often the data it accepts is semantically and syntactically altered by a providing system to satisfy interfacing requirements. However, there are also cases where data from different sources need to be properly merged before reaching the HIE's interface.