In a recent Webinar, ebizQ explored the fundamentals of developing SOA applications, with the benefit of the expertise of Ted Farrell, chief architect of application development tools for Oracle Corporation. Farrell most notably discussed service-oriented architectures as a way of changing the way we think about building software.

With SOA, “We’re able to actually break them down into smaller pieces and manage them separately,” he said. “This allows us to start versioning or updating certain pieces of our infrastructure without needing everything to move with it,” Farrell said. For an immediate replay of the Webinar, click here: http://www.ebizq.net/webinars/5266.html

Farrell discussed the overwhelming need for such flexibility and manageability in our business environment. “In an ideal world, we would be able to build all our applications from scratch, being completely in control of all the different architectures and how they work together. But in the real world, that’s not how it works. Even if we get the opportunity to start building a piece of it from scratch, we still have to integrate with applications that already exist, and we end up writing a bunch of glue code, to kind of piece the process and data together,” he explained.

The problem with writing a lot of ‘glue’ or integration code, Farrell said, is that it is very fragile. “This makes for a very brittle environment and it’s something that’s very hard to manage,” he said.

With a service-oriented architecture, Farrell identified several benefits. “You decouple interface from implementation, and that allows you to not worry about the details of back-end implementation.” Also, SOA allows for loosely coupled interfaces and multi-channeled access across numerous tiers.

Other benefits that Farrell identified include better orchestration, which separates the application flow from the back-end services; SOA also makes for a looser relationship and more flexibility between services. In general, SOA allows for better process flow, Farrell said. It also allows for data mapping and transformation, and encourages rather than discourages continual small changes to your application environment, instead of the current way of doing things, which usually enable “only very large changes every year, 18 months or two years,” Farrell said.

Farrell shared several more aspects to building SOA Applications, including: