• contact@isoagroup.com
  • (707) 773-1198
Welcome to our Blog

Blog / News

DataPower Gateway & Why You Want One!

Before we even get into what a DataPower Gateway is, let’s begin by discussing what a “gateway” is, how they differ and why you could potentially want another.

First, a “gateway” is simply a device that joins together two different networks. In the most common scenario, your enterprise networks with the Internet. A router is an example of a gateway device. It directs and decides where information packets are sent.

Another term to understand regards a firewall. A firewall is a filter that examines said packets, against a set of defined rules, in order to decide whether to allow the packets access.  Your security and infrastructure team go to great lengths to ensure firewalls are implemented to prevent unwanted access to your network(s).

Finally, a DataPower gateway is a hybrid implementation of the network components (the gateway + a firewall) just mentioned.  It is not meant to replace those components, but to supplement them with a specialized application layer (i.e., Layer 7) protocol.  The application layer allows your enterprise to implement specialized application services, and DataPower provides additional security that routers and firewalls do not.

So, what does a DataPower Gateway provide that the other network devices don’t do well (or at all) and why are they important to your company?

Here are a few features you can achieve through DataPower:

1.     Wire speed XML Parsing

Extensible Markup Language (XML) has been around for quite some time and is used to represent the data exchanged between multiple parties.  XML provides a tagged method to identify data elements so that you, your partners, and customers can exchange XML documents as a way to share data.

The problem with XML is not all information passed in an XML document is always needed.  To be as efficient as possible, it is a good practice to “starve” the data elements down to just that which you require.  The way of filtering these fields is called “parsing”.  Parsing in application servers is slow.  Load balancing the requests, in order to perform a task to meet a specified service level, becomes necessary when you encounter large volumes of parsing. This can lead to even larger server farms, more administration (backups, fix-packs, etc.) and increased hardware/software costs.

DataPower has a special, built-in XML parsing chipset designed to parse at the speed-of-the-wire, vastly outperforming server based parsing.  This specialized application feature is what makes DataPower stand out from the other previous mentioned devices.

If you are already using multiple servers to load balance parsing of XML traffic, you should consider routing those transaction through DataPower and apply your parsing on the “wire”. If you could reduce the effort spent on supporting the server farm, while simultaneously reducing your costs, what are you waiting for? It’s faster to ride in a car than ride a bicycle.

2.     Authentication/Authorization and token switching

Gateways primarily reside on the edge of the network.  That is an optimal location to perform authentication and authorization.  Not only does DataPower integrate with many authentication/authorization servers, but it can also switch the authentication tokens to another format (i.e., basic authentication to Kerberos).  Being that DataPower is standards-based, it works with pretty much any authentication mechanism.  If your authentication/authorization server is not available out-of-the-box, you can also accomplish the integration using a custom stylesheet.  This feature makes DataPower a powerful gateway addition.

3.     Advanced Security Implementation

DataPower provides enhanced security to implementations, such as Layer 7.  For instance, DataPower has a built-in, specialized ability to encrypt and decrypt at the speed-of-the-wire, meaning you can apply encryption to the XML payload.  You have the ability to sign with digital certificates, as well as verify signatures from other partners’ payload.  Plus, DataPower can also perform 2-factor authentication using a variety of methods.

Another very common use of DataPower is to use it to manage SSL/TLS.  Since DataPower can live in a DMZ, on the edge of the network, it’s best to establish the security there, instead of letting it pass through to your backend servers.

Finally, DataPower provides XML threat protection and SQL injection filtering that other devices or applications are incapable of performing.

There are many more security features in DataPower, but these are just a few to highlight, but remember you are merely scratching the surface.

Takeaway/Action Item

  • Take the time to investigate your DataPower implementation to see if you are taking full advantage of the features.
  • DataPower is a secure appliance. Involve your architects and security teams to ensure you are maximizing your investment.
  • If you are considering publishing API’s, you will need a powerful gateway.

Want to know more? Contact iSOA Group at info@isoagroup.com.

Does your DataPower Implementation Support These 4 Key Features?

Is your DataPower implementation supporting your corporate security?

The right implementation will be agile, secure and efficient.  Depending on who, and how long ago, the DataPower Gateways were implemented, you might find these key features are missing.

And, don’t forget how agility in implementing your services through the Gateway allows your company to deliver products to customers quickly.  Winning business and protecting your assets will help you sleep at night.

So, does your DataPower Gateway have these key features?

Here is what you should look for:

1.     Logging information to your SIEM (eg. QRadar)

Security plays an important part in your DataPower configurations by identifying and protecting you against threats.  While DataPower finds these threats and acts appropriately to keep your company protected, it’s a best practice to configure a Log Target to output the messages to your company SIEM (Security Information and Event  Management).

2.     Repeatable Agile Framework to speed implementations

Configuring DataPower doesn’t require programming, which makes it very agile in providing capabilities in a short time.  To improve the agility even more, you can configure an Agile Framework that will allow you to build new services, faster, and adhere to standards with little fuss.   If you aren’t using a custom framework you are probably doing more work than necessary by replicating similar configurations that cause more ongoing maintenance.

3.     Utilizing DataPower’s threat protection

DataPower comes out of the box with built-in threat protection for your XML payloads.  There are additional configurable protection methods that guard against Denial of Service and SQL Injections, to name a few.  You can even add virus protection as part of your DataPower configuration.  Since these features are readily available out-of-the-box, ensure you turn them on.

4.     Wire speed transformations

Who doesn’t want the fastest processing of XML parsing?  DataPower has a built in XML Parser that will parse at “Wire speed”.  If you are using multiple servers to load balance parsing of XML traffic, you should consider routing those transactions through DataPower and apply your parser on the “Wire”.  You can reduce the effort to support the server farm, improve the speed for parsing XML messages, all while saving money (always a good thing!).


Takeaway & Action Items:

  • Take the time, regularly, to investigate your DataPower implementation to see if you are taking full advantage of the all features of DataPower, inlcuding new features in updates of the firmware from IBM.
  • DataPower is a secure appliance. Involve your architects and security teams to ensure you maximize  your return on you DataPower investment.
  • Consider a DataPower Advisor to review your implementation, share best practices, and assure you keep up-to-date on all of the latest DataPower features, including acting as an API Gateway.


Want to know more? Contact iSOA Group at info@isoagroup.com.

Expert’s Corner: When to Use DataPower XSLT vs. Gateway Script

In April 2014, IBM introduced a new Scripting Language to customize and configure DataPower for deployment based on Javascript.  This introduced a new approach, beyond XSLT, and also opened up the ability to leverage Javascript skills common in the marketplace.

Our trusted advisors did some research on when to use XSLT vs. Gateway Script:

IBM continues to upgrade GWS (GatewayScript) with each firmware release. Initially, it lacked some of the extension functions that are provided for in the XSL functions.

They are now pretty much have caught up, with a few exceptions, primarily in the various protocols that are supported in URL-open extensions. What they have done with GWS is add a lot of JSON capabilities and security updates for JSON (JWE, JWK, JWT). GWS is more traditional programming versus XSLT’s template model. It is much easier to handle things like setting up conditionals or loops. Output messages to the log are as simple as typing: console.debug (“accessCount = %i, accessCount); You can still use a combination of XSL and GWS in a service policy. Also, you have a debugger in GWS which means now you can step through your GWS code. You can build functions in GWS, which is much easier than writing call-template or apply-templates. E.G., Var PO = producePurchaseOrder (bookOrder, booksDB). You can also execute GWS from dynamic content and run it out of the temporary folder. From a performance standpoint, GWS is a secure and optimized Javascript. It is probably a shade slower since you cannot take advantage of the XML chip on physical DataPower appliances, but many folks on virtual appliances won’t have that option anyway.

Bottom line is as follows:

  1. If you are new to XSLT and have javascript skills, go with GWS.
  2. If you have existing XSLT written and need to perform specialized scripts that are easier to do in a traditional javascript, go right ahead. Example might be some calculations or date manipulation.
  3. If you want to use more of the latest JSON capabilities, using GWS makes it easier because JSON is just javascript notations.
  4. You can also check out the store:/// folder for examples of GWS.
  5. If you are dealing with XML transformation and are familiar with XPATH, then it’s OK to use XSLT.

Want to know more? Contact iSOA Group at info@isoagroup.com.

Expert’s Corner: Is DataPower a Firewall or a Layer 7 Protocol Proxy?

When discussing the capabilities of DataPower with colleagues, the topic of routing capabilities of the DataPower appliance often comes up.  It may seem convenient, at first, to compare it to a firewall, but it actually behaves much differently.   Keeping a clear understand of its behavior and how it handles routing of messages is important, as you determine the correct architecture and use cases for deployment.

DataPower operates almost exclusively as a non-transparent, Layer 7 protocol proxy, handling only an explicit number of protocols, such as HTTP (HTTPS) and FTP (FTPS). While it may appear that DataPower passes data, or messages, from one network segment to another, messages are actually terminated on the inbound TCP connection, introspecting message based data, and then a separate and distinct TCP connection is created from the device to a destination host.


Unlike Router/Firewalls, DataPower devices DO NOT route IP packets directly. They employ a high degree of interface isolation which is controlled by the configuration set in DataPower, but they will not connect two network segments for random protocols.

A protocol specific proxy service (XML Firewall, Multiprotocol Gateway, WS-Proxy, etc.) must be configured on the device in order to pass any data through said device, to a destination host.

For some supported protocol types – namely asynchronous messaging protocols such as IBM MQ Series™, IBMʼs WebSphere Messaging Engine™, or Tibcoʼs EMS™ protocol – the device does not act as a protocol proxy at all, but instead is responsible for establishing TCP level connections to support both the ingress and egress message path associated with an integration service.

Want to know more? Contact iSOA Group at info@isoagroup.com.

Expert’s Corner: When to Use an NFS Hard vs. Soft Mount

If you are connecting your gateway to an NFS file system, there are two options for how to mount it.

  1. A soft mount, which means that the application, or gateway, connection will attempt to mount the drive and once connected, will start to process the file. If for some reason the gateway cannot reach the file system after a period set by the nfstimeout parameter, then it will receive an error. However, if the file system goes down during the transaction, the transaction will stop and there may be some data corruption.  The advantage of a soft mount is that it has minimal impact on gateway performance; a disadvantage is the potential for data corruption.
  2. A hard mount; once the gateway is connected to the file system it is more of a “hard connection”, meaning that the gateway or server will continue to attempt to reconnect if the file system is unreachable. Once reached, it will continue the transaction, assuring the integrity of the system and data. The advantage is that data integrity and messaging is assured; the disadvantage is there is a performance impact with the constant connection.

We recommend a soft mount when the data integrity is not as critical and therefore your application, or gateway, will know there was an error in the connection.  As an example – a backup that was interrupted and not completed.   We recommend a hard mount when data integrity and the need to complete a transaction is of utmost importance.

If you would like to speak with an iSOA Trusted Advisor or engage our team for assistance please email us at info@isoagroup.com, or call us at 707-773-1198

Want to know more? Contact iSOA Group at info@isoagroup.com.

Expert’s Corner: When to Use PKIX vs. Exact Match for Certificate Validation


DataPower, as many other gateways, can validate certificates via different standards depending on your requirements, as well as those of the systems, partners, and clients that will need to be secure as you are exchanging information.

As an example, DataPower supports three different “validation modes”; the command to set the validation mode:

  1. cert-validation-mode legacy: This mode is maintained for backwards compatibility. This is where validation credentials contain the exact peer certificate to match, or the certificate of the immediate issuer. These might be an intermediate CA or a root CA.
  2. cert-validation-mode pkix:  The complete certificate chain is checked, from subject to root, with this validation credential for certificate validation.
  3. cert-validation-mode exact-match: The validation credentials contain the exact peer certificate to match.

Choosing which mode to standardize on may be a challenge depending on the industry and your security needs, but as a best practice, we recommend using PKIX.

When using PKIX, DataPower will verify that the client certificate is either matched exactly in the certificate list, or that a complete signer chain from the incoming cert, all the way to the root certificate authority, can be established. Since this is your primary method for verifying client identity, you should ensure that it is fully validated.

PKIX implies that you understand the signers of the clients. You need to include all the intermediates and root signer certificates. If you don’t, DataPower will reject the connection.

For more information for DataPower users, we recommend this link in the IBM Knowledge Center

If you would like to speak with an iSOA Trusted Advisor or engage our team for assistance please email us at info@isoagroup.com, or call us at 707-773-1198.

Want to know more? Contact iSOA Group at info@isoagroup.com.

Expert’s Corner: Introducing Technical Advice from iSOA Professionals

Welcome to iSOA Group’s Expert’s Corner.

In addition to launching our new website, we are excited to announce another valuable service – the Expert’s Corner. iSOA Group’s trusted advisers are leaders in our industry and, as such, have a wealth of knowledge at their disposal. And, as the Dalai Lama said, “Share your knowledge. It is a way to achieve immortality.”  Whether you are new to IBM’s DataPower© or CA’s API Gateway©, a long time operator, or a newbie developer, we hope you will find our Expert’s Corner of interest.

Topics will range from discussing the pros and cons of NFS with DataPower, when to use Exact Match or PKIX for authentication, or some “tips and tricks” from our Gateway Consultants. Less fluff, more stuff!

If you have questions on, or suggestions for, a post, please email us at social@isoagroup.com. We are always looking to provide relevant content to our readers!

Want to know more? Contact iSOA Group at info@isoagroup.com.

Learning in Las Vegas: iSOA’s Insights and Observations from Interconnect 2017

iSOA Group, Inc. rolled out our very own red carpet to capture attendees’ minds and share our vision of the foundation for digital innovation.
We started the week prior to Interconnect by rolling out our new website; launched with our continued focus on helping companies build a secure, flexible, and integrated foundation for digital innovation.

During Interconnect, we focused not only on informing prospects and partners of iSOA’s strengths, but also on our own education in the latest industry trends and IBM offerings.  We were also a sponsor, with a pedestal in the Hybrid Cloud Test Drive section of the concourse.

Our CTO, Bryon Kataoka, shared the stage with two clients in breakout sessions.  1) With Cuna, which concentrated on migration of DataPower to I
BM’s API Connect, and 2) with Quest Diagnostics on the implementation of a strategic SOA solution.  Slides of those sessions are available for download, below:

Move from IBM DataPower to IBM API Connect with Custom User Policies; Guidance from Cuna

Quest Diagnostics: From Strategy to Implementation with Our SOA Strategy

Brian Silverman, iSOA Group Sales and Marketing Leader, led a Lightening Talk in the IBM Hybrid Cloud Integration booth centered on API’s as a foundation for standardization of infrastructure and security.

From a learning perspective, the iSOA team found IBM’s Interconnect agenda and content insightful and innovative.  A few highlights from our team are include:

Bryon Kataoka presenting at Interconnect ’17

  • Sherlock Holmes was right, it is “elementary, my dear Watson”, as IBM’s Watson and cognitive computing were at the center of keynotes, the solution expo, and presentations throughout the event. From language translation, to emotional awareness and energized bots, to integrated weather forecasting, IBM’s Watson was at the center of the conference and positioned as a leader in the cognitive AI space. IBM did not just highlight this, but also in announcements including the exciting partnership with Salesforce and their Watson-powered AI offering, Einstein.
  • Watson capabilities are accessible via API’s on IBM’s Bluemix platform-as-a-service (PAAS) platform, enabling companies to include services such as language translation, and helping companies enable their own applications and bots.
  • Yes, API’s and API management were a hot topic of their own. Not just in our own presentation with Cuna, but in numerous sessions on different use cases and the capability of IBM’s API Connect solution. Our team attended many of the breakouts, swhere many  were standing room only.
  • Cloud and hybrid cloud are not just a trend – it is the norm. Did you know that analysts estimate most companies have more than 5 cloud providers?  It isn’t too hard to get your head around that if you think of the different services available for infrastructure, application platforms, and cloud based applications.  The key, as we have been promoting for years, is the need to have a hybrid integration framework that enables flexibility and trust across cloud and on-premise systems and applications.
  • Finally, looking to the future, Blockchain is more than just bitcoin turned on its side. Blockchain and IBM’s focus is on the hyper ledger standard supporting a new approach for companies to securely share trusted transactional information in a productive manner. From a few companies, to many around the globe, all sharing the same trusted information.  The example in Monday’s keynote was tracking diamonds, and their authenticity, to assure value and reduce the black market for stolen gems.

Look for more insights from our team in our soon to be launched Expert’s Corner and CTO Insights.

Interested in learning more?  Please reach out to Brian Silverman at bsilverman@isoagroup.com or contact our office at 707-773-1198.

Want to know more? Contact iSOA Group at info@isoagroup.com.

iSOA Interconnect 2017 Hybrid Cloud Integration Session Recommendations – Follow Up

As a continuation of our last post (link) that listed our recommendations on API Connect sessions to attend at Interconnect 2017, below we provide our suggestions on hybrid cloud integration and IBM’s integration solutions presentations that will be worth attending. Read more

Want to know more? Contact iSOA Group at info@isoagroup.com.

Follow iSOA to IBM’s Interconnect: API Management Session Recommendations

Interconnect 2017 is just around the corner and with so many great session topics, it may be difficult to decide which to attend. With our recent focus on API management, we wanted to share a few API themed recommendations to include in your schedule.
Read more

Want to know more? Contact iSOA Group at info@isoagroup.com.