This site is devoted to all issues and trends pertaining to the refactoring of legacy code/systems to an SOA architecture. This includes:

• Tools and techniques for exposing existing business logic services in a secure manner
• Tools and techniques for exposing existing data services in a secure manner
• Best practices for service-oriented design
• Forums and articles to guide your refactoring efforts

Reading from CBDI, Lawrence Wilkes identifies the following top ten traits of the successful SOA organization:

1. Have a level of cultural and organizational maturity that supports SOA goals
2. Ensure there is an appropriate balance of investment in shared assets and activities that might only realize benefits in the longer term
3. Organizational separation between provisioning and solution assembly
4. Create a Service Portfolio that is the inventory of enterprise assets from which projects source the capabilities they require
5. Continually assess where you are on the SOA Maturity curve and other appropriate process maturity models
6. Put clear management direction in place for SOA
7. Enjoy the luxury of already having a portfolio of modular systems, built on an inventory of shared components
8. Promote sound software engineering discipline that ensures reuse, consistency and traceability and applied best practices such as component-based development (CBD)
9. Focus SOA attention based on a real compelling event, such as a merger or terminal decline, that instigates strong motivation to re-engineer the portfolio
10. Put a good IT governance framework in place

According to SearchWebServices.com and Jason Bloomberg , Senior Analyst, ZapThink, LLC the Four Pillars of SO Development are:

1. Iterative development -- we're representing each sphere of development with a pair of arrows to indicate the fundamentally iterative nature of SO development. Business analysts must work iteratively with business users, both to satisfy the original requirements as well as to maintain agility as those requirements change. Likewise, component developers must continually iterate their code to satisfy ongoing changes to the service contracts.
2. User involvement -- unlike the waterfall model, where users specify requirements at the beginning of a project only, business users continually drive SO development. The meta-requirement is for a system that responds well to change, and as a result, the "requirements definition phase" of any SO project is actually a set of ongoing activities.
3. Contract-first development -- Business analysts work with users to distill requirements into contracts that then act as the marching orders for component developers. Such metadata both represents the requirements as well as the test plans that analysts can execute to guarantee that services meet their requirements. In other words, contract-first development is an example of test-first development, and both approaches are examples of metadata-driven application development.
4. Refactoring -- The services layer of abstraction affords IT the luxury of a curtain that hides the inner workings of the technology from the business. Rather than an excuse to maintain a poor infrastructure, this abstraction layer actually gives IT more leeway to make continual improvements to the technology. Refactoring is thus the underpinning of reuse, as IT may now work to streamline technology across platforms to meet the needs of the business.

According to Using Message-oriented Middleware for Reliable Web Services Messaging, messaging middleware reliability is embodied in three facets:

1. Middleware endpoint-to-endpoint reliability - A message, once delivered from an application (process) to the messaging middleware, is guaranteed to be (eventually) available for consumption by the receiving process. The middleware ensures eventual message delivery within its distributed network of middleware endpoints.
2. Application-to-middleware reliability - The middleware's messaging API, used to send and receive messages, supports reliability properties such as message delivery guarantees, message persistence, and transactional messaging.
3. Application-to-application reliability - Sending and receiving applications engage in transactional business processes that rely on application-to-middleware reliability and middleware endpoint-to-endpoint reliability.

According to Carnegie Mellon - Software Engineering Institute:

"Message-oriented middleware is software that resides in both portions of a client/server architecture and typically supports asynchronous calls between the client and server applications. Message queues provide temporary storage when the destination program is busy or not connected. MOM reduces the involvement of application developers with the complexity of the master-slave nature of the client/server mechanism."

"Nominally, MOM systems provide a message queue between interoperating processes, so if the destination process is busy, the message is held in a temporary storage location until it can be processed. MOM is typically asynchronous and peer-to-peer, but most implementations support synchronous message passing as well."

"MOM is most appropriate for event-driven applications. When an event occurs, the client application hands off to the messaging middleware application the responsibility of notifying a server that some action needs to be taken. MOM is also well-suited for object-oriented systems because it furnishes a conceptual mechanism for peer-to-peer communications between objects. MOM insulates developers from connectivity concerns- the application developers write to APIs that handle the complexity of the specific interfaces."