OK, so it's been nearly one yr since I posted Part I...pretty crazy I didn't consider doing a series on the topic. Anyway, here's some further discussion about the concept of Service Oriented Architecture...
First off, traditional web client applications can rarely be generalized as a thin web client. Like MS Silverlight, what you end up with, using a set of solid WCF services to harness the backend is nothing less than a SOA application taht just so happens to front a rich interactive application (RIA) interface. Calling a Silverlight or Flex app a thin client is akin to wearing a McClaren jacket at a tour through the Maranello factory. So, SOA in and of itself is merely teh notion of using an agnostic set of services that perform complex business logic; the front end application merely consumes what's thrown at it.
First off, traditional web client applications can rarely be generalized as a thin web client. Like MS Silverlight, what you end up with, using a set of solid WCF services to harness the backend is nothing less than a SOA application taht just so happens to front a rich interactive application (RIA) interface. Calling a Silverlight or Flex app a thin client is akin to wearing a McClaren jacket at a tour through the Maranello factory. So, SOA in and of itself is merely teh notion of using an agnostic set of services that perform complex business logic; the front end application merely consumes what's thrown at it.
Consider your fancy new Silverlight app using Entity framework and WCF services throughout...you've got adjacent customers that could surely tie into those services and solve their own sets of business needs. Data Exchanges are merely a consumer of SOA - such an interface (or exchange) can be created through simple WCF web services or through more complex varieties.
Imagine that Contoso Shipping has this new Silverlight application. Consider the various adjacent systems that interact with the shipping provider. The distributor to the cardboard box maker could use a look-see into your organization in order to know when to send more boxes to you. Our cardboard box maker company uses its own sophisticated, local software solution for its work mgmt, and isn't about to create something and get the shipping company to expose its data.. Instead, our shipping company merely partners with the box company. In doing so, a service contract is setup and those wcf services that provide the interfacing needed (likely existing services that already poised doing other work) are directed out through this new web service. The box company has the bulk of the work from here - they need to extend their local solution (system) to consume these services, transform the data structures coming across and do some analysis. The output sends data points to their system, all the while the system of record remains internal to the box company, but the shipping company gets real-time data from the box company about its # of boxes coming, etc, etc. Make sense?
In this context, a service oriented arch exists that can be consumed by other (dozens) of client applications in order to make use of the data constructs. The service provider merely exposes and publishes its web services to get at the data, and its approved partners get access to the data for consumption, etc.
The interesting part is that of the analysis needed up front to properly put business and technical req's together to facilitate a) exposing a usable service for potential or known users, and b) providing the data exchange using a broad enough declaration of services that can be consumed by the masses. The last, most complex part is that of reconciliation - either the servicing party or the client party must be responsible to resolve data issues that can and will exist between the two parties. In my opinion, it's always easiest to put the burden on the client (consumer of the services). But, this depends on your system of record...if the State, let's say, exposes criminal data to the state counties for use, it likely expects that this is the system of record, and all such edits need to exist in this single system. So, as the State body, we can't expect that the counties will update this system in a fire and forget mode. Counties need to resolve conflicts in the data, e.g., you send me this, and it doesn't match my interface schema or conform to its pre-justified rules, it's kicked out, and you fix it...or, you send me a case record, but some pre-requisites fail, we abort the data exchange, and the county must resolve. The state in this context expects that the local agencies get good data into the system. One step further, imagine the local agency being satisfied with its own local system; they merely have a data entry person stuff data into the system of record (the statewide data stores)...if this person puts bad data in, they resolve it. If not, garbage in, garbage out, especially when in a case like this, reporting is so critical.
