Soa implementation styles

SOA Implementation Styles

Shivnarayan VarmaSr. Architect

25th January 2013

© 2012 Fiserv, Inc. or its affiliates.

What are we going to discuss

2

1. SOA Introduction

2. SOA vs EAI

3. SOA vs Web Services

4. Different SOA Implementation StylesI. SOA with REST

II. SOA with JAX-WS

III. SOA with Messaging

IV. SOA with ESB

V. SOA with Java/JEE and JMS (MessageMQ)

VI. SOA with Java based products like Gemfire/Tangosol.

VII. Sample use case for using SOA without ESB


SOA Introduction

3

SOA allows the integration of existing systems, applications and users into a flexible architecture that can easily accommodate changing needs. Integrated design, reuse of existing IT investments and above all, industry standards are the elements needed to create a robust SOA.


SOA vs EAI

4

EAI products are essentially the same as ESB products. The difference between them is ESB's addition of and emphasis on Web Services. Both EAI and ESB share the idea of a centralized point of control and try to reduce everything to a common denominator. The architecture of ESB and EAI middleware is almost the same.


SOA vs Web Services

5

SOA Web Services

Service Oriented Architecture” is the term that designates a philosophical approach to a solution’s design

The utilization of web services is one method by which such an architecture might be attained.

SOA doesn't have to be limited to Web services -- it could be built on CORBA components .

Lot many times attempting to implement SOA, only by implementing Web services end up with redundant, incompatible, and often unmanaged services that have nothing to do with architecture."


SOA with JEE (Java Web Service) Architecture

6


SOA with JEE (RESTful Web Service)

7



8

When should I use REST based service?• Use REST when the web services are completely stateless.• Scalability and Performance• Loose Coupling• Consistency and Uniformity• REST services are more light weight (use JSON) over SOAP.• When we are decided with HTTP protocol model. (JAX-WS also

supports SOAP over JMS).• We don’t need distributed transactional features.


JAX-WS vs REST in web services

9

• REST SOAP

Simple point-to-point communication using well-established HTTP verbs, protocols, and standards.

Supports a variety of transports (HTTP, JMS, etc.) Integrates with a variety of web service standards. Typically used to pass contractually structured

data between applications. Support distributed Transactions protocol,

standard messaging for retry

Agnostic to language and platform. Conceptually simpler to understand and

develop. Less reliance on tools Closer in design and philosophy to the web.

Agnostic to language, platform, and transport. Designed for distributed environments and

applications. Richer, more mature, standards-based support

and integration. Built-in error-handling (faults). Extensible through integration with other

transports and data bindings. Locked into the HTTP transport model.

Cannot be scaled to non-HTTP communication models.

Lack of standards support for security, policy, messaging, etc., making apps with richer requirements harder to develop.

Heavier abstraction and steep learning curve. More verbose. Difficult to develop without tools.



10

Web Services Are Web Sites

/products

/products/{id}

GETHEAD PUT DELETE

The product list (/)List your products

- - -

A product (/{product})

List the product’s objects

-Create the product

Delete the product

/product/{id}

Get the object’s value and metadata

Get the object’s metadata

Set the object’s value and metadata

Delete the object



11

JAX-WS vs REST in web services• An advantage of REST over SOAP is that the action is specified by

the HTTP method and by the URL; this means that fewer bytes have to be sent as compared to SOAP which relies on verbose XML. And fewer bytes mean less latency; in this scenario REST is recommended instead of SOAP.

JSON VS XML:• JSON is smaller and thus uses less bandwidth and memory during

parsing/generation .It supports Boolean and numeric values.



12

UILayer

Network Layer

text

IPhone Client Rest Handler Layer

DispatcherServlet mapped to /rest

Web.xml

1. Configure ContextLoaderListener load rest-context.xml

2. Configure Rest Servlet against<url-pattern>/service/*</url-pattern>

text

REST End Point

4

Service Layer

Ibatis DAO Layer

Database

8

5

7

10

11

Application Layer

9 6

JSON/XML Converter

SpringMethodHandler Adapter

1

2

JSON/XML Converter

startup

IPhone Client Corpoint ME Server side


SOA with JEE Web Service(JAX-WS)

13



14



15

When should I use JAX-WS based service?• Supports a variety of transports (HTTP, JMS, etc.)• Support distributed Transactions protocol, standard

messaging for retry.• Designed for distributed environments and applications.• Richer, more mature, standards-based support and

integration.• Built-in error-handling (faults).• Extensible through integration with other transports and data

bindings.


JMS Technology

16


SOA with Java/JEE and JMS (MessageMQ)

17


SOA Implementation with JMS 2 Cont.

18


SOA using Messaging

19

• Asynchronous messaging is fundamentally a pragmatic reaction to the problems of distributed systems. Sending a message does not require both systems to be up and ready at the same time. Furthermore, thinking about the communication in an asynchronous manner forces developers to recognize that working with a remote application is slower, which encourages design of components with high cohesion (lots of work locally) and low adhesion (selective work remotely).

•


SOA using Messaging (Point to Point Model)

20

A Point-to-Point Channel ensures that only one receiver consumes any given message. The channel can have multiple receivers that can consume multiple messages concurrently, but only one of them can successfully consume a particular message. If multiple receivers try to consume a single message, the channel ensures that only one of them succeeds, so the receivers do not have to coordinate with each other.

Example: JMS QueueIn JMS, a point-to-point channel implements the Queue interface. The sender uses a QueueSender to send messages; each receiver uses its own QueueReceiver to receive messages [JMS 1.1],


SOA using Messaging (Public Subscribe Model)

21


SOA using Messaging (Public Subscribe Model)

22

A Publish-Subscribe Channel works like this: It has one input channel that splits into multiple output channels, one for each subscriber. When an event is published into the channel, the Publish-Subscribe Channel delivers a copy of the message to each of the output channels. Each output end of the channel has only one subscriber, which is allowed to consume a message only once. In this way, each subscriber gets the message only once, and consumed copies disappear from their channels.

• Example: JMS Topic• In JMS, a Publish-Subscribe Channel implements the Topic

interface. The sender uses a TopicPublisher to send messages; each receiver uses its own TopicSubscriber to receive messages


SOA with Message BUS

23

• Use Messaging to transfer packets of data frequently, immediately, reliably, and asynchronously, using customizable formats.


SOA using ESB

24

• Limitation of MOM: Message Oriented Middleware (MOM) provides the ability to connect applications in a loosely coupled, asynchronous fashion. However, MOM by itself requires low-level coding in an application. Using a traditional MOM, along with custom coding techniques, can get you a long way toward a distributed integration solution. However, without a higher level of abstraction of the routing logic, this approach also suffers from having integration logic hard-wired and intertwined with the application logic. Depending on the MOM being used, even the distributed characteristic might be limited because some traditional MOM infrastructure is not capable of spanning physical network boundaries very well.


SOA using ESB

25

• Why we need ESB: Finally, in an ESB, services can be configured rather than coded. Process flow and service invocations can transparently span the entire distributed bus. An ESB provides a highly distributed integration environment that spans well beyond the reach of hub-and-spoke architectures, and a clear separation of business logic and integration logic such as routing and data transformation. An ESB architecture forms an interconnected grid of messaging hubs and integration services, with the intelligence and functionality of the integration network distributed throughout.

© 2012 Fiserv, Inc. or its affiliates. 26

26

Capabilities and Features of an ESB

• Message Transformation• Protocol Transformation• Message Routing• Security• Transaction • Orchestration• Registry

Consumer Services requests use a transportprotocol (e.g. JMS) different from theprotocol (e.g. HTTP) of the Provider

Transform Provider message format toConsumer message format and vice versa

(XML to ASCII, XML to XML, etc.)

Content based routing of Consumer messages to appropriate Provider & Vice

Versa. Support for rules based routingSupport for WS-Security, SAML, encryption,

Authentication and AuthorizationSupport for WS-AtomicTransaction,

WS-Coordination, WS-BusinessActivity

Support for Orchestration & Choreography


Typical ESB Architecture

27

•

27

Messaging Backbone

JMSWS-* XML Services …

EnterpriseService

JCA

Management Monitoring Deployment …

EnterpriseService

EnterpriseService

BaseServices

ExtendedServices


ESB Definition

28


Without ESB SOA is difficult to manage.

29


Issues with SOA using ESB

30

• In a SOA environment each service must perform identification, authentication, and authorization every time. Establishing a security context can be compute intensive relative to the rest of the work the service may perform.In SOA environment share state either passing large XML documents between steps (which can be computer and I/O intensive) or writing intermediate state to a database which adds the latency of disk I/O and created data management challenges if a process is abandoned before it is finished.

• Another difficulty may be encountered with long-running business processes, where managing state across multiple Web Service calls presents challenges in dealing with session time-outs. XML is often the preferred data standard in SOA, mainly due to

its elegance from an application interoperability standpoint. Unfortunately the flexibility comes with associated performance inefficiencies in storing, marshalling/ unmarshalling and manipulating XML documents.


Relevance of EDF (ELASTIC DATA FABRIC)

31

Using MOM in combination with EDF

• There are two especially important ways that help to reduce application latency is by reducing network and disk-based communication, and the other is by staging the data in an object format that works better with applications.

• A distributed data grid, also called a distributed data cache, operates between the database and the in-memory of an application and provides a temporary repository for data, enhancing performance by improving access and eliminating bottlenecks.

• The best way to describe a distributed cache is something that acts across one or more nodes. that they can add and remove nodes while running.

• if you start with four servers and add four more, these platforms will rebalance the data fairly evenly across the nodes and if any node goes down you are not down because they replicate the data. "So elastic caching also provides fault tolerance and high availability at a fraction of the cost of what it would take just to re-architect a database,"



32

• To achieve the real promise of Service Oriented Architectures, IT organizations need to move from a ‘centralized’ data management system, characterized by back-office databases and warehouses, to a more distributed middle-tier data fabric that provides a scalable way to access and distribute data across multiple services. Simply put, data must be accurate, timely, highly available, and instantly accessible to any business process.

• From a scalability viewpoint, services need ways to keep large datasets operationally ready for access by distributed business processes. SOA infrastructures must scale transparently and handle incremental additions of new data sources as well as additional volume of current sources

• Data Virtualization:• High Performance Data Access• High Availability• Low Latency Data Distribution

SLAs.



33

Business Application Data:by which operational data can be

held in memory for low latency access and increased system performance and throughput. The subset of data held in memory is swapped intelligently based on client request patterns. In certain cases, perational data volumes may stretch the physical limits of RAM available on a machine. In such cases data can either be partitioned across nodes or moved to disk (with indexes to the disk storage areas) to accommodate surging data loads.

Security Context:

SOA environments perform security checks and look up a user’s authorization with each invocation of a service. This means that a service invocation results in a check with a policy server or other security mechanism. These mechanisms inevitably look in a database to find this information. For globally distributed organizations this often means a trip across a WAN as well. All of this work adds latency and significantly slows down fast services. For composite processes with N number of steps this work is performed N times. If the security context is cached in GemFire it can be seamlessly shared across

all of the steps in the workflow and the services that compose that process avoiding unnecessary delays that impact QoS and



34

Soa implementation styles

Technology

public subscribe

restful web

elastic data

jee web service

distributed

based support

web services

web services