Oracle Service Bus Reviews

We are an IT solution provider and this is one of the products that we implement for our clients. We have competencies in different ESB products including Mulesoft ESB, Oracle Service Bus, and Microsoft BizTalk. 

The most valuable feature is the adapters.

This solution can be easily integrated.

The reporting is very good.

This solution would benefit from having more cloud-based adapters. 

I am a solution architect and while my background is mostly in Microsoft solutions, I am familiar with the Oracle products as well. Our company has dedicated teams that are specialized in many different solutions. The choice is driven by the client. For example, if a customer mostly has Oracle products then that is the solution that we implement.

This client for Oracle Service Bus was having trouble with point-to-point integrations, so everything was being done at the back end and it affected the ability to do jobs. This is the reason that they adopted this solution.

The initial setup is a little bit complex. One of the ways it is complex is that there are a lot of features and the customer may not want all of them. Once you figure out which ones the customer doesn't want, they have to be disabled.

The price of this solution is better than the subscription-based Mule ESB.

Mule ESB is another solution that we have a dedicated team for and a lot of experience with. It is very powerful and we felt that in this particular scenario, Oracle had an edge. Mule out-of-the-box is missing a lot of features that Oracle has, and we see this year that Oracle is getting much better than Mule.

Another reason that Oracle was selected over Mule ESB is because of the pricing.

The suitability of this solution depends on the customer's environment and requirements. For situations where they are many integration points, whether they are on-premises or in the cloud, this is a good solution.

Overall, this is a good solution from the user's perspective, but it is a little bit complex to manage.

I would rate this solution a nine out of ten.

I use this solution for development with complex integration.

This product is not complicated and very easy to learn.

Integrating this solution with other technologies is not difficult.

There are times when I select components in composite and they do not appear, and I cannot figure out why. This can happen when you develop a big project and clone it, then look for a service. Sometimes, you cannot find your work. It's a big problem.

This solution is stable, although sometimes we see some strange behavior in the developer, where some parts do not appear. In cases like this, we need to reset.

I have not contacted technical support.

Prior to this solution, we used Java and Java Brains suite. Using Java is more complicated, and these things are taken care of by Oracle Service Bus.

Overall, this product is quite good and I feel comfortable when I use it.

I would rate this solution a nine out of ten.

Integration. Writing of services. It's a proxy layer.

It helps in building reusable, well-defined services. 

It is lightweight and one can easily integrate with different applications, databases, JMS, or Web services through different protocols. 

It needs to support more adapters, because the integration points keep changing and new things keep coming up. It also needs to be more scalable.

Stability is very good.

I have seen that it is able to perform under high-load transactions. It was very good at supporting high transactions, up to 300 transactions per second. That requires more servers, obviously.

Sometimes we have issues, so we'll raise them with Oracle. I would say their support rates eight out of 10.

It needs some knowledge of different artifacts and you also need to have some knowledge of Web servers, the application server, something about the database; at least some knowledge. It is not very difficult and not easy. I would put it somewhere between easy and medium complexity.

When selecting a vendor, at least from the architecture and the developer's standpoints, looking at the implementation and scalability are the two most important things.

Oracle provides good documentation, look through that. This solution is advisable when you need some kind of layer in between, so that it acts as middleware for different systems. That's where you will need to use this.

• It’s a lightweight tool compared to Oracle BPEL
• The design of the product.

Because it can handle JSON inputs, we can now use JSON.

The logging and error-handling framework can be improved.

Usage of DVMs, MDS and other additional features that are possible in XSLT in BPEL are missing in this product.

I have used it for the past three years and I am satisfied with it.

There were no issues with deployment; it was very straightforward.

I have not encountered any stability issues. The product is highly stable.

I have not encountered any scalability issues. The product is highly scalable.

Technical support is 3 out of 5; availability of materials and support related to OSB 11g is less commonly available.

Even though we had been using Oracle BPEL, we had to go with Oracle Service Bus because it is able to handle JSON inputs. We tried to implement one scenario using Oracle BPEL but couldn’t achieve it in BPEL, so we had to go for OSB and were amazed by its flexibility in accepting incoming messages.

Initial setup involves a learning curve; it’s not as straightforward as Oracle BPEL. For example, defining custom variables, assigning and replacing different activities is a bit intriguing compared to BPEL.

We implemented it through Zensar. Their level of expertise is 4 out of 5.

ROI is not tangible, but we have benefited highly from this product.

I heard it’s available free with Oracle SOA Suite 11g, so don’t worry about additional licensing costs for this product.

Before choosing this product, we did not evaluate other options. We only explored different Oracle alternatives.

It is a very lightweight product and has great processing speeds.

It's sort of a one-stop shop for web services. All of our web services interact with each other. Instead of calling specific server host names and specific URLs, we call the OSB service bus URL that's configured for that specific client. It's very simple to know where things are going because we can generate the URL specifically with our naming convention, so that we know where it goes, who's calling it, what environment it's for.

With the most recent version, 12c, I'm still getting use to using it, learning how to use it, how to configure it. The Oracle documentation is OK, but there aren’t a lot of good examples for me to follow. It describes the concepts and what it can do, but how to apply them has been a struggle, so far. I'm still looking for help in that area.

I have been using it for at least eight years.

It is very stable. It processes hundreds of thousands of transactions per month. Once, with our primary system for handling customers coming into our site for orders and order information, the customer would come in and send an email to our internal users; that crashed our Exchange server but OSB kept running. It was fine. It's very stable and it has to be for what it does. It's kind of like a load balancer in a way; if it goes down, then everything behind it will stop operating.

It can meet our scaling needs moving forward. I would be surprised to see it have a problem with scalability.

Technical support is OK. We know what to expect from Oracle support. You're going to ask a question. Generally, you're provided with a document: "Check out this support doc. Does this answer your question?" If it doesn't right away, then they'll take a closer look.

It's OK. It's not ideal, but after working with it for so many years, I know what to expect out of it.

Initial setup is pretty straightforward for an Oracle product. Again, we know what to expect with it and it works well.

When I select a vendor to work with, I look for reliability and ease of use. Performance is everything and this has proven itself over the years. That's why we keep using it.

This solution can be used for internal connectivity between enterprise applications and a Telco client.

I like the ease of deployment and the ease of implementation.

The support for GraphQL needs to be improved, and the response time for global support could be faster.

We have been implementing this solution for more than eight years.

It's a stable product. There are no issues with stability.

It's a scalable solution.

We have three customers who are using this solution.

Local support is very fast, but if you have to escalate the ticket to the global team it takes a lot of time. It could be time-consuming.

Global support response time could be faster.

The initial setup is straightforward.

It took me an hour and a half to install.

We have a team of five including one manager, and four engineers to maintain this solution. 

I completed the installation myself.

I would recommend this solution for large enterprises.

I would rate Oracle Service Bus a nine out of ten.

We use Service Bus to expose our service endpoints.

Service Bus is good at routing and transformation. 

The weak point of OSB is that it is not suitable for modern application implementation like microservices which need smart endpoints. With a dumb pipe through and rest API or lightweight message, Bus is not. 

I've used Service Bus for one or two years.

For a microservices solution, we preferred to use rest APIs and a lightweight message Bus such as Kafka or RabbitMQ for integration.

I rate Oracle Service Bus six out of 10. OSB isn't suitable for working with modern applications. We can use it for a monolithic application, not in microservices techniques.