UNIT – 2

Web Services Framework:

A Web Services Framework is a comprehensive structure that supports the development,
deployment, and management of web services. Web services are software components that
interact over a network, typically using XML-based messages following the Simple Object
Access Protocol (SOAP), RESTful principles, or other communication protocols.
Figure. Framework of Web Services

Key Components of a Web Services Framework in SOA:

1. Service Interface:
o WSDL (Web Services Description Language): Defines the service interface,
specifying the operations, input and output parameters, and the binding
information. WSDL is a cornerstone of the framework, enabling service
discovery and interaction.
2. Messaging:
o SOAP (Simple Object Access Protocol): A protocol for exchanging structured
information in web services, using XML. It defines a standardized format for
sending and receiving messages.
o REST (Representational State Transfer): An architectural style that uses
standard HTTP methods (GET, POST, PUT, DELETE) and is often used for
simpler, stateless interactions.
3. Service Discovery:
o UDDI (Universal Description, Discovery, and Integration): A directory service
where businesses can publish their web services, making it easier for clients to
find them.
4. Security:
o WS-Security: A standard that defines how to secure SOAP messages through
encryption, signatures, and other mechanisms to ensure confidentiality, integrity,
and authentication.
 5. Service Composition:
o BPEL (Business Process Execution Language): A language for defining
business processes that interact with web services. It allows the composition of
multiple services into a single workflow.
6. Service Management:
o WS-Management: A protocol for managing and monitoring web services,
providing capabilities like configuration, deployment, and performance
monitoring.
7. Quality of Service (QoS):
o WS-Reliable Messaging: Ensures that messages are delivered reliably between
distributed applications, even in the presence of network failures.
o WS-Policy: A framework for specifying quality-of-service policies, such as
security requirements, transaction support, and message reliability.
Figure: Relationship between SOA & web Services

Benefits of a Web Services Framework in SOA

• Interoperability: Web services can be accessed across different platforms and
programming languages, facilitating communication between heterogeneous systems.
• Reusability: Services can be reused in different applications, reducing development time
and costs.
• Scalability: SOA allows for scaling services independently, improving the overall
system performance and flexibility.
• Loose Coupling: Services interact through well-defined interfaces, minimizing
dependencies and making it easier to update or replace services without impacting other
components.
Example Technologies and Tools
• Apache Axis: A framework for constructing SOAP processors.
• JAX-WS (Java API for XML Web Services): A Java API for creating web services.
• Spring Web Services: A framework for creating document-driven web services.
 A well-implemented Web Services Framework in SOA provides a robust foundation for
building, deploying, and managing web services, ensuring that they are secure, reliable, and
scalable.
a) Services:
A "service" is a discrete unit of functionality that can be accessed remotely and invoked
using standardized protocols. Services are designed to be reusable, composable, and loosely
coupled, allowing for greater flexibility and scalability in building complex applications.
services can indeed be categorized based on their intended lifespan and usage patterns. These
classifications can be broadly divided into temporary services and permanent services.

• Temporary Services- Roles with runtime.

• Permanent services- Based on application resources.

The classification of services into temporary and permanent categories helps

organizations manage their service portfolios more effectively. Temporary services allow for
flexibility and rapid response to immediate needs, while permanent services ensure stability and
long-term support for critical business functions. By understanding the intended lifespan and
usage patterns of their services, organizations can allocate resources appropriately, maintain
service quality, and achieve their business objectives more efficiently.
Temporary services are designed to address short-term needs or specific, time-bound
requirements. They are often created for a particular project, event, or a specific business
process that has a limited duration.
Characteristics of Temporary Services:
1. Short Lifespan:
o These services are intended to exist for a limited period, after which they may be
retired or decommissioned.
2. Project-Specific:
o Temporary services are often tied to specific projects or initiatives. Once the
project is completed, the services may no longer be needed.
3. Quick Deployment:
o They are usually deployed quickly to meet immediate needs and may not go
through the same rigorous development and testing processes as permanent
services.
4. Limited Reusability:
o These services may not be designed with reusability in mind and might be
tailored to specific requirements that do not generalize well to other contexts.
5. Simpler Governance:
o Governance and management of temporary services might be less stringent
compared to permanent services, given their short-term nature.
Examples of Temporary Services:
• Event Management Services: Services designed to support a specific event, such as a
conference or a marketing campaign.
• Ad Hoc Data Integration Services: Services created to facilitate data integration for a
one-time data migration or analysis task.
• Pilot or Proof-of-Concept Services: Services developed to test new technologies or
approaches in a controlled, temporary environment.

Permanent services are designed to provide long-term, stable, and reusable functionality
within an organization. They are typically core to the business operations and are expected to
be available indefinitely.
Characteristics of Permanent Services:
1. Long Lifespan:
o These services are intended to be long-lasting and are expected to be maintained
and updated over time.
2. Business-Critical:
 o Permanent services often support essential business functions and processes that
are critical to the organization’s operations.
3. Rigorous Development:
o They go through thorough development, testing, and quality assurance processes
to ensure reliability and robustness.
4. High Reusability:
o These services are designed with reusability in mind, making them applicable
across different projects and business units.
5. Strict Governance:
o Governance, management, and monitoring of permanent services are usually
more comprehensive, ensuring compliance with organizational standards and
policies.
Examples of Permanent Services:
• Customer Management Services: Services that handle customer data, interactions, and
relationship management.
• Inventory Management Services: Services that manage inventory levels, orders, and
supply chain logistics.
• Payment Processing Services: Services that facilitate transactions and payment
processing across various business channels.
A temporary classification or service is defined based on roles, with a runtime of messages. A
permanent classification or service is defined based on application resources while also
providing service roles and service models, which can lead to solutions.

b) Service roles:
In SOA context, serve as the foundation for all web services, each of which maintains
distinct roles. However, services can be categorized based on their functions or the value they
provide.
• There are different kinds of service roles: initiator, relier, and recipient, which are
dependent on massagers.
• All service roles are not labelled client-server.
• A software environment with potential roles and responsibilities in service scenarios
influences all service roles.
• A service role functions as a service provider, capable of invoking various web services.
• Web services form the basis of a service role that has the ability to disseminate service
descriptions, complete with boundaries and future plans.
• A recipient receives the message, represents itself as a service provider, and functions as
a web service.

Figure. A service provider is an agent and owner.

 • A service provider entity interacts with various organizational entities.

c) Service models:

When services are used to lead the classification of application logic, they provide business
solution tasks and are referred to as a service model.

1. The existing three categories of a service model:

o Business Service Model
o Utility Service Model
o Controller Service Model

➢ Business service model:

1. This model serves as a fundamental and essential component of service-oriented

architecture.
2. This model can represent as corporate or informational data.
3. This model also supports business processing and gathers the composition data.

Figure: Service composition consisting one master controller, one sub-Controller, four business
services and one utility service.
➢ Utility Service Model:

1. The utility model of web service design follows service agents, and potentially reuses
services.
2. This model enables all the characteristics of services
3. This model promotes intrinsic interoperability services.
4. This model possesses the maximum level of autonomy.

➢ Controller Service Model:

1. This model consists composition of services that execute and support various business
tasks.
2. This model also represents the implementation composition.
3. This model illustrates the potential for leveraging reuseable opportunities and possesses
the minimum degree of autonomy.

Figure. Categories of Services

The categories of services are explained using an Order Service system as below:

Entity Services: This service handles services like Purchase order, order date, insurance
policy, create customer service, create product services. Service provider is an entity connects
with different organizational agilities.

Eg:- Create customer{ }, Get history{}, Get profile{}, Delete profile{}, Update profile{},
Update customer{}.

Task services: Services with various tasks which are dealing with multiple entities (more than
1 entity). Tasks like Customer purchase, creating purchase order number, validating customer
details.

Utility services [Reusable services]: These services belong to Technology oriented services to
build larger and higher-level services. Event logging, notifications to other domains etc.,
Eg., Send SMS{}, sene email{}.

Proxy:- Connection between members of system and service oriented and conflict subsystem.

Process:- This service creates application oriented services to implement business processes.
Acts as an interpreter between application and service.

Device:- Device service doesn’t include the API which is not well suited with service oriented
system. For example, a proxy server referred as network device to communicate between other
services.

Service Descriptions:

1. A service description always includes loose coupling support.

2. A loosely coupled system (independently build modules) must establish the services that
will communicate the service description and implement the services.
3. The description document is the primary component of the service description, and it will
support Web Services Description Language (WSDL). A WSDL must enable loosely
coupled services by compiling the message formats between two kinds of services.

a. A service description can fall into one of the following two categories:

o Abstract Description
o Concrete Description

b. Web services connect an abstract description to interfaces, transmitting messages without

relying on technology. An abstract description can be described in three ways.

▪ Port-type
▪ message
▪ Operation

A port type is defined as sorting different kinds of messages based on services. A service is
always divided into functions, and then it is referred to as an operation.

4. The abstract interface always provides a concrete description, which connects technologies
through physical transmission. A concrete description can be described in three ways:

1. Port 2. Binding 3. Services

There is always a need for communication between technology and services. A model-based
system must describe a service in terms of both temporary and permanent classification.

A service description is also referred to as an end-point representation; it always identifies

the physical location and address of services. It is also referred to as the point of actual content
based on description.

Meta Data and Service Contract:

Metadata in SOA is essentially data about data. It provides essential information about services,
making them discoverable, understandable, and consumable. It's the blueprint for how services
interact. Metadata services accept abstract and concrete descriptions; they interface and
exchange messages.
A service contract comprises Web Service Description Language (WSDL) and
Extensible Schema Definition (XSD), and it also formalizes the structure of services based on
incoming and outgoing messages. A service contract also supports policy by providing rules,
preferences, and possible service details. A service contract must include a service description
and other types of documents, such as WSDL, XSD, and policy.

Key components of metadata in SOA:

• Service description: Details about the service's functionality, inputs, outputs, and
errors.
• Quality of Service (QoS): Performance, reliability, and security attributes.
• Governance information: Policies, standards, and compliance requirements.
• Versioning information: Tracking changes to the service.
• Security information: Authentication, authorization, and encryption details.
Benefits of metadata:
• Improved service discovery: Enables easy identification of available services.
• Enhanced interoperability: Facilitates integration between different systems.
 • Improved service management: Supports effective monitoring and governance.

• Enhanced developer productivity: Provides clear information about service

capabilities.

Service Contract in SOA

A service contract defines the agreement between a service provider and a service consumer. It
outlines the expectations, responsibilities, and obligations of both parties.
Key elements of a service contract:
• Service interface: Defines the operations, messages, and data types.
• Service level agreement (SLA): Specifies performance, availability, and support
levels.
• Security requirements: Outlines security measures and protocols.
• Governance policies: References relevant governance policies.
Relationship between metadata and service contract:
• Metadata describes the service contract: Metadata provides detailed information
about the service contract's elements.
• Service contract is a core part of metadata: The service contract is a crucial
component of the overall service metadata.
Metadata is the comprehensive information about a service, while the service contract is a
specific aspect of that metadata that focuses on the agreement between the service provider and
consumer.
Service Description, Advertisement and Discovery:
A service description provides detailed information about a service, including:
• Functionality
• Inputs and outputs
• Quality of service
• Governance information
• Versioning
• Security details
It identifies the latest version of service descriptions. To discover web services and to meet
criteria requirement.
Service Advertisement
Service advertisement is the process of making a service known to potential consumers. It
involves publishing service descriptions in a discoverable format.
Key aspects of service advertisement:
• Service registry: A central repository where service descriptions are stored.
• Publication mechanism: The method used to add service descriptions to the registry
(e.g., manual, automated).
• Metadata standards: The format used for service descriptions (e.g., WSDL, OWL-S).

Service Discovery
Service discovery is the process of locating and selecting appropriate services based on
consumer requirements. It involves searching for service descriptions in a service registry and
matching them with the consumer's needs.
Key aspects of service discovery:
• Search criteria: The parameters used to find suitable services (e.g., service name,
function, QoS).
• Discovery mechanism: The method used to search for services (e.g., UDDI, WS-
Discovery).
• Binding: Establishing a connection between the consumer and the selected service.

Public and Private Registry:

Public Registry
A public registry is a shared repository accessible to anyone on the internet. It's a platform
where developers can share and discover reusable components, services, or artifacts.
Examples:
• Public code repositories: GitHub, GitLab
• Container registries: Docker Hub
Advantages:
• Large community: Access to a vast pool of resources and expertise.
• Rapid development: Leverage pre-built components to accelerate development.
• Cost-effective: Often free or low-cost to use.
Disadvantages:
• Security risks: Potential exposure of sensitive information.
• Dependency management: Challenges in managing dependencies on external
components.
• Performance: Potential latency issues due to remote access.
Private Registry
A private registry is a restricted repository accessible only to authorized users within an
organization. It's used to store and manage internal components, services, or artifacts.
Examples:
• Internal artifact repositories: Nexus, Artifactory
• Private container registries: Docker Registry, Harbor
Advantages:
• Security: Protects sensitive information and intellectual property.
• Control: Full control over the registry and its contents.
• Performance: Typically, faster access due to internal network.
• Compliance: Easier to meet regulatory requirements.
Disadvantages:
• Limited resources: Requires dedicated infrastructure and management.
• Potential duplication: Risk of reinventing the wheel if not managed effectively.

Application in SOA
In the context of SOA, both public and private registries can play a role:
 • Service metadata: A private registry can store service descriptions, while a public
registry can be used for sharing common service interfaces.
• Service components: A private registry can store reusable components, while a public
registry can be used for acquiring third-party components.
• Artifacts: Both public and private registries can be used to store various artifacts like
libraries, configuration files, and deployment scripts.

A Universal Discover Describe Integration (UDDI) is a part of the registry that tracks all
services. A registry must be manually checked, and it searches for the for the new
programmatically standardized Application Programming Interface (API). All service registries
locate all centralized services that receive the solution of services and candidate services. A
public registry defines and accepts any organization that registers services and acts as a service
provider. A private registry establishes its acceptance within the services organization by
defining the boundaries for service development, leasing, and purchase. By effectively utilizing
both public and private registries, organizations can balance the benefits of collaboration and
innovation with the need for security and control.
Business Entities and Business Services:
Business Entities
In the context of SOA, business entities represent the core data objects within an organization.
They are the fundamental building blocks of the business domain and encapsulate information
essential to the business operations.
• Examples of business entities: Customer, Product, Order, Account, Employee.
• Characteristics:
o Represent real-world concepts.
o Have attributes and relationships with other entities.
o Are relatively stable over time.
Business Services
Business services are the operational units that encapsulate business logic and provide specific
functions to interact with business entities. They expose the capabilities of the business to
other systems or applications.
• Examples of business services: Customer management, order processing, product
catalogue, account inquiry.
• Characteristics:
o Provide a well-defined interface.
o Are loosely coupled to other services.
o Can be composed of multiple services.
o Often align with business processes.
All Public registries will track the record of organization and it acts as business entity and
it also provides profile information of an organization. All Business services may or may
not related as Web Services. A Business Entity is also a part of binding template, it defines
as registries must follow the logics to binding the information of services. Then it is called
Binding Template. All Register services must provide the pointer of services description
based on Web Services then it is called t model. Where t stands for template.
Relationship Between Business Entities and Business Services
• Business entities are the data foundation for business services.
• Business services manipulate and process business entities to fulfil specific business
requirements.
• A business service can operate on multiple business entities.
• A business entity can be accessed by multiple business services.
Example:- Online retail system:
• Business entities: Customer, Product, Order, Address.
• Business services:
o Customer management (create, update, delete customers)
o Product catalog (search, view product details)
o Order processing (place order, process payment, ship order)
Key Points
• Business entities and business services are fundamental concepts in SOA.
• Clear identification of business entities is crucial for designing effective business
services.
• Well-defined business services enhance reusability and agility.
Messaging:
Messaging is the cornerstone of communication in a Service-Oriented Architecture (SOA). It's
the mechanism through which services interact and exchange data.
o A message defines communication.
o A message is also a communication service with relevant formats and transport
protocols.
o A SOAP is a component of messaging that standardizes services through a transport
mechanism. Hence, all messages are processed by web services.
o A SOAP also describes the message's structure and how it moved from one node to
another. A SOAP also provides a nodal network between messages and services.
o SOAP stands for Simple Object Access, which can define all message formats.
o A SOAP-based structure can be categorized into three categories:

● Envelope
● Body
● Header
o An envelope in SOAP structure and its components also represent a metaphor. It is also
housing for all parts of the message.
o A body is also a part of the SOAP structure; all message formats must be discovered in
XML format. All XML formats define the actual content of messages. Hence, it is
called Message Payload.
 o The header is another component of SOAP. All messages are allocated blocks. Hence, it
is a physical unit of communication for internal and external messages.

Key Characteristics of Messaging in SOA

• Asynchronous: Messages are sent without immediate expectation of a response,
promoting decoupling.
• Reliable: Messages are typically guaranteed to be delivered, ensuring data integrity.
• Secure: Messages can be encrypted and authenticated to protect sensitive data.
• Flexible: Messaging systems can handle various message formats and protocols.

Messaging Patterns in SOA

• Request-Reply: A synchronous pattern where a service sends a request and expects a
response.
• Message Queues: A store-and-forward mechanism where messages are persisted until
consumed
• Publish-Subscribe: A one-to-many pattern where a publisher sends messages to
multiple subscribers.

Messaging Technologies
• JMS (Java Message Service): A Java API for message-oriented middleware.

• AMQP (Advanced Message Queuing Protocol): A protocol for message-oriented

middleware.
• MQTT (Message Queuing Telemetry Transport): A lightweight protocol for IoT
applications

Example: Order Processing in SOA: In an order processing system, messaging can be used
to:
• Order placement: Customer places an order (request-reply).
• Inventory check: Order service sends a message to inventory service to check
availability (request-reply).
• Payment processing: Order service sends a message to payment service (request-
reply).
• Order confirmation: Order service sends a confirmation message to the customer
(fire-and-forget).

Atomic Transactions: Atomic transactions in SOA provide a critical mechanism for

maintaining data consistency and reliability, especially in systems where data integrity is
paramount. They enable complex, multi-step processes to be executed safely, ensuring that all
changes are correctly applied or entirely rolled back in case of failure.

Atomic transactions typically adhere to the ACID properties, which ensure reliable transaction
processing:
• Atomicity: Ensures that all parts of the transaction are treated as a single, indivisible
operation. If any part fails, the entire transaction fails, and the system is left
unchanged.
 • Consistency: Ensures that a transaction brings the system from one valid state to
another, maintaining all defined rules and constraints.
• Isolation: Ensures that transactions are executed independently of each other.
Intermediate states of a transaction are not visible to other transactions, preventing
interference.
• Durability: Ensures that once a transaction is committed, its results are permanent,
even in the case of a system failure.
2. Two-Phase Commit Protocol (2PC)
The Two-Phase Commit Protocol is a common mechanism for achieving atomic transactions
in distributed systems. It consists of two phases:
• Phase 1: Prepare: The coordinator sends a prepare message to all participating
services, asking them to confirm if they are ready to commit the transaction. Each
participant responds with a vote (yes or no).
• Phase 2: Commit/Rollback: If all participants vote yes, the coordinator sends a
commit message, and the transaction is finalized. If any participant votes no, the
coordinator sends a rollback message, and all participants undo any changes.
3. Transaction Coordinator
A transaction coordinator is a component that manages the coordination of the transaction,
ensuring that all participants agree on the outcome. It handles the communication between
services and manages the commit or rollback process.
4. Compensating Transactions
In some scenarios, it may not be possible to use strict atomic transactions due to the
distributed nature of services or the need for long-running processes. In such cases,
compensating transactions are used as a fallback mechanism. A compensating transaction is
an operation that reverses the effects of a previously completed transaction, essentially
"undoing" the transaction if something goes wrong later.
5. Distributed Transaction Management
In a distributed SOA environment, transactions often span multiple services and databases.
Managing distributed transactions requires careful handling of network latency, partial
failures, and resource locking. Middleware solutions, such as Enterprise Service Buses (ESBs)
or distributed transaction coordinators, can help manage these complexities.
6. Challenges
• Network Latency and Failures: Ensuring that all participants are synchronized and
agree on the transaction outcome can be challenging due to network issues.
• Scalability: The more participants in a transaction, the more complex and resource-
intensive the coordination becomes.
• Consistency Models: Different systems may have different consistency requirements,
making it challenging to enforce ACID properties universally.
7. Use Cases
• Financial Transactions: Ensuring that funds are transferred accurately between
accounts.
• Order Processing: Guaranteeing that inventory updates, payment processing, and
order confirmations are consistent.
• Data Synchronization: Keeping data consistent across multiple systems and services.

Orchestration vs. Choreography in SOA

In the realm of Service-Oriented Architecture (SOA), orchestration and choreography are two
distinct approaches to coordinating the interactions between services.
Orchestration
• Centralized control: A central entity (orchestrator) manages the flow of a process.
• Sequential execution: Services are invoked in a predetermined order.
• Complex process handling: Well-suited for complex business processes with
multiple steps and conditions.
• Tight coupling: Services are tightly coupled to the orchestrator.
Example: A loan approval process where a central system coordinates credit checks, property
valuation, and underwriting.
Choreography
• Decentralized control: Services independently follow a predefined agreement
(choreography).
• Event-driven: Services react to events and messages from other services.
• Loose coupling: Services are loosely coupled, promoting autonomy and flexibility.
• Complex interactions: Suitable for complex interactions where services have equal
responsibility.
Example: An order processing system where multiple services (inventory, shipping,
payment) interact based on events like order placed, payment confirmed, etc.
Table. Key Differences of Orchestration and Choreography

Feature Orchestration Choreography

Control Centralized Decentralized
Execution Sequential Event-driven
Coupling Tight Loose
Complexity Handles complex processes Suitable for complex interactions

When to Use Which

• Orchestration: Best for processes with clear sequential steps and a strong central
authority.
• Choreography: Ideal for distributed systems where services have equal importance
and autonomy.

------------------------------------------------------------------------------------