On the web site WhatIf.intel.com, Intel provides Alpha software free of charge, but without any warranty that it works as expected or will be supported as is in the future. Nevertheless, this release gives you the opportunity to experiment with OpenCL* capabilities on Intel CPUs long before they become available as a commercial product on Intel platforms.

OpenCL* is an emerging standard from the Khronos Group industry consortium. As a Khronos founder and promoter, Intel has made significant contributions to OpenCL* feature set and continue to be part of the Khronos OpenCL* Working Group. Intel is a strong supporter of open industry standards that create developer choice and foster innovation. The Intel® OpenCL SDK is an addition to Intel’s proven, innovative parallel programming tools available to developers.

Lots of great feedback has helped us to shape this update release. And here's just a sample of what's new:

• 64 bit support
• Full coverage of the OpenCL* 1.1 standard on the CPU (check Intel® OpenCL SDK website for conformance status)
• Preview Feature: Support for printf() in OpenCL* C kernels (cl_intel_printf)
• Intel OpenCL Offline compiler bug fixes and improvements

Intel® OpenCL SDK is based on a published Khronos Specification, and is expected to pass the Khronos Conformance Testing Process. Current conformance status can be found at www.khronos.org/conformance.

* OpenCL and the OpenCL logo are trademarks of Apple Inc. used by permission by Khronos.

You can learn more and download this alpha from the Intel® OpenCL SDK website.

You can share your feedback with us through our support forum.

Known methods suffer from either limitation of scalability or additional synchronization overhead. For example, the most popular implementation for erasing an item from a concurrent container is to exclusively lock the item before or after cutting it out from a list. So, no one can see (find) and access it anymore thus it’s safe to destroy it completely. It involves fairly small overhead if there is no contention but otherwise it leads to blocking of a thread destroying the object and so imposes scalability degradation. And in some situations, it can cause a deadlock.

To unlock scalability and to enable multiple references, a reference counter is usually used in combination with mutual exclusion. Each owner thread increments the counter to acquire access. To release the rights or to remove the object, the counter is decremented. The thread which reaches zero destroys the object. This method involves overhead of two (!) additional atomic operations (per turn) modifying the counter.

The new algorithm was developed (but not yet released) to overcome described issues while combining theirs strengths in concurrent_hash_map container distributed within Intel® Threading Building Blocks. But it is general enough to be used widely in similar situations and with any other container or collection of objects that accessed and destroyed concurrently.

Usually, a mutual exclusion and a reference counter are represented by separate synchronization objects because their functions are considered as orthogonal. It means separate synchronization. But used in combination, all status fields can be read at once without explicit synchronization and some joint operations can be optimized to only one atomic RMW operation which performs synchronization only once reducing the overhead.

The algorithm enables this optimization by combining spin lock and reference counter inside one machine word of one synchronization object. It which provides the same functionality as its parts while also enabling extra functionality such as full and recurrent lifetime cycle of a dynamic object with stages of construction and destruction, which are protected by mutual exclusion. Of course, recycling is useful only for user objects that are not deallocated after destruction.

Separate operations that don’t benefit from the combination can still be executed separately by addressing only necessary parts of the synchronization object and thus reducing the synchronization effort.

Another optimization which becomes possible due to one atomic read of all fields is considering the acquired mutex to be a reference to the object without an explicit increment of the reference counter. In other words, the lock operation does not touch the reference counter at all, while still keeping the object marked as “in use”. There are also other tricks improving scalability and fail-safety guarantees that may be interesting to experts.

However, users interested in improving scalability and performance of theirs synchronization may need some new high-level usage model to apply this synchronization algorithm. A prototype of such an interface may be like std::shared_ptr but with some additional semantics to manage also access rights to an object.

If you are interested in this idea, I will probably provide more details in the next blog. And perhaps then, your feedback will help us to finally release the code (which already 2 years waits its turn) as part of TBB.

Update: Thanks for comments! Let me clarify the purpose of this technique. It is a small-sized synchronization primitive that is suitable to individually protect each object from a swarm of similar objects. And so, it is *not* supposed to handle heavy contended case with a lot of threads trying to lock/attach to the same object nor to support thousands of references (yes, 16 bit ref counter is enough, otherwise it is not the primitive you need). Here, under scalability I meant that it allows to unlock a list (bucket) which contains up to several objects while desired object is locked by a busy thread. Thus, many threads accessing many different objects which can share the same list finally meet less contention - it is what reference counter is about. It is probably a subject for separate blog where I can show the use case in pseudo-code.

As always, if you want to take things further and are evaluating SOA Expressway in order to make a decision to buy then we have pre sales engineers ready to get involved and help with your use case.

Evaluate SOA Expressway here.

Why is this the case? One reason is that security policy enforcement remains tightly coupled to applications, making security a hard problem for the average developer. In fact, the phrase 'tight coupling' may not even go far enough to describe the problem. A better way to put it is that application code or business logic is irrevocably enlaced with security processing. The same code processing a purchase order or rendering HTML content is probably also performing a wide range of security processing such as input validation, digital signature verification, decryption, authentication, access control, authorization and numerous other functions.

This is a problem because, let's face it, as evidenced by the OWASP top ten, software developers aren't security architects; they solve different problems in their day to day jobs. When it comes down to doing code reviews or auditing security policy, the existing security code is bound up with the rest of code. It becomes difficult to figure out where the security processing starts and stops without doing a full code review - and who has time for that?

Are we all Insane?

Based on the most recent OWASP, it appears that we haven't made more than marginal improvements in application security. A famous Einstein quote seems to reflect the situation:

"Insanity: doing the same thing over and over again and expecting different results.” - Einstein

Rather than constantly hound developers to improve input validation or write more secure code maybe there is a better way? Rather than focus on what hasn't worked it's time divide and conquer this problem by moving security away from applications into a dedicated gateway.

Service Gateways: The Art of Decoupling

So what do we mean by decoupling in this context? To the extent possible, we need to stop the trend of irrecovably enlaced security processing and break these functions away from the application server and into a dedicated gateway where they become the responsibility of a security architect, not an application programmer. This means that security processing such as threat defense and trust functions should be the job of a dedicated service gateway not intertwined with the application. With this model, the service gateway provides a virtual endpoint for the real application, be it a SOAP or REST service, and enforces security on the wire. The basic model is shown as follows:

In this model, there is a simple trust relationship between the gateway and the application server. The hard work of threat prevention and trust enablement is done by the gateway and presents only secured messages to the application server. This protection is more than just one way: It is also able to protect clients, especially browsers. It does this by also scanning and cleansing messages as they are returned to clients. This bi-directional control is what allows the gateway to combat some of the OWASP top 10 threats quite effectively, all without lengthy code reviews or micro-managed changes to application logic.

So how can a service gateway provide additional protection against the OWASP Top 10? Let's go through the risks for 2010 and see how these are addressed with Intel(R) SOA Expressway, Intel's service gateway product.

Threat: A1- Injection

Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.

Serivce Gateway Mitigation: Code injection comes in many forms and part of the reason for it stems from weakly typed programming languages such as JavaScript and lack of input validation. Fortunately, common code injection techniques can be easily trapped by a security gateway using a defense in depth approach with multiple layers of protection. Beginning at the very bottom, type checking can be enforced on the wire with XML schema types, but since many schemas are extensible by design this is only the beginning. After type enforcement specific language specific attacks can be scanned for such as SQL Injection and XPath injection. Furthermore, since code injection is context dependent and may include shell injection, LDAP calls, PHP code and other languages (maybe some yet unforeseen) the service gateway provides a full regular expression capability for both required and forbidden regular expressions. This will allow the gateway to trap any possible code injection at the perimeter. The best part is that this sort of input validation is no longer required at the application server. Developers rejoice!

Threat: A2 - Cross-Site Scripting (XSS)

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

Service Gateway Mitigation: Combating XSS threats happens with two protection mechanisms – one is keeping the script out in the first place and the second is making sure the script is never sent to a browser, even if it gets stored on the application server somehow. The threat that the script poses is not necessarily to the application server, but to the client who unknowingly executes it. Similar to code injection attacks, a service gateway can scan for tags using the same regular expression mechanism, either on the forward or reverse leg. In other words, for incoming requests, documents or messages, content should be scanned executable scripts (variations of <script>, for instance) and should never be allowed in. However, since the service gateway may not be the only entry point to the application (there may be other data sources, such as internal databases or interfaces), content scanning on the reverse leg, back to the client is required. This protects the client even in cases where a database is hacked and a script is inserted into content to be rendered to a browser. Even in this case, the script will be trapped by the gateway before damaging the client.

Threat: A3 - Broken Authentication and Session Management

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.

Service Gateway Mitigation: The main threat here actually relates back to our initial premise, which is that average developers aren’t security architects and may end up with custom authentication and session management schemes that contain holes. A service gateway can mitigate this threat simply by supporting standards such as WS-Security, SAML and SSL/TLS, all of which provide a very well-understood way of handling authentication, message security, and session protection. Why re-invent the wheel? Standards like these exist to provide a secure foundation for applications. Further, service gateways can also sit in front of applications with weak security design, such as exposed session IDs in query parameters, and provide a secure endpoint that uses a stronger way of handling sessions (such as an embedded encrypted and signed session identifier in the message itself) to the external caller, but maps to the expected way of session management by the application. The best part of this model is that no application changes are required. The service gateway provides the secure façade to an otherwise insecure application. In addition, authentication can be handled at the gateway itself, delegating authentication decisions to existing user-stores and identity management systems and presenting only pre-authenticated requests to application servers. Service gateways can provide secure endpoints for applications in spite of broken application servers.

Threat: A4 - Insecure Direct Object References

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

Service Gateway Mitigation: This threat stems from the fact that authorization for a reduced privileged user is often difficult to implement correctly, especially for individual object handles and especially after a user is already authenticated. A service gateway can mitigate this threat by authorizing users for specific resources and actions at the policy enforcement point, rather than at the application. Due to the fact that the service gateway is a full application level proxy, it can determine for a particular request, such as an HTTP GET, if the target resource (URI + query parameter) is accessible. Moreoever, it may be possible for the service gateway to expose indirect object identifiers that are mapped to direct identifiers at the application, such as an account number or account profile. This model would provide increased controls for authorization for these type of direct references without overly intrusive changes to the application.

Threat: A5 - Cross-Site Request Forgery

A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

Service Gateway Mitigation: Cross-Site Request Forgery (CSRF) attacks are particularly malicious because they take advantage of an already authenticated session between a user and a service. You may be wondering, if the request is in fact authenticated, how can one defend against such a threat? The answer is to fundamentally improve the authentication mechanism to prevent this type of request hijacking. In CSRF hijacking occurs by convincing a user to click on or otherwise execute an unanticipated function. A common delivery mechanism for a CSRF attack is an HTTP service call (REST call) represented by a link containing the function or functions that the attacker wants the victim to execute. CSRF works because the user already has a legitimate session with the service, and in many cases, a malicious service call can be deduced because REST service calls use unprotected, visible HTTP headers and query parameters. The good news is that service gateways contain all of the building blocks to mitigate CSRF attacks such as nonce checking, digital signatures, hash checking, and the ability to parse secondary session cookies present in hidden HTTP fields. These building blocks are used to authenticate individual requests based on some unpredictable value or second, per-request hidden authentication cookie. The flip-side of this is that applications must be re-designed to include this extra, protected authentication information for individual requests which means re-tooling applications with stronger authentication protocols from the outset.

Threat: A6 - Security Misconfiguration

Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application.

Service Gateway Mitigation: As the number of applications and services continues to grow within the Enterprise, the chance that one of these components, such as an application server or middleware platform, will be misconfigured will continue to rise. Further, Enterprises that rely on custom operating systems or custom hardware make this problem that much harder on themselves. It is easy to issue a general requirement to keep software up to date and properly configured, but the obvious problem here is that this is a never-ending cycle of continual patch management and re-evaluation. Moreover, as business requirements change, software must change to match. Service gateways can't solve this problem, but they can vastly reduce the scope of what must be configured. By pulling security policies and functions away from application servers and centralizing them, the chance of security misconfiguration can be reduced because the number of systems that contain security processing code is also reduced. In addition, centralizing security policy on the wire means that services that trust the gateway are all configured to share a consistent security policy among them.

A7 - Insecure Cryptographic Storage

Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.

Service Gateway Mitigation: Protecting sensitive data with encryption or hashing techniques requires experienced application developers with security expertise. It also involves the proper use of cryptographic tool-kits and an understanding of key management techniques for symmetric and asymmetric encryption algorithms. As far as data protection goes, service gateways can decouple both transport layer and message level data protection away from applications as defined by policy and not code. This effectively moves the problem of defining the data protection policy away from the average developer and into a purpose-built gateway that can apply data confidentiality on any part of the message content, either based on OASIS/W3C standards or custom data protection schemes. In some cases, service gateways can also offer data-at-rest protection by storing encrypted data in a database, completely bypassing the application itself. In this last example, the service gateway is really acting as a security service that can make sensitive data available to applications without actually having to include security processing in those applications.

A8 - Failure to Restrict URL Access

Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.

Service Gateway Mitigation: This threat stems from the use of a basic authentication model that relies on security by obscurity. In this case, the application assumes the protected page or resource cannot be easily found and that access to the page is gated by an authentication challenge. Once the challenge succeeds, the user is given the URL or location of the protected resource. The obvious problem here is that the user can simply save the resource location and skip authentication entirely. The real threat here lies in the case where the attacker steals the location of the protected resources or figures it out through a brute-force attack on likely resource locations. Service Gateways do an excellent job of protecting against these threats as they are based on an explicit white-list policy model and can easily enforce per-request authentication and resource-based authorization. If a specific service endpoint is not explicitly configured in the service gateway, the request will be rejected. This checking applies not only at the HTTP URI and query parameter level, but also to HTTP parameters, such as a SOAP Action or individual XPath expressions that must match the request headers or body. Aside from this white-list behavior, Service Gateways can enforce authentication based on credentials in carried in the message header, such as HTTP Basic Authentication or WS-Security and can also enforce fine-grained authorization based on a combination of a subject, resource and action.

A9 - Insufficient Transport Layer Protection

Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.

Service Gateway Mitigation: While transport level security in the form of SSL/TLS has been around for awhile, challenges remain with ensuring correct configuration, especially with respect to cipher-suite selection and chain of trust. Service Gateways shine here again as they also act as SSL acceleration and termination points with support for multiple SSL server and client identities. This means that SSL/TLS can be configured in the gateway once in front of existing applications, effectively offloading both the handshake and bulk data processing of the SSL protocol to the gateway. The benefit of this approach is not just performance, but it allows SSL/TLS to be decoupled from back-end application servers and centralizes the cipher suite selection, CA authentication policies and private key storage in a single place where there is less of a chance of misconfiguration

A10 - Unvalidated Redirects and Forwards

Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

Service Gateway Mitigation: This category of attack appears to be confined to web applications rather than services in general as the attack is based on a browser redirect. This type of phishing attack can fool a user into thinking a phishing site is a legitimate one and these types of redirects can be prevented by a systematic scan ('spidering') of the web application to look for pages that issue an HTTP redirect command (302-207). This process, however, can be time-consuming and such a scan must be done on all suspected web applications. Service Gateways can mitigate this type of attack in two ways. First, the redirect can be immediately trapped at the gateway itself, preventing it from ever reaching the user, and second, malicious content bearing URLs defined by a regular expression can be trapped when detected in certain parts of the content, such as an HTTP query parameter. In other words, if an application or service doesn't expect to have URLs in parts of it's content, the service gateway can actively scan for URLs and URL-like strings in query parameters and flag these as potential threats.

Conclusion

As we have seen, the OWASP top ten spans covers a large number of application vulnerabilities, and while we can do our best to protect against these at the application itself, this often becomes a practical limitation as the number and complexity of applications continues to grow within the Enterprise. Adding to this is the fact that security processing is tightly coupled to the application, making security policies difficult to audit, manage and change. Service Gateways can help protect against many of the OWASP threats by pulling security processing out of the application into a dedicated gateway where policies can be more easily managed by a security architect, not an application developer.

These bring together, the latest versions of Intel’s industry-leading C/C++ and Fortran compilers, performance and parallelism libraries, correctness analyzers and performance profilers to help improve application performance, code quality, and reliability. Above and beyond the features of Intel Parallel Studio XE 2011, Intel Cluster Studio includes capabilities for distributed memory programming using MPI.

In terms of prior products, these products are:

• Significant upgrades still focused on top performance for your applications.
• v12.0 – Intel’s latest C/C++ and Fortran compilers
• Updated MKL and IPP libraries (Intel^® Math Kernel Library and Intel^® Integrated Performance Primitives respectively)
• Update Intel^® MPI Library
• Intel^® VTune™ Amplifier XE is the new product name for the best VTune we’ve ever made! The performance tuning tool of choice for many, sports new features and completely reworked user interface based on our very popular Whatif.intel.com prototype known affectionately as “PTU.” The coolest new feature: “frame analysis”… we need a whole blog just on this feature – it is amazing!
• Debut of Linux versions of key innovations from the Intel Parallel Studio 2011, including: memory checking, and parallel programming models.
• Intel^® Inspector XE 2011 is the new product name for combining the groundbreaking Intel^® Thread Checker with memory checking capabilities.
• Intel^® Composer XE 2011, new product name for Intel^® Compiler Suite Professional Edition with the latest compiler and libraries from Intel
• Intel^® Trace Analyzer and Collector with enhancements. The new Ideal Interconnect Simulator helps figure find imbalances by simulating application behavior in the "ideal communication environment."
• Fortran includes the Microsoft Visual Studio shell (no need to buy Visual Studio again!), and the Intel^® Composer XE and Intel^® Amplifier XE work within that shell.

Many new features, highlights include:

• Intel^® Parallel Building Blocks (PBB)
  • solutions for parallel programming in C and C++
  • composable, interoperable solutions for task and data parallelism
  • explicit support for vectorization to utilize SIMD instructions including SSE and AVX
  • elegant new array notation, including elemental functions, for C and C++ programmers
  • solutions for multicore today and ready for many core programming tomorrow
  • includes version 3 of Intel^® Threading Building Blocks
  • includes Intel Cilk™ Plus support

• Support for AVX, tuned and ready for use. Being ready for AVX can be a big performance boost for applications!
• Frame analysis in VTune
• Threading error detection extended to cover .NET codes. So possible dead-locks and race conditions can now be detected even in .NET code.
• Co-array Fortran support – both node-level and distributed (via MPI).
• Standards tracking for C++ (0x) and Fortran (nearly all of Fortran 2003, key features of Fortran 2008 including coa-array)
• Static Security Analysis tool for tracking down more problems such as uninitialized data and buffer overflows.
• Support for the latest environments: Microsoft Visual Studio 2010 (while still supporting 2005 and 2008), Eclipse, Windows 7, and the latest Linux distributions.
• And, of course, updates to support the latest processors and processor features.  As always, striving to give the best performance of any compiler library – one Intel and compatibles.

We work to win business by striving to offer the best performance of any compiler or library, please let us know if you find we do not. Lawyers won’t allow me to guarantee we’ll fix it and always win, but the results speak for themselves. I’m confident you’ll find we can help the performance of your application. You can refer to optimization notice for more information regarding performance and optimization choices in Intel software products.

More information on these products, including how to get trial editions, can be found at intel.com/software/products.

Intel SOA Expressway provides sophisticated logging capabilities that allow the user to audit and trace any message sent or received through the system. This same facility is also used when debugging applications to see what went wrong. In this blog we will see how easy it is to investigate application failures using the transaction log and variable dumps. Expressway has seven levels of logging, and with transaction logs turned on, the full payload of data sent and received can be examined in detail. To get started, we will first create a simple workflow, run the application, and then inspect the debug output available for that application.

Create the application.
Let’s create the test application that performs a simple operation on an XML document. In this example we’ll take the input string and wrap it with an XML tag <Output>, like this:
Input string -> <Output>Input string</Output>
This simple application will make it easy for us to test the debugging capabilities of Expressway. In our example, we’ll create a simple application and deliberately send messages that will trigger errors to demonstrate debugging. To create the application, start Intel® Services Designer, select File -> New->Intel SOA Expressway Project in the main menu and give that project a name and choose the “simple application” type.

Initially, the new application consists of a workflow file (with .bpel extension), the WSDL file (web service declaration), and an XSD file (data type definitions used in both workflow and WSDL). The simple application template creates a workflow that contains only Receive and Reply actions. We’re going to add some logic between them to process the input. The WSDL created by the template will work fine for our application, so we’re going to leave it as is. The schema, however, created by the template is too simplistic for our case so we’ll change it a bit. Also we’ll add a data file for use in the application.

First, let’s modify the schema of the output message. For this application, we allow any XML content in it (<xsd:any>).

Second, let’s create the XML document that will be a template for output message, and save it in our project, in the same folder with Workflow and WSDL files.

Then, let’s add some logic to the workflow.

In this example we need to read the document contents to a variable. For the sake of simplicity, we’ll take a local document bundled with the application. To do this, pick Data->XML Builder from the palette, match the type to the output message’s type, and build an XPath expression with the extension function soae-xf:document() with the name of the XML document as a parameter. When we give the name “Template” to this action the new variable with the same name will be automatically created to store the result. You can see the XMLBuilder action between the Receive and Result in the following screen shot:

Next, we need to modify the document to produce the output message. To do this pick Data->Expression in the palette and place the action to the diagram. The expression action will hold the result. Type “Result” to the name box and then choose $Receive.payload expression in the expression pop-up. This tells the expression set to access the payload from the previous step. Finally, override the expression’s destination to $Template/Output, as shown below. This will modify the $Template variable, instead of creating a new variable.

In the last step we can choose the $Template variable to hold the reply. In cases where Expressway is acting as a proxy, the reply might be from a back-end server or partner web service, but for this example the reply is back to the sender without an additional service call.

To deploy the application right-click the project name in the project tree, choose Deploy As-> Intel SOAE Application in the pop-up menu, and then type the hostname name of the machine running SOAE Expressway.

Running the application
Once the application has deployed with no errors, it should be ready to receive messages – let’s send some through.
For sending messages I’m going to use the soapUI [1] tool which is a nice GPL tool for dealing with SOAP traffic Create a new project using SOAP UI using File->New->SOAPUI Project and set the initial WSDL to the WSDL from the Expressway application. You’ll need to choose an operation to invoke (there’s only one operation in our application). Once the WSDL is selected, soapUI will automatically create a valid input message for that operation, based on the WSDL.

In the raw request view I’ve typed “Hello” as the request content and changed the destination address. You can see this in the following picture:

You can press the green button on the toolbar to send the message and see the result.

Here is where things get interesting – the response message doesn’t contain “Hello” and shows an error instead. Let’s find out what happened.

Investigating the failure
First we’ll use the dashboard to get some basic information. The dashboard will allow is to instantly see if the request passed or failed. Next, we’re going to inspect the transaction logs and see what happened to the application.

Let’s open the management console and take a look at the dashboard: it shows that one request has recently failed.

To get more information we need to adjust the log levels and send one more message (by default, only high-level information is written to the logs). Under “Global Logs Levels” on the web interface we can set the “Workflow Engine” component level to TRACE, l which turns on the transaction logs.

Let’s send the message again and observe what happens. The transaction log will show a failed transaction:

You can drill-down into the failure by clicking the arrow to get more information. Here we can see the error message that we’ve received (“Uncaught BPEL fault…”) as well as additional trace entries just before the failure.

Open the log exception entry by clicking the “+” next to it. The error message tells that something’s wrong with the expression $Template/Output – it unexpectedly returned an empty node set.

Now let’s look through the previous log entries by clicking “<” button to find most recent variable values prior to the error.

We can see now that the Template variable really doesn’t contain the <Output> element. In order application we’ve tried to write some data to $Template/Output so its’ no surprise that the workflow engine ran into a problem.

Fix the bug and try again
The problem with the sample application was caused by the template for the output message. It’s loaded by the function soae-xf:document(), which was called in the XML Builder action (the Template action in our original application). To fix the problem, we should add an artificial root element to the XML document, as shown below. Once this is done, the XML Builder would work normally, as it strips the root element of the loaded document. Alternatively, we may also use an Expression action, which doesn’t strip the root element of the loaded document.

After modifying the application by adding an artificial root element we can redeploy it and send one more message.

This time the message is processed smoothly. The output looks good: the text “Hello” is wrapped with the <Output> element with the appropriate namespace declaration.

The dashboard also shows that the last request was processed successfully. The original failed requests are summed on the dashboard.

If we look at the logs, we’ll see that the transaction has completed successfully. The previous (failed) transaction is shown here as well.

The variable dump shows the output message. If you use the “” (next) buttons, you can see how the variables were modified during the workflow execution.

Summary
SOA Expressway provides the capabilities for detecting and troubleshooting application problems and bugs through the use of the transaction logs. If an error was detected, you can inspect the data being processed and see how the variables were changed at every step of execution of the workflow. For more information check out www.dynamicperimeter.com or www.intel.com/software/soae

[1] soapUI – www.soapui.org.

I know that you will want to catch at least one of Tim’s talk at SC10. Tim is talking Open MP and Open CL this year.  Here is where and when you can attend Tim talks.

About Tim Mattson

Tim Mattson earned a PhD. for his work on quantum molecular scattering theory (UCSC, 1985).  This was followed by a Post-doc at Caltech where he worked on the Caltech/JPL hypercubes.  Since then, he has held a number of commercial and academic positions with high performance computers as the common thread. Application areas have included mathematics libraries, exploration geophysics, computational chemistry, molecular biology, and bioinformatics. 

Dr. Mattson joined Intel in 1993. Among his many roles at Intel, he was applications manager for the ASCI Red Computer (the world’s first Tera-FLOP computer), helped create OpenMP, founded the Open Cluster Group, led the applications team for the first Tera-FLOP CPU (the 80 core terascale processor), launched Intel’s programs in computing for the Life Sciences, helped create OpenCL (a parallel programming framework for hybrid systems composed of CPUs, GPUs, and other processors), and was part of the team that created Intel’s 48 core SCC processor (the single chip cloud computer).

Currently, Dr. Mattson is a principal engineer in Intel’s Visual Applications Research Laboratory. He conducts research on performance modeling for future multi-core microprocessors and how different programming models map onto these systems.  This work builds on his two most recent books: Design Patterns in Parallel Programming (written with Professors Beverly Sanders and Berna Massingill) and Introduction to concurrency in programming languages (written with Matthew J. Sottile and Craig E Rasmussen).

One of possible use cases of SOA Expressway (www.dynamicperimeter.com) is rapid creation of such small support workflows. They are created in Services Designer using drag and drop. SOA Expressway can execute tens of such workflows at once - just add one more application to the active configuration and save it.

I'll show how to easily create a workflow that copies data from IBM Websphere MQ to MS SQL database.

1. Launch Services designer
2. Create an empty project
3. Create an empty workflow in this project
4. Add 'Receive' and 'SQL Statement' activities
5. Configure 'Receive'
1. Choose 'JMS' as transport protocol
2. Choose ‘No output (one-way)’ in Response data – we’re not doing to reply to JMS in this example
3. Configure other fields in JMS receive activity. For IBM Websphere MQ Initial context factory class should be 'com.ibm.mq.jms.context.WMQInitialContextFactory' . Other fields like queue name, connection factory name, JNDI URL are installation specific. You can choose an existing queue or create a new one using Websphere MQ Explorer.
4. If your Websphere MQ server requires additional connection parameters like MQCONTEXTMODE - put them to 'Optional custom parameters field'.
6. Configure SQL action
   1. Enter JDBC datasource name. You’ll have to configure datasource with this name in web interface of SOA Expressway. I’ll use ‘jdbc/mssql’.
   2. Write SQL statement to be executed, for example
      ‘insert into test(message) values (?)’ . Make sure that the target table exists and the query is valid.

   3. Add one parameter to the statement, choose ‘Xpath’ type and choose Xpath expression to be used as parameter value. To insert whole message received from JMS use ‘$Receive.body’

The resulted workflow will look like:

You’ll have to add vendor-specific .jar files to SOA Expressway before your workflow can communicate with third-party software like databases, JMS servers, etc. We have IBM message queue and Microsoft database so we should create 2 providers – one provider with client .jar files for Websphere, type = JMS and another – with client .jar files for MS SQL, type = JDBC. This should be done only once after SOA Expressway installation – you don’t have to upload those files again when you create a new or modify an existing workflow. This upload is done in ‘Configuration’ -> ‘System configuration’ menu in the Web interface. Choose ‘Providers’ -> ‘Add’, create provider named ‘websphere’ with type ‘JMS’ and upload all client .jar files corresponding to your Websphere MQ installation. After this create ‘mssql’ provider with type ‘JDBC’ and upload MS SQL client .jar file to it (for example, sqljdbc4.jar).
Now SOA Expressway is ready to work with IBM Websphere MQ and Microsoft SQL server. You can deploy your application directly from the Services Designer or export workflow from the Designer and upload it using web interface. In any case you’ll have to set up configuration in WI before the application actually starts working:

• Enter your JMS server’s host, port and user credentials in ‘JNDI properties section’ of Input Server
• Create JDBC recource with name ‘jdbc/mssql’ and put host, port, database name, database user name and password to it

That’s all. Now close and activate this configuration and data you put to the JMS queue will be transferred the to the database.
This example is intentionally made as simple as possible to make step-by-step instructions clear and not too boring. It can be extended in several ways:

• Make JMS input server not one-way, but two-way. In this case you can put result of database operation - success marker or newly created record ID to JMS reply queue
• Make interaction of JMS and database transactional. SOA Expressway supports XA transactions ( http://en.wikipedia.org/wiki/X/Open_XA ). In current workflow if a database error happens, JMS message is lost – it’s taken from the queue and is not put to the database. You can set ‘Enable XA’ flag in ‘Receive’ properties in the Services Designer and add ‘XA Commit’ activity to the end of workflow. In this case if database query fails, message will be returned to JMS queue and workflow will pick it up for processing later.

Let’s get real

Sceptical readers may think ‘OK, this all sounds good as usual in ads, but it doesn’t have anything common with setup I have at work’. Let’s add some complexity and security. Low level technical details are omitted – feel free to ask in comments.
I'll add modify this workflow:

• Put message from incoming queue to one of 2 queues based on its content
• Add SSL to JDBC connection

The modified workflow will be:

I've added:

• ‘if’ switch with expression ‘string($Receive.body) = 'BLACK'
• Insertion in one queue (BLACK_QUEUE) if this is true
• Insertion in another queue (WHITE_QUEUE) otherwise

Insertion into queue is ‘Invoke’ activity, request data is ‘$Request.body’, response data is ‘No output (one-way)’, all JMS connection parameters are same as in ‘Receive’ activity.
Save application and deploy it. If you think I’m cheating because I promised to add SSL – you’re really reading this, thank you. SSL connection is just configuration issue – we’ll configure it in the Web interface.
After you deployed application, edit JDBC datasource settings to enable SSL. Connection properties vary from vendor to vendor, for MS SQL use ‘encrypt=true;trustServerCertificate=true’ . If you set up this application using another database, find similar properties in manual. Save and activate application. Now if you put message ‘BLACK’ in incoming queue, it’ll be put to database and moved to ‘BLACK_QUEUE’, all other messages will be put to ‘WHITE_QUEUE’. How can you make sure that JDBC connection is really encrypted? You can just trust documentation – if it says that encryption is turned on with those parameters, it’ll work. If you don’t trust it like me – you can watch the traffic between the SOA Expressway host and the database host. If encryption is not enabled, you can see queries in plain text. If it is enabled, you don’t see any SQL expressions.

Happy escape from routine :)

Anyhow I did actually manage to get some work done and one of the things that struck me was how similar e invoicing integration issues are with banking and healthcare which the SOA Products group already has extensive experience of. the acronyms and standards change but the general method of solving the security and flexibility problems remains the same.

So here's some of the barriers to adoption or difficulties we’re facing:

• The big picture, each country has its own security, audit and legal requirements and during research I could not find 2 countries that approached e-invoicing exactly the same way.

• Heterogeneous environment doesn’t have the advantages or disadvantages of enforced transfer networks like banks with SWIFT.

• Advantages – a clear direction, good docs, security, reliability, assurance.

• Disadvantages – high cost, little flexibility, slow adaptation.

• Some companies find comfort in paper and others don’t feel they’re technically up-to-speed for e-invoicing especially small and medium enterprises.

And on top of these there’s security; always the necessary evil. Mainly a concern for large enterprises and service providers servicing SMEs. From the slide, generally the hard and fast requirements are  “Assurance/Compliance” & “Trust & Control” boxes.

“Perimeter Defence” and “External Threats” are best practices to protect confidential enterprise data that’s being exchanged. In effect they’re pretty much requirements as well.

Starting from the top we have the generation of signature. Should it be an Advanced signature or a Qualified digital signature? Does the the signing certificate need to be bound to the individual or the organisation because there are differing regulations for that in different countries.

Does your set of signing certificates fit in with your existing Certification Authority and public key infrastructure? Is the trust relationship there with other business systems & issuers? Can you deal with multiple types of authorisation including tying your e-Invoicing application into your organisations existing Single Sign On? The SSO and Certificate trust structure becomes important when you realise the need to maintain personal responsibility for the invoice with the individual who generated it.

Can you deal with multiple encryption types, especially when you start trading in another country and your existing e-Invoicing application does not provide support for the new cryptographic requirements?

With your external B2B and B2C trading partners you may have to have an internet facing service. Do you really want your e-invoicing or billing application to have to face issues like content attack and denial of service? All these add up to a headache that’s necessary for business continuity.

The advantage is that once this hurdle is passed there is little change required. Only additions to existing services.

Clearly there’s a requirement for flexible, generalised software tools like Service Gateways to apply some mediation and governance.

A Service Gateway is an obvious solution to tackling the difficulties above without recourse to excessive customisation of your existing e-Invoicing app which then leaves you with a point to point integration problem i.e. you have to start coding a lot of interfaces between formats, security token types, certificates, encryption routines etc. Always assuming your e-Invoicing application supports all of those that you wish to communicate with.

Because most or all of your security, certification and signing requirements are built into a Service Gateway like Intel® SOA Expressway you don't have to worry about different sets of capabilities for the multiple e-Invoicing apps you have in your own organisation and there's only one place you need to update when integrating externally, especially when billing between countries. As the Service Gateway seamlessly deals with routing and mediation for both format and protocol there are fewer integration worries. Indeed if you're part of a larger enterprise you may already have a Service Gateway that you can make use of.

For more in depth information, including seminars visit Dynamic Perimeter.com.

For example, a couple of weeks ago I held a conference call with a potential customer that wanted a demonstration of creating and deploying a SOA Expressway applications that, among other things, would interoperate with a JMS Message Queue. Utilizing an existing Message Queue in my lab, the entire time to build, deploy, and successfully test an application took just under 15 minutes!

Overview of the Process

Assuming you have a running JMS Message Queue and the client drivers needed to interact with it, here are the steps.

1. Using the web interface, the JMS client drivers are uploaded into a Java Provider which can be utilized by any application running in SOA Expressway.

   

2. In Services Designer, create a new workflow that utilizes an invoke step to a JMS Message Queue.

   

3. Supply the input to and JMS parameters the invocation step.

   

4. Export the application bundle an upload to SOA Expressway.

   

5. Supply the JMS credentials required for JNDI Lookup of the MQ Service.

   

6. Save or Activate the configuration the application was loaded to.

Additional Thoughts

SOA Expressway works with any standard JMS MQ provider. To date, I have personally configured SOA Expressway to work with Apache Active MQ, Websphere MQ, Sun Java System Message Queue, and Progress' Sonic MQ, all without a hitch. Customers have been really impressed on how easy it is to do, as well how powerful their applications become when integrated with other built-in services like JDBC, FTP, File, HTTPS, data transformation, etc. [The workflow illustration in step 2 above actually illustrates this.] My future posts will delve into these more, however, you can check out additional use cases right now! These use cases not only showcase SOA Expressway as an integration appliance, but as a Service Gateway, for SOA Edge Security, for Runtime Governance, a BPMS id Broker, Cross Domain Sharing, as a Cloud Gateway and much more! For additional information please see:

• www.dynamicperimeter.com
• SOA Expressway's Blog Site
• Ritu Kama's Blog Site

While a formal STS generally assumes WS-Trust aware clients and SOAE can support that, this need not be the case and imposes additional requirements on a lightweight client. Instead of a formal WS-Trust request, the client can pass a simple credential in the form of a username/password token and retrieve the proper token for the web service they are trying to access. As long as we are sticking with common standards such as HTTP, HTTP Basic Authentication and SSL, WS-Trust isn’t necessary for simple cases.  In the model proposed here, Expressway is acting as a STS used to broker the authentication between a lightweight client and web service requiring a SAML assertion.   

The STS is trusted by both the client and the service and it negotiates the authentication between the two.  The client trusts the STS and doesn’t need to apply additional processing on the returned SAML assertion. Instead, it invokes the target service and treats the assertion as opaque.

The following diagram shows how Expressway can be deployed as an STS:

In this scenario, the client initiates a token request to the STS (Expressway) along with their identity in an acceptable form, such as username and password. In this example, we are assuming client is sending a username/password token and trusts the STS over a one-way SSL connection. These requirements provide the minimum level of security required yet don’t impose onerous WS-Security or WS-Trust requirements on a lightweight client. The STS authenticates and validates the client’s credentials and issues a security token such as a SAML token back to the client. Generally as a good practice, the STS will sign the token to prevent token tampering after it was issued. The STS then sends the token back to the client. With the SAML assertion in hand, the lightweight client now forwards the web service request along with the trusted security token issued by the STS. The target Web Service validates the security token and confirms that the token was issued by trusted STS and sends the web service response if everything looks good.

As many of you are familiar with, SOA Expressway exposes an AAA action in Services Designer that can be used in your workflow to implement the functionality for SOAE to be a STS for your environment. AAA action provides a lot of flexibility in terms of different token types that are supported, e.g. HTTP Basic Authentication, UsernameToken, SSL certificate etc. We can configure SOAE to authenticate clients against a variety of Identity Management solutions supported such as Microsoft’s Active Directory, CA’s Site Minder or Oracle’s Identity Management products such as OIM and OAM. SOAE can then issue a token such as a SAML assertion, sign it and send it to the client. Client can then make the web service call with the token.

Following screenshot demonstrates our AAA policy with an example. In this example, SOAE, our STS is expecting a username and password in HTTP Basic Authentication header from the client. It will then authenticate the user with the LDAP server configured in the AAA policy. After client has been validated, SOAE will generate a SAML token and sign it before it is returned to the client.

The STS workflow is shown in the screenshot below.

• The Receive action is for SOAE to receive a HTTP request from the client with username and password in Basic Authentication header.
• The AAA Action invokes the AAA policy shown in Figure b using the client’s credentials and if the client is authenticated, creates a signed SAML assertion. The catch block is included in the workflow for Error Handling. It catches any authentication failures in the policy such as invalid credentials, missing credentials etc. In case of an authentication exception, SOAE returns 401 Unauthorized error back to the client.
• The Reply action returns the SAML assertion back to the client.

Hope you find this blog helpful. You can get more information on SOAE at www.dynamicperimeter.com and a great primer on STS is at msdn.microsoft.com/en-us/library/ff650503.aspx. Please feel free to send me your comments and suggestions.

For those not familiar with SOA Expressway extension functions, they are granular operations that can be performed on the contents of messages or XML / JSON documents which SOA Expressway can embed into XPath or XSLT. What they add up to is a Swiss Army Knife for doing all sorts of useful things, especially when SOA Expressway is used in some message mediation or security mediation capacity.

The range of functions encompasses:

• digest generation (MD5, SHA, etc.)
• exslt functions for dates and regular expressions.
• crypto and canonicalization.
• full digital signature generation and verification.
• encoding and decoding to binary, base64 etc.
• timestamping, UUID generation, random numbers.
• cookie and authentication token handling.
• MIME attachment get and set.

Okay I could go on; there were more than two hundred functions the last time I counted. Go to our site at www.dynamicperimeter.com and request the full documentation set to find out more.

So how does an extension function get used in everyday life?

Here's how to write a message to the transaction log from within your XSLT. I'm assuming you have constructed a basic workflow and already have an XSL Transform action within it.

The basic form would look like this:

<?xml version="1.0" encoding="ISO-8859-1"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" xmlns:soae-xf="http://www.intel.com/soae/xpath/">

    <xsl:variable name="log" select="soae-xf:write-transaction-log('info',concat('Transaction ID:  ',soae-xf:get-transaction-id(),'; Comment: ','test',';'))"/>

    <xsl:template match="/">

    <!-- The variable is parsed lazily and is only evaluated when it is used in the test below. -->

        <xsl:if test="$log"></xsl:if>

        <xsl:apply-templates />

    </xsl:template>

</xsl:stylesheet>

There are three parts to remember:
1, Make sure your transform has the soae-xf, exslt or soae-cache namespace declared as appropriate (shown in blue).
2, Declare your Extension Function with a variable. In this case $log (shown in green).
3, Do something with the variable to force the evaluation of the variable. In this case we test $log for some contents. This is a necessary step since one of the performance features of the XSLT engine is lazy parsing which eliminates the evaluation of variables which may turn out to be unnecessary.

Interoperation between the workflow variables and execution steps and the nitty gritty of XSLT is necessary because it gives the developer added flexibility when it comes to mediating messaging in a product that's used as a gateway or ESB.

This blog posting is about how to leverage an existing Identity Management asset such as Microsoft* Active Directory along with Intel® SOA Expressway in order to bring authentication and authorization to your Oracle* Fusion Middleware SOA implementation. This isn't to say that there isn't tremendous value in the Oracle* Identity Management suite of products or that what we're presenting here will obviate the need for a more robust Identity Management capability. That takes time to digest to the point of being able to implement, operate and manage in the scope of a larger enterprise SOA. Since there is standards based integration to all of Oracle* Fusion Middleware we will blog about many facets of leveraging Intel's SOA Expressway, a web services security gateway, in order to expose business services along with identity platform services for secure delivery. In this case we will show a few simple Microsoft* Active Directory Organizations and Groups that allow you to protect a BPEL Process with not only authentication but role and attribute based authorization. In the future we will also look at the third 'A' after Authentication and Authorization which is that of Accounting (or Audit) which is a critical part of enabling integrated governance.

Let's first have a look at our simple synchronous BPEL Process in Oracle* JDeveloper:

This BPEL process will make a call to the HR sample schema in an Oracle* Database. It will do so with the name of a Region from the Employee Details View in that schema:

Here are the input and output XSD types of the BPEL process itself which reflect the SQL query parameter as well as the return type from the database query:

Make sure you have deployed a JDBC configuration to Oracle* WebLogic that supports your JNDI name for the HR database lookup in your BPEL process. Here is a good blog on how to set up this item (using the first ~6 screen shots in the WebLogic Administration Console as a reference).

Now let's expose this Oracle* Fusion Middleware BPEL Process in our service gateway. Save the WSDL from the location shown in Oracle* Fusion Middleware Enterprise Manager (on the 'Test' tab of the deployed BPEL Process):

You will also need to update the reference to HR_Table.xsd in the WSDL (delete the highlighted text) and make sure that file is available along with the WSDL from your BPEL process:

In Intel SOAE Expressway Services Designer we will begin a project of type 'Service Proxy':

Now we can use the WSDL from our BPEL process to define what is to be proxied:

Then we'll use HTTP Basic Authentication with LDAP:

Before we get into our use case to tie these items together here is a screen shot of my Microsoft* Active Directory configuration with another tool next to it called JExplorer which can be handy for exploring the LDAP Directory Information Tree. It is very important to understand these basic LDAP types as Microsoft* Active Directory is based on LDAP (and referred to as LDAP from hereon since this could be any LDAP server as far as Intel SOA Expressway is concerned). The groups here are from data in the HR schema from the Oracle* Database:

Let's now update the ldap_auth.aaa (Authenticate, Authorize, Audit) object with the details needed to Authenticate to LDAP. We'll do that on the Identity Management tab of the ldap_auth.aaa object. I've created a user named 'Peter Hall' in LDAP and made him a member of Region->Europe and the Department->Human Resources group:

then Authorize access to the SOAE_HR service which we'll do on the Resource Authorization tab of the ldap_auth.aaa object:

We will use the variable %extracted-identity here to determine membership in the Human Resources group in
LDAP. You can use the same query in JExplorer to test that your LDAP will provide a return value. Once we're done with that we'll save the ldap_auth.aaa object and compile our project in Intel SOA Expressway Services Designer by exporting a bundle we can load onto the SOA Expressway runtime. We do this by navigating to Intel SOA Expressway->Export Application Bundle after right clicking on our project in Eclipse. At this time a dialogue box is presented:

This is telling us that we haven't yet generated our BPEL workflow for Intel SOA Expressway and clicking OK will do so automatically. Once done we now have our BPEL model that performs the service proxy functionality described in the ldap_auth.aaa object along with WSDL that we imported from our BPEL HR service:

We also have an export bundle that we can load into the Intel SOA Expressway runtime to test:

The important thing to do before making this Application active is to store the LDAP hostname and credential that will be used to bind to LDAP when executing the AAA step in our service proxy workflow. We start by editing the 'Invocation Agent' that will make the AAA calls to LDAP:

And entering our credential for the LDAP bind:

Now we will use the WSDL generated in our Intel SOA Expressway Services Designer to create a request in a SOAP testing tool like SOAPUI. We will need to provide our username and password, in my case it's peterhall and Password1, as a Base64 encoded variable in an HTTP Header called Authorization. Take your username:password and convert it with a tool such as this and put the string 'Basic ' in front of the result as seen here. You will also need to change the endpoint hostname in SOAPUI from the Oracle* BPEL Server referenced in the WSDL to the hostname for Intel SOA Expressway:

While this proxied request should succeed if everything is done correctly we haven't confirmed that Peter Hall, who says he is an authorized requestor of Human Resources data for Europe, should actually receive that data. In order to do that we'll create another AAA object in our project and utilize it for querying another branch in our LDAP for membership in the Region that was passed to the request. First we need to delete the template object that was generated from the original project so it doesn't try to regenerate existing workflows. You could continue to add security steps to the template to make the project creation of security workflow assets more automated but it is easier to watch the development process initially to gain understanding of what's being generated:

Now we'll open the BPEL process created for us in the previous steps and drag another AAA action from the Security palette to the right onto the BPEL workflow after our first AAA step. Finally select the new AAA object in the workflow by a single left click and in the bottom 'Properties' tab is a link to 'Create New Policy'. Accept the defaults and change the names to be more descriptive:

Now let's finish this up by Authorizing access to this particular set of HR data from the BPEL HR service by validating the Region attribute value passed in from the client request. We will continue to use %extracted-identity from the HTTP Basic Authentication for the LDAP query intersection with the Region OU:

We'll also add an 'If' control loop that compares the value returned from our LDAP query with that provided by the user:

In this simple case a user belongs to one and only one Region but there are logic constructs in BPEL to handle XML repeating groups converted to and from comma seperated lists. Here is our XSLT/XPath comparison for the 'If' control that will simply exit if the user has submitted a Region other than the one they belong to. In a production system we would generate a more meaningful message for error handling:

substring(substring-before(string($AAA3_InternalSecurityMetadata/soae-ab:aaaLDAPAuthorizationResponse/ldap:ExternLookupResponse/ldap:batchResponse/ldap:searchResponse/ldap:searchResultEntry/@dn),','),4,20)=string($Receive/soapenv:Body/hr:HRSelect_regionInputParameters/hr:region)

Once we've saved and re-deployed our application bundle we are now not only providing a means for the client to provide data about their Region to the service but also using LDAP search to Authorize that the authenticated user can see that data.

In this blog we've exposed the Identity Management functions necessary to Authenticate and Authorize our Oracle* Fusion Middleware BPEL HR service with LDAP and we've done so in a programmitic way that mimics the kinds of tasks developers perform for the creation of business logic. This enables a simpler, business oriented middleware stack while also enabling SOA developers to control the way their applications are secured at the edge of the network and providing enterprise architects ability to enforce how these policies are applied.

This is only a rudimentary use case here in terms of simple business rules and Oracle* Fusion Middleware itself, in fact one that could be performed with the ESB/Service Mediation capabilities of Intel SOA Expressway. However, this was to lay a foundation for the next blog posting on this subject where we will look at enabling the Oracle* BPEL Process Manager Human Workflow web services with SAML assertions on the Intel SOA Expressway service gateway in order to present stateful data persisted in the scope of business transactions with asynchronous services. Also between the template creation of the Intel SOA Expressway Services Designer project as well as the creation of the export bundle that serves as an archive of designtime and runtime we've uncovered some interesting possibilties that we will address in a future blog on service development lifecycle including configuration management.

To wrap up there are a number of challenges that await, impact somewhat unknown, in the scope of an SOA as it goes beyond the intial maturity spiral or recovers from a 'Big Bang' SOA that experienced varying degrees of success for adoption across the enterprise. One of those challenges that will indeed permeate the entire SOA lifecycle is that of Identity Management. The major enterprise application vendors (and smaller ones as well) have a wealth of tools for implementing a robust Identity Management strategy. However, factoring these products into an SOA that is attempting to move to the next level of maturity for offering services across an organization and potentially to the outside world as well, can be an arduous, potentially lengthy undertaking for a myriad of reasons. One of the most conspicuous of these reasons is how a set of common operation procedures will be reached that satisfies the risk inherent with managing identities that will have access to critical information systems such as those based on Oracle* Fusion Middleware. Since middleware suites like Oracle's are based largely on SOA there is a safe and easy way to expose these services to a larger audience as you realize the appetite for a broader Identity Management infrastructure over time. That way is Intel SOA Expressway which can not only leverage your existing enterprise Identity Management infrasructure like LDAP for authentication and authorization of Oracle* Fusion Middleware services but also offer a service oriented development patterned environment for these Identity Management operations that will become such a critical part of your enterprise SOA as you reach new levels of maturity.

If you'd like to sign up for an evaluation of SOA Expressway as a download or online you can do so here.

*Other names and brands may be claimed as the property of others.

In response, the SOA Expressway team has teed-up a special offer for Cisco customers looking to move to replacement XML Gateway.

This is an interesting development to be sure, and it probably signals that Cisco is seeing less demand for XML traffic than anticipated. Voice and video probably have taken over a larger share.

All this being said, I remember talking to a CTO at a major networking company (not Cisco) about 5 years ago about the proportion of XML traffic as a fraction of total Internet traffic, and while I forgot his name, I can't forget his comment which was something along the lines of: "90% percent of Internet traffic is spam and porn."

I wonder how much the proportion has changed in the last 5 years? Hopefully it is an upward trend :)

"Altova MapForce® 2010 is an award-winning any-to-any graphical data mapping, conversion, and integration tool that maps data between any combination of XML, database, flat file, EDI, Excel 2007+, XBRL, and/or Web service, then transforms data instantly or autogenerates royalty-free data integration code for the execution of recurrent conversions."

In case you weren't aware, SOA Expressway is remarkably extensible. In this post I will share with you my experience integrating MapForce's data mapping projects into SOA Expressway.

Use Case

Suppose there is a need to integrate legacy flat file delimited data into a web services orchestration within SOA Expressway. Since web services utilize XML for its payload, the legacy data needs to be converted to XML. Although SOA Expressway's Data Transformation services could easily transform the legacy data into XML required by web services, a MapForce data mapping project already exists that easily handles this XML conversion.

Because MapForce allows it's projects to be exported to external executable code, these data mapping projects don't necessarily have to be redeveloped by another integration appliance to be utilized by that appliance.

Using this feature to export Java code, MapForce data conversions can be directly integrated into SOA Expressway. SOA Expressway's Java Extensibility Guide (included in the product) outlines how to incorporate this code to build a customized "data-mapper".

Exporting the "data-mapper" to a Java plugin allows any application with SOA Expressway to utilize it.

Comments

This use case provides another demonstration of SOA Expressway working along side with other integration appliances. Even though SOA Expressway has the tools to directly work with legacy data and protocols, it is nice to know how easy extensible it is. MapForce is a solid product with a rich feature set. I found the Java code generated by MapForce very thorough, flexible (allowing for a variety of input and output formats), well commented, and with plenty of error and logging capability.

Interested in trying this out? You can download a 30-day evaluation of SOA Expressway from www.dynamicperimeter.com/download/SOAExpressway and if necessary an evaluation copy of MapForce from Altova's website.