Data Service Overview

Http://www.infoq.com/cn/articles/narayanan-soa-data-services? Utm_source = bshare & utm_campaign = bshare & utm_medium = sinaminiblog & bsh_bid = 148096884

Data Service is a software service that encapsulates operations on key data entities related to enterprises. Enterprise data is stored in multiple systems. To interact with enterprise data, multiple interfaces or multiple mechanisms are required. In addition, data services must provide services to different channels (branches, online businesses, and call centers) and mechanisms (event-driven, on-demand, and batch processing, this also brings challenges to data services. If there is no abstraction layer to isolate data consumers from this complexity, integration between data sources and data consumers in an enterprise will end with an Italian point-to-point integration.

Data Service allows consumers to access or update multiple data sources. More importantly, when a consumer needs to operate multiple data sources, data service helps maintain data integrity. They can also help build reusable data services that can be used by multiple projects and innovations. Data Services can also perform key governance functions-they help to centralize, monitor, manage versions, reuse data types, and execute data visualization and access rules.

The additional benefits of data services include data source abstraction, aggregated data provider, and reuse (in a universal, interoperable, and flexible consumption mode) consistent with the Logical Data Model, multi-version support for services, value-added features, and single point of interaction. Therefore, data services provide a sustainable foundation for enterprises to improve their business needs.

Basic principles of data services

Data Source Abstraction: Data Service isolates consumers from physical data sources. This allows the data provider to change the data structure (adding/deleting tables, columns, or other database objects) and Data Format (from plain text to XML), data persistence mechanism (from a single database to multiple databases, changing database providers, adding table partitions), Data Exchange Protocol (from ODBC driver to ole db driver ), will not adversely affect each consumer. Any changes to these parameters will only affect the data service code and will not require each consumer to change its data access logic.
   
Aggregation: Data Service allows the provider to use one or more data sources to construct business entities. This idea applies not only to homogeneous data sources, but also to heterogeneous data sources. For example, aggregation can be performed between two databases or between a database and an XML document. This allows the data service to combine structured data with semi-(or non-) structured data. For example, data service can aggregate text data (such as disclaimers from a data source) and party profile data from another data source. For the consumer's needs, the provider can also use different data sources to construct a party or account data message, and then aggregate it with the target message. This allows consumers to obtain desired information without querying, accessing multiple data sources, and performing aggregation. In addition, by performing aggregation, the Data Service provides consumers with simpler programming interfaces for data access, error processing, and maintenance.
   
Reuse: Data Service can be used as Reusable Building Units for operating enterprise data. Data Services that perform CRUD (add, query, modify, and delete) and search operations on enterprise data can be reused across multiple projects. Data Services (also known as Entity services) are reusable due to several features: general nature, platform interoperability, and support for multiple consumption modes. Data Service logic can be applied to multiple business processes, which greatly promotes reuse. For example, the find party service can be used to find a party when an authorized individual on the retail account is assigned a assignment, and to find a party when merging duplicate data during a data merge activity. Data Services have cross-platform interoperability and can be used by other consumers through multiple transmission protocols (such as HTTP and JMS. They can also be accessed through mainstream information exchange modes: sending and discarding, request-response and publishing-subscription. Therefore, consumers can access these services as needed, such as through the user interface or asynchronous processes that require reliable message transmission.
   
Consistent with the Logical Data Model: By keeping data structures consistent with various data attribute behaviors, Data Service provides the ability to be consistent with Logical Data Model entities (such as profile and account. Without data services, each consumer can only interpret physical data attributes in its own unique way. The additional risk that comes with this is that the consumer is directly coupled with the provider of the underlying data structure. Data Service allows cross-mode data type reuse and cross-service operation reuse. Because the mode is defined based on the logic data model defined/dominated by the information architecture, data service provides alignment with these logic models. This allows the Data Service to use logical data values and logical data attributes (rather than system-specific values and attributes ). Why is this important? Because the biggest obstacle in the process of retiring the legacy system is the physical legacy values and attributes that are distributed and used everywhere in multiple consumption applications. This makes every consumer of Data tightly coupled with the legacy system. By keeping the data service consistent with the Logical Data Model, the data service can effectively understand consumers and legacy values and attributes.
   
Support multiple versions of the service: Data Service allows the provider to select one or more versions of the service. This allows data service providers to provide pilot services or new services to small target consumers. This also allows the data service provider to easily provide new features in the new version of the service, without forcing all consumers to upgrade at the same time. Likewise, this allows data service consumers to migrate elegantly to new data service versions.
   
Value-added functions: In addition to the basic functions of operating data entities, data services also provide value-added services, such as data caching (providing efficient/fast access to frequently accessed data) and filtering (for example, the customer only wants to receive publishing information related to a certain data entity, as well as subscription Management (publishing registration management for the customer ).
   
Single point of interaction: For consumers, data services act as a single point of interaction with data entities. They can use consistent metaphor/mechanism to operate enterprise data (profile data, account data, cross-reference, relationship data, etc.) in different data domains ). This also simplifies authentication (verify the consumer's certificate) and authentication (for example, whether the consumer has the right to execute the service? Can consumers see the properties of confidential data ?) . This single point of interaction allows organizations to have repeated consumer integration processes in multiple data services.

Scope of data services

Data Service focuses on actions on data entities-that's all. Therefore, the data service scope includes various operations on data entities, aggregating data from multiple different data sources, and using multiple protocols to simplify data interfaces for consuming multiple platforms, mappings between logical interfaces and physical Provider Interfaces, as well as elegant error handling for Data Service errors. Data supply and Big Data Extraction conversion can also use data services, although these fields generally use ETL and data profiling tools. The execution routes of Business Process Orchestration logic and business rules are not within the scope of data services because they suppress reuse. The logic related to the screen/application of the special user interface is beyond the scope of data service.

Data Service Development

The development of data services follows the "contract first" approach. service contracts-Input and Output Models-are developed based on requirements. Pattern Design should follow several guidelines and best practices, and it is necessary to review the key content here:

The Design of pattern properties, types, and elements should be combined with the Logic Data Model of Information Architecture Function release and governance. This ensures that system or technology-related identifiers/values are not exposed to the common mode contract. To ensure that the pattern is consistent with the strategic direction of the organization, standard encoding values need to be used and a new standard pass value can be added as appropriate.
   
Check whether existing contracts have the opportunity to be reused. The business entity model can also be governed by the functions of the Information Architecture. standard enterprise data entities should be reused as much as possible. For example, both get product and Create Product Data Service web methods can use the same product mode. This also applies to the design of the Publishing Service-the reuse mode when releasing data entities. The process is different from the exposure mode when calling requests. This not only saves time, but also ensures that the data service consumer has a consistent definition of the data entity when preparing the data service input or parsing the data service output.
   
When designing a WSDL contract for a data service consumer, the import mode is required to ensure that the WSDL document is consistent with the interface used for data compilation. This ensures that the WSDL document is lightweight and modular.
   
You should use tools such as web service interoperability [WS-I] wsdlvalidator to validate the schema and WSDL documentation, ensure that the data service contract does not use a platform/provider/technology-related structure that hinders interoperability and Data Service reuse.
   
Once a contract is determined, data allocation should be designed to implement it. The data orchestration module contains the data service provider component modules that are executed in a serial, parallel, or in combination. In the development process, this step will determine exactly the call sequence, the call concurrency, and the call dependency.

Data service consumption mode:

Computing Environment: Data Services can be consumed on most platforms. Most consumers use:. net public Language Runtime (CLR), Java Virtual Machine Runtime Environment (JRE), mainframe systems and Unix/Linux. All in all, this computing environment can be any environment that can execute web service calls; a reliable queue can send or receive messages.
   
Transmission Protocol: Data Services can be consumed through reliable (such as JMS on MQ series) or unreliable (such as HTTP) message transmission protocols. Some data services may only be provided by certain transmission tools based on this function.
   
Message exchange mode: Data services can be accessed through four main message exchange modes: Request-response (strict SLA), request-response (loose SLA), I .e., release, release, and subscription.

Author Profile

Vijay Narayanan is me and is currently the software development team leader, responsible for building reusable data services and automated business process components for financial service companies. I am engaged in many software projects, from individual user systems to large, distributed, multi-user platforms with multiple services. On http://softwarereuse.wordpress.com/, I have a blog about software reuse.

View Original English text:Introduction to data
Services