Dust off those ESBs and SOA solutions — they’re headed to the cloud. This month, two major vendors, Oracle and Red Hat, announced that they are updating their SOA solutions to support cloud integration.https://o1.qnsr.com/log/p.gif?;n=203;c=204663295;s=11915;x=7936;f=201904081034270;u=j;z=TIMESTAMP;a=20410779;e=i
And to think, only a few weeks ago we were pondering whether APIs, for all intents and purposes, are the equivalent of SOAs.
Oracle will launch a new family of cloud adapters to run on the Oracle SOA Suite 11g platform. That’s the same platform used for on-premise integration and services now. Predictably enough, the first adapter is for Salesforce.com, but plans are to support other SaaS solutions as well.
But that’s hardly the main selling point here. No, the big deal is what Oracle Vice President for Product Management Demed L’Her calls Oracle’s “unified integration” vision.
This architectural change means enterprises will need only one middleware stack to solve both cloud and on-premise integration. Essentially, the Oracle Cloud Adapters are architected to run alongside Oracle’s existing set of intelligent adapters used for on-premise integration, D’Her told Integration Developer News. In turn, that means integrators and developers will need to learn how to use only one tool for both types of integration.
That may make life easier for IT, he said, which often struggles to keep up with the multiple integration solutions needed to connect with different cloud applications.
“We know cloud applications are growing and here to stay, but having to adopt two different middlewares is not the right approach, we believe,” D’Her is quoted as saying. “Our number one goal is to make these adapters for SaaS look to the development group exactly like those for on-premises integration.”
Shortly after Oracle’s announcement, Red Hat released JBoss Fuse Service Works 6, which is a commercial release that will compete with Oracle SOA Suite and the IBM Integration Bus, according to PC World.
While we don’t hear a lot about SOA these days, it’s an approach that could be useful as more companies move tasks to the cloud, Sameer Parulkar, Red Hat principle product marketing manager for JBoss integration products, told PC World.
“As workloads move from on-premise to cloud, they still need integrations between different endpoints,” Parulkar said.
The wording in articles and the Red Hat press release is a bit tricky, though. While Oracle outright says how its new approach will support cloud, Red Hat is a bit more circumspect, repeatedly saying JBoss Fuse Service Works “sets the stage for…” cloud and mobile application integration.
“The diverse and interdependent nature of today’s business services ecosystems requires more than simple service orchestration—integration, governance and monitoring are crucial for supporting the needs of the business,” Craig Muzilla, senior vice president, Applications Platform Products Group at Red Hat, said in a prepared statement featured on MarketWatch. “JBoss Fuse Service Works sets the stage for faster and easier cloud, mobile application and business process development and integration by providing a comprehensive offering that allows IT to simplify service-enabling of existing and new applications and data.”
So what does this all mean? I’m not sure. Perhaps this is just an API management add-on. As enterprise architect Todd Biske recently pointed out in a TechTarget column (requires registration), in one case, you’re managing services; in another, it’s interfaces. But management features are not exactly an exciting selling point, he adds.
Biske also highlights one significant difference between SOA and API that may shed some light on how closely SOA and API management are related:
One key feature API management tooling has embraced that was not prominent in the SOA architecture heyday is that of identity token provisioning. It's one thing to have a fully documented API that allows a consuming system to be coded, but are you going to use a service that has an API for getting identity tokens that allows you to run as fast as you can go, or one that requires your team to wait four weeks for a manual process?