The advent of Web services has publicized the importance of an open communications framework. As a result, most IT professionals are at a stage where they acknowledge the relevance of Web services technologies.
As we've established previously, the majority of Web services currently being built are, more or less, a mixture of application and business services. These types of hybrid services are attractive because, with minimal effort, they fulfill immediate requirements with clear ROI benefits. The proliferation of hybrid services is the result of the bottom-up approach having become so commonplace. They provide an immediate means for all past forms of application architecture to take part in the open Web services communications framework.
Business services, on the other hand, often need some justification. Many still resistor are even unaware ofthe benefits of introducing service-oriented principles into the domain of business analysis. It is easy to ignore service-oriented business modeling and simply focus on service-orientation as it applies to technology and technical architecture. The common rationale for this approach is that whatever business processes need to be automated can be divided up into physical Web services as required.
Many of the characteristics of contemporary SOA we listed in Chapter 3 can still be attained without the use of business services. Though it may appear that you are saving yourself a load of work by taking this path, the apparent benefits are superficial. There are very good reasons for taking the time to model and build business services. In this section we list a series of benefits for incorporating service-orientation into the business process level.
11.2.1. Business services build agility into business models
Service-orientation brings to business process models a structure that can significantly improve the flexibility and agility with which processes can be remodeled in response to changes. When properly designed, business services can establish a highly responsive information technology environment; responsive in that changes in an organization's business areas can be efficiently accommodated through re-composition of both a business process and its supporting technology architecture (as expressed by the application services layer).
As business-driven as SOAs are, there are often real world restrictions (infrastructure, security constraints, budget constraints) that require the technology side to push back. This can shift the burden of adaptation over to the business process models. This type of agility requirement can be met by the business service layer, as it allows business services to adjust to requirement changes originating from an organization's technical environments.
In other words, applying service layer abstraction to both business and technology ends establishes the potential for an enterprise to achieve a form of two-way agility (Figure 11.2).
Figure 11.2. Changes originating in the business logic domain are accommodated by the application logic domain and vice versa.
11.2.2. Business services prepare a process for orchestration
Whether or not you will be moving to an orchestration-based service-oriented environment anytime soon, it is becoming increasingly important to be ready for this transition. Orchestration brings with it concepts that, when implemented, lie at the core of SOA. Therefore, modeling current processes so that they eventually can be more easily migrated to an orchestration-driven environment is recommended.
11.2.3. Business services enable reuse
The creation of a business service layer promotes reuse in both business and application services, as follows:
11.2.4. Only business services can realize the service-oriented enterprise
Business service modeling marries the principles of service-orientation with an organization's business model. The resulting perspective can clearly express how services relate to and embody the fulfillment of business requirements.
Applying business services forces an organization to view and reinterpret business knowledge in a service-oriented manner. Altering the perspective of how business processes can be structured, partitioned, and modeled is an essential step to achieving an environment in which service-orientation is standardized, successfully consistent, and naturally commonplace.
Though the business services layer may accurately represent a corporate business model upon implementation, it will become outdated once new and revised business requirements emerge. As long as it is kept in relative alignment with the current state of business models, it will continue to serve as a valuable view of the enterprisevaluable because it does not exist in abstract but in an implemented and operational form.
As mentioned earlier, RailCo has decided to structure its SOA around a services layer consisting of separate business and application sub-layers. Given that it does not have extensive business requirements, these layers will not contain many services. However, the important aspect of this initial project is that it will define an architecture that accommodates additional services and solutions.
As part of its analysis, RailCo has identified the following benefits of investing in extensible business services:
At this stage, RailCo simply is listing potential benefits that can be met by introducing services it has not yet even modeled.
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