Generational SOA

Posted by Mark Little on Apr 02, 2008 10:27 AM

Community

SOA

Topics

Loose Coupling

Tags

SOA Adoption

Since it hit the top of the hype curve people have been saying that SOA principles have been around for a long time before SOA was popularized. Loose coupling as an approach for distributed systems and EAI has frequently been compared to the software pattern of late binding. Software development principles and practices have continuously evolved over the decades, often in a very Darwinian approach. We've had generational programming languages, such as Fifth Generational Languages like Prolog, and now according to Kirstan Vandersluis, founder and chief scientist of XAware, we should recognize the fact that we've gone through at least four generations of architectural approaches based on Services.

Across industries, smart architects have been exposing functionality as reusable services [for years]. This got me thinking about the how service oriented architectures have been evolving over the years. Those of us working to expand capabilities in SOA tooling have recognized that services and SOA have been around far longer than the "web service standards" that have made SOA so popular over the last few years. It is apparent that in the software industry, we have gone through phases of maturity in our service-oriented implementations.

Kirstan echoes the sentiment that sometimes SOA is too strongly associated with Web Services. He believes that we're not quite there yet in being able to realize the full potential of SOA, but these things take time.

The traditional 12 or 18 month development cycles involving armies of analysts and developers are replaced by a business analyst drawing a flow graph of the new process, then clicking a button for deployment to enterprise-ready infrastructure. The "service oriented" approach is measured in days or weeks using a fraction of the engineering resources.

However, as we've heard elsewhere sometimes your mileage may vary and SOA projects are not automatically successful through some implicit/embedded panacea. But as Kirstan suggests, this is a generational problem and as we go on we should get better (or something else will arise). According to Kirstan we've had 4 generations (so far) of Service based architectures:

1st Generation Services - Simple services coded in a 3GL language like C, C++, C#, or Java, which don't use modern SOA standards like WS-* or REST. These services tend to tightly couple the consumer with underlying resources. Older distributed computing technologies like CORBA and DCOM fall into this category as well.

2nd Generation Services - Services that are standards-based and fairly simple, like implementing an operation to retrieve, modify, create, or delete a data set on a database.  These services can often be auto-generated from other sources, such as from a Java or C# class, an EJB, or a database query. These services tend to reflect a method on an object, or expose an underlying implementation strategy like a relational table. They are easy to create, but because they are technology-oriented rather than business-oriented, they are unwieldy to use directly in a business process. Instead, they require combining with other services and logic to provide the proper level of granularity for orchestration.

3rd Generation Services - Truly "service-oriented", these services are aligned with a step in the business process. Loose coupling is achieved by explicitly defining data formats that are the payload of the service request and response, and these formats are driven by analysts that know the business process at hand, not by technologists attempting to optimize execution times and storage requirements. These services are often created by stitching together and transforming 1st and 2nd generation services to achieve a coarse-grained service that is suitable for orchestration and at the same time achieves loose coupling.

4th Generation Services - These are 3rd generation services that are institutionalized as managed, secure, governed, and reusable services. 4th generation SOA involves an ecosystem of SOA-aware technologies and procedures, which allow construction and management of business processes and higher level services. Given time to achieve 4th generation services, a company will maximize the benefits of SOA, enabling them create and modify business processes quickly to meet the changing demands of the business.

1. Back to top

   Those aren't generations of SOA

   Apr 4, 2008 11:03 AM by Steve Jones

   This doesn't lay out generations of SOA it lays out generations of coding. Generation 1 is just old school RPC Generation 2 is just CRUD or old school Forms based development (SQL is a standard afterall) Generation 3 isn't service oriented its process oriented with services being a step and assumes everything will be consumed by a process. Generation 4 is really the first generation of SOA and makes a big assumption that business process is the only form of activity in a business. It can be said that SOA has been around for years but its not right to say that just because something was exposed over the wire to be reused that it is SOA. Component Based development was not SOA. I agree that the evolution is towards the business but a generational approach that is really about development approaches rather than architectural approaches doesn't sum up the change that SOA is about. SOA starts when you think about systems in terms of services, that isn't about CRUD or technology its about the "A" of SOA... the architecture. If there can be said to be generations in SOA then so far we are still mainly in generation 1, which is treating SOA as a technology centric solution.

   Reply

2. Back to top

   Re: Those aren't generations of SOA

   Apr 6, 2008 1:25 PM by Kirstan Vandersluis

   Steve, I agree that each “generation” I describe cannot be thought of independently as SOA. However, many implementers have thought they had an SOA after slapping a SOAP interface on a bunch of queries and POJOs (what I call 2nd generation services, the term JBoWS is gaining popularity- http://www.infoq.com/news/2008/03/jabows-jbogs-pops). The result is simply a different way to “code” a solution, but does not help the company achieve the larger goal of business agility through SOA.
   
   We have seen significant press recently covering surveys on the state of SOA. On one extreme, AmberPoint’s survey finds 98% of respondents viewing SOA projects as successful. On the other end, Anne Thomas Manes from the Burton Group is having trouble finding companies meeting success with their SOA initiative (she did find one recently). I think these mixed results can be attributed to respondents having a wide range of “service-oriented maturity”. If you think JBoWS is SOA, and you have JBoWS, then you'll tell others that your SOA is a success.
   
   Taken as a whole, the intent of my blog was to help implementers recognize their company’s level of maturity in simple terms, and encourage them to reach for a higher level to gain the true benefits of SOA.

   Reply

3. Back to top

   Services and Alignment with Business

   Apr 8, 2008 11:02 AM by Kirstan Vandersluis

   Steve had specific criticisms I'd like to address in addition to my general comment above.
   
   Are the “generations of services” I describe really “services”, or is it more proper to call them components, or some other bundle of callable technology? I‘d reassert that they are services. Technical services for generation 1 and 2, but services still. Sure, you could refer to them by their technical names as well, RPC, DCE, WS, etc. And many of them are not service oriented (generation 2/JBoWS especially), one of the main points of my blog. But some of them are very service-oriented, like my credit care authorization service example. The latter has the additional benefit of aligning to a step in a business process. A business analyst can use it as a building block in other processes, and its contribution to the overall process is easily measured.
   
   As far as “process orientation” in defining services (my example of generation 3 services), I see ample rationale to take this approach, and have seen it work successfully in IT organizations. By aligning a service definition to a step in a business process, where the actual process is defined by a business analyst, IT immediately achieves some alignment with business. The business has a building block which is reusable and measurable. So many services are being developed today, and the number is accelerating with RIA-SOA approaches. I tell implementers to “think like a business analyst” when designing services, in an attempt to avoid non-reusable services tightly coupled between consumer and infrastructure.
   
   Steve’s larger point about SOA being treated as a technology solution rather than a broader organization/process/technology overhaul is a very good one. Technology should be treated as the “last mile” of SOA, after organizations and processes have made the transition to service orientation. This is, of course, the most difficult part, and maybe why so many companies in their haste to make progress towards SOA, start laying the last mile first, then hope the larger SOA “network” plugs in later to take them to SOA bliss. The problem clearly grows exponentially, not linearly, with the size of IT. Smaller businesses (where I spend most of my time) will have a much better chance of making the transition simply because they have so many fewer moving parts.

   Reply

4. Back to top

   Re: Services and Alignment with Business

   Apr 10, 2008 8:52 AM by Steve Jones

   The process point is one of the most dangerous ones IMO. Equating a service to a step assumes that a service offers only a single capability and that all business elements are done via processes. Not only have value chains been replaced by value networks, meaning that process orientation is less business centric than previously, but also large amounts of organisations do not operate on simple step oriented business processes. I have seen POA (which is what you are proposing) work reasonably well for package extension work where process is the dominant metaphor, but I have seen this literally destroy complex programmes due to the lack of flexibility that it gives.
   
   Technology isn't, IMO, the last mile of SOA its more like a part of the infrastructure. In the same way as a Telco could replace the exchange without you caring so you could replace the EAI with ESBs and the business wouldn't care. The last mile is the mentality shift from thinking in terms of processes and steps into thinking about services and interactions. It is the mentality shift of doing services that represents the change.
   
   It might be true that smaller businesses find the technology oriented approach reasonable, but as you say the problem gets exponentially larger and more complex with larger businesses and I'd say that from experience a technology centric approach will deliver at best a minor incremental benefit, will normally deliver no noticeable benefit and on a reasonably frequent basis will leave the organisation worse off.
   
   I have regularly advised people to cancel SOA programmes which have focused purely on the technology and judging by the results of those that take the advice over those that don't I'd say that technology centric SOA delivers less benefits on average than not doing it!

   Reply

5. Back to top

   Re: Services and Alignment with Business

   Apr 10, 2008 8:55 AM by Steve Jones

   I nearly forgot to say. In terms of what I would say to do
   
   1) take a services view
   2) Understand the business services
   3) Understand the actors/drivers
   4) Understand the interactions
   5) Understand what is important
   
   THEN worry about the technology
   
   This InfoQ book will help :)

   Reply

• Older >