Micro SOA: Service Design Principles and How to Practice (Part 1)

Quoted from: http://www.infoq.com/cn/articles/micro-soa-1/

really good article

A large number of Internet companies are embracing SOA and service-oriented, but many discussions on SOA in the industry tend to be lofty. This article attempts to discuss SOA in a relatively down-to-earth way from a slightly different perspective, focusing on the origin, nature and specific operation methods of SOA at the micro-practice level, and also introduces various popular methods in today's Internet industry. Remote calling technology, etc., is more suitable for architects and programmers who are engaged in practical work to read.

For ease of reading, this topic will be presented in two parts. This article is the first, looking at the definition of micro-SOA and briefly analyzing its core principles.

Amazon CEO Jeff Bezos: The little-known SOA guru

Because SOA has considerable difficulty and threshold, we might as well start with a small story, from which we can get a glimpse of the general idea and function of SOA.

According to Steve Yegge, a famous former Amazon employee, who famously "spit out after drinking", around 2002, CEO Bezos enforced the following six principles at Amazon (excerpted from Cool Shell ):

Program modules of all teams should expose their data and functions through Service Interface.
The information communication of the program modules between the teams must pass through these interfaces.
Other than that, there is no other means of communication. All other forms are not allowed: you can't use direct link programs, you can't directly read other teams' databases, you can't use shared memory mode, you can't use backdoors of other people's modules, etc. By calling the Service Interface.
Any technique can be used. For example: HTTP, Corba, Pubsub, custom network protocols, etc., all are fine, Bezos doesn’t care about them.
All Service Interfaces, without exception, must be designed to be open to the outside world from the core to the surface. In other words, the team must plan and design so that the interface will be open to programmers all over the world in the future, without any exceptions .
People who don't do this will get fired .

It is said that Amazon's website displays a page of product details and may call 200-300 services in order to generate highly personalized content.

Steve also mentioned:

Amazon has transformed the culture into a "service first" company, and today this is the basis for all their designs, including features that are never known to the outside world and are used only internally.

At that time, they would not have done it without the fear of being fired. I mean, they're still afraid of being fired today because it's basically every day life there, working for Bezos, the scary pirate boss. They do, though, because they already believe Service is the right direction. They have no doubts about the strengths and weaknesses of SOA, and some of the weaknesses are significant and unquestionable. But in general, this is correct, because SOA-driven design will produce a platform (Platform).

Today, we all know that Amazon has evolved from the world's largest book store to the world's most successful cloud platform...

Bezos' six principles show a high degree of foresight and strong belief. Even today, more than ten years later, it still feels deafening... I remember an old saying: "Those who do not seek for the world are not enough for a moment; It's not enough to find a corner."

Of course, a tyrannical figure like Bezos who combines divinity and magic can create both epoch-making progress and unprecedented disaster.

SOA Talk: Macro and Micro

SOA, or Service Oriented Architecture, is a particularly big topic.

For the convenience of discussion, I will briefly divide SOA into two levels (probably imitating macroeconomics and microeconomics, but there is no absolute boundary for the division here):

Macro SOA : It is oriented to high-level department level, company level and even industry level; it involves comprehensive and overall considerations in business, management, technology, etc.; the architecture system includes service governance (such as service registration, service monitoring), service Orchestration (such as BPM, ESB), service collaboration (choreography, more for cross-enterprise integration), etc. I think SOA itself is mainly an architecture oriented to the macro level, and its benefits are best reflected at the macro level, and most of the SOA industry discussions are also focused on this aspect.
Micro SOA : For limited, local teams and individuals; it involves business, architecture, and development considerations for independent, specific services.

Many industry experts believe that the concept of SOA is too abstract and not grounded. I think the main reason is that macro-level SOA involves too much and often needs to be considered comprehensively, and many aspects are far from ordinary people. The SOA at the micro level is more likely to achieve the "three closeness" proposed by Brother Tao in the past: close to reality, close to life, and close to the masses.

At the same time, the success of macro SOA usually requires the implementation and implementation of SOA at the micro level, just as macroeconomics generally requires a solid micro foundation (for example, the famous Keynesianism has been widely criticized for the lack of micro foundation)

Therefore, we focus on the purpose of SOA implementation and focus on analyzing micro-SOA, which is also a small supplement to the mainstream discussion in the industry.

SOA fixed

According to the definition of English Wikipedia: SOA is a design pattern (or design principle) of "software" and "software architecture". It is based on independent software fragments to provide their own functions to other applications through "services".

What is a "service"? According to the definition of OASIS: Service is a mechanism to access one or more software functions according to the established "interface" (in addition, this access must comply with the policies and restrictions in the "service description")

Service example (the code is usually in java example)

public interface Echo {
    String echo(String text);
}

public class EchoImpl implements Echo {
    public String echo(String text) {
        return text;
    }
}

Maybe every developer is writing similar object-oriented Service every day. Is this implementing SOA?

SOA Design Principles

Since SOA is a design principle (pattern), what does it contain? In fact, there is no standard answer in this regard, most of them follow the induction of famous SOA expert Thomas Erl:

Standardized service contract Service loose coupling Service abstraction Service abstraction Service reusability Service autonomy Service autonomy Service statelessness Service discoverability Service discoverability Service composability Sexual Service composability ....

The overall goal of these principles is to improve software reusability, reduce development and maintenance costs, and ultimately increase a company's business agility.

However, well-known experts in the industry such as Don Box, David Orchard and others have their own different summaries and emphasis on SOA.

Not only does SOA have no absolutely unified principles, but the contents of many principles themselves are quite vague and broad: for example, how loose does the so-called loose coupling principle need to be to be considered a standard? This is like how handsome a person must be to be considered a handsome guy? How many meters does a building have to be to be considered a tall building? Different people may have their own steel scale in their hearts... Partly due to these theoretical uncertainties, the SOA that different people understand or implement may actually be quite different.

Analysis of loose coupling principle

There are many SOA principles, and real understanding often requires gradual accumulation and experience, so I will not expand them in detail here. Here we only take the loose coupling of services as an example, and briefly analyze this principle from different dimensions to illustrate the richness of the connotation of SOA principles:

Implemented loose coupling : This is the most basic loose coupling, that is, the service consumer does not need to rely on a specific implementation of the service contract, so that internal changes on the service provider will not affect the consumer, and the consumer can switch freely in the future. to other providers of the contract.
Loose coupling of time : It is typically an asynchronous message queuing system. Because of the broker, the producer and the consumer do not have to maintain availability and the same throughput at the same time, and the producer does not need to wait for a reply immediately.
Loose coupling of locations : typically a service registry and an enterprise service bus (ESB), the consumer does not need to know the specific location of the provider directly, but all use the registry to find or route through the service bus.
Version loose coupling : The consumer does not need to rely on a specific version of the service contract to work, which requires the service contract to provide backward compatibility as much as possible when upgrading.

SOA and traditional software design

We can think that: SOA ≈ modular development + distributed computing

Combining the traditional best practices of the two, it is basically possible to derive most of the design principles of SOA. SOA is not a lot of new things in terms of software design (not considering business architecture for the time being).

Application of SOA principles

Based on the principles of SOA, it may be difficult for us to say that an application is absolutely in line with SOA, but it can eliminate applications that are obviously not in line with SOA.

Use the above principles of standardized contracts, loose coupling and reusability to try to analyze the Echo example above:

Echo's service contract is defined with a Java interface, rather than a platform- and language-independent standardized protocol, such as WSDL, CORBA IDL. Of course, you can raise the bar, Java is also an industry standard, and even what the National Dental Prevention Group has unanimously recognized is also an industry standard.
The Java interface greatly increases the coupling with the Service client, that is, the client must also be Java, or a dynamic language on the JVM (such as Groovy, Jython), etc...
At the same time, Echo is a Java native interface, which requires the caller to be within the same JVM process...
Although Echo's business logic is simple and independent, the above technical limitations prevent it from being easily reused in other occasions, such as distributed environments, heterogeneous platforms, and so on.

Therefore, we can argue that Echo does not quite fit the basic design principles of SOA.

Transparency towards SOA?

Modify the above Echo and add Java EE's @WebServices annotation (annotation)

@WebServices
public class EchoImpl implements Echo {
    public String echo(String text) {
        return text;
    }
}

Now, Echo is released as Java WebServices, and the underlying framework automatically generates WSDL as a standardized service contract, so that it can interoperate with various remote languages and platforms, which better solves the loose coupling and flexibility mentioned above. problem of reuse. According to general understanding, Echo seems to be an ideal SOA service.

But...even this extremely simplified example raises a number of key questions that determine some of the difficulty of SOA design and development:

Converting an ordinary Java object into WebServices by adding annotations "transparently" completes the leap from object-oriented to service-oriented?
Is it a good way to generate a WSDL service contract via a Java interface?
Are WebServices the Best Remote Access Technology?

Object Orientation vs Service Orientation

Object Orientation (OO) and Service Orientation (SO) have a lot in common in basic concepts, such as the pursuit of abstraction, encapsulation, and low coupling as much as possible.

However, compared with OO, SO has very different typical application scenarios, such as:

Most OO interfaces are only used by a limited number of people (such as teams and departments), while SO interfaces (or contracts) should generally not make too many restrictions and assumptions about the scope of users (can be different sectors, different companies, different countries). Remember the Bezos Principles? "The team must plan and design well in order to open the interface to programmers all over the world in the future, without any exceptions."
Most OO interfaces are only accessed within the process, while SO interfaces are usually called remotely.

Simply put, the scope of use of SO interfaces may be much wider than that of general OO interfaces. We use a website as an analogy: the web interface of a large website is the entry point and boundary of its entire system, which may face visitors from all over the world (so it often does work such as internationalization), and the traditional OO inside the system Interfaces and programs are hidden behind the web interface and are only used internally to a smaller extent. The ideal SO interface, like the web interface, also becomes the system entrance and boundary, which may be open to developers all over the world. Therefore, SO will be different from OO in design and development.

summary

On the basis of the above-mentioned more abstract SOA principles, we can try to derive some more detailed and operational principles to reflect the uniqueness of SO in concrete practice. Stay tuned for the next article in this series!

About the Author

Shen Li , Dangdang's architect and technical committee member, is mainly responsible for Dangdang's SOA implementation (ie service-oriented) and the development of distributed service framework. He also has long-term work experience in foreign companies such as BEA, Oracle, and Redhat, and has been engaged in the development of many different SOA-related frameworks and containers. His email: [email protected]

Thanks Ma Guoyao for reviewing this article.

To contribute to InfoQ Chinese station or participate in content translation, please email to [email protected] . You are also welcome to follow us on Sina Weibo ( @InfoQ ) or Tencent Weibo ( @InfoQ ) and communicate with our editors and other readers.