Share your experience using ibi iWay Service Manager

We are currently using the latest version of the IBM DataPower Gateway, 10.0.6.0.

We are using the IBM DataPower Gateway for authentication purposes. We also developed a firewall for our purposes. When we develop a web application and require security for that particular web application, we can use the IBM DataPower Gateway. We also use SOAP services. If we want to deploy on the IBM DataPower Gateway, then we can utilize it. It's also used for authentication and authorization. It also has a rate limiting feature. If we handle multiple loads on this server, then using the rate limit function, we can handle the traffic load and API traffic load.

We are currently using the IBM DataPower Gateway only for API purposes. If we have a rate-limiting purpose and we deploy multiple APIs, then an issue will occur on the IBM DataPower Gateway. A rate-limiting issue will occur. For that type of feature, we also require some support from IBM.

We are using the IBM DataPower Gateway for security purposes. As per the development perspective, there are some limitations with IBM DataPower Gateway because it only supports XML and XSLT language, but it does not support the Java language. This is the only limitation of the IBM DataPower Gateway. For the authentication and authorization purpose, we can use the IBM DataPower Gateway. It's a very good product.

We are mostly using the IBM DataPower Gateway for security purposes and load balancing purposes. If we are handling the load for a particular server, then we can use the IBM DataPower Gateway.

The IBM DataPower Gateway is mostly used for security purposes. If we have some APIs and we are using some security for those APIs, then we can use it. It can also be used as a load balancer. It's also used for certificate management, user management purposes, authentication, and authorization.

For routing, the IBM DataPower Gateway has multiple URL-based routing and content-based routing capabilities. If we have multiple URLs, then we can use an XML script. Using the XSLT language, we can configure multiple URLs and implement URL-based routing. Content-based routing means if we have multiple requests, we can route the request to a particular URL. For this, we need to use the XSLT language only. We can't use XML, Java, or other scripting languages.

With IBM DataPower Gateway, we are using all the APIs. All APIs have been configured on the gateway. We have configured the particular TLS profile and some TLS client profiles as well. Using that TLS profile, we have configured the APIs and authentication. We have configured some tokens also, including JWT tokens and different types of auth tokens. There is also a rate limiting feature which we use for handling API loads.

I have significant experience with the IBM DataPower Gateway. As a security product, it is very good. However, from the development perspective, it has limitations because it only supports the XSLT language. It does not support multiple languages. We can't modify it because this is a custom OS. We can't customize the given product. Whatever feature is available on the IBM DataPower Gateway, that feature is the only one we can use. If we require additional features, we can't configure them on the IBM DataPower Gateway.

We do not utilize IBM DataPower Gateway's caching capabilities.

I have been working on the IBM DataPower Gateway for the last 5.8 years.

For the IBM DataPower Gateway, if we require a production environment or a development environment, for production, we definitely require three nodes in the cluster node. Because if there is multiple traffic on a single node, then it will definitely cause some damage or issues will occur. If we have multiple nodes for the IBM DataPower Gateway, then it will handle the multiple traffic. For a development environment, only a single node will be enough to handle the traffic.

If we have multiple servers and a multiple cluster for the IBM DataPower Gateway, then there will be no issue handling the traffic. However, if we have multiple traffic and only a single node, then issues will definitely occur. IBM DataPower Gateway does not handle all the traffic on a single node. If we have multiple nodes, then they can handle a large amount of traffic.

At the VM level, we can modify the RAM and the hard disk. However, it will impact the server. IBM does not recommend increasing the resources to increase the scalability once you install the product. It will be very risky. Once you install the product, we can't scale the resources on the IBM DataPower Gateway. This is also a limitation of this product.

Before IBM DataPower Gateway, we had used some .NET services. We had deployed them on the particular platform. Once IBM DataPower Gateway came into the picture, we started using it only for security purposes.

The installation process is very easy. We require 18 GB RAM and a four CPU processor and one particular server. Using that server, you can install it easily. There is also IBM documentation available on Google. Using that documentation, you can easily install the IBM DataPower Gateway.

The installation requires some large resources. However, the installation is easy. If we face any issue, then the IBM team will be available for our support.

This product is definitely expensive because if any issue occurs in the live environment or production environment, and our organization faces some issue with the IBM DataPower Gateway, then the IBM team will provide support. That's why the product is expensive.

Regarding pricing, I don't have much information because my management team manages the licensing. In my point of view, I think it costs around 5 Crore in Indian Rupees.

We can use Apigee, which is one of Google's gateways. However, as per the security purpose and implementation purposes, IBM DataPower Gateway is a very good product for implementation and configuration purposes. Some other organizations are also using the Apigee product.

In the previous version, there were some limitations, but in the upgraded versions, IBM has fixed some bugs. Currently, we don't have many limitations. It only supports the XSLT language from a development perspective. It does not support Java or Python. Other than XSLT, the IBM DataPower Gateway does not support other languages. On a scale of 1-10, I would rate this solution a 7.

I used JBoss ESB for banking API and banking software. We created our own modules since banking APIs and banking applications require extensive security measures. Since banks handle sensitive financial data, the JBoss setup must be rock solid. JBoss ESB provides security parameters and enables HTTPS and TLS for the channels which can be disabled if needed.

JBoss ESB provides role-based access control (RBAC) and includes an admin console that can be used with CLI. I used Active Directory and LDAP, for which JBoss ESB has great support. JBoss ESB internally provides JAAS (Java Authentication and Authorization Service). It can easily provide security and we can sanitize logs. Without log sanitization, we cannot prevent data leaks such as CVV logs or PAN. When putting logs over a console, sometimes sensitive information is leaked through loggers in our code. We can sanitize the log without changing the code using JBoss ESB admin panels and CLI.

The most valuable feature is that JBoss ESB is maintained by Red Hat, providing long-term support and security patches every six months. It is tested and certified for enterprise service. Since I'm creating websites and portals completely on Jakarta EE for enterprise applications, this certification is crucial. JBoss ESB has excellent support, and troubleshooting is available 24/7 through Red Hat. It provides support for servlets, JSP for web applications, and distributed transactions.

For banking APIs handling asynchronous calls, it provides GMS messaging service. JBoss ESB also has strong support for JAX-RS, REST API, dependency injection through CDI, and bean validation.

JBoss ESB should focus on startup and performance as EAP is heavier than lightweight Java frameworks, which impacts microservices and cloud environments. Improvements should include faster start times and reduced memory footprints. Better cold-start performance in containers should be emphasized.

Cloud-native features must be enhanced since many enterprises are shifting to Kubernetes and OpenShift, making EAP more cloud-friendly. This could include providing smaller container images, native auto-scaling support, and improved integration with cloud configuration services. Enhancing the developer experience is crucial; while the current configuration is powerful, it can be complex for newcomers. As an experienced user, I navigate it easily, but newcomers struggle due to heavy reliance on XML configuration. Transitioning to a JSON-based configuration or YAML format would be beneficial, and simplifications in clustering setup for local testing would greatly assist users.

I have been working with Red Hat and JBoss ESB for more than six years. During my time at TCS, I worked with JBoss EAP 7 for banking API and banking applications.

The initial setup and deployment was relatively straightforward, although I faced a few challenges. When working on Java 8 and using EAP version 7, I downloaded it from the Red Hat customer portal. After that, I set up the environments for JBoss ESB, unzipped the version, and configured the home variables along with its path in the bin.

I encountered some issues when creating the management user, which is required in JBoss ESB. However, after reading the documentation, I easily resolved it, creating one and later working with JBoss ESB standalone. Overall, it is simpler and does not present much complexity, even for newcomers in IT.

JBoss ESB performs exceptionally well in terms of stability and reliability. The reliability features include session replication, clustering, and failover, along with transaction recovery, which offers robust built-in recovery for incomplete transactions even post-crash or restart. Clustering failover automatically transfers control to another node in the cluster if one JBoss ESB node fails.

Session replication ensures user data isn't lost during server failures as web sessions are stored on multiple nodes. In terms of stability, compliance with Jakarta and Java EE standards using standardized APIs reduces complexity issues. The long-term support provided alongside Red Hat's memory management and tested configurations are key aspects. Most importantly, controlled version updates are applied on a schedule, helping avoid sudden disruptions, especially when code is in production and not publicly updated automatically.

I implemented JBoss ESB's clustering feature for our banking website and APIs where high availability was required. Clustering JBoss ESB means multiple application server instances work together as one logical server. I added more servers to handle loads to provide good latency and throughput. They provide excellent load balancing through Apache HTTP server plus mod cluster, recommended by Red Hat.

The dynamic node discovery feature eliminates the need to maintain manual lists of nodes. They provide automatic lists using dynamic node discovery, which intelligently provides load distribution based on node health. We can replicate sessions, distribute modes, and ensure failure readiness. With more than five microservices, JBoss ESB provides good throughput and failure-over readiness.

The technical support and customer service for JBoss ESB is primarily focused on security fixes and patches. When deploying code, it should contain dependencies considered as common vulnerabilities and exposures patches. I experienced issues with existing vulnerabilities in log4j, which was highly critical. I raised a ticket and received a call from Red Hat, who provided documentation on resolving the vulnerabilities.

The Red Hat Security Advisory (RHSA) team checked my EAP version to determine if CVE affected my installation. They introduced me to OpenSCAP, a security scanning tool for JBoss ESB vulnerabilities, and provided guidance through server.log files to resolve these issues. Based on my experience with the technical support, I rate them 10 out of 10.

Positive

I was involved in the initial setup and deployment of JBoss ESB.

I am currently using JBoss ESB as an end user. I chose JBoss ESB because it is excellent for open source Java, Java EE, and Jakarta applications. Initially developed by JBoss, it was later acquired by Red Hat. I have used WildFly up to UAT and dev server, but the paid version is JBoss ESB.

The most important aspect I appreciate is that it provides implicit and explicit dependencies, allowing developers to focus on business logic rather than dependency management. My review rating for JBoss ESB is 10 out of 10.