Is SOA the next evolution in software products?

http://blog.open4businessonline.com/2014/11/soa-at-core-of-products.html

Explorer 4 Business Network

SOA Fundamentals Course on Udemy

I am producing a course for Udemy called "SOA Fundamentals".  Here is the Introduction...

The course will cover a Glossary of Service Oriented Computing and Service Oriented Architecutre terms, concepts, design patterns on the technical side and the SOA Manifesto, Strategic Goals and Software Development Lifecycle on the business and management side.

The course will be about 6 or 7 lectures and a list of references.

The course will include as one of the primary teaching tools, a comprehensive exam on the fundamentals that will prepare the students for one of the SOA Certification exams from Oracle, IBM, Zapthing or SOASchools.

Service Oriented Architecture is the basis for O4IPaaS and many of the examples in the course will be based on application of O4IPaaS tools and principles, as well as the major Vendor's products like IBM Message Broker, WSRR, and Open Source products like Mule.

Enjoy!

MO

Why is a Service Oriented Architecture critical to an Integration Platform

As Lead Architect for the Smart Communications Service Oriented Architecture Center of Excellence, part of my job has been to educate the various departments, their architects, designers and developers on the merits and techniques for success in a migration to a Service Oriented Architecture.

At O4BO we have a new division called O4IPaaS.com for our Integration Platform as a Service.  We fully follow the SOA Manifesto 

Recently we had an excellent example of why SOA can be critical to a business.  One of our clients is using our O4SaaS solutions and our Portal.  They had a major upgrade to a legacy financial package they had largely developed in house many years ago.

This financial application was large with many modules and included multiple data sources, user input, batch processing, and 3rd party software.  Many of the original developers both internally and externally that worked on the previous version are no longer available (even permanently, i.e. death) so making changes to the code to just keep up with changing regulations was and still is a nightmare.

One such change required before the end of the year (I won't get into more details or blame) was deployed over this last weekend in off peak times, and while initial testing mirrored the testing on staging and everyone was set to go live on Monday....within hours of live production use with users, some problems started to show.  Initially it was thought to be just a configuration problem but correcting the configuration (heap size) problem and a restart did NOT solve the problem, it just moved the problem down the flow to another module.

It took until the end of the week to isolate and correct the problems(2).  Was it because there was inadequate planning?  Was it because there was inferior staff?  Was it some other reason?  You know what I think?  I think that while the specific defect was obviously a human error, poor testing or no testing at all, but THAT was the result of the monolithic non service oriented tightly coupled architecture of the application as a whole.

Imagine that same application that same flow, that same business logic, that same database and essentially the same interfaces.  Now look at the UML sequence diagram below.

With a tightly coupled architecture each of these swim lanes corresponds to a method or module within the application.  Because they are tightly coupled, any change to any one of them can have ripples across the entire application.

Now take that same sequence diagram and change those swim lanes into separate services with a JMS interface in and out and a very thin orchestration application that did the routing and potentially transformation of the message as it flowed through the system.  These "Atomic Services" can be discreet applications in themselves with a JMS inbound queue it watches and an outbound queue it writes to.  The data format can be well defined and could be XML or JSON (or anything really).  These small discreet application services can change at a moment's notice, be deployed hot, and tested in place with test queues.

Because these Atomic Services are smaller they follow the separation of concerns principle and typically do ONE THING, and do it well.  Once that service is fully tested it may never need to be touched again.  With a little forethought even minor changes to the payload or other services may not even require changes to any other atomic service.

In the case of the week long very costly and very painful deployment of an upgrade a look at the changes needed show a very large and complex UML sequence diagram, but those changes would be in just two swim lanes.  If the application was SOA then just those two Atomic Services would need to be changed.  They could be changed in a few hours and tested much more thoroughly and with test queues they could be tested right alongside the live services and with a good orchestration engine the new versions could be gradually phased in by financial group over time until the old service could simply be removed.

Just ask one of the consultants that did 117 hours of billable time or the department head that had to pay for that time, whether he things a SOA would be a good thing.

We at O4BO/O4IPaaS have at our heart, a Service Oriented Architeture based on an Enterprise Service Bus that is event driven.  We have an intelligent Context Aware Rules Engine that does dynamic application orchestration, and we have tools for wrapping any API in Atomic Services so they may participate in a SOA migration.  You can start by using us ONLINE as a Service, then migrate to your own cloud or migrate your applications to our Cloud or anyplace in between.