Service interface design tools

2017-11-03 09:05:05

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.

13.5.1. Auto-generation

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:

Does the tool allow you to take ownership of the WSDL it auto-generates? If yes, you may be able to use the tool as a starting point to create the overall structure of the WSDL definition. Then, you have the option of continuing to work with the markup independently.

Does the tool allow you to view existing WSDL definitions accurately? If you've created your own WSDL, it may be preferable to be able to view its element hierarchy through a graphical interface. Some tools, however, cannot accurately interpret a WSDL that was not created using the tool.

Does the tool validate accurately against the W3C WSDL specification? Some front-end tools are tied to a particular server platform and therefore may validate WSDL markup according to the constraints of the proprietary features provided by the platform's server products.

Does the tool allow you to edit and maintain WSDL definitions without inserting unwanted markup? This is a primary concern of many development productsregardless of whether the WSDL definition initially was created with the tool or whether you are using it to make changes to an existing definition, some tools have the tendency of inserting excess markup code.

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.

Case Study

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
Auto-generating service interfaces by deriving them from existing component classes is not a desirable service design approach for building SOA. As long as modeling tools don't interfere with WSDL output, they can provide a rapid approach to the service-oriented design process. Hand coding WSDL service definitions and associated XSD schema content provides the highest degree of independence and can be supplemented with an editor that provides validation and testing features.

SUMMARY OF KEY POINTS

Auto-generating service interfaces by deriving them from existing component classes is not a desirable service design approach for building SOA.

As long as modeling tools don't interfere with WSDL output, they can provide a rapid approach to the service-oriented design process.

Hand coding WSDL service definitions and associated XSD schema content provides the highest degree of independence and can be supplemented with an editor that provides validation and testing features.

Case Study

Категории