Oracle Service Bus Reviews

We are doing lots of aggregation and routing – the two most important features that we are using it for – and transformation of the services and data.

I am using the latest version, 12.1.4. It's deployed on AWS cloud and on-prem. 

The routing and aggregation are the most valuable features. It's split and join.

I have been using it for two and a half years.

It's stable.

We are not using it on the container. It's a monolithic type of deployment on AWS, so obviously you won't have the scale of the containerized platform, but it's okay. I think with the 400 services, I haven't seen many issues. We have faced a problem with the heap memory side, but that is stable now.

I have also used TIBCO. It's difficult to manage, but it's a very robust product. You will not see any issues, but management of TIBCO is a challenge. You need expertise. In Oracle, you don't need a huge skillset, but if you talk about the robustness of the product, TIBCO is better. The performance of TIBCO is better compared to Oracle.

Deployment was easy. Sometimes, the API response is a problem if your payload is heavy.

We have a very huge project, almost 400 services. For developing support and services, it will take time.

We used our integration partner for deployment. Deployment wasn't a challenge, but creating the services takes time.

Oracle Service Bus is not a business application. It's a pure technical application, so there is no direct relation with ROI. It will help you to scale your application and orchestrate it, but it won't give you direct ROI because the nature of operating is different.

We have an unlimited yearly license.

I would rate this solution 7 out of 10.

The use case involves tasks such as determining the appropriate licensing size, collaborating on firewall projects, and constructing the infrastructure to support the product. In most cases, I focused on integrating Oracle Service Bus to address issues, primarily with local ISPs and one ISP in Colombia. For larger projects covering all offices in Colombia, as well as two or three other projects, my involvement extended to local ISPs in Buenos Aires, specifically with Firecorp, a service provider catering to various companies within the country.

Enhanced error-handling capabilities significantly boosted the reliability of our application, preventing crashes and ensuring high availability. For context, when dealing with critical services requiring 24/7 availability, we would often implement geographic replication and active-active modes. This setup ensured continuous operation, with one system seamlessly taking over in case of downtime. While automated processes are feasible today, we relied on monitoring tools to confirm operational status. Upon detection of any issues, the system would automatically switch to an alternate data center. Our architectural approach varied based on project requirements, prioritizing resilience and continuity. The distinction between traffic replication and backup lies in the time needed for restoration. By adhering to proper processes, both methods yield similar outcomes, with the primary difference being the time required for recovery.

It aids in ensuring compliance with industry standards and protocols, although I'm uncertain whether the server comes with any preconfigured compliance settings. In my experience, I've been involved in PCI compliance and SOX compliance for large companies, and while considering the brand is essential, compliance configuration often extends beyond the software running on the network. Compliance efforts primarily focus on securing access and safeguarding information within servers or databases, rather than on individual software tools.

The most valuable feature for addressing data transformation requirements varies depending on the different layers involved in an IT project. My expertise primarily lies in infrastructure aspects. Therefore, it's important to consider various factors such as project size, focus, and the hardware being utilized, along with its configuration. For instance, when discussing infrastructure, noteworthy features would include ICI or NSX, STM, and essentially anything related to ensuring optimal performance and cost-effectiveness while considering the overall impact on the budget.

There is significant room for improvement in the monitoring capabilities. Enhancing this aspect of our monitoring process is essential for effectively pinpointing the root cause of issues accurately and resolving issues in our system.

I have been working with it for approximately eight years.

The stability is consistently high, with only one notable issue encountered. I would rate it nine out of ten.

While it offers high scalability, it also presents a challenge due to its complexity. Our user base ranges from five thousand to thirty thousand, with one particular department in Argentina boasting over fifty thousand users, since it's one of the government departments. I would rate it seven out of ten.

We've contacted tech support a few times, and the experience has generally been satisfactory. Regarding issue resolution and root cause analysis, I would rate it nine out of ten. However, when it comes to the time taken to escalate to the appropriate engineer with the necessary expertise, I would rate it five out of ten.

Neutral

I've been involved in numerous projects spanning over twenty-five years. My experience ranges from implementing SAP solutions to integrating various data sources and operating systems. I've managed nationwide deployments using remote desktop solutions and utilized SQL Server extensively. Throughout my career, I've worked with diverse technology brands, databases, and operating systems, including hardware components from Cisco, and storage solutions from NetApp, EMC, and HP. While I haven't directly compared Oracle with other ESP products, one noticeable difference is pricing. Oracle products tend to be higher-priced options, which may impact budget considerations. Additionally, while Oracle offers robust features, it often requires a larger team of skilled professionals to manage effectively, which can further affect costs.

The initial setup is complex.

The number of people involved in deployment varies depending on the project's scale, ranging from one for smaller projects to four or five for larger ones. In my experience, significant deployments often entail multiple profiles. For instance, in the database aspect of a major project, installation, configuration, testing, and tuning phases are crucial. This process typically spans several stages, with additional tuning iterations even after transitioning to production.

The pricing is on the higher side. I would rate it ten out of ten.

My recommendation varies greatly depending on the specific context. Factors such as budget constraints, available personnel for system management, and geographical location play significant roles. It's crucial to consider the unique challenges and resources available in each country or region. For instance, hiring local talent in countries like Argentina, Brazil, or Colombia may present different challenges and salary considerations compared to the UK. Overall, I would rate it seven out of ten.

Its ease of use is valuable. It's very easy to use. It's no code/low code. Oracle Middleware products are also rich in adapters. 

It's stable. There aren't any bugs or issues.

If they can containerize this, that would be nice. If they can provide docker images and offer support for those containers, that would be great.

It's a stable product. Oracle purchased it from someone else, and it was already well-established. 

Its implementation depends on your skills. The more experience you have, the better designs or architecture you will have. The product might be the same, but the quality will vary based on how you implement it.

They are now moving towards the cloud. You have to evaluate what your requirements are and what your future strategies are. Based on that, you can go with an on-prem one or a cloud one. Nowadays, many products come with iPass, which is the lighter version or flavor of a product. The lighter flavors are for citizen developers, but if you want to do complex orchestration and build complex integrations, you definitely need a product like this with all the features available.

I'd rate Oracle Service Bus an eight out of ten. 

We use Oracle Service Bus to send data to ServiceNow because we needed to connect Salesforce to ServiceNow, so that's our use case for the solution.

What I like most about Oracle Service Bus is that you can use it for many integrations. For example, you can use it for on-premises to on-premises integrations, on-premises to cloud integrations, and cloud to on-premises integrations.

What needs improvement in Oracle Service Bus is the connectivity between adapters such as the Salesforce adapter and database adapters. The limited number of adapters compatible with Oracle Service Bus makes you want to switch to a different solution.

I have ten years of experience with Oracle Service Bus.

Oracle Service Bus has good stability. My company rarely has an issue with it. It's mostly stable.

Oracle Service Bus is a scalable solution.

Sometimes, we contact the Oracle Service Bus technical support team and they immediately assisted us with our issues.

The initial setup for Oracle Service Bus wasn't complex. You can easily install it. There wasn't any challenge with installing the solution.

The implementation strategy my company used was to install Oracle Service Bus via scripts, similar to a DevOps deployment.

We implemented Oracle Service Bus through an in-house team.

A different team handles the licensing for Oracle Service Bus, so I don't know how much it costs.

My company has almost a hundred customers, so it has a lot of users of Oracle Service Bus.

Only four people handle the deployment and maintenance of Oracle Service Bus.

I would recommend Oracle Service Bus to people who want to start using it because it could be used for a lot of cases and for a lot of integrations.

My rating for Oracle Service Bus is nine out of ten.

We use Oracle Service Bus in the business sector (B2B and B2C). The developers use Windows machines for development and CentOS is the current OS for test, preprod and production environments.
Our primary use case was to implement business processes that can use legacy services (Java, .Net, Package Software). The other main objective was to monitor and analyse our business processes.

This tool allows us to define our services precisely. Although the XML language and the duo of XSD and WSDL may seem cluttered and inflexible at first glance, it provides us with rigour in our development processes and in defining our services. By using a strict service contract, we were able to reduce the misunderstandings between the development teams and the maintenance costs of our project.

Oracle Service Bus is a comprehensive product with many useful features for defining business processes, a powerful mapper, an implementation with many connectors that make life easier.

We were able to easily implement business processes related to sales scenarios.

As I explained earlier, Oracle Service Bus focuses on orchestrating services, but also allows us to compose services. This allows us to improve the granularity of the orchestration.

We have been able to take advantage of the monitoring

The documentation is well done.

The product is heavy and requires many resources (CPU, hard disc, memory). The installation is lengthy and complex and looks like an installation from the 90s. The installation of a database (Oracle if possible) and Weblogic is also required.

Today Oracle offers a Docker image that could reduce the installation effort.

In development, we often do not have the equivalent of the machine we can use in production. Because of the resource requirements, it was difficult to test clustering and high availability on development.

II have been using Oracle Service Bus for about three years as an integration platform for various integration projects. started using Oracle Service Bus for approximately three years for different projects.

With respect to stability, the product is good.

Scalability suffers because this is a very large product. Everything is recorded, and everything is very strict at the technical level. For example, it keeps track of what name is linked to each transaction.

If you have a lot of money, then this is a scalable product.

Being an Oracle product, everything is recorded in a database. That means that there is a bottleneck in terms of scalability. 

We have between 10 and 20 developers working on this product. It is now in production but I can't easily estimate the total number of users.

We spent some time testing and found some problems with scalability. It can be difficult because when you test, you don't really simulate the behavior of the end-user. For example, people might generally use it in the morning but then one afternoon, everybody is using it and you don't know why. Ultimately, we had good test results but we were annoyed with the scalability.

We had some issues with support. It was a situation where we were under pressure and it took the technical support too long to reply and too long to solve our problem.

I am familiar with a few similar products such as TIBCO, webMethods, and OpenESB.

OpenESB is a similar product that is based on different technology. To scale OpenESB, you need to have a very large machine.

Deploying Oracle Service Bus is a bit rigid if you compare it with similar tools, like OpenESB. For example, when you deploy an application on Oracle, you can deploy a set of services. The important part is that the service is defined when you deploy it. This can be a problem because in some cases, you just want to expose the interface of the service so that it can be used by other services.

Assume that you have services A and B; with some products, you can develop service A without having service B on your system. You simply define a dummy B on your system and after that, you can deploy. This capability means that you have can many teams working concurrently and you can manage many different types of routines because you don't have to access the service itself. You only have to access the interface. However, Oracle Service Bus does not have this capability.

With respect to implementation, this is a very heavy product. It isn't something that is implemented in isolation. Rather, you have to have applications such as a database and an application server, in addition to the Oracle Service Bus itself.

The basic installation will take a day to complete. After that, you need the resources to run that type of software.

The deployment itself is very easy because you just have to install a service on the application server. 

Our in-house team was responsible for deployment but I was not there for all of it.

This is a very expensive product and the price varies depending on factors such as the number of processors and the number of users. Our licensing fees are approximately $300,000.

Depending on what other products you license from Oracle, you may have use of Oracle Service Bus. For example, if you use Oracle CRM then you have the right to use the Service Bus as well.

In a case like this, you have a good product, and you can save money on the license that can be put toward development, machines, and resources such as memory.

We target large companies that already have a regular license but if you have an SME or an average company with 100 people or less, then this product is not worth it because the cost is so high. Furthermore, you will be locked in with Oracle.

In summary, this is a very complete product and it works well for us.

I would rate this solution an eight out of ten.

I use Service Bus to integrate multiple applications at an enterprise level. I work in the telecom sector and we integrate multiple applications and build PRM and CRM inventory systems. We are customers of Oracle and I'm the integration lead. 

Service Bus supports multiple protocol technologies and web services as well as file-based integration. It's very good in JMS-based integration. Nowadays, web service calls are based on SOAP and REST. Service Bus integrates well with different types of these supported protocols and systems. It's great in XML web service integration although REST and JSON formats are more in use these days. 

Service Bus lacks two main elements. The first is accessibility with the REST services and JSON. These are things that are generally available in most of the APIs address space nowadays. The second would be improved cloud compatibility. Oracle sometimes lags behind when it comes to newer formats.

I've been using this solution for 10 years. 

Service Bus is quite stable. If you implement it according to the guidelines, then I think it's a very stable product and provides good performance. 

The solution does not support auto-scaling. Nowadays, you have Kubernetes for containerization. It can scale up and down based on the load and volume and is better than Service Bus. We have around 10 people using Service bus; the technical team, an engineer, and mid-level developers. 

The technical support is very helpful and generally knowledgeable. Occasionally you get someone who is less knowledgeable but most of the time, they're great.

Positive

The initial setup is relatively simple and straightforward. It's not difficult for a layman to implement, especially the cluster environment. Deployment in an enterprise-level environment requires some experience because there are some complexities. If you're implementing without having modeled the threading effectively, the service performance is reduced. It's not a product limitation, but more about how you implement it. 

The main difference I see between Service Bus and other solutions is the cloud. The newer products coming out are cloud-native. Service Bus lacks that because it was not initially on the cloud. It needs to be more cloud-native. 

This is a very stable and good product to use. It's essential to have sufficient knowledge around implementation and to deal with thread work management to get better performance. A lot comes with experience but before implementing, it's worth going to Oracle and studying the recommendations around implementation and integration. 

Some improvements are needed around some of the latest technologies and trends, so I rate this solution eight out of 10.

Oracle makes adapters that work with a ton of software, so it makes it a lot easier to integrate with other systems.

It is stable.

It's hard to find developers to work on it, and it's also very expensive to license in the cloud.

The pricing is high.

It's very complex and hard to learn. There's a steep learning curve.

The solution is complex to set up.

I've been using the solution for six or seven years. 

It's definitely stable. It's fast and it's definitely heavily supported. That's definitely something I would describe it as. The reliability and performance are good.

While it is not scalable in the cloud, it is scalable outside of that. 

We have 45 users on the solution currently.

Support is pretty fast and they do work to fix bugs in a timely manner.

I replaced this solution with a Red Hat product.

It's more mature than Red Hat. They have a whole process that you go through. If the bug is their fault, you'll get a fixed board within one to two days, which is great if it's a major issue. I'd say support is a little better than the Red Hat solution.

The initial setup is not straightforward. It's very complex. 

The cost of the solution is too high. I can't remember the exact pricing, however, it is extremely expensive. There are cheaper better solutions out there. 

We're just a customer or end-user.

I'd rate the solution five out of ten.

It becomes the platform for all managed file transfers. If you're looking at a high-speed managed file transfer or solution around that, it becomes a basic layer, or especially in use cases in payment gateways, or API-based types of solutions, probably this becomes a default there.

The solution will provide a visual view of your total process, which is where, and why it is stuck somewhere and probably where it is. You gain a real-time understanding of where the process is. The reporting around what is happening and if it is stuck, where it is stuck, and what actions to be taken is useful.

Overall, the solution is quite good and has lots of great features. There are always continuous improvements that are happening. 

The solution is quite expensive. 

It would be ideal if they could optimize it a bit. 

I've worked with Oracle for the last seven-and-a-half years.

Any new deployment I've seen has been stable. It's not a problem. There are no bugs or glitches and it doesn't crash or freeze. It's reliable. 

The solution is scalable. I've seen banking institutions use it and scale it quite well. 

If we are putting this up on the cloud, now they've released something similar to a support cost. They have to give us yearly support. You can actually buy the cloud credits probably if somebody wants to be on the cloud. However, normally you will get support, yearly support. What they've done is you buy back that support using Oracle cloud. With the cloud, you don't need support the way you do with the on-prem models. Support contracts are offered yearly with an annual subscription. 

When you need support, you raise a ticket. It's very simple. You follow up and send the logs. It's a long process. People may sometimes try to take Oracle Consulting Services which can also help with various types of things.

The initial setup process depends on project to project, however, typically, everything is paid for. Probably if you want to sell something, everything which is currently being sold in Oracle is specific to the cloud. If they want to move their on-prem to cloud, or they have services, free services, lift and shift services, and of course open-source. You name it and within a month maybe, or three months, depending on the type of job but other than that, everything is costed. Basically, everything, whatever resources you have to buy from Oracle is available and can be taken care of.

Any maintenance requirements are related to whatever package the client decides on. 

Oracle can deploy engineers to help with the deployment. 

This is a very, very expensive solution. It will cost a company a lot. 

It only is available on-premises; it is not subscription-based. These are perpetual licenses. Whether you take it to the cloud or not, with Oracle, you have to pay perpetual licensing. Oracle does not have the cloud as a subscription model.

This was a company that was acquired earlier, from DevLogic. Now people are asking for microservices-based architecture which currently is not an option. Especially, they use SOA services. Everything is not microservices-based architecture today. People who have been in banks, telcos, finance companies, even the government, those who have been using it for a long time, are the people probably who are the target audience right now. However, in the future, people are looking at types of services with architecture systems, which currently, SOA is not.

I'd rate the solution seven out of ten.