Achieving initial success for a Service Oriented Architecture (SOA) is defined by:

• the creation of loosely coupled consumer-provider connections,
• compliance with the principle of separation of responsibilities between the consumer and the supplier,
• publish a set of reusable, shared services
• and ensuring that consumers accept and use the service.

Many development teams create and use services, but there is still a painful selection of architecture in which services will be widely used, with the potential for reuse by internal development teams. Instead of creating a consistent service architecture and demonstrating the multiple use of the same services, developers again and again do not purposely create Just a Bunch of Web Services (JBOWS) or Just a Bunch of REST Services. of REST Services (JBORS)).

A simple application most often works with some kind of service and a spaghetti network of endpoints, data providers of this service, which are intertwined with one-to-one connections. Many teams agree in this case that the focus on SOA and REST is not that it helps in solving flexibility issues. Rather, a substitution of a set of IT tools, message formats and protocols takes place.

Managing an SOA, API, and application can become a bridge between these concepts and improve the architectural consistency of the entire solution.
')

Services, API and architecture

When you decide what to use as best practices for a service-oriented architecture, define the design of RESTful services, when you form a plan for managing them, clearly define how your services and API fit together into the overall architectural picture.

Externally, the RESTful API set is simply specialized versions of web services and provides similar technical capabilities. Design and REST API, and SOA services involves the disclosure of atomic functionality using well-defined interfaces. The end-point public contract (API) and service end-point serve as basic units for building the core of systems, and developers present their solutions by controlling access, aggregation, composition, and orchestration of endpoint interaction. A successful and expandable solution for both API and SOA requires resolving issues related to:

• Infrastructure for delivering messages via the Internet / Intranet,
• service level management
• security, in every sense of the term.

SOA and API have common problems of integration, endpoint layout, message model definition, security, and quality of service. Managed APIs are “SOA implemented as needed.”

Managed APIs are:

• Having an active alert model and enabling subscriptions.
• Supplied with a service-level agreement (SLA).
• Reliable, with authorization and authentication, protected.
• With the ability to monitor and monetize analytics.

Most service endpoints are deployed on platforms that do not provide management capabilities, although services must demonstrate the characteristics of a managed API. Using the Facade pattern for the API allows developers to create a layer for managing endpoint addresses, monitoring usage, enforcing usage quotas, restricting traffic, and authorizing consumers.

Combining control for SOA and API can allow teams to use the benefits of both SOA services (reuse and evolutionary implementation) and API (extended scope and uncoupled interfaces)

SOA management

In many organizations, the implementation of SOA results in a point-to-point integration of services, rather than in building a real architecture. Approximately, as in the picture below, everything is connected with everything.



To achieve the desired state of the architecture, developers must modify existing service management programs to mitigate risk factors and support SOA principles. Deferring a centralized service management solution often results in highly specialized, non-reusable services, the rapid spread of multiple business domain implementations (and this will not follow the bounded domain context principle), which ultimately leads to an increase in the cost of supporting the entire solution.

Effective SOA management programs control the development and operation of service-oriented systems. Commands that implement SOA solution management use prescriptions, processes, dimensions, and organizational initiatives of the following kind:

• Prescriptions define "how to do the right thing right." They describe laws, guidelines, corporate rules and best practices.
• Processes are actions that make it possible to check a project or artifact for compliance with prescriptions, and decide whether to give the green light or reject it. Some processes can be automated and run automatically, others require attention and time of the team.
• Measurements help determine the effectiveness of a management program, and are also required to understand how processes comply with regulations.
• The organization should promote a culture that supports and rewards management practices.

The SOA systems management program should provide guidance on the entire solution life cycle, including: creation, testing, support, deletion, management, and versioning.

The SOA component management infrastructure must provide tools and services to support the management program. They should provide mechanisms for managing and supporting regulations. Mechanisms for the introduction of checkpoints in various phases of software development and the ability to verify that services, API and other projects comply with the regulations. Support automatic and manual stages of acceptance, handling of exceptional situations.

Some SOA governance policies provide management guidance during development and during operations. The service registry can help manage components that are both in development and in active use.

The service portfolio is “A” in SOA

The key goal of any SOA system is to build and maintain a portfolio of services that represents a clear and clean architecture. You can start building such a service catalog based on the technology and business domains of the organization. Working through the interaction of services and interfaces is only a small part of all the actions that need to be performed in order to build a highly efficient system for delivering, interacting and maintaining trust in your set of services.

Running additional projects such as optimizing an application, identifying hidden business processes, or building a business information architecture is an excellent mechanism for understanding data dynamics, decomposing a business domain, and determining which programs and services should support business processes.

API Management

Obviously, the goals and objectives of the business have a significant impact on the management of public contracts. Leading API management platforms provide the ability to conduct analytics and assess business value. The platform should provide collection of information about subscription, use, provide performance metrics, and also have integration with billing and payment systems.

API management includes subscription management and API metadata promotion. The last point is optimizing the use of tags for creating categories of API and supporting documentation for developers. The management process must ensure the passage of check-points during the design of the API and before it is published.

The API economy should include measurements on completeness of use and load. API management in this sense includes tracking API usage (by version, by API type) and load (by version, by API type), as well as other measurements and prescriptions. Through an understanding of the use and load on the API, business owners and API architects can consciously invest in the development, expansion of infrastructure, optimize the structure and completeness of services.

Best management practices

For effective and productive provision of IT solutions, the development team must synchronize the actions for managing the API and services. API management includes an obvious set of developmental stages (creation, publication, reduction, end of support, blocking), each step of which can be redefined. Management logging facilitates service metadata management, design, development, testing, and operational intervention. The screenshot below shows the intersection between two management processes:

Summary of requirements

Documentation and a description of the interaction of public contracts or services significantly affects how widely the capabilities of consuming, aggregating, orchestrating, or combining API and services across the organization’s domain boundaries will be used. Supporters of API refuse heavy, formal interfaces of interaction towards the documentation clear for the person.

Best REST practices begin to influence the design and description of systems. When creating RESTful API and SOA services, you should pay attention to the following points:

• Do not reveal endpoints that provide fragile data models and dictate a complex interaction pattern.
• Qualitatively describe how the session context and its state affect each other.
• Qualitatively document the message model.
• Describe usage limits and security issues (for example, authorization protocols, how to authenticate a user).
• Hide implementation details from external interfaces.

API and Service Metadata Documentation

Operating SOA and APIs should include metadata definitions and prescriptions that help identify, classify, and describe potential customers. Metadata should assist in the formation of data about the service or API. Prescriptions are used to match metadata with published services and endpoints. Metadata can answer the following questions:

• Overview (e.g. name, description)
• Life cycle attributes (version, depending on versions of other services, development / support status)
• Classification (basic service, composite, infrastructure, business)
• Endpoint Attributes (protocol, address, WS- * specification)
• Data model (JSON, RAML, XML, WSDL schema, version, semantics, checks)
• Requirements and regulations at the service level (availability, responsiveness, security, capacity, capacity)
• Dispatching (redirection, ordering, caching, transformations)
• Dependencies (APIs, services, databases, location, frameworks)
• Physical dependencies (application platform, security, management)
• Business process model (UML diagrams, business classifications)
• Interaction information (consumers, suppliers, recycling)
• Usage statistics (number of users, availability, bandwidth, time peaks)
• Accounting and stimulation methods (charge for shows, subscription, size of returns)

Metadata allows you to define a formal description of the endpoint, to ensure accessibility / detectability and reuse by other teams. Many organizations do not use all these options, they simply simplify the service logic. They are working to create a single service or API that will allow you to perform critical business scenarios, revise the systematization of metadata, and increase reusability for internal development teams.

Management balance

To achieve a productive balance between soft action and total control, it is necessary to take into account all kinds of obstacles and the culture of development within the development team. The actions associated with the implementation of SOA / API, can often slow down because of:

• Lack of education, knowledge, and support from knowledgeable people
• Distrust or lack of communication within the organization
• Conflicting incentives
• Poor SOA / API per se design
• Lack of metrics
• Lack of control

Leadership is necessary, but if management processes are burdensome, they will cause discontent and resistance. Processes should look natural or automated at any opportunity. For example, compliance with some rules can be checked automatically with a check or during registration of the service in the system. Look for tools that can organically integrate into the workflow of developers, so that they can easily and simply receive information from the system, that some part of the result of their work does not comply with the regulations and a correction is necessary. Contract management systems can be invaluable in managing resource consumption, service improvement requests, development lifecycle management, and API versioning.

Next steps for organizing API management

Successful large and small SOA solutions, API-oriented solutions of the enterprise scale - are based on a wide reuse of services and information in all areas of business, across all domains and development teams. Successful management includes:

• Organization of a centralized review of system design
• Strengthen control over information models and ways to implement them
• Implementation of compliance monitoring
• Creating a general agreement on the use of services
• Inventory of application and integration capabilities
• Implement the API management review process to timely reflect changes in the software and services capabilities catalog.
• Extend software lifecycle management to maintain service orientation.

---

With this post, I want to draw attention to the use and design of the API in your products. This article tells you that SOA is not just a set of services, it is more, you can also project this idea into other areas of development: the creation of desktop applications, frameworks, libraries, and so on. The success of your enterprise depends on the convenience and consistency of the API.

Since, in our opinion, this topic is very relevant and will be increasingly relevant, we at GoSharp decided to organize a conference on this topic and are waiting for applications from those who have something to say on the subject of design, development and API support.