Service-oriented development with consumer-driven contracts

The transition to SOA presents many new challenges to the software development lifecycle: Organizations can overcome these challenges only by forming a well-defined service-oriented development capability.

The challenges that SOA poses to development

Service orientation is not just about adopting a new architecture. SOA actions are sure to fail if organizations make their architectures more service-oriented and do not change their development technologies accordingly.

Some of the challenges in starting, building, and operating services include:

In the start-up phase, the description of the service function must be reusable in a variety of contexts: the granularity can be reused only in a particular situation, or in a large number of complementary jobs, and can be reused in different situations.

When building services, we must ensure that providers and consumers can evolve independently of each other. If the consumer of a service function must change with the provider, then the service is not really loosely coupled.

When running services, we need to understand the relationships between services so that we can diagnose problems, assess the impact of changes in service availability (availability), and evolve design plans for new or changing business requirements for each service.

From the perspective of an overall asset, the specific development lifecycle of each service must be coordinated and not unduly tied to a single, extremely slow, and ultimately unsustainable schedule of activities.

The challenge that SOA poses to the software development lifecycle stems from the federated nature of service assets. Valuable business results are no longer implemented by applications that "have one-way time activity tables, and where ownership, budget, and operational boundaries are dispersed", rather than through interactions between services that "have their own unique service development lifecycle." However, reconciling these lifecycles is not a one-time fix. Instead, as we will see, we need to identify a group of collaborative activities and artifacts that represent "commitment to deliver a common outcome" (collaborative activities and artefacts). These activities and artifacts provide the basis for a moment, if simply seen, to unite the development lines.

Implementing SOA with an agile approach means early delivery of high-value business results and often the need to publish versions frequently. If the agency tries to adopt this approach, it will only further aggravate the development challenge. Despite its name, many people believe that agile software delivery is detrimental to the institutional agility benefits associated with SOA. The frequent release of agile methods is often dispensed with because of the operational risk of publishing new versions of services in environments where there are many known associations between services. Moreover, while agile encourages close and timely collaboration, such activities are difficult to coordinate across multiple services and their lifecycles.

Federal expectations

Traditional chimney-type application development excludes each other's delivery line (delivery streams) from business ownership, budget, and operational boundaries. The difference between service-oriented development and traditional chimney-style application development is that it emphasizes external dependencies and constraints and integrates them into every step of the development lifecycle. This is an area of SOA governance: managing delivery relevance and arranging delivery lines around a public representation of "service assets and the business activities, processes, and results supported by that asset." SOA governance relies on insights and feedback-insights into the current state of the service catalog, and feedback on the impact of evolving service providers and consumers. We can create artifacts of federal expectations and constraints, thus enhancing the ability to gain insight and feedback. These artifacts can then be transferred between phases in a particular service development line (the service development stream) and/or exchanged between different development lines.

One practical way to master and exchange expectations and constraints is to use so-called consumer-driven contracts (Consumer-driven contracts). The consumer-driven contract is a member of a tightly connected service contract of three sets-the provider contract, the consumer contract and the consumer-driven contract, which describes the relationship between the service provider and the service consumer from the perspective of expectation and constraint:

Provider contract (Provider contracts)--provider contract is one of our most familiar service contracts, reference Wsdl+xml Schema+ws-policy. As the name implies, the provider contract is centered on the provider. The provider prescribes what it is to provide; then the consumers bind themselves to this rigid contract. No matter how much functionality the consumer actually needs, the consumer accepts the provider contract and then couples the entire functionality of the provider.

Consumer Contracts (Consumer contracts)--on the other hand, a consumer contract is a more precise description of a consumer's needs. The consumer contract describes a specific part of the provider's functionality that is required by the consumer in a specific interactive context. Consumer contracts can be used to label an existing provider contract, and consumer contracts also help to identify a provider contract that is not yet defined.

Consumer-driven contracts (consumer-driven contracts)-consumer-driven contracts describe the constraints that a service provider promises to all its current consumers. Consumer-driven contracts are created once consumers have communicated their specific expectations to the provider. Constraints created on the provider side determine a consumer-driven contract. If the provider accepts a consumer-driven contract, it can improve and modify its services by simply ensuring that the existing constraints are met.

Life cycle for service-oriented development