Service Oriented Computing

Akshaya Ganesan
Assistant Professor[Off-Campus]
BITS-Pilani
Precap

• SOAP Web Services

• Structure of SOAP messages
• Service Description with Web Services Description Language (WSDL)
• UDDI
Agenda

• REST alternatives
• gRPC
• HTTP/1.1 vs HTTP/2
 Alternatives for REST
Evolution of Inter-Process Communication
• Conventional RPC – CORBA, RMI
• SOAP
• REST
• gRPC
• GraphQL

• Problems With REST

• Inefficient text-based message protocols
• Lacks strongly typed interfaces between apps
• REST architectural style is hard to enforce
gRPC

• Problems with RPC- laid the motivation for gRPC

• In 2015, Google released gRPC as an open-source RPC framework;

• An interprocess communication technology that allows you to connect, invoke, operate, and
debug distributed heterogeneous applications as easily as making a local function call.
 A microservice and a consumer based on gRPC

The service definition is specified in

The ProductInfo service is modeled in
the ProductInfo.proto file, which
such a way that it is exposed over the
both the server and client sides use
network as a gRPC service.
to generate the code.

Image Ref: gRPC: Up and Running by Kasun Indrasiri and Danesh Kuruppu
 Service Definition
gRPC uses protocol buffers as the IDL to define the service interface.
• Protocol buffers are a language-agnostic, platform-neutral, extensible mechanism to serializing structured
data.
// ProductInfo.proto
syntax = "proto3";
package ecommerce;
service ProductInfo {
rpc addProduct(Product) returns (ProductID);
rpc getProduct(ProductID) returns (Product);
}
message Product {
string id = 1;
string name = 2;
string description = 3;
}
message ProductID {
string value = 1;
}
 gRPC Server and Client

1. Implement the service logic The client stub

of the generated service provides the same
skeleton by overriding the methods as the server,
which client code can
service base class.
invoke; The client stub
2. Run a gRPC server to listen translates them to
for requests from clients and remote function
return the service invocation network
responses. calls that go to the
server side
HTTP Connection 1.x

https://developer.mozilla.org/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x
 HTTP/1
Problems
• HTTP/1.x clients need to use multiple connections to achieve concurrency and reduce latency;
• -> Head of line Problem
• HTTP/1.x does not compress request and response headers, causing unnecessary network
traffic;
• HTTP/1.x does not allow effective resource prioritization, resulting in poor use of the underlying
TCP connection
 HTTP/2
— Hypertext Transfer Protocol version 2, Draft 17
• HTTP/2 enables a more efficient use of network resources and a reduced perception of latency
by introducing header field compression and allowing multiple concurrent exchanges on the
same connection… Specifically, it allows interleaving of request and response messages on the
same connection and uses an efficient coding for HTTP header fields. It also allows prioritization
of requests, letting more important requests complete more quickly, further improving
performance.
• The resulting protocol is more friendly to the network, because fewer TCP connections can be
used in comparison to HTTP/1.x. This means less competition with other flows, and longer-lived
connections, which in turn leads to better utilization of available network capacity. Finally,
HTTP/2 also enables more efficient processing of messages through use of binary message
framing.
 HTTP/2
Frames -> Messages -> Streams -> A single TCP connection

https://web.dev/performance-http2/
 HTTP/2
Streams, messages, and frames #
• The introduction of the new binary framing mechanism changes how the data is exchanged
between the client and server.
• Stream: A bidirectional flow of bytes within an established connection, which may carry one or
more messages.
• Message: A complete frame sequence that maps to a logical request or response message.
• Frame: The smallest unit of communication in HTTP/2, each containing a frame header, which
at a minimum, identifies the stream to which the frame belongs.
Features and Benefits of HTTP/2

• It’s a binary protocol

• It used header compression HPACK to reduce the overhead size
• It allows servers to “push” responses proactively into client caches instead of waiting for a new
request for each resource
• It reduces additional round trip times (RTT), making your website load faster without any
optimization.
• HTTP/2 supports response prioritization.

HTTP/2 also has problems, We now have HTTP/3 as well!

 gRPC Communication Patterns
Four fundamental communication patterns used in gRPC-based applications:
• unary RPC (simple RPC),
• server-side streaming,
• client-side streaming, and
• bidirectional streaming.
 gRPC Communication Patterns
unary RPC (simple RPC)
rpc getOrder(google.protobuf.StringValue) returns (Order);

Image Ref: gRPC: Up and Running by Kasun Indrasiri and Danesh Kuruppu
 gRPC Communication Patterns
server-side streaming
rpc searchOrders(google.protobuf.StringValue) returns (stream Order);

Image Ref: gRPC: Up and Running by Kasun Indrasiri and Danesh Kuruppu
 gRPC Communication Patterns
client-side streaming
rpc updateOrders(stream Order) returns (google.protobuf.StringValue);

Image Ref: gRPC: Up and Running by Kasun Indrasiri and Danesh Kuruppu
 gRPC Communication Patterns
bidirectional streaming
• rpc processOrders(stream google.protobuf.StringValue) returns (stream CombinedShipment);

Image Ref: gRPC: Up and Running by Kasun Indrasiri and Danesh Kuruppu
 Message Encoding
length-prefix framing
gRPC Advantages and Disadvantages

• gRPC Advantages
• It has simple, well-defined service interfaces and schema
• It’s polyglot

• Disadvantages
• It may not be suitable for external-facing services
• The support for gRPC in browser and mobile applications is still in the primitive stages.
 Comparison
A common microservices deployment pattern with different protocols
Comparison- Key Takeaways

• The winner is, of course, “it depends.”

• Each technology has strong benefits, but those come with trade-offs.

• REST is the most ubiquitous standard for web-based APIs.

• This means it’s easy to get started, you can use a wide variety of languages, and it works
natively with web browsers.

• In their own way, GraphQL and gRPC address some of the limitations of REST.
• GraphQL allows a client to specify just the information they need, which can greatly reduce
duplicate or unnecessary data being transmitted. But, it requires additional setup and
training.
• gRPC is built for fast transport, leveraging HTTP/2. This requires a well known contract,
typically using Protocol Buffers, that is shared by the client and server.
References

1) https://accreditly.io/articles/the-differences-between-http-11-http2-and-http3
2) https://web.dev/performance-http2/
3) gRPC: Up and Running by Kasun Indrasiri and Danesh Kuruppu
Thank You!
In our next session: