Before we can begin building a service-oriented solution, we need to understand what makes a service suitable for SOA. In other words, how can we build Web services that are truly service-oriented?
The answer lies in service-orientation. This approach to modeling business automation logic has resulted in a set of commonly accepted principles applied to each unit of logic that constitutes a service within an SOA. It is through the application of these principles that the primitive components of an SOA (services, descriptions, messages) are shaped in support of service-orientation.
This chapter begins with a look at how service-orientation applies to the enterprise as a whole and then discusses individual principles in-depth.
In Plain English sections
A knowledge of the principles of service-orientation is perhaps even more important than concepts covered in past chapters. They are core to the design of services regardless of what underlying technology is used to implement them. Therefore, our In Plain English sections return to supplement the descriptions of individual principles.
How case studies are used: As you might recall from the case study background information provided in Chapter 2, one of RailCo's business goals was to improve their existing automation processes by moving toward SOA.
In this chapter we examine the services built so far as part of RailCo's technical environment and discuss how they comply to or diverge from individual principles of service-orientation. Existing TLS services that already possess service-orientation characteristics are used for comparison purposes.