NAGP Service & Middleware presentation.pptx

© 2019 Nagarro – All rights reserved 1
© 2019 Nagarro – All rights reserved
Sanjeev Nirala
Dinesh Kumar
NAGP Session
Middleware & Services

Agenda
 Middleware
 Network Interaction Model
 Socket Programming
 Middleware Introduction
 Categories
 Types
• RPC, gRPC
• OOM
• MOM
• Enterprise Integration
 Services
 Introduction
 SOA, Microservice
 Web Services
 SOAP Web Services
 RESTful Web Services
 Enterprise Service Bus
 Apache ServiceMix
 Business Process Management

Middleware
01

Network Interaction Models
Applications of Middleware
Peer-to-Peer
 No dedicated server.
 No difference between client and server side of
communication
 Each computer is responsible for making its own resource
available.
 P2P communication is facilitated using sockets
 Any computer can initiate a communication with any
other computer
 The protocol is symmetrical and masks the underlying
network communication from user
Client-Server
 Client-Server networks require dedicated servers
 A computer network in which one centralized, powerful
computer (called the server) is a hub to which many less
powerful personal computers or workstations
(called clients) are connected.
 The clients run programs and access data that are stored
on the server
 This offers centralized access to services and device
Network Interaction Models

Socket Communication
•What exactly is a Socket?
• A communication end point between computers just like electrical
socket.
• The data structure used for communication between applications.
• Sockets provide an abstraction in the session layer of ISO-OSI
• Networking model to hide the complexities of wire transmission.
•What exactly creates a socket?
• Combination of IP address and port (http://10.104.55.34:80)
•What makes a connection?
• Source (IP address: Port), Destination (IP address: Port)
• Source socket and destination socket pair uniquely identifies a
connection

Socket Communication
Sockets APIs
• bind() - Associates a socket with socket address structure (IP + Port)
• listen() - Causes a bound TCP socket to enter listening mode
• accept() – Accepts a received incoming attempt to create a new TCP connection
from remote client, and creates a new socket associated with the socket address
pair of this connection.
• socket() - Creates a new socket of certain type and allocate resources
• connect() – Assign a free local port number to a socket
• send() , recv(), write(), read(), sentdo() – For sending and receiving data to/from a
remote socket
• close() - Causes system to release resources allocated to a socket.
• gethostbyname(), gethostbyaddr() – To resolve host names and address – (IPv4
only)
Socket types
STREAM – Uses TCP, reliable, connection/stream oriented protocol
DATAGRAM – Uses UDP, unreliable, connection-less, message
oriented protocol
RAW – Raw data transfer directly over IP (no transport layer)
Sockets can use
UNICAST – for a particular destination IP
MULTICAST – a set of destinations ( 224.x.x.x)
BROADCAST – direct and limited
LOOPBACK – 127.x.x.x

Socket Communication Hands-On
https://github.com/Dinesh-Nagarro/NAGP-2019.git

Middleware - Introduction
Features
 Layer between OS and distributed applications, bridges gap between low-level OS communications and programming
language abstractions
 Provides common programming abstraction and infrastructure for distributed applications
 Hides complexity and heterogeneity of distributed system
 Shield developers of distributed systems from low-level, tedious, and error-prone platform details – such as socket
programming
 Supports protocol handling, communication faults, QoS
 Access control, authentication
 Synchronisation, concurrency, transactions management, Storage management, load balancing
 Naming, location, service discovery, replication
 Includes web/app servers, DBMS, CMS and similar tools
Middleware is a technology that is used to transfer
information from one program to one or more other
programs in a distributed environment and making it
independent from the communication protocols, OS and
hardware used.

Middleware - Evolution

Middleware - Category
Enterprise Middleware
 Enterprise middleware connects software components or
enterprise applications
 It is the layer of software between the operating system
and the applications on either side of a computer network,
usually supporting complex, distributed business software
applications.
Platform Middleware
 Platform middleware connects different application
architectures.
 Platform middleware supports software development and
delivery by providing a runtime hosting environment, such
as a container, for application program logic.
 Its primary components are in-memory and enterprise
application servers, as well as web servers and content
management
Note: Gartner Inc. and Forrester Research

Middleware - Types
Database
&
File System
RPC
&
Messaging
Location
Time
&
Security
Object
Request
Broker
(RMI, CORBA)
Transaction
Processing,
Application
Server,
Monitoring &
Email
User Interfaces,
Printing &
Multi-Media
Configuration,
Change,
Operations,
Performance
Management
Services
Middleware
Types
Data
Management
Service
Communication
Service
Distribution
Service
Object
Management
Service
Application
Co-operation
Service
Presentation
Service
System
Management
Service

Blocking & Non-blocking
Blocking
When and application issues a blocking system
call, the execution of application is suspended. The
application is moved from OS run queue to a wait
queue.
Non-blocking
A nonblocking system call doesn’t halt the
execution of the application for an extended time.
Instead, it returns quickly, with a return value that
indicates how many bytes were transferred.

Synchronous & Asynchronous
Synchronous
Synchronous basically means that you can only execute one
thing at a time.
Caller is blocked until callee returns
Asynchronous
Asynchronous means that you can execute multiple things at a
time, and you don't have to finish executing the current thing in
order to move on to next one
 Client is blocked until the server call returns – Tight coupling
 Connection overhead (marshalling, protocol overhead)
 Difficult to react to failures
 Not well suited for nested calls
 Caller sends a message and continue its work – Loose coupling
 Store and forward communication

Synchronous Vs Blocking, Asynchronous & Nonblocking
Asynchronous vs Nonblocking
Nonblocking read() returns immediately with whatever data are available –
the full number of byte requested, fewer or none at all.
An Async. read() call requests a transfer that will be performed in its entirety
but will complete and at some future time.
Synchronous vs Blocking
A Synchronous call may involve blocking behaviour or may not.
It depends on the underlying implementation (i.e. it may also be spinning,
meaning that you are simulating synchronous behaviour with asynchronous
call.

Remote Procedure Call (RPC)
 Birell and Nelson (1980s)
 Basis for two-tier systems
 Calling procedure on remote machine, masks remote function
calls as being local, procedural
 Start of the development of distributed systems
 Request/reply paradigm usually implemented with message
passing in RPC service
 Marshalling of function parameters and return value
 Basis for middleware, EAI & web
RPC Timeline
 Interfaces for procedures
 IDL – Interface Definition Language
 Compilation of IDL
 Client and server stub for every defined procedure
 Interface headers
How it works ?

Disadvantages of RPC
 Synchronous request/reply interaction
 Tight coupling between client – server
 Client may block for long time if server is loaded
 Leads to multi-threaded programming at client
 Slow/failed clients may delay server when replying
 Multi-threading essential at server
 Distributed Transparency
 Not possible to mask all problems
 RPC paradigm is not object oriented
 Invoke functions on server as opposed to methods on objects

gRPC
gRPC is a high performance, open source RPC framework, that can run in any environment, initially developed by Google. It
helps in eliminating boilerplate code and helps in connecting polyglot services in and across data centers.
It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health
checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications
and browsers to backend services.
Features
 Simple service definition
Define your service using Protocol Buffers, a powerful binary serialization toolset and
language
 Start quickly and scale
Install runtime and dev environments with a single line and also scale to millions of
RPCs per second with the framework
 Works across languages and platforms
Automatically generate idiomatic client and server stubs for your service in a variety of
languages and platforms
 Bi-directional streaming and integrated auth
Bi-directional streaming and fully integrated pluggable authentication with http/2 based
transport

Protocol Buffers in gRPC
Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data –
think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use
special generated source code to easily write and read your structured data to and from a variety of data streams and using a
variety of languages.
Pick your favorite language
Protocol buffers currently support generated code in Java, Python, Objective-C, and C++. With our new proto3 language version, you can also
work with Dart, Go, Ruby, and C#, with more languages to come.

APIs in gRPC

gRPC Hands-On
The framework is based on a client-server model of remote procedure calls. A client application can directly call methods on a
server application as if it was a local object.
Following steps to create a typical client-server application using gRPC:
• Define a service in a .proto file
• Generate server and client code using the protocol buffer compiler
• Create the server application, implementing the generated service interfaces and spawning the gRPC server
• Create the client application, making RPC calls using generated stubs

Object Oriented Middleware (OOM)
Java Remote Method Invocation (RMI)
 Distributed objects in Java
 RMI compiler creates proxies and skeletons
 RMI registry used for interface lookup
 Single-language system in Java
Common Object Request Broker Architecture (CORBA)
 Language- and platform independent
 Architecture for interoperable distributed computing
 Internet Interoperability Protocol (IIOP)
 CORBA Interface Definition Language (IDL) - Stubs (proxies) and
skeletons created by IDL compiler
 Interface Repository - Querying existing remote interfaces
 Implementation Repository - Activating remote objects on demand
 Objects can be local or remote
 Object references can be local or remote
 Remote objects have visible remote interfaces
 Masks remote objects as being local using proxy objects
 Remote method invocation
 Support for object-oriented programming model
Objects, methods, interfaces, encapsulation, Exceptions
 Synchronous request/reply interaction
 Location Transparency
System (ORB) maps object references to locations

Disadvantages of OOM
 Synchronous request/reply interaction only
 Asynchronous Method Invocation (AMI)
 But implementations may not be loosely coupled
 Distributed garbage collection
 Releasing memory for unused remote objects
 OOM rather static and heavy-weight
 Bad for ubiquitous systems and embedded devices

Message Oriented Middleware (MOM)
Message-oriented middleware is software or hardware infrastructure supporting
sending and receiving messages between distributed systems.
 Communication using messages
 Messages stored in message queues
 Message are sent and received asynchronously
 Message servers decouple client and server
 Various assumptions about message content
Challenges with integration solutions
 Networks are unreliable
 Networks are slow
 Any two applications are different
 Change is inevitable
Integration styles
 File Transfer
 Shared database
 Remote method Invocation
 Messaging
Client App.
local message
queues
Server App.
local message
queues
message
queues
Network Network Network
Message Servers

MOM Properties
Message is transmitted in following steps
 Create — The sender creates the message and populates it with data.
 Send — The sender adds the message to a channel.
 Deliver — The messaging system moves the message from the sender’s computer to the receiver’s computer, making it available to the receiver.
 Receive — The receiver reads the message from the channel.
 Process — The receiver extracts the data from the message.
MOM Features
 Remote Communication.
 Platform/Language Integration.
 Asynchronous Communication.
 Variable Timing.
 Throttling.
 Reliable Communication.
 Disconnected Operation.
 Mediation.
 Thread Management.

How MOM helps in decoupled architecture
• Decoupling database writes
• Seamlessly adding new functionality
• Replication of data and events

MOM models
Point-To-Point
• P2P Model uses “Queue” as Destination
• In P2P Model, a Sender or Producer creates and sends messages
to a Queue
• In P2P Model, a Message is delivered to one and only one
Consumer
• We can configure any number of Senders and Receivers to a
queue

MOM models
Pub/Sub
• Publisher creates and publishes messages to Topics
• Subscriber subscribes to interested Topics and consumes
all messages
• Pub/Sub Messaging model has timing dependency,
• Messages posted before subscription is not available to
consumers
• Any messages posted before subscription or any
messages posted when it is inactive, cannot be delivered
to that Consumer
• Unlike P2P Model, in this model Destination does not
store messages
S.
No.
Point-Point Messaging
Model
Publish/ Subscribe
Messaging Model
1.
Each Message is
delivered to one only
and one Receiver
Each message is delivered
to multiple Consumers
2.
P2P Model has no
timing dependency
Pub/Sub model has some
timing dependency
3.
Receiver sends
acknowledgements to
Sender once its
receiver messages
Acknowledgement is not
required

RabbitMQ – Messaging Middleware
 Open-source message-broker software that originally
implemented the Advanced Message Queuing Protocol and has
since been extended with a
 Plug-in architecture to support STOMP, MQTT and other
protocols.
 Lightweight and easy to deploy on premises and in the cloud.
 Supports distributed and federated configurations to meet high-
scale, high-availability requirements.
Features
 Asynchronous messaging
 Distribute deployment
 Enterprise & cloud ready
 Tools & Plugins
 Management & Monitoring
 Developer experience

RabbitMQ – Hands-On
 The producer publishes a message to an exchange. When creating an
exchange, the type must be specified.
 The exchange receives the message and is now responsible for routing the
message. The exchange takes different message attributes into account, such
as the routing key, depending on the exchange type.
 Bindings must be created from the exchange to queues. In this case, there are
two bindings to two different queues from the exchange. The exchange
routes the message into the queues depending on message attributes.
 The messages stay in the queue until they are handled by a consumer
 The consumer handles the message.
https://customer.cloudamqp.com/instance

EI Framework (Apache Camel)
 Open source framework for message-oriented
middleware with a rule-based routing and mediation
engine
 Java object-based implementation of the Enterprise
Integration Patterns using an API to configure routing
and mediation rules
 URIs to work directly with any kind of Transport or
messaging model such as HTTP, ActiveMQ, JMS, JBI,
SCA, MINA or CXF,
 Pluggable Components and Data Format
 Small foot-print and dependencies, can easily be
embedded in any Java application.

Enterprise Integration Patterns
 EAI and SOA platforms, such as IBM WebSphere MQ
, TIBCO, Vitria, Oracle Service Bus, WebMethods
(now Software AG), Microsoft BizTalk, or Fiorano.
 Open source ESB's like Mule ESB, JBoss Fuse,
Open ESB, WSo2, Spring Integration, or Talend ESB
 Message Brokers like ActiveMQ, Apache Kafka, or
RabbitMQ
 Web service- or REST-based integration, including
Amazon Simple Queue Service (SQS) or
Google Cloud Pub/Sub
 JMS based Message Service
 Microsoft technologies like MSMQ or
Windows Communication Foundation (WCF)

Enterprise Integration Patterns
More than 50 patterns are implemented

Apache Camel Hands-On
 Define a route using domain-specific languages (DSL) for programming languages like Java or Groovy or routes in XML with Spring DSL
 Java DSL offers a bit more features which are not supported in Spring DSL. However, Spring DSL is sometimes more beneficial as XML can be
changed without the need to recompile the code.

Services
02

IT Business Challenges
 Uncertainty about the future
 Financial management
 Monitoring performance
 Regulation and compliance
 Competencies and recruiting the right talent.
 Technology
 Exploding data
 Customer service
 Maintaining reputation
 Knowing when to embrace change

Application Architecture Approaches
TCP/IP - IPC MOM/XML
SOAP, ESB, BPM
REST, Cloud, Mobile
CORBA, COM/DCOM, RMI, EJB
Monolithic Architecture EAI EDA/MSA
SOA
RPC

Service Oriented Architecture
 Service-oriented architecture (SOA) is a style of software design where services are provided to the other components
by application components, through a communication protocol over a network.
 An SOA service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently,
such as retrieving a credit card statement online.
 SOA is also intended to be independent of vendors, products and technologies.
SOA Core Values
 Business value is given more importance than technical strategy.
 Strategic goals are given more importance than project-specific benefits.
 Intrinsic inter-operability is given more importance than custom integration.
 Shared services are given more importance than specific-purpose
implementations.
 Flexibility is given more importance than optimization.
 Evolutionary refinement is given more importance than pursuit of initial
perfection.

SOA - Principles
 Standardized Service Contract
Services adhere to a service-description
 Loose coupling
Services minimize dependencies on each other
 Service Abstraction
Services hide the logic they encapsulate from
the outside world.
 Service Reusability
Logic is divided into services with the intent of
maximizing reuse
 Service Autonomy
Services should have control over the logic they
encapsulate
 Service Statelessness
Ideally, services should be stateless
 Service Discoverability
Services can be discovered (usually in a service registry)
 Service Composability
Services break big problems into little problems
 Service Interoperability
Services should use standards that allow diverse
subscribers to use the service

SOA Elements
Service Definition:
 It logically represents a business activity with a specified
outcome.
 It is self-contained.
 It is a black box for its consumers, meaning the consumer does
not have to be aware of the service's inner workings.
 It may consist of other underlying services
Service components:
 The interface defines how a service provider will perform
requests from a service consumer
 The contract defines how the service provider and the service
consumer should interact
 The implementation is the actual service code itself

SOA Importance

Microservices
Microservices - also known as the microservice architecture - is an
architectural style that structures an application as a collection of
services that are
Highly maintainable and testable
Loosely coupled
Independently deployable
Organized around business capabilities
Owned by a small team
The microservice architecture enables the rapid, frequent and reliable
delivery of large, complex applications. It also enables an organization
to evolve its technology stack

SOA vs Microservices
SOA Architecture
Follows “share-as-much-as-possible”
architecture approach
Importance is on business
functionality reuse
They have common
governance and standards
Uses Enterprise Service bus (ESB) for
communication
Multi-threaded with more overheads to
handle I/O
Maximizes application service reusability
Traditional Relational Databases are more
often used
A systematic change requires modifying
the monolith
DevOps / Continuous Delivery is becoming
popular, but not yet mainstream
Microservice Architecture
Follows “share-as-little-as-possible”
architecture approach
Importance is on the concept of “bounded
context”
They focus on people, collaboration and
freedom of other options
Simple messaging system
They use lightweight protocols such
as HTTP/REST etc.
Single-threaded usually with the use of Event
Loop features for non-locking I/O handling
Focuses on decoupling
Modern Relational Databases are more often
used
A systematic change is to create a new
service
Strong focus on DevOps / Continuous
Delivery

Web Service
 Web service is a standardized medium to propagate
communication between the client and server applications
on the World Wide Web.
 A server running on a computer device, listening for
requests at a particular port over a network, serving web
documents (HTML, JSON, XML, Images), and creating web
applications services, which serve in solving specific
domain problems over the web (www, internet, HTTP)
Web service Types

Web Service - SOAP
 SOAP stands for Simple Object Access Protocol. It is a XML-based protocol for accessing web services.
 SOAP is a W3C recommendation for communication between two applications.
 SOAP is XML based protocol. It is platform independent and language independent. By using SOAP, you will be able to interact
with other programming language applications.
 Client contacts UDDI registry to find service
 Client retrieves WSDL
 Client builds SOAP message
 Client sends SOAP message to web service
 Service sends a SOAP response

Web Service - REST
 An architectural style of client-server application
 Centered around the transfer of representations of resources through
requests and responses
 Data and functionality are considered resources and are accessed using
Uniform Resource Identifiers (URIs), typically links on the Web
 The resources are represented by documents and are acted upon by using
a set of simple, well-defined operations
 Loosely coupled and lightweight web services that are particularly well
suited for creating APIs for clients spread out across the internet
Features of a RESTful Services
 Messages
 Representations
 URIs
 Uniform interface
 Stateless
 Links between resources
 Caching
Principles of a RESTful application
 Resource Identification through URI
 Uniform Interface for all resources:
• GET (Query the state, idempotent, can be cached)
• POST (Update a resource or create child resource)
• PUT (Transfer the state on existing/new resource)
• DELETE (Delete a resource)
 “Self-Descriptive” Message representations
 Hyperlinks to define relationships between resources and valid state
transitions of the service interaction

SOAP Vs Rest
SOAP REST
Meaning Simple Object Access Protocol Representational State Transfer
Design Standard protocol with predefined rules to follow Architectural style with loose recommendation and
guidelines
Approach Function-driven Data-driven
Statefulness Stateless by default but a SOAP API can be made stateful Stateless in nature, no server-side sessions
Caching API calls are not cached API calls are cached
Security WS-Security with SSL support. Provides an inbuilt ACID
compliance
Supports SSL and HTTPS
Performance Requires more power, resources, and bandwidth. Requires fewer resources
Messaging format Only XML XML, JSON, plain text, YAML, HTML and others
Transfer protocols SMTP, HTTP, UDP, and others Only HTTP
Nature Heavyweight Lightweight
Recommended for
Financial services, enterprise level apps, payment gateways, high-
security apps, telecommunication services.
Public APIs for web services, social networks, and mobile
services.
Advantages Standardization, security, extensibility High Performance, Scalability, Flexibility and browser
friendliness
Disadvantages More complex, poor performance, less flexibility Unsuitable for distributed environments, less security

Web Services Hands On
SOAP REST

Enterprise Service Bus
An enterprise service bus (ESB) is a middleware tool which connects all the services together over a bus like infrastructure. It
acts as communication center in the SOA by allowing linking multiple systems, applications and data and connects multiple
systems with no disruption
Popular ESB implementations:
 Jboss ESB (http://www.jboss.org/jbossesb/)
 Apache Servicemix
(http://servicemix.apache.org)
 Open ESB (http://www.open-esb.net/)
 Mule ESB (http://www.mulesource.org)
 JBoss Fuse
(http://www.jboss.org/products/fuse)
 WSO2 ESB
(http://wso2.org/downloads/esb)

Need of ESB
Point-to-point, unique and custom made integration solution Integration solution using ESB

Apache ServiceMix
Apache ServiceMix is a flexible, open-source integration container that unifies the features and functionality of
Apache ActiveMQ, Camel, CXF, and Karaf into a powerful runtime platform you can use to build your own
integrations solutions. It provides a complete, enterprise ready ESB exclusively powered by OSGi
Core Features
 Reliable messaging with Apache ActiveMQ
 Messaging, routing and Enterprise Integration Patterns
with Apache Camel
 WS * and RESTful web services with
‐ Apache CXF
 OSGi-based server runtime powered by Apache Karaf
Additional Features
 BPM engine via Activiti
 Full JPA support via Apache OpenJPA
 XA transaction management via JTA via Apache Aries
 Legacy support for the JBI standard (deprecated after the
ServiceMix 3.x series) through the Apache ServiceMix
NMR that includes a rich Event, Messaging and Audit API

Apache ServiceMix Hands-On
Scenario1: File routing Scenario1: Routing & Messaging

THANK YOU

NAGP Service & Middleware presentation.pptx

More Related Content

Similar to NAGP Service & Middleware presentation.pptx

Recently uploaded

NAGP Service & Middleware presentation.pptx

Editor's Notes