Keving Boyle, one of my local Microsoft Architect Evangelists makes an interesting observation here...

http://blogs.msdn.com/socalarchitect/archive/2005/09/23/473399.aspx?CommentPosted=true#commentmessage

and I'm not surprised because I still hear from a lot of companies that need to get started with Web Services 101. SOA just sounds like this big huge ominous endeavor if you listen to all the buzz out there...yet it should be very simple in my opinion.

OOP to classes is like components to applications is like services to systems

The question is of when an “application“ becomes a system, and that is a question of composition, complexity and distribution.

Notice you did not see the term “web services“ above. Web services are NOT a requirement of SOA, there are an interoperability facilitator.

Enterprise systems should be designed so that major chunks of functionality can be moved, distributed, refactored, replaced with alternate application or vendor sources...without tumbling down the entire system. Today's system is no longer a single monolithic endeavor by a single vendor. We are now in the business of building composite systems that comprise many applications or feature sets that are respectively built by appropriate domain experts. So, systems must be sure that major sources of functionality are not tightly coupled. Major features become “services“. Each “service“ can receive inputs, or return outputs...and everything that happens in the middle should be completely independent of the rest of the application (black box). That means I should be able to move the service to another machine, another vendor and still have things work just fine so long as the location can be found. So, a service is designed to use its own tables, configure its own file IO directories, and manage all other resources needed to perform its function. That does not mean there is a different database for every service in an application. It just means that the service is programmed not to depend on another services table structure. Use the same database, use a different database, it should not matter to the application as a whole because the service maintains its own configuration.

Consider this progression.

An application that logs incoming Web service requests, records a transaction, and shoots off a request to generate a PDF from the XML.

The functionality that logs messages doesn't have to be on the same tier, and the application may leverage another application to do the work...therefore that is a service (logically speaking):

The transaction logging activity is a core part of the application, but could later be distributed therefore that can be considered a logical service as well. In particular the PDF generating functionality could receive XML inputs, and be considered a separate service as well:

But, let's not think small. This entire system could be considered a service to another application that requires PDF generating and transaction reporting activities. In this example, the system is a certificate issuance system (from a system I designed for the insurance industry years ago) - so that would be the purpose of this interoperable service endpoint:

SOA is an approach to system design that has been implemented in systems of many differing technologies in the past, that makes a business more agile. New technologies are making SOA easier to implement, Web services make SOA interoperable, but it is really about designing enterprise systems so that there is an appropriate level of configurability and reuse at the outer "service" or "functionality" layer.

Indigo (WCF) will just make the implementation of services a natural part of system development.

What do you think? Is SOA too confusing?