NAGP Service & Middleware presentation.pptx

NAGP Service & Middleware presentation

1. Sanjeev Nirala Dinesh Kumar NAGP Session Middleware & Services

2. 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

3. Middleware 01

4. 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

5. 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

6. 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

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

8. Mid dleware - 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.

9. Mid dleware - Evolution

10. Mid dleware - Category Applications of Middleware 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 Applications of Middleware Note: Gartner Inc. and Forrester Research

11. Mid dleware - 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

12. 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.

13. 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

14. 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 .

15. 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 ?

16. 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

17. 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

18. 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.

19. APIs in gRPC

20. gRPC Hands-On https://github.com/Dinesh-Nagarro/NAGP-2019.git 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

21. 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

22. 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

23. 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

24. 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. 

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

26. 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

27. 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

28. 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

29. RabbitMQ – Hands-On https://github.com/Dinesh-Nagarro/NAGP-2019.git 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

30. 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.

31. 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)

32. Enterprise Integration Patterns More than 50 patterns are implemented

33. 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. https://github.com/Dinesh-Nagarro/NAGP-2019.git

34. Services 02

35. 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

36. 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

37. 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.

38. 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

39. 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

40. SOA Architecture & Protocol SOA architecture is viewed as five horizontal layers. These are described below: Consumer Interface Layer : These are GUI based apps for end users accessing the applications. Business Process Layer : These are business-use cases in terms of application. Services Layer : These are whole-enterprise, in service inventory. Service Component Layer : are used to build the services, such as functional and technical libraries. Operational Systems Layer : It contains the data model.

41. SOA Importance

42. 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

43. SOA vs Microservices SOA defines four basic service types, as depicted below Business Services: Coarse-grained services that define core business operations. Represented through XML, Business Process Execution Language (BPEL), and others. Enterprise Services: Implement the functionality defined by business services. Mainly rely on application services and infrastructure services to fulfill business requests. Application Services: Fine-grained services that are confined to a specific application context. A dedicated user interface can directly invoke the services. Infrastructure Services: Implement non-functional tasks such as authentication, auditing, security, and logging. Can be invoked from either application services or enterprise services. Functional Services:  They Support specific business operations. Accessing of services is done externally and these services are not shared with other services. As in SOA, infrastructure services implement tasks such as auditing, security, and logging. In this, the services are not unveiled to the outside world. MSA has two service types, as depicted below

44. 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

45. 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

46. 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

47. 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

48. 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

49. Web Services Hands On https://github.com/Dinesh-Nagarro/NAGP-2019.git SOAP REST

50. 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)

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

52. ESB Core Features Routing: ESB has the ability to redirect a client request to a particular service provider based on deterministic or variable routing criteria. Security: ESB protects services from unauthorized access. Process Choreography & Service Orchestration: ESB manages process flow and complex business services to perform a business operation. Process choreography is about business services while service orchestration is the ability to manage the coordination of their actual implementations. It is also capable of abstracting business services from actual implemented services. Transaction Management: ESB provides the ability to provide a single unit of work for a business request, providing framework for coordination of multiple disparate systems. Decoupling: ESB can decouple clients from service providers. Transport Protocol Conversion: ESB gives you the ability to accept one input protocol and communicate with another service provider on a different protocol. Message Enhancement: ESB allows you to Isolate the client and make some basic changes to the message. For example, changing date format of incoming message or appending informational data to messages. Message Transformation: Transform an incoming message into several outgoing formats and structure. For example, XML to JSON, XML to Java objects.