Please enable JavaScript.
Coggle requires JavaScript to display documents.
Service Oriented Architecture - Coggle Diagram
Service Oriented Architecture
What is a service?
A reusable component that can be used as a building block to form larger, more complex business application functionality
A service may be as simple as “get me some person data,” or as complex as “process a disbursement.”
A service provides a discrete business function that operates on data.
How the service is implemented, and how a user of the service accesses it, are limited only by the SOA infrastructure choices of the enterprise.
Component of distinctive functional meaning that typically encapsulate a high-level business concept
Service contains
Contract – message type def, constraint, description (comment)
Interface – set of operations
Implementation – Logic and data
Characteristics of a Service
Supports open standards for integration
Loose Coupling
Stateless
Location Agnostic
Type of Services
Business Process
Activities/Tasks/Services
Application/Packages
Infrastructure
Example of a Service
Creating a Purchase Order inside a mainframe application
Requesting and reserving a room in a hotel
Applying for a loan by filling out a loan request form
Search books/music based on keywords
What is SOA
A set of components which can be invoked, and whose interface description can be published and discovered (W3C)
A client/server design approach in which an application consists of software services and software service consumers (also known as clients or service requesters).
Distributed Deployement
Expose enterprise data and business logic as loosely coupled, discoverable, structured, standard based, coarsegrained, statless units of functionality called services
Composability
Assemble new process from existing services that are exposed at a desired granularity through well defined
Reusability
Choose a service provider and access to existing resources exposed as services
Interoperability
Share capabilities and reuse shared services across a network irrespective of underlying protocols of implementation technology
Principles underlying SOA
Boundaries are explicit.
Services are autonomous
Share schemas and contracts, not implementations
Service compatibility is based on policy
SOA Characteristic
Based on open standards
Foster inherent reusability
Foster intrinsic interoperability
Emphasizes extensibility
Fundamentally autonomous
Promotes dynamic discovery
Promotes architectural composability
promotes loose coupling throughout the enterprise
Supports incremental implementation
Potential Benefit of SOA
Feedback at different level
More efficient development process
Adequate business infrastructure
Cost saving
Risk mitigation
Evolutionary approach
Independence from technology
Reuse
Why SOA?
Interoperation issues
Increased Competitions
Enhancement of Business Capabilities
There must be consensus On Interoperability
Key Compnents of SOA
Services (common denominator)
Service Description
Advertising and Discovery
Specification of Associated Data Model
Service Contracts
Challenges of SOA
Technical Challenges
Security challenges - loosely coupled environment
Optimization
Performance - XML brings robustness not speed
Organizing the services – registry & repository
Finding the right services and right interfaces
Transaction management is complex in interactions between logically separate system