Will rest be the future of SOA?

It seems that no matter where we go, we can hear the saying that rest will be the future of SOA. Many publications also compare rest and soap with the ws*[1] standard, but these comparisons appear to be too simplistic. Two more mainstream approaches have emerged recently--real rest (true rest) and rest as a service-oriented technology approach (also known as rest Web Service [2]). This article focuses on whether one of these methods can improve the SOA implementation.

the true rest for SOA

The real rest of course is an implementation of resource-oriented architecture, not a purely technical decision. So when it comes to the discussion of true rest, the real question is: its underlying support-resource-oriented architecture (ROA)-is really a good fit for your SOA implementation.

To evaluate the problem correctly, let's first recall the architectural style of SOA, which is based on the functional decomposition of the enterprise Business Architecture and introduces two high-level abstractions: Enterprise business services and business processes. Enterprise business Services represent the existing IT capabilities (consistent with the business functions of the Enterprise). Business processes orchestrate business services and define the overall functionality of the business.

Rest is a set of architectural guidelines called resource-Oriented architecture (ROA). Roa is built on the concept of resources; Each resource is a distributed component that can be accessed directly, and can be handled through a standard, generic interface. Therefore, the most fundamental of resource-oriented architecture (ROA) is a resource-based decomposition [3].

The question we really need to answer in order to assess whether this true rest applies to SOA-oriented implementations is, "what is the relationship between services and resources?" "

Services vs. resources What is a service?

In the simplest case, a service can be defined as a self-contained, independently developed, deployable, manageable, and maintainable software implementation that provides the enterprise as a whole with specific business-related features and is designed to be "integrated". The service can be defined by a verb (verb) (for example, " validating Customer Credit", which describes the business function of the service implementation).

A service is not a programming structure or a set of APIs, but rather a framework for implementing an enterprise solution (design unit, implementation, and maintenance) and deployment artifacts. Service interfaces (especially for a given service) define service capabilities and can be implemented in a number of ways. There are two basic ways to define a service interface--RPC style and message (messaging) style, RPC style implementation uses service semantics and is defined by a set of parameters in the service interface. The message-style service interface is effectively fixed (essentially, it only requires "execution") to use an XML document as input and output (which is very similar to the GOF design pattern). In this case, the service semantics are determined by the semantics of the input and output messages [4].

In the past, services were often defined as collections of a set of methods, but as explained in reference [2], these methods are independent of each other [5], but as a whole they share the same namespace, simplifying the management of services.

What is a resource?

In the simplest case, resources can be defined as a directly accessible, independently developed, deployable, manageable, and maintainable software artifact that supports specific data. Resources can be defined by nouns (noun), such as "Doctor's Appointment ", which describes the data provided by the resource. A resource can also be associated with other resources and provide references (links) to them. In fact, a resource is similar to an object [6], but it is an object with predefined (CRUD) interface semantics.

The semantics in rest are based on the HTTP operation set, as follows [5]:

• createresource--Create a new resource (and the corresponding unique identifier) –put
• getresourcerepresentation--Get resource Information –get
• deleteresource--Delete a resource (optionally including an associated resource) –delete (only referenced Resource), POST (used when the associated resource needs to be deleted)
• modifyresource--Changing Resources-post
• getmetainforatmion--access to resource metadata information-head

The resource is defined by two parts: the resource URL and the input/output parameters defined on all operations provided by the resource [7]. This differs from the service in that the methods of service are completely independent and can be deployed in a separate endpoint (endpoints), while the resource approach follows the OO semantics, which means that all methods (except Createresource Must be attached to one of the underlying resources (the same URL).

the fundamental difference between resources and services

Based on the above definitions of resources and services, intuitively they are clearly different. Let's go through the differences and then discuss how they affect the final architecture.

As described in the literature [6]:

Rest is not only service-oriented, but service-oriented and rest-irrelevant

The difference between the two is further clarified in the literature [7]:

if WS-* is compared to RPC in the internet world, rest is the database management system (DBMS) of the internet world ... Traditional SOA-based integration manifests the interaction between different software artifacts through a variety of processes or methods. Rest effectively sees each software artifact as a set of database tables, and these artifacts communicate between them using SELECT, INSERT, update, and delete. (or as you want to use GET, PUT, POST, DELETE). Where do you put the business logic? In a stored procedure? Not quite right, actually in the trigger.

Here we use the Java EE to make a slightly less appropriate analogy. We think of the service as a stateless session bean, and the resource is imagined as an entity bean.

The service (or session beans) acts as a controller to control the operations required for execution, regardless of the underlying resource. For example, an expense account service may use account IDs, spending amounts, and accounts required to spend. Such a service can spend any existing account.

A resource (or entity bean) acts as a data access mechanism, facing an instance of a given data type. For example, in order to spend from an account, you need to find the information about this account before you can update it to spend on the required account. It is also a reminder that unlike entity beans that can implement any of the required methods, a rest resource has only one way to change Resources . This means that real business operations--spending--can only be encoded as part of a message request.

the conclusion of distinguishing the derivation

In summary, it is impossible to use this real rest to build an SOA system. Building the system is possible, but it must not be SOA. Both can start with a business-consistent decomposition, but they end up with completely different architectural styles based on different components and connectors because each uses a distinct decomposition method [8].

Just because they're all trying to solve the same problem--business-to-it alignment, and business-driven decomposition, doesn't mean the final architectural style is the same.

Another problem is the possibility of using the real rest to build a complete system. For these reasons, this issue is equivalent to the possibility of using only database or entity beans to build a complete system. Of course you can, but you need to add the processing code in the way stored procedures (overriding the intent of the method), or trigger (complete post-processing based on data changes). The same applies to the true rest implementation-you can only implement data updates by changing the intent of the Modifyresource method (typically using command-line mode).

Therefore, a rest-based implementation is quite different from this true rest, and it generally contains at least some of the elements of a rest Web service. So what is the rest Web service?

REST Web Services

The rest Web service approach is a method of building an SOA using rest technology purely as a means of communication. In this case, the service is defined by the decomposition of the SOA style, while the rest-based web service [9] acts as a communication.

Although generally referred to as rest, this method is not a bit related to the real rest, but is similar to pox (plain old XML over HTTP), but unlike Pox, it not only supports XML, but also supports other data types. such as JSON (JavaScript Object Notation), ATOM, binary data blocks. Moreover, unlike pox, it is usually based on get and put only, and it is based on more HTTP methods.

Thanks to the advantages of the web and the ubiquity of Ajax technology, the use of JSON is becoming a mainstream approach; Most popular browsers have built-in JSON support. Because processing XML in JavaScript, especially with many namespaces, is not an easy task, it is much easier for web implementations to use a JSON-based rest Web service. The expansion of RESTful Web services for web interaction has led to the growing popularity and widespread spread of these technologies.

What is the real difference?

Publications describing soap and rest differences often point to the benefits of rest Web services such as [11]:

• Lightweight--no extra XML markup required
• Human-readable result set
• Easy to build-no tool support required

While these differences are important (I'll discuss them later), the main difference between soap and rest is that rest is implemented directly on top of the HTTP protocol, and SOAP introduces an abstraction layer (SOAP messaging) that can be implemented on top of any transport protocol. Standardized soap bindings currently exist on HTTP, SMTP, and JMS, and non-normalized bindings have already been implemented in some other protocol solutions. This additional layer of abstraction, which provides a protocol and decoupling based on SOAP implementations, is the source of the differences between soap and rest Web services.

The view of this abstraction layer is largely dependent on the different people. The rest camp considers it a product of over-design and claims that it does not provide any real value. They claim that HTTP has provided all the features necessary for the service interaction implementation. The SOAP camp, on the other hand, argues that HTTP is not the only protocol that is typically required for service interactions (especially within an enterprise), and designing a convenient, extensible [10] abstraction layer is necessary to build robust, feature-rich service interactions.

While both viewpoints have their merits, I think it is not practical to limit the SOA implementation to a single protocol, HTTP. Admittedly, HTTP is ubiquitous, and its use generally does not need to invest in additional infrastructure, but HTTP is unreliable (Http-r is not widely adopted), synchronous (resulting in instantaneous coupling) [11], and there is no transactional semantics, and so on.

Furthermore, even if HTTP is considered to be the only protocol used in the implementation, it is very convenient to use the SOAP envelope to isolate the business information (the SOAP message body) and the infrastructure information or the additional information (the SOAP message header) from the SOAP message. In general, if your original implementation does not require any infrastructure or additional data, the entire SOAP envelope is very expensive-just two tags and provides a well-defined way to add data if necessary.

So, in every way, separating business information from infrastructure concerns in the form of data envelopes is a powerful pattern, and even rest Web service implementations often use this approach. The use of standard soap or custom envelope [12] mode depends on the implementation.

other key points of difference

Let's take a moment to discuss the differences between soap and rest Web services that are often referenced by published publications.

Simplistic

A common view is that rest is much simpler than soap. According to this view, the simple roots of rest are based on the fact that rest does not require WSDL or any interface definitions. At least this argument is a bit naïve to say. Any technology used to communicate between a service consumer and a provider must agree on the semantics of the syntax and its message interaction (interface) [13]. This means that as far as rest is concerned, one of the following two methods is possible:

• Defines an interface as text, and writes the encoding/decoding of the data "manually" based on the generic interface definition in the interface document description. Although this approach is often respected by rest enthusiasts, its interfaces contain fewer than 10 to 15 elements, but this is not a typical coarse-grained rest service. Moreover, this method is prone to error, so most viable rest frameworks abandon the method and use the following method.
• Define interfaces at the level of the XSD, based on popular frameworks (for example, XML-oriented JAXB or Castor, for the JSON-loaded Jackson) to generate data encoding/decoding. The effect of this approach is a simple version of WSDL, and requires much more work than a SOAP-based implementation. In fact, the exact same approach is often used in soap-based implementations to design a separate interface and command pattern for service execution. WSDL2.0 and/or WADL for rest is an extension of the method.

Another soap that is often complained about is the complex set of ws* standards. Although there is no single specification to list these critical ws* standard sets and their relationships, there is still a standard for most service interaction use cases. Even so, choosing an appropriate ws* standard and its usage may also require some additional understanding and implementation time, but:

It is absurd to argue about simplification or standardization in the Battle of rest and SOA, because the simplicity of no standard support can only be detrimental to cost and application manageability.

So, in addition to the simple-to-extreme examples, such as "Temperature converters", rest is not much simpler than soap.

Lightweight

Another reason that many rest enthusiasts preach that rest is a replacement for soap is that the rest request and response messages are actually shorter. This is mainly based on two reasons:

• SOAP requires a layer of XML wrappers to wrap all the request and response messages, which increases the size of the message. That's true, but the point is not how many bytes the wrapper has added, but rather the proportions it creates throughout the load. Because the size of the wrapper is fixed, its proportion becomes smaller as the message grows larger and, ultimately, negligible. Given that the General Service is fairly coarse-grained, the size of the request and reply messages is also quite large, so the load on the SOAP envelope is not a big problem.
• SOAP is an XML-based message transmission, and XML uses redundant encoding. REST, in this regard, provides a more lightweight alternative to message transport--json[14]. That's true, but with the message transfer optimization mechanism (MTOM), which is supported by most SOAP frameworks, you can split messages into smaller XML-based SOAP envelopes/Header/body parts, while the additional parts containing message content can be encoded into any MIME type, including JSON and binary streams.

While rest is theoretically lighter than soap, in fact, with some advanced soap design techniques, the difference between real-life soap and Rest message sizes is small.

Easy to build – no tooling support required

Because rest is based on HTTP, its supporters believe that we can use familiar techniques such as the Java servlet API and Java HTTP support to write the implementation side and client of the rest service without the help of any particular tool. This can be said to be true, but only if you want to "manually" implement build input/output messages and data groups. The same can be done with SOAP Web services. However, there is little hope of writing this sample code, and the result will be the use of tools, both soap and rest.

Conclusion

Rest applies both to system designs that use the ROA (the True REST method) and to SOA design implementations that use rest technology (rest Web Services). While both approaches have their advantages, they do not change the hardest part-defining business services/resources that are consistent with the enterprise business model. There are cases where both are appropriate, but in the final analysis it is entirely two different styles.

[1] Look here, there is a good analogy in the text.

[2] The word I use here, technically meaningless, does not mean rest, but is widely used in the industry, and many people think it is rest.

[3] By definition, a resource can be any component that should be directly rendered and accessed.

[4] One common implementation of this type of service is based on the "command pattern". An input document defines the command itself and the data used to execute the command.

[5] The method is independent from the fact that different methods can execute the same data--this refers to enterprise data that exists regardless of whether the service is exposed, rather than an object instance in Oo that targets specific data.

[6] For example, there is a direct analogy between OO and rest in the literature [4].

[7] Many rest advocates claim that the latter is not necessary. We'll go back to this question later in the article.

[8] architectural styles are like "design patterns" that are designed to structure and connect between different software systems. The literature [10] provides a more complete definition of architectural style, "architecture style refers to a set of schemas with the same principles and attributes"

[9] Another name that is widely used in the industry-by definition, a Web service is a SOAP message.

[10] All ws* implementations are heavily dependent on soap, especially SOAP headers.

[11] You can always implement an asynchronous message mechanism on HTTP, but you need an extra layer of abstraction, such as soap, which uses ws-addressing on it.

[12] Many rest advocates believe that HTTP already has a standard set of headers, so the SOAP message header is completely unnecessary. The problem here is that a set of predefined HTTP headers has a well-defined semantics, but any application-specific data must have a custom HTTP message header, which is the same complexity as a custom SOAP message header.

[13] An interesting example is that, in many JAX-RS implementations of the client API, the interface is often a Java interface-many support for multiple languages.

[14] Simplicity usually means high price--so try to use a JSON message to achieve polymorphism by not having to manually encode the object type

Will rest be the future of SOA?