Considering the regular characteristics of an n-tier app with layers like: presentation, business, data access; how is this normally rebuilt to make a Service-Oriented Architecture (SOA)?
Seeking high level overview from programmers experienced in this exercise.
To a degree I picture it conceptually flattening out rather than having one vertical stack. Or as a series of horizontal modules each encapsulating their own mini n-tier stack. With heavier protocols in between for messaging.
My understanding is that an SOA approach is what you'd use to allow systems to talk with each other (as opposed to sending data between layers); with the variation that you could build apps that consist of only some of the traditional layers and relying on the existing services for the data.
I also think the S in SOA refers to Business Services (something at the busines slevel) and not Web Services (something at the technology level).
So in that sense I don't think apps are 'rebuilt' into an SOA; sure that would happen - but driven at a higher level. I mean, you'd be wanting to do it only after having evaluated the benefits, doing a business case, etc.
What sort of overview are you after, a technical one? Or something else?
High level overview: get someone who understands the data and the services that you offer (or want to offer), figure out how to carve them up - go for simplicity: http://www.objectwatch.com/whitepapers/ITComplexityWhitePaper.pdf
SOA and n-tier are somewhat different concepts. n-tier is generally about the application architecture of building a standalone application (which may have some defined interfaces to other applications etc).
SOA takes a step back from this and looks at the range of business services that are required across the enterprise and where they should be provided, with an aim to reduce duplication. These may well build on or reuse elements of existing n-tier applications. For example there might be a number of existing applications that allow an order to be created (e.g. intranet client based application by sales team, online at website etc), which then need to synchronise or aggregate their data at some point. Instead a 'place order' service could be created, that can be reused by a number of different front-end applications.
These initial services could well exist based on functionality within existing applications that is then wrapped in a business service to provide the reusable interface.
You might then look at chaining a number of services together in different ways (orchestration) to provide a composite service - e.g. place_order is followed by an optional call to a supplier company service to restock the warehouse if the stock level is below certain level, and a further call is made to a billing service to create an invoice etc.