| CIO Blogs
IT Blog Awards |
Subscribe
RSS news feed
Add to Technorati FavoritesRecent Posts
- New CTO blogger: Sean Rhody on Wireless On-site Collaboration
- SAP are Twittering, IBM are teleporting Avatars, and Google are Lively
- The Gold in Chrome
- Google Chrome
- The 2 Magics and the Hype Cycle
- Wii, Second Life, (and maybe the iPhone), it’s all coming together
- Web 2.0, Enterprise 2.0, Agile Enterprise, and Business Technology means what?
- User Expectations are being formed outside the Enterprise
- Innovation Brief
- Olympics 2.0, Miss Bikini and the end of Operating Systems
Navigate
Search the blog
« Social Computing and Anti Social Behaviour | Main | Winners and Losers, no real change, is the industry mature? »
Just what is SOA?
The industry is buzzing with SOA being positioned as the next big thing. As with all new technological fashions SOA promises to delver better, faster, cheaper IT support than was possible before it arrived on the scene. However, all this hype seems to have resulted in a great deal of confusion around just what SOA is, and what it isn’t. Is it a new generation of middleware based on web services and the WS-* family of standards? Is it a new generation of process modelling tools based on BPEL et al? Is it something to do with enterprise architecture? Or is it just another over hyped technology?
For me, SOA is very simple idea: break your solution into a number of discrete services and then organise the services into an end-to-end solution. This might sound very similar to the component based architectures of the late 90s as it is—the main difference being that SOA takes a more coarse-grained view of functionality.
The most contentious point has been defining just what a service is; it's nearly impossible to get any two "experts" to agree on a single definition. Are they stateful or stateless? Do they support synchronous or asynchronous interfaces? Is WS-* mandatory? What makes them loosely coupled? I think that it’s pointless attempting to create such a detailed definition since it is usually quite easy to find an exception invalidating it. For example, a data service (responsible for CRUD operations to persist a business object) can be considered either stateful or stateless depending on your point of view. The data service appears stateful to clients using it, as it allows them to persist objects and then retrieve them; the service's state is the objects that are persisted. However, an implementer might create the service with an object-relational mapping tool making the implementation essentially stateless, as it simply passes all data through to an underlying database. Is the service stateful or stateless? It depends. It's more productive to stick with a rather abstract definition.
I typically use something like the following:
A service is a coherent block of functionality that represents a distinct function or activity within the business.
A service-oriented architecture is then an architecture created by arranging a set of services. Rather than representing our solution as application layers—where each layer covers the full width of the solution—we break the problem into a number of distinct services. Typically these services come on two flavours:
Business Services. Containing implemented business logic (processes and rules).
Technical Services. Supporting technical functionality required to ensure the smooth operation of the overall solution. This might include data services (for persisting business objects), services for authentication or identification, or even services that provide online access to catalogues of other services.
While it's fairly obvious what technical services are required (typically one for each technical function we need to support) a major challenge in developing an SOA can be deciding on what business services we need to create. The answer is surprisingly simple: create a business service for each business function or activity we need to support.
Since the 80s the business community has expended significant effort developing activity-based models of business (those of us with MBAs should be familiar with Michael Porter's work) which break business into a number of discrete activities based on the idea of a value-chain. Rather than reinvent the wheel, us technologists can leverage this work to simplify the creation of our service-oriented architectures, with the added bonus that the resulting architecture will be meaningful for the business.
Once we've discovered the business services (creating a business service architecture, as it were) the processes of identifying the required technical services becomes fairly straight forward. A business service that wants to persist business objects needs a technical data service. A business service connected to external partners requires a B2B gateway. Any user represented in a business process will require a user interface. And so on.
This is the approach taken in the OASIS SOA methodology. The methodology is definitely worth a read, as it explains the ideas behind the approach as well as the approach itself. Couple this with the recent work at OASIS on a SOA reference model and we might just have something that we can all live with.
Posted by Peter Evans-Greenwood on July 25, 2006 in
Architecture
::
Technology
| 
Digg this | 
Seed Newsvine
TrackBacks
TrackBack URL for this entry: http://www.capgemini.com/cgi-bin/blog/mt-tb.cgi/45
Comments
# on July 27, 2006 3:29 PM, Paul Gielens said:
Technical Services and more specific the Data Service you mention is an Anti Pattern. Perhaps the reason for the different types of services that appear in the SOA blueprints has something to do with the service orientated ambiguity. SOA means so many different things to different people. What about service boundaries? One of the core tenets of SOA is that the services have a clearly defined boundary. Services are autonomous; another tenet of SOA which means that the data on the inside is private to the service and always encapsulated by the service so the only way of accessing it is through the business logic of the service. This data is only loosely correlated to the data on the outside travelling in the form of messages. In essence services explicitly expose certain business capabilities outside these boundaries. Is persisting business object instances (CRUD operations) really a business capability? Where to draw this boundary? What’s the difference between splitting our solutions in applications layers such as the Data Access/Persistence layer, or to break the problem into distinct services such as the Data Service/Persistence service?
# on July 28, 2006 12:48 AM, Peter Evans-Greenwood said:
I agree that SOA means many things to different people, which I think if most of the problem. There is general agreement that services should show strong encapsulation (as you mention), but pretty much everything is up for grabs. Take autonomy for example. Just what does this mean? It could imply anything from encapsulation all the way through to complete independent control (i.e. proactivly managing it's own execution) depending on who you talk to. Different situations require different capabilities. What capabilities you use over and beyond encapsulation depends on the scale of your problem and your non-functional requirements. Creating a data service might be over design and an anti-pattern in the low range, but creating a standard service based CRUD interfaces can provide valuable flex points in the high range.
I also try and avoid forcing every service to deliver a "business capability". Is yellow pages, white pages, etc., (WSDL) a business capability? Or perhaps identity management? As Dan McGoveran said [http://www.bijonline.com/index.cfm?section=article&aid=247]:
"The software industry’s current love affair with service orientation seems to be resonating with business. We talk about business processes, business transactions, business events, business activities, business metrics and key performance indicators, and even business services. The language IT uses is now a bit more familiar to business users, and they’re beginning to expect great advances. It’s really too bad they’re going to be disappointed. Unfortunately, though the words may sound like they refer to business, the software industry uses them to denote technology. We’ve merely plastered over the gap between business and IT by mimicking the words used by business, all but ignoring the details of how they are used."
Some functionality is driven by business requirements, and some by technical requirements. Dividing each of these concerns into separate "types" of service is a good way of controlling the chaos.
# on July 31, 2006 1:29 PM, Paul Gielens said:
Thanks Peter for your reply!
I would like to comment on the drivers of functionality and their place in SOA. I think D. Krafzig at al., Enterprise SOA: Service-Oriented Architecture Best Practices captured this well.
---Unlike business services, technical infrastructure services, such as a persistency service or a transaction service, provide operations such as begin transaction, update data, or open cursor. Although this kind of technical functionality is very useful when it comes to implementing a business operation, it has little strategic relevance from the SOA point of view. More generally, technology must not have any impact on the high-level structure of the application landscape or cause dependencies between components. Actually, the SOA must decouple business applications from technical services and make the enterprise independent of a specific technical implementation or infrastructure.---
Instead of finding a good way to control the chaos it is interesting to find out what led to this chaos. I think an important challenge of a Service/SOA is finding the right abstractions.
# on March 16, 2007 11:35 AM, Tahir Rauf said:
Interesting, I found it helpful