The information entry point focuses on services that enable all applications to access and update the same consistent view of data, as if the entire enterprise contained just a single database. Traditionally, each application implements its own data access to what is supposed to be the same data. Data spread across multiple databases and inconsistencies in data access can lead to different applications answering the same query differently, causing inconsistent user experiences. Likewise, the same information must sometimes be stored in multiple databases, which means that each application that updates the data must update all of the databases consistently. When the data is moved or the format must be changed, each application using the data must be independently updated, which can cause more inconsistencies.
Information services can best be implemented using a data integrator that acts like a database with a services interface but is capable of performing extensive processing on the data. The simplest services provide reusable access to CRUDcreate, read, update, and deletethe data, both structured and unstructured. More powerful services integrate information that resides in a range of heterogeneous repositories, possibly with redundant and inconsistent informationdata that may need to be cleansed, consolidated, and/or enriched. Services also simplify access to external sources of data, such as querying a business partner's inventory.
The value of information-focused services is that they hide the details of how the data is accessed. As new sources are added, old ones removed, and data rearranged, only the service implementations need to be updated; the applications using the services remain unaffected.
|The value of information-focused services is that they hide the details of how the data is accessed.|
Information services fit well into SOA because they enable an SOA application to treat information as a service. Services typically perform business functionality, but sometimes that functionality is essentially to CRUD some data. A business process to fulfill a purchase order may need to access a customer's credit profile; that access can be a service that simply retrieves the profile data. That profile data may be scattered among different databases needing integration, and may need enrichment and cleansing. Those databases may be different tomorrow than they are today; in all cases, the service hides those details. The process may also need to update the purchase order. It can do so using a service that hides what databases and schemas are actually used to store the order.
To start developing an information service, look for data that needs to be accessedread and/or writtenby a variety of applications, especially data that needs to be made available to business partners in a controlled fashion. A key example would be access to databases of record for master data elements. This approach is especially helpful when the applications do not agree entirely on the data format to be used, when the data is partitioned or duplicated across multiple databases, or when the data needs to be cleansed. The service provides a single point of access for all applications that need to read and/or write the data. Information services then lead themselves to monitoring to determine if and when specific data is being used.
The reuse entry point focuses on services that enable applications to share functionality. A reusable service provides reuse not just at development time, through shared code, but at runtime, through a shared execution environment. It is an especially good approach to access existing functionality in so-called legacy systems. A reusable service may or may not map nicely to an easily recognized business task; it may be an IT service that nicely encapsulates behavior that several applications need.
Reusable services can be implemented from scratch or can wrap existing functionality. When creating a brand new component, it can be made more reusable by making it a servicegiving it a context-free API and an interface based on open standards, and deploying it such that multiple applications can link to it at deployment-time or runtime. A service may simply wrap functionality that already exists, yet the wrapping still provides value by making the functionality far easier to reuse by a variety of applications, even if they're written in different languages and run on different platforms. A legacy application written in COBOL running on MVS with a copybook interface may be difficult to reuse; but create an adapter for it with a WSDL interface and XSD data structures, and then any Web services client can use it.
|Reusable functionality shortens development time by reducing redundant design and development effort and leveraging assets that have already been tested and debugged.|
The value of reuse-based services has several aspects: Reusable functionality shortens development time by reducing redundant design and development effort and leveraging assets that have already been tested and debugged. By deploying the functionality as a service, it is instantly available to any application that can connect to it. Because it is not embedded in all of those applications, bug fixes and feature enhancements are easier and less disruptive to deploy. Systems encapsulated behind a service interface are easier to later replace or outsource; they're also easier to make available to business partners.
Reusable services fit well into SOA because one of the main goals of SOA is reuse. When two business processes can use the same activity, that's reuse. When two applications need access to the same data, that's reuse. Even when the business people have difficulty identifying reusable business tasks, IT people can usually identify reusable components. Making the reusable components into reusable services makes them part of an SOA.
To start developing a reusable service, look for opportunities for reuse. When multiple applications need the same functionality, make that into a component; and rather than deploying that component embedded in the applications, consider deploying it standalone as a service that the applications link to. When accessing a legacy system, strive to wrap the access code in a service interface that's deployed with the legacy system; then it can be reused by other applications that need to access the legacy system, without each of them having to implement their own access.