SOA Implementation Styles
Shivnarayan Varma
Sr. 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 Serv...
© 2012 Fiserv, Inc. or its affiliates.
SOA Introduction
3
SOA allows the integration of existing systems, applications and...
© 2012 Fiserv, Inc. or its affiliates.
SOA vs EAI
4
EAI products are essentially the same as ESB products. The
difference ...
© 2012 Fiserv, Inc. or its affiliates.
SOA vs Web Services
5
SOA Web Services
Service Oriented Architecture” is the
term t...
© 2012 Fiserv, Inc. or its affiliates.
SOA with JEE (Java Web Service) Architecture
6
© 2012 Fiserv, Inc. or its affiliates.
SOA with JEE (RESTful Web Service)
7
© 2012 Fiserv, Inc. or its affiliates.
SOA with JEE (RESTful Web Service)
8
When should I use REST based service?
• Use RE...
© 2012 Fiserv, Inc. or its affiliates.
JAX-WS vs REST in web services
9
•
REST SOAP
• Simple point-to-point communication ...
© 2012 Fiserv, Inc. or its affiliates.
SOA with JEE (RESTful Web Service)
10
Web Services Are Web Sites
/products
/product...
© 2012 Fiserv, Inc. or its affiliates.
SOA with JEE (RESTful Web Service)
11
JAX-WS vs REST in web services
• An advantage...
© 2012 Fiserv, Inc. or its affiliates.
SOA with JEE (RESTful Web Service)
12
© 2012 Fiserv, Inc. or its affiliates.
SOA with JEE Web Service(JAX-WS)
13
© 2012 Fiserv, Inc. or its affiliates.
SOA with JEE Web Service(JAX-WS)
14
© 2012 Fiserv, Inc. or its affiliates.
SOA with JEE Web Service(JAX-WS)
15
When should I use JAX-WS based service?
• Suppo...
© 2012 Fiserv, Inc. or its affiliates.
JMS Technology
16
© 2012 Fiserv, Inc. or its affiliates.
SOA with Java/JEE and JMS (MessageMQ)
17
© 2012 Fiserv, Inc. or its affiliates.
SOA Implementation with JMS 2 Cont.
18
© 2012 Fiserv, Inc. or its affiliates.
SOA using Messaging
19
• Asynchronous messaging is fundamentally a pragmatic reacti...
© 2012 Fiserv, Inc. or its affiliates.
SOA using Messaging (Point to Point Model)
20
A Point-to-Point Channel ensures that...
© 2012 Fiserv, Inc. or its affiliates.
SOA using Messaging (Public Subscribe Model)
21
© 2012 Fiserv, Inc. or its affiliates.
SOA using Messaging (Public Subscribe Model)
22
A Publish-Subscribe Channel works l...
© 2012 Fiserv, Inc. or its affiliates.
SOA with Message BUS
23
• Use Messaging to transfer packets of data frequently, imm...
© 2012 Fiserv, Inc. or its affiliates.
SOA using ESB
24
• Limitation of MOM: Message Oriented Middleware
(MOM) provides th...
© 2012 Fiserv, Inc. or its affiliates.
SOA using ESB
25
• Why we need ESB: Finally, in an ESB, services
can be configured ...
© 2012 Fiserv, Inc. or its affiliates.26
26
Capabilities and Features of an ESB
• Message Transformation
• Protocol Transf...
© 2012 Fiserv, Inc. or its affiliates.
Typical ESB Architecture
27
•
27
Messaging Backbone
JMSWS-*
XML
Services
…
Enterpri...
© 2012 Fiserv, Inc. or its affiliates.
ESB Definition
28
© 2012 Fiserv, Inc. or its affiliates.
Without ESB SOA is difficult to manage.
29
© 2012 Fiserv, Inc. or its affiliates.
Issues with SOA using ESB
30
• In a SOA environment each service must perform ident...
© 2012 Fiserv, Inc. or its affiliates.
Relevance of EDF (ELASTIC DATA FABRIC)
31
Using MOM in combination with EDF
• There...
© 2012 Fiserv, Inc. or its affiliates.
Relevance of EDF (ELASTIC DATA FABRIC)
32
• To achieve the real promise of Service ...
© 2012 Fiserv, Inc. or its affiliates.
Relevance of EDF (ELASTIC DATA FABRIC)
33
Business Application Data:by which operat...
© 2012 Fiserv, Inc. or its affiliates.
Relevance of EDF (ELASTIC DATA FABRIC)
34
Upcoming SlideShare
Loading in …5
×

Soa implementation styles

526 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
526
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
15
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Use orange title slide for on-screen presentations only. To print, use the following white title slide instead of this one to save toner.
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • The components that participate in the JMS scenario are: Mail Service Proxy This component is used by the Processor application to deliver a JMS message that holds the information to send to the customer.
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Bullet slide example
  • Soa implementation styles

    1. 1. SOA Implementation Styles Shivnarayan Varma Sr. Architect 25th January 2013
    2. 2. © 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 Styles I. 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
    3. 3. © 2012 Fiserv, Inc. or its affiliates. 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.
    4. 4. © 2012 Fiserv, Inc. or its affiliates. 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.
    5. 5. © 2012 Fiserv, Inc. or its affiliates. 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."
    6. 6. © 2012 Fiserv, Inc. or its affiliates. SOA with JEE (Java Web Service) Architecture 6
    7. 7. © 2012 Fiserv, Inc. or its affiliates. SOA with JEE (RESTful Web Service) 7
    8. 8. © 2012 Fiserv, Inc. or its affiliates. SOA with JEE (RESTful Web Service) 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.
    9. 9. © 2012 Fiserv, Inc. or its affiliates. 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. 10. © 2012 Fiserv, Inc. or its affiliates. SOA with JEE (RESTful Web Service) 10 Web Services Are Web Sites /products /products/{id} GET HEAD 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. 11. © 2012 Fiserv, Inc. or its affiliates. SOA with JEE (RESTful Web Service) 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. 12. © 2012 Fiserv, Inc. or its affiliates. SOA with JEE (RESTful Web Service) 12
    13. 13. © 2012 Fiserv, Inc. or its affiliates. SOA with JEE Web Service(JAX-WS) 13
    14. 14. © 2012 Fiserv, Inc. or its affiliates. SOA with JEE Web Service(JAX-WS) 14
    15. 15. © 2012 Fiserv, Inc. or its affiliates. SOA with JEE Web Service(JAX-WS) 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.
    16. 16. © 2012 Fiserv, Inc. or its affiliates. JMS Technology 16
    17. 17. © 2012 Fiserv, Inc. or its affiliates. SOA with Java/JEE and JMS (MessageMQ) 17
    18. 18. © 2012 Fiserv, Inc. or its affiliates. SOA Implementation with JMS 2 Cont. 18
    19. 19. © 2012 Fiserv, Inc. or its affiliates. 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). •
    20. 20. © 2012 Fiserv, Inc. or its affiliates. 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 Queue In 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],
    21. 21. © 2012 Fiserv, Inc. or its affiliates. SOA using Messaging (Public Subscribe Model) 21
    22. 22. © 2012 Fiserv, Inc. or its affiliates. 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
    23. 23. © 2012 Fiserv, Inc. or its affiliates. SOA with Message BUS 23 • Use Messaging to transfer packets of data frequently, immediately, reliably, and asynchronously, using customizable formats.
    24. 24. © 2012 Fiserv, Inc. or its affiliates. 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.
    25. 25. © 2012 Fiserv, Inc. or its affiliates. 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.
    26. 26. © 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 transport protocol (e.g. JMS) different from the protocol (e.g. HTTP) of the Provider Transform Provider message format to Consumer 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 routing Support for WS-Security, SAML, encryption, Authentication and Authorization Support for WS-AtomicTransaction, WS-Coordination, WS-BusinessActivity Support for Orchestration & Choreography
    27. 27. © 2012 Fiserv, Inc. or its affiliates. Typical ESB Architecture 27 • 27 Messaging Backbone JMSWS-* XML Services … Enterprise Service JCA Management Monitoring Deployment … Enterprise Service Enterprise Service Base Services Extended Services
    28. 28. © 2012 Fiserv, Inc. or its affiliates. ESB Definition 28
    29. 29. © 2012 Fiserv, Inc. or its affiliates. Without ESB SOA is difficult to manage. 29
    30. 30. © 2012 Fiserv, Inc. or its affiliates. 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.
    31. 31. © 2012 Fiserv, Inc. or its affiliates. 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. 32. © 2012 Fiserv, Inc. or its affiliates. Relevance of EDF (ELASTIC DATA FABRIC) 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. 33. © 2012 Fiserv, Inc. or its affiliates. Relevance of EDF (ELASTIC DATA FABRIC) 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. 34. © 2012 Fiserv, Inc. or its affiliates. Relevance of EDF (ELASTIC DATA FABRIC) 34

    ×