High Performance Extensible Logging
0 Comments | Posted by Martin Potočnik in SOA-IBM on 2 November 2011
HPEL or High Performance Extensible Logging is a new feature of IBM WebSphere Application Server version 8.0. It provides efficient logging and tracing utilities for storing and accessing log, trace, system.err and system.out data. It is an alternative to java.util.logging logger that was used as a logging utility on WAS.
HPEL stores and processes log and trace records in a binary form which is the main reason for its efficiency. As you can see in the figure below (source IBM Publib), primarily HPEL engine forwards streams into two repositories (log and trace). Text format is also supported but should be disabled when performance is a key concern.
If we want to use HPEL we must firstly enable it and secondly configure it.
Business Object deserialization from remote XML file over HTTP on WAS Part 2
3 Comments | Posted by Martin Potočnik in SOA, SOA-IBM on 10 June 2011
In this post we continue with BO deserialization of a remote XML file over HTTP. In the previous part (if you haven’t read the first part, I strongly suggest you do so) we have statically set the HTTP endpoint (binding on HTTP Import) to the XML file on the HTTP server (http://localhost:8080/NewCustomer.xml). Since this approach is not useful we will illustrate how to use a mediation component to dynamically set the XML file endpoint. If we briefly take a look at our getCustomer operation we can see it has an input field (string) through which we will set the XML file location (endpoint):

Our assembly diagram now look like this:
![]()
It contains a mediation and HTTP Import; both have the same interface (CustomerInterface). We will set (override) the endpoint in the mediation flow – request flow looks like this:

It has a HTTP Header Setter and a Trace mediation primitives. HTTP Header Setter mediation primitive can be used for changing, copying, adding and deleting HTTP headers. In our case we will dynamically override the endpoint with value provided by the input message. We must add a new HTTP Header Element and set it like this:
- Mode: Create
- Header Name: DynamicOverrideURL
- XPath Value (we read a value from input message): body/getCustomer/input
Trace mediation primitive is used only for tracing the message (so we can see it in the console). Message looks like this:

If we take a look at HTTPHeader we can see the DynamicOverrideURL element which contains our endpoint url (http://localhost:8080/NewCustomer.xml) that we propagated through input string.
So, that’s the end of BO deserialization from remote XML file over HTTP on WAS. I hope it was informative and helpful.
Project interchange ZIP can be found here and the XML file is here.
New Certificates for SOA and Cloud
0 Comments | Posted by Martin Potočnik in Cloud Computing, IMPACT, News, SOA, SOA-IBM on 19 April 2011
Our team gained new competences at IBM’s Impact 2011 conference! Matej Hertiš was recognized as IBM Certified Solution Advisor for Cloud Computing and Martin Potočnik was recognized as IBM Certified SOA Associate.
![]() |
![]() |
Business Object deserialization from remote XML file over HTTP on WAS Part 1
1 Comment | Posted by Martin Potočnik in SOA, SOA-IBM on 28 March 2011
Let’s say you need to convert data from a remote XML file (located on a remote server) into business object. In our scenario we have a Customer business object (schema) and CustomerInterface which are defined like this:

Input parameter will be used in part 2 and will define XML file URL. In this part XML file URL will be statically configured. Output is a Customer business object that we need in our service or process.
On the server we have the following XML file:

So how to deserialize data form a remote XML file into a business object over HTTP?
The most elegant solution is to use HTTP Import component (HTTP binding overview can be found here):
- Make sure remote XML file is accessible and valid.
- Create a HTTP Import Service with an interface (more info).
- In the properties window of HTTP Import component we must define:
- Endpoint URL (XML file URL in our case)
- HTTP version and method
- Default data format handler – we will use UTF8XMLDataHandler (more info). It converts UTF-8 encoded XML data into business object and vice versa.
- In the Method Bindings section you can also set: data serialization data handlers (for input and output), HTTP Header (character set, media type, etc.), HTTP Proxy, Security and Performance (read timeout and number of retries). In our case we will leave the default settings.
When endpoint URL and proper data handlers (UTF8XMLDataHanler in our case) are configured, we can test our component. Content of the input message is irrelevant since endpoint URL is statically configured. Let’s see the result:

We have successfully deserialized a Customer business object from a remote XML file. In part 2, we will include mediation component that will allow us to dynamically set endpoint URL for the XML file.





