Some Q&A on SOA

Q: What are the differences in managing SOA applications compared to traditional applications?

A: SOA applications are comprised of component services that do not reside in one area of responsibility. So there have to be clear Service Level Agreements in place to make such an application manageable. Also, clear and unambiguous monitoring and error detection needs to be in place, lest service support groups pass the buck on where problems truly reside.


Q: What new technical challenges do these applications bring?

A: Many developers are not familiar with asychnronicity. Even though multithreading has been around for decades, not many truly have a multithreaded mind. Such asynchronous thinking is fundamental in understanding and managing SOA applications.

Also, the design of, and designing with services is quite different from building a traditional, monolithic application. In the latter, events happen in a predefined order: the program flow. With SOA applications, this order is not fixed. Therefore, a service must not rely on events to happen in a certain order for it to function properly, it must be idempotent.

Another challenge is the concept of marshalling and unmarshalling. Too easily is precious processing time wasted on inefficient serialization and deserialization schemes. Developers must now learn to think about how services can communicate most efficiently. And, unlike using APIs, that may not be by making frequent, granular calls, lugging large objects around.


Q: What are the challenges in troubleshooting performance problems with these applications?

A: Actually, diagnosing and remediating performance problems is much easier with SOA applications. Let’s assume that such an application is entirely made up of Web services (SOAP over HTTP). Each of these services can be invoked independently, in their deployment environment. Using simple test clients, performance problems can rapidly be narrowed down to specific services. The underperforming services can then be improved either through coding, faster hardware or load-balancing.

The real challenge with SOA apps is solving timing problems. This is especially true in asynchronous high-speed environments (thousands of messages per second). If services are not written to cope with differing sequences of events, they will yield different results with different sequences.


Q: How much work is involved in integrating management of these applications with traditional applications?

A: Technically, the amount of work depends on how application-management-savvy an organization is. If they already have outfitted their current applications with management agents, then doing so with services will feel quite natural. If not, then managing services will be a learning curve.

Organizationally, however, a transformation will be needed to build, support and use business-oriented services. The traditional silos of responsibility and accountability will no longer suffice and a much more collaborative environment will have to emerge. This requires unwavering attention and support for SOA from IT management and a modified


Q: What are some of the areas that companies tend to overlook?

A: Popular misconceptions about SOA are:

• SOA means installing some web services
• SOA is synchronous, request-reply
• SOA is expensive to undertake
• It takes a long time to see any ROI from an SOA effort
• It’s a or a suite of products
• It’s a turnkey solution
• It’s just EAI
• It’s a technology solution to a technology problem
• Our organization doesn’t have to change to embrace SOA