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.
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.
The solution is primarily used for the ESB. When we want to integrate applications with each other, they want to communicate with each other, we use this. If one application wants to send a message to some other applications. It's used for transformation and integration.
The solution is very stable.
The scalability is very good.
The installation is quite straightforward.
We've been pleased with the level of technical support.
The pricing of the product could be better. It's a bit high.
We started using the solution around 2014. We've used it for quite a few years now. It's been a while.
The solution is stable. There are no bugs or glitches. It doesn't crash or freeze. It's reliable.
The scalability is very good. If a company needs to expand it, it can do so. It's not a problem.
Due to the fact that the solution is technical, there are not that many people on it. We are only a few specialized people that work on this ESB. In development, there are around five to seven people. They are a mix of engineers, managers, and admins.
Technical support has been good. We're satisfied with the level of service on offer.
The initial setup is very straightforward and simple. It's not overly complex or difficult to implement.
In our systems, we install it for our local development. It's easy for us. It takes minutes to install it. The deployment process is quick.
We have five or six technical people that can handle deployment and maintenance tasks.
The pricing could be better.
We pay for the solution on a yearly basis.
The product is a part of the Fusion Middleware. We have the full suite including the SOA and WebLogic.
I'd rate the solution at a nine out of ten.
If a company wants to go to the Oracle stack, I'd recommend this solution. If a company wants to use it, it should first evaluate their requirements and whether they need to expand or if they have the capacity.
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.
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.
The middleware provides the service from our core banking and manages the equipment from the satellite system to the core banking SMS or to any other system. Any system can communicate to another system through the solution.
The most valuable feature is the monitoring feature, where we can track the web's UI development.
The tracing. Some unknown errors will sometimes happen and the error message isn't clear. The security process to protect the servers also needs improvement. Sometimes, you need to open the whole project and complete another setup in the server, then hurry back and go through the service application to complete the security setup. If Oracle SB had one button to complete this process in one step, it would be better.
For the next update, I'd like to see event-driven architecture.
I've been using Oracle Service Bus for five years.
The solution is stable.
It's easy to scale mostly from the Oracle side. We added another node in the cluster but we haven't yet tried it.
When we've contacted support, they haven't always resolved the issue. We've then tried from our end to find a workaround and ended up finding a solution. Their support service could be improved.
The setup was simple and deployment was managed on my own. It took only a few minutes.
I would give this solution a seven out of ten. My advice is to be aware of the amount of space to collect all the requirements because sometimes, maintenance on existing setups can rebuild the servers from the beginning.
I'm an integration architect and we're a customer of Oracle.
What's valuable is the ability to master the process in one location. That's the main difference between other firewall products and this. Usually, there's an issue when you want to integrate many services together because you can't save contacts in one place. For example, if you have A, that calls B, that calls C, that calls D, there's no place to store your contacts and that's a problem. We can do that with Oracle.
The main inconvenience is the composition between services. Using software initiation, occupation with BPM, or BPI is better. There are issues, especially if you want to create some compensation in your service bin. If you have six or seven services you call in the same process, it's very difficult and that's the main issue. I get compensation with the WBS tool.
Another point relates to monitoring. When you want to show what's happened in your system, you have to deploy a direct system on each service. It's simple to put the monitoring on your BPM and that's the main difference for me. Also, connectors can be on Apache Kafka, on Oracle, or OpenESB, or on Mule, it's the same thing. It's how you execute the process. For example, OpenESB support is the difference between the interface with the service and the implementation. Oracle is more intelligent. When you want to invoke a service B, for example, you don't directly invoke service B but ask the system for the best and most accurate implementation of B for your system and it provides that. You can't do that with a simple ESB.
For additional features, if I compare OpenESB, there is the possibility to define policy between services so that when you create a connection, you can't associate the connection with the policy. That could be included in the solution.
I've been using the product for a year.
It's a stable solution.
I have no problems with the scalability, but when you define the hierarchies there can be problems.
We've never used technical support, we have our own tech team within the company.
Implementation took a few weeks, no more. It was relatively simple I believe but I'm not an expert on deployment and installation.
This is a good product, not an exceptional product. You could say it's a bit greedy as it requires lots of additional resources because you have to deploy the database and then ESB on top of that. But if you have the resources and people, it's a good product.
I would rate this product seven out of 10.
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.