SOA Service Design principles

Service Design Principle 1: Optimizing Remote Calls

The remote invocation here specifically refers to RPC (remote Procedure call). Of course, the more object-oriented argument should be remote method invocation or remote service invocation and so on.

However, the remote call method is often limited to the specific business and deployment environment, such as intranet, extranet, homogeneous platform, heterogeneous platform and so on. Sometimes it is also considered the degree of support for such things as distributed transactions, message-level signing/encryption, reliable asynchronous transmission, etc., which are often referred to as Sla:service level agreement, and even the familiarity and acceptance of developers, among others. Since so interfaces are often accessed remotely, and network transmissions, object serialization/deserialization, and so on, are much more expensive than local object accesses, so it is often important to choose high-performance remote invocation methods to speed up system responsiveness, reduce bandwidth usage, and improve throughput.

Therefore, the remote invocation method often needs to make the choice and the tradeoff according to the concrete situation.

Taking the Java remote service as an example to analyze the different scenarios, the transmission mode of some possible better choice: Intranet + Framework Java Client + large concurrency: Multiplexing tcp long connection + kryo (binary serialization) (Kryo can also be replaced with PROTOSTUFF,FST) Intranet + Different Framework Java client: TCP + Kryo Intranet + Java Client + 2PC Distributed transaction: RMI/IIOP (TCP + binary) Intranet + Java Client + reliable asynchronous invocation: JMS + kryo (TCP + binary) Intranet + different language Speech client: Thrift (TCP + binary serialization) Extranet + different language client + Enterprise features: http + WSDL + SOAP (text) extranet + for browser, mobile and other clients: HTTP + JSON (text) extranet + different language client + high Performance: HTTP + protocolbuffer (binary)

To put it simply, TCP protocol + binary serialization is better suited for intranet applications, in terms of performance. In terms of compatibility, simplicity, HTTP protocol + text serialization is better suited for extranet applications. Of course, this is not absolute. In addition, the TCP protocol here is not limited to the remote invocation protocol must be located at the fourth layer of the OSI network model of the original TCP, which can contain any non-HTTP protocol above TCP.

So, to answer the above question, webservices (classic wsdl+soap+http) is the technology that best conforms to the aforementioned SOA design principles, but not the same as SOA, and I think it only satisfies the bottom line of SOA, not necessarily the best choice for a particular scenario. This is just as a decathlon is hard to compete with individual champions on every single item. A more ideal SOA service is better able to support webservices while supporting a variety of remote invocation modes, adapting to different scenarios, which is the design principle of a distributed service framework such as Spring Remoting,sca,dubbo,finagle. Remote Invoke Technical explanation: HTTP + JSON is suitable for SOA.

JSON is easy to read, general-purpose, and even good support for browser clients, but also often used by mobile phone apps, a great alternative to XML.

But JSON itself lacks a standard schema that is widely accepted as XML, and the general HTTP + JSON remote invocation method lacks the standard IDL (interface Definition language) like thrift,corba,webservices and so on. Causes the service side and the client not to form the strong service contract, also cannot do for example automatic code generation. As a result, HTTP + JSON can significantly increase the development effort and the likelihood of errors in complex applications while reducing the learning threshold.

For example, Sina Weibo provides an open API based on HTTP + JSON, but because of the complexity of business operations, it also encapsulates the client class library of various languages on JSON to reduce the user's workload.

In order to solve this problem, the industry has many different schemes to add IDL for HTTP + JSON supplement, such as RSDL, JSON-WSP, WADL, WSDL 2.0 and so on, but in fact they are not very acceptable.

It is also worth mentioning that the JSON format is as redundant as XML, even if optimizations such as gzip compression are generally less efficient than many binary formats, while compression, decompression introduces additional performance overhead. Remote Invoke technical explanation: Apache Thrift Multi-language service Framework

Thrift is the first set of cross-language service development frameworks from Facebook that supports C + +, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C #, JavaScript, node. js, Sma Lltalk, Delphi and almost all major programming languages, with excellent versatility.

Thrift is widely used by giants such as Facebook,twitter and the open source community, and is a very mature technology.

The Thrift service contract is defined by an IDL similar to the following form:

struct User {
    1:i32 ID,
    2:string name,
    3:string password
}

service UserService {
    void Store (1: User user),
    userprofile retrieve (1:i32 ID)
}

Very similar to the C language, easy to read and easy to write, more straightforward than WSDL. It's more convenient than using programming languages like Java, and sometimes you can put all relevant interfaces and data structure definitions in the same file, publish without having to hit a compressed package, or even paste it directly into the document.

Thrift also provides tools to automatically generate server and client code for various languages based on IDL:

[Lishen@dangdang thrift]thrift--gen java user.thrift
[Lishen@dangdang thrift]$ thrift--gen cpp User.thrift
[ Lishen@dangdang thrift]$ Thrift--gen php user.thrift
[Lishen@dangdang thrift]$ thrift--gen CSharp User.thrift

I think thrift is a much simpler and more efficient technology than webservices, one of the most alternative technologies for webservices in SOA. Remote Invocation Technical explanation: Multiplexing TCP long Connections

This is a way to pursue extreme high-performance, high-elasticity, and this is just a brief introduction.

Typically, Twitter's mux RPC protocol and Google's Spdy protocol, where multiple requests share the same long connection at the same time, is the byte block in which a connection alternately transmits different requests. It avoids the recurring connection overhead and avoids the waiting idle of the connection to reduce the total number of system connections, and avoids the problem of thread-blocking (Head-of-line blocking) in TCP sequential transmission.

In addition, the domestic relatively famous open source Dubbo framework of the default RPC protocol, as well as the industry many small open source RPC framework are similar ideas.

With multiplexing, it is generally required that both the server side and the client support additional semantics similar to the session layer (the sixth layer of the OSI network model), resulting in the need to rely on the same set of RPC frameworks.

Many other RPC mechanisms are using TCP short connections. Even if some RPC uses a long connection, but a connection can only send a single request at the same time, and then the connection is idle to wait for the response to receive the request, the connection can be released or reused until the response is complete.

HTTP 1.1 also supports a long connection based on the pipeline mode, where multiple HTTP requests can also share a single connection, but it requires that the response (response) also be returned in the order of request (requests), FIFO first-out. In a fully multiplexed connection, which response is ready before it can be transmitted without queuing.

Of course, there is no absolute good or bad between short connections, long connections, and multiplexed long connections, depending on the specific business and technical scenarios, which are not expanded in detail here. Remote Invocation Technical explanation: Efficient serialization of Java

In recent years, a variety of new and efficient methods of Java serialization have been constantly refreshed, with the highest level of serialization performance, such as open-source frameworks such as KRYO,FST. They provide a very efficient serialization and deserialization implementation of Java objects, and in a typical scenario, the serialization of the JDK standard (i.e., custom serialization based on the Serializable interface), which is not considered for a standard serialization of the Externalizable interface, The serialization time overhead can be reduced by more than 20 times times, and the size of the resulting binary bytecode may be reduced by more than 4 times times.

In addition, these efficient Java serialization methods are significantly less expensive than cross-language serialization, such as thrift binary serialization, or JSON, and so on remote invocation technical interpretation: RMI/IIOP and distributed Transactions

RMI/IIOP is a standard remote invocation in Java EE, IIOP is a CORBA protocol, only RMI on IIOP supports two-phase commit distributed transactions, while providing and CORBA interoperability.

Of course, strict two-phase commit transactions are not efficient, and can seriously impact system scalability or even usability, and so on, and generally only in very critical business. Remote Call Technical explanation: Google Protocolbuffer Cross-language serialization

Protocolbuffer is a highly efficient binary serialization method developed by Google, and its serialization performance is similar to that of thrift. In fact Thrift was originally an imitation of Protocolbuffer. But the biggest difference between it and thrift is that he doesn't have an RPC implementation (because Google doesn't open up the RPC section, but there are a number of third-party implementations).

Because it is not coupled with RPC, Protocolbuffer can be easily integrated into a large number of existing systems and frameworks. In China it is also widely used in the open API, such as Baidu, Taobao, and HTTP collocation as an efficient cross-platform cross-organization integration approach. Service Design Principle 2: Eliminate redundant data

Also, because of the high cost of remote calls to the service, it is necessary to avoid the overhead of serialization and transmission in its input parameters and return results, as much as possible by avoiding redundant fields that are not required by the current business use case. At the same time, removing redundant fields can simplify the interface and avoid unnecessary business confusion for external users.

For example, there is a way to return article list in the article service

List<article> getarticles (...)

If the business requirement is simply to list the title of the article, avoid the fields such as contents and so on in the returned article.

The classic solution here is to introduce the commonly used data Transfer Object (DTO) pattern in oo to tailor the data fields to be transferred specifically for use cases of a particular service. Here is an additional data transfer object to add a ariticlesummary:

List<articlesummary> getarticlesummaries (...)

The additional dto is a real hassle, and generally OO programs can return directly to their own business model with redundancy. Principle of Service Design 3: coarse-grained contract

Also, because of the high cost of remote calls and the fact that the external consumer of the service has less knowledge of a particular business process than the people inside the organization, the contract (interface) of the service usually needs to be coarse-grained, and one of the operations may correspond to a complete business use case or business process. This reduces the number of remote calls while reducing the cost of learning and coupling.

OO interfaces can often be very granular, providing the best flexibility and reusability.

For example, article service supports bulk deletion of articles, which can be provided in OO interfaces

Deletearticle (Long ID)

For the user to make a cyclic call (without considering optimizations such as back-end SQL), but in the so interface, it is best to provide

Deletearticles (set<long> IDs)

For the client to call, reducing the possible n-time remote calls to one time.

For example, to place an order with a use case, a series of actions

PlaceOrder, Calculatetotalprice, AddItem, AddTax,

Oo We can give users the flexibility to choose, respectively, to call these fine-grained reusable methods. But in so, we need to encapsulate them in a coarse-grained way for the user to make a one-time remote call, while also hiding many of the complexities of the internal business. In addition, the client relies on 4 methods to become dependent on 1 methods, which greatly reduces the degree of program coupling.

Incidentally, if each operation in the above order case itself is also a remote service (usually within the intranet), this coarse-grained package becomes the classic service composition (portfolio) and even service Orchestration (service orchestration). In this case, coarse-grained service can also improve performance, because external network customers, multiple cross-network remote calls become a cross-network call + multiple intranet calls.

For this coarse-grained service package and combination, the classic solution is to introduce the facade pattern commonly used in Oo, masking the original object to a dedicated "appearance" interface. At the same time, it is likely to require us to introduce a new service parameter/return value data structure to combine the original object model of multiple operations, which is also used in the aforementioned dto pattern.

A simple facade example (Fooservice and Barservice are two hypothetical native Oo Service,façade that return their resultant values):

Class Foobarfacadeimpl implements Foobarfacade {
    private fooservice fooservice;
    Private Barservice Barservice;

    Public Foobardto Getfoobar () {
        foobardto fb = new Foobardto ();
        Fb.setfoo (Fooservice.getfoo ());
        Fb.setbar (Barservice.getbar ());
        return fb;
    }
}   

Of course, there are times when it is possible to add another local service and domain model outside of fooservice and barservice without facade and DTOs, which is related to a specific business scenario. Service Design principle 4: General contract

Because the service does not assume the scope of the user, it is generally supported for clients of different languages and platforms. However, various languages and platforms vary greatly in feature richness, which determines that service contracts must take the greatest common divisor of common languages, platforms, and serialization methods in order to guarantee wide service compatibility. Thus, the service contract cannot have advanced features in some languages, and parameters and return values must also be widely supported simpler data types (such as the inability to have object circular references).

If the original OO interface does not meet the above requirements, then we also need the above facade and DTOs, the OO interface into a common so contract.

For example, the original object model

Class Foo {
   private Pattern regex;
}

Pattern is a Java-specific pre-compiled, serializable regular expression (which improves performance), but with no specific framework support, it may not be possible to be directly recognized by other languages, so you can add DTOs:

Class Foodto {
   private String regex;
}

Service Design Principle 5: Isolate Changes

While both OO and so pursue low coupling, so because of the wide range of users, the need for a higher degree of low coupling.

For example, the aforementioned article Service,oo can be directly returned to the article object, and this article object within the OO program may be the core of the modeling domain model, even as O/R mapping and so on. And in so if also directly return to this article, even without the previously mentioned redundant fields, complex types and other problems, may also let external users and internal system core object model, even O/R mapping mechanism, data table structure and so on have a certain degree of correlation, so that, Internal refactoring can often affect external users.

As a result, there is a need for facade and dtos again, using them as intermediaries and buffer bands to isolate internal and external systems and minimize the impact of changes in the interior system. Principle of Service Design 6: Contract Advance

Service is often involved in cooperation between different organizations, and according to normal logic, the first task of cooperation between the two organizations, is to first sign a clear contract, detailed provisions of the content of cooperation between the two sides, the form of cooperation and so on, so as to form a strong binding and security, while everyone's work can be parallel, Don't wait for each other. Therefore, the best practice in SOA is the contract first, that is, the design of the contract, can have business, management and technology and other aspects of the people to participate in, and define the corresponding WSDL or IDL, and then at the time of development through the tool to automatically generate the target language corresponding code.

For WSDL, the threshold for contract-first is slightly higher, and it is difficult to manually compile without good XML tools. But for thrift IDL or protocolbuffer, because they are similar to common programming languages, contract design is relatively easy. In addition, for simple HTTP + JSON (assuming that no other description language is replenished), the J