Assembling "New" Service Based Solutions from Existing Services, Page 3
Key Service Architectural Tenets
Figure 1. Interaction Sequence: Here's the Service Consumer/Enterprise Content Collaboration Service interaction sequence.
- Successful service assembly requires that service interactions (see Figure 1) be based on predictable service interface contracts, the availability of DAO or data access APIs, the existence of generic exception handling workflow APIs, and QoS management and monitoring tools.
- Use standardized payload formats to package the request and response parameters provided on the envelope. These should include clear action verbs and other enterprise-standard instructions to facilitate mapping the request-based metadata to the processing instructions in the enterprise rules repository.
- Make sure an enterprise-level governance process is in place to rationalize the metadata and the rules published to these centralized repositories to ensure that mapping and processing instructions in the canonical request are predictable and efficient. The governance process should also ascertain the quality of enterprise-level taxonomy and relationship-mapping rules to enable the Enterprise Information Integration Service to navigate efficiently between the structured content and unstructured content repositories.
- Ensure that standardized metadata keywords and an efficient metadata repository is available to the runtime environment.
- Adopt standards such as XML, XML Schemas, XSLT, XPath and XQuery functions to make information processing efficient.
In conclusion, using the best practices and architecture tenets mentioned in this article allow an enterprise to reuse service-based investments to gain time-to-market benefits while promoting information flow standardization and improving the quality of business service management. In addition, using utility service components that "canonicalize" requests and responses into XML allow downstream interactions to be more predictable, while still providing ease of use and flexibility to consumers, making their service interactions simple and easy to code.
The most important byproduct from adopting these best practices and architectural principles is that they make it easy for enterprises to dynamically wire additional exception-handling flows, additional repository searches and/or to offer alternative keyword suggestions to end users or service consumersprovided the design-time constructs are all in place to facilitate the runtime interactions. In addition, given the separation of concerns among the utility service components, any new feature implementation can be concurrently designed, tested and deployed.
One might also be able to offer this type of content collaboration service in the context of cloud computing, where the content collaboration service provider has a mechanism to deal with multi-tenancy in both the content and metadata repositories. The challenge in cloud computing lies more in the realm of transporting large binary content across the wire and in the scalability of the content collaboration service across firewalls rather than in the architectural construction itself. But that's a discussion for another article!
About the Author
Surekha Durvasula is an enterprise architect with more than 11 years of experience designing and architecting a variety of enterprise applications in the financial services sector and the retail industry vertical. Most of her work has been in the area of distributed N-tiered architecture, including J2EE component architecture. Her more recent focus has been on Service-Oriented Architecture and Business Process Management. Her efforts as an Enterprise Architect involve not only architecting new applications and business services, but also in leveraging the principles of SOA to extend the life of existing Enterprise Information Systems.