The service-oriented design phase is the first in which real technology is touched. Though we are not yet programming Web services, the primary deliverable of this stage is a physical service interface definition.
As we've already established, to design a service interface requires the use of the WSDL and XML Schema markup languages. This section discusses three common approaches to working with these languages.
WSDL and XSD schema markup code can be auto-generated using a development utility. Typically, this program will derive the service interface from some existing source, such as a component class.
This approach is common with developers who want to efficiently generate a service interface that mirrors the interface of a distributed back-end component. The result is a Web service that follows the proxy service model and one that generally is geared to bring RPC-style communication into the SOAP messaging framework.
The use of this method is highly discouraged within SOAs. It runs contrary to the standardization required to establish a consistent series of endpoints within service-oriented environments. It also opposes the preference of WS-* specifications for a document-style (non-RPC-style) messaging model.
Although auto-generation of service interfaces is a feature promoted by several prominent development platforms, it is not one that is explored in this book. The service design processes described in Chapter 15 all are based on a "WSDL first" approach, meaning that a service interface must be designed prior to the development of the service's immediate underlying application logic.
13.5.2. Design tools
Several front-end tools providing a visual representation of the different parts of the service interface currently exist. These allow you to drag and drop elements and constructs associated with the WSDL and XML Schema languages to assemble a service interface without having to type out elaborate markup syntax.
To help ease the transition of developers more accustomed to traditional component-based solution environments, these tools provide graphical user interfaces that promote "don't worry about the WSDL" features. The end result is typically an auto-generated WSDL definition consisting of markup produced within the confines of the tool's output generation capabilities.
As development platforms begin to incorporate more and more of the Web services technology set as part of their native environments, front-end tools are becoming increasingly sophisticated.
When planning to use a design tool, take the following considerations into account:
The service design processes provided in this book can be completed with the right design tool. The best types of tools are editors that allow you to seamlessly switch between a graphical view and a source code view and that supplement this with built-in WS-I Basic Profile compliance testing features.
13.5.3. Hand coding
If you are a developer or an analyst proficient with the syntax-level details of the WSDL and XSD languages, you can consider writing out the service interface designs using a simple text (or XML) editor. This approach gives you the ultimate level of control over your service design and helps you avoid issues associated with some design tools.
If you would like a visual representation of some of your larger or more complex definitions, you still can use a modeling tool as a viewer only. You simply let it read in your WSDL file and provide you with a graphical view. As long as you don't actually save your work using the tool, you will maintain your independence. Further, these tools can be helpful for validating the hand coded service definitions.
Although it is very common to use WSDL design tools, we take complete control of our service descriptions in each of the three service design processes described in Chapter 15, building them from scratch according to our design standards and preferences. As a result, all of the accompanying case study examples provide samples based on this approach. We do this to best demonstrate the use of the WSDL language within SOA.
While gearing up for the delivery of their respective SOA solutions, both RailCo and TLS give some thought to how they are going to tackle the design of service interfaces. IT staff in both organizations gained hands-on experience building Web services in past projects and are therefore relatively comfortable with the core SOA technology set.
Each project team decides to proceed by hand coding the required WSDL definitions and associated XSD schema types, using an editor with validation and WS-I compliance testing features.
SUMMARY OF KEY POINTS
Part I: SOA and Web Services Fundamentals
The Evolution of SOA
Web Services and Primitive SOA
Part II: SOA and WS-* Extensions
Web Services and Contemporary SOA (Part I: Activity Management and Composition)
Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security)
Part III: SOA and Service-Orientation
Principles of Service-Orientation
Part IV: Building SOA (Planning and Analysis)
SOA Delivery Strategies
Service-Oriented Analysis (Part I: Introduction)
Service-Oriented Analysis (Part II: Service Modeling)
Part V: Building SOA (Technology and Design)
Service-Oriented Design (Part I: Introduction)
Service-Oriented Design (Part II: SOA Composition Guidelines)
Service-Oriented Design (Part III: Service Design)
Service-Oriented Design (Part IV: Business Process Design)
Fundamental WS-* Extensions
Appendix A. Case Studies: Conclusion