Seven principles for service-oriented development

The future software architecture requires a new development approach. Is your company ready for the job?
by Jason Bloomberg
Today's description of Web services (Web service) is primarily about integration. Companies that have come out of recession have taken the cost of integration down as an obvious goal. The use of open, standards-based, loosely coupled Web services technologies provides a less expensive integration approach for businesses. However, Web services not only simplify integration, they are more useful. In fact, they are destined to fundamentally change the way people create and use software.

To get rid of the old-fashioned way of thinking, software experts have to understand the technology of Web services and understand how Web services can provide us with the future. The following seven principles of service-oriented development--they come about as the old-fashioned way of thinking shifts to new ways of thinking--Provide a guide to the idea that you form this new level.

1. The dynamic service replaces the static component
Building a Web service is not just about creating software that has special features as the traditional component development expects. A Web Services Web Services Description Language (WSDL) file dynamically describes the functionality of a Web service. So, developers only need to point out where to find the WSDL file, so that the software that invokes the Web service can find a description of the service's functionality at run time. This principle requires that the logical layer be separated from the business logic Layer and the persistent (persistence) logic layer in a system that uses Web services. When developers build a Web service, they may not know how that service is invoked, or what the user interface of the Web service consumer will be. A Web Services architect cannot combine business logic with display logic.

2. Service rendering (exposure) and response (Reflection) replaces traditional system integration
Today's system architects integrate projects based on system-level requirements. The architect plans how the various components should be integrated. As an alternative to this top-down approach, service-oriented development employs a bottom-up approach. Before any system structure is formed, each component in the system renders as a Web service. Each service (querying a feature that serves itself) then provides the external system with the information they need to access the service.

When building a system, the Web Service architect first considers the requirements of the system and carries out the service assembly. During the service assembly process, the architect accesses the dynamic description of the service, which represents only a portion of the actual API. The architect then determines the structure of the system, and even before running, the individual components and their interfaces are not fully described.

3. Write code for a wide range of applicability instead of writing code for reusability
Writing code for reusability is an important feature of object-oriented programming. In fact, for developers, writing reusable code can be more challenging than writing code for an individual-use application. Therefore, flexible software methods such as Extreme programming (XP) avoid reusability. In XP, if the external functionality goes into the code, the developer will rewrite, or refactor (refactor) the code until it is as simple as possible.

While refactoring can form a number of reusable methods, because the final code satisfies many situations, this approach differs from the traditional code written for reusability because it aims to create flexible and widely applicable code. The differences between reusability and the wide applicability code are small, but they are the essence of the service-oriented development process. The best approach is to combine the structural principles of service-oriented development with flexible development principles.