Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 4: SERVICE-ORIENTED ARCHITECTURE (SOA) AND WEB SERVICES - Coggle…
Chapter 4: SERVICE-ORIENTED ARCHITECTURE (SOA) AND WEB SERVICES
Benefits of SOA
Organizational Benefits:
Enables businesses to respond quickly and cost-effectively to market changes.
Promotes reuse of services at the macro level, enhancing efficiency.
Simplifies integration with and utilization of existing IT assets, including legacy systems.
Reasons for Treating Service Implementation Separately:
Promotes the idea that services can be delivered quickly and independently.
Helps businesses understand systems and simplified user interfaces, promoting agility and innovation.
Encourages good design by decoupling services from consuming projects.
Separates documentation and test artifacts, facilitating future reuse of services.
Advantages of Implementing SOA
Reusability
: Services are self-contained and can be reused across different applications.
Easy Maintenance:
Services can be updated, upgraded, and maintained without complications from interacting with other services.
Reliability
: SOA services are complete and easy to test, debug, and maintain.
Availability
: Services are available for consumer requests via public directories.
Scalability
: Services can run on different servers, enhancing scalability and availability.
High-Quality Services
: Consistent data and continuously maintained service codes lead to high-quality applications.
Platform Independence
: Services can run on any platform, allowing integration across different vendors.
Increased Productivity:
Versatile services can be adapted and reused, enhancing developer productivity.
Characteristics of SOA
Standardized Service Contract:
Services have descriptions defining their functionality.
Loose Coupling:
Minimal dependencies between services and client applications.
Service Abstraction:
Services hide their internal logic, providing only information on their functionality to clients.
Service Reusability:
Services are designed to maximize reuse of logic across multiple applications.
Service Autonomy:
Services have control over the logic they encapsulate and their functionality.
Service Statelessness:
Ideally, services should not maintain state between requests, allowing for better scalability and flexibility.
Service Discoverability:
Services can be discovered, usually through a service registry like UDDI.
Service Composability:
Services break down complex problems into smaller, modular components, each serving a separate business functionality.
Service Interoperability:
Services use standards like XML and HTTP communication to ensure compatibility and interaction with diverse subscribers.
Web Service Technologies
Definition:
A Web service facilitates interoperable machine-to-machine interaction over a network.
Interface Description:
It has an interface described in a machine-processable format, specifically WSDL.
Interaction Protocol:
Other systems interact with the Web service according to its description using SOAP messages, often conveyed using HTTP, and utilizing XML serialization along with other Web-related standards.
Architecture of Web Services
Roles
: The architecture of web services involves three roles: service provider, service requester, and service registry.
Operations
: The interaction among these roles involves three operations: publish, find, and bind.
Artifacts
: These operations and roles act upon the web service artifacts, which include the web service software module and its description.
Requesters and Providers
Web Service Purpose:
A Web service provides functionality on behalf of its owner, which could be a person or organization.
Provider Entity
: The provider entity is the person or organization that offers an appropriate agent to implement a specific service.
Requester Entity:
The requester entity is a person or organization that intends to utilize the Web service provided by the provider entity. It uses a requester agent to exchange messages with the provider entity's provider agent.
Engaging a Web Service Overview:
The requester and provider entities establish knowledge of each other, or at least one entity becomes aware of the other.
The requester and provider entities agree on the service description and semantics that will govern their interaction.
The service description and semantics are implemented by the requester and provider agents.
The requester and provider agents exchange messages, thus executing a task on behalf of the requester and provider entities. This exchange represents the concrete interaction with the provider entity's Web service.
Web Service Integrations
Integration methods: SOAP or REST protocol.
REST (Representational State Transfer):
Architectural style for designing networked applications.
Provides a uniform interface using standard HTTP operations (GET, POST, PUT, DELETE).
Exchange representations of resources.
JSON and XML are common formats in REST services.
REST:
Relies heavily on HTTP methods.
Exposes server resources to clients.
Clients can interact with resources using HTTP methods (GET, POST, PUT, DELETE).
Resource
Key abstraction of information in REST.
Anything that can be named can be a resource.
Identified by a resource identifier.
State of the resource at any timestamp is known as resource representation.
Representation consists of data, metadata, and hypermedia links.
Data format of a representation is known as a media type.
RESTful Web Service:
Implements REST architecture style.
Exposes resources via URL.
Uses HTTP methods (GET, POST, PUT, DELETE).
Provides information about response in response code.
Each response provides hyperlinks to other resources.
REST Methods:
GET
: Retrieve data from a server.
POST
: Send data to the server to create or update a resource.
PUT
: Send data to the server to update or create a resource (idempotent).
DELETE
: Delete the resource at the specified URL.
CRUD REST Verbs and Endpoints:
CREATE (POST): /store/product
READ (GET):
/store/product/mouse
/store/product/123
/store/product_category/computer
UPDATE (PUT): /store/product/123/200
DELETE (DELETE): /store/product/123
Designing RESTful API:
Use Nouns in URI: Design API for resources, always use nouns (e.g., /users instead of /createUser).
Plurals or Singulars: Prefer plurals for resource names but singulars are also acceptable.
Let the HTTP Verb Define Action: Use HTTP verbs (GET, POST, PUT, DELETE) to define actions on resources.
Don’t Misuse Safe Methods: Avoid misusing safe methods like using GET to delete content.
Depict Resource Hierarchy Through URI: Represent resource hierarchy in URI (e.g., /users/123/posts/1).
Version Your APIs: Embed version in URL (e.g., /v2/users) for backward compatibility.
Return Representation: POST, PUT, or PATCH methods should return updated resource representation.
Filter, Search, and Sort: Use query parameters for filtering, searching, or sorting resources. Examples:
Filtering: /users/123/posts?state=published
Searching: /users/123/posts?state=published&ta=scala
Sorting: /users/123/posts?sort=-updated_at
SOAP (Simple Object Access Protocol):
XML-based protocol for structured information exchange via Web services.
Web services described by a Web Service Definition Language (WSDL) file.
Supports different transport protocols like HTTP or SMTP.
Uses named operations and supports WS-Security and Reliable Messaging.
SOAP Web Service:
Client bundles account registration information into a SOAP message.
SOAP message sent to Web Service as body of HTTP POST request.
Web Service unpacks SOAP request and converts it into a command understandable by the application.
Application processes information and responds with a new unique account number.
Web Service packages response into another SOAP message, sent back to client in response to HTTP request.
Client unpacks SOAP message to obtain results of account registration process.
SOAP Web Service Example:
SOAP Documents:
SOAP Message Skeleton
SOAP WSDL Example
SOAP Request Response:
SOAP Request Example
SOAP Response Example
Importance of API Design:
Easy to understand for straightforward integration.
Well-documented to ensure understanding of semantic behaviors, not just syntactic.
Follow accepted standards like HTTP for consistency and interoperability.
HTTP Status Codes Overview:
REST APIs utilize the Status-Line part of an HTTP response message to convey the outcome of the client's request.
Status codes are categorized into five groups:
1xx: Informational - Communicates transfer protocol-level information.
2xx: Success - Indicates successful acceptance of the client's request.
3xx: Redirection - Requires additional client action to complete the request.
4xx: Client Error - Indicates errors attributable to the client.
5xx: Server Error - Responsibility lies with the server for these error status codes.
REST Specific Status Codes:
200 (OK): Successful execution of the requested action with no need for a more specific code.
201 (Created): Signifies the creation of a resource within a collection.
400 (Bad Request): Generic client-side error indicating issues like malformed request syntax or invalid parameters.
401 (Unauthorized): Indicates attempts to access a protected resource without proper authorization.
404 (Not Found): The requested resource is not found but may be available in the future.
405 (Method Not Allowed): The requested HTTP method is not allowed for the resource.
500 (Internal Server Error): Generic error response indicating an unexpected condition on the server.
Service-Oriented Architecture(
SOA
)
SOA is a style of software design where services are provided to other components by application components through a communication protocol over a network.
The basic principles of SOA are independent of vendors, products, and technologies.
A service is a discrete unit of functionality that can be accessed remotely, acted upon, and updated independently, such as retrieving a credit card statement online.
A service has four properties according to one of many definitions of SOA:
It logically represents a business activity with a specified outcome.
It is self-contained.
It is a black box for its consumers.
It may consist of other underlying services
Overview of SOA
In SOA, services use protocols for passing and parsing messages, described by metadata.
Metadata describes both functional and quality-of-service characteristics of services.
SOA enables the combination of large chunks of functionality into applications purely from existing services.
Services present a simple interface that abstracts away underlying complexity, acting as black boxes.
Users can access independent services without knowledge of their internal implementation.
Concept of SOA
Service-orientation promotes loose coupling between services.
SOA separates functions into distinct units called services.
Developers make services accessible over a network for users to combine and reuse in applications.
Services and their consumers communicate by passing data in a well-defined, shared format.
They also coordinate activities between two or more services.
SOA Pattern
Service provider:
Creates a web service and registers its information in the service registry.
Service broker, service registry, or service repository:
Makes web service information available to potential requesters.
Service requester/consumer:
Locates entries in the registry and binds to service providers to invoke web services. Can access multiple services if the provider offers them.