Q1.

The architecture of web service consists of three roles and the interaction consists of
three operations. With a neat diagram explain the idea of web services and interactions with
a suitable example for the data and controlflow.

ANSThe architecture of web service interacts among three roles: service provider, service
requester, and service registry. The interaction involves the three operations: publish, find,
and bind.

Roles in a Web Service Architecture

There are three roles in web service architecture:

o Service Provider o
Service Requestor o
Service Registry

Service Provider

From an architectural perspective, it is the platform that hosts the services.

Service Requestor

Service requestor is the application that is looking for and invoking or initiating an
interaction with a service. The browser plays the requester role, driven by a consumer
or a program without a user interface.
 Service Registry

Service requestors find service and obtain binding information for services during
development.

Operations in a Web Service Architecture

Three behaviors that take place in the microservices:

o Publish o

Find o Bind

Publish: In the publish operation, a service description must be published so that a

service requester can find the service.

Find: In the find operation, the service requestor retrieves the service description directly. It
can be involved in two different lifecycle phases for the service requestor:

Bind: In the bind operation, the service requestor invokes or initiates an interaction with the
service at runtime using the binding details in the service description to locate, contact, and
invoke the service.

Q2. Explain the essential roles and interactions of web service. Your answer must support
with a neat diagram and suitable real-world applications.

ANS

Roles in a Web Service Architecture

There are three roles in web service architecture:

o Service Provider o
Service Requestor o
Service Registry

Service Provider

From an architectural perspective, it is the platform that hosts the services.

Service Requestor
 Service requestor is the application that is looking for and invoking or initiating an
interaction with a service. The browser plays the requester role, driven by a consumer
or a program without a user interface.

Service Registry

Service requestors find service and obtain binding information for services during
development.

Operations in a Web Service Architecture

Three behaviors that take place in the microservices:

o Publish o

Find o Bind

Publish: In the publish operation, a service description must be published so that a

service requester can find the service.

Find: In the find operation, the service requestor retrieves the service description directly. It
can be involved in two different lifecycle phases for the service requestor:

Bind: In the bind operation, the service requestor invokes or initiates an interaction with the
service at runtime using the binding details in the service description to locate, contact, and
invoke the service.

example of real world applica on

In an online travel booking system, multiple web services are often involved:

• Flight Booking Service: Provides available flights, pricing, and booking op ons.
• Hotel Booking Service: Provides informa on about available hotels, pricing, and
booking op ons.
• Car Rental Service: Offers car rental op ons, pricing, and booking.

Workflow:

1. The travel booking applica on (Service Consumer) finds and binds to the flight
booking service (Service Provider) to get available flights.
2. It then binds to the hotel booking service to get hotel op ons based on the user's des
na on and travel dates.
3. Finally, it binds to the car rental service to provide rental op ons to the user.
These interactions enable the travel booking application to offer a comprehensive travel
package to the user by combining data from various service providers.

This interconnected network of web services makes modern applications more modular,
scalable, and interoperable, allowing them to deliver complex functionalities seamlessly.

Q3. Interpret atleastfour major design challenges of distributed systems. Your answer
should not focus on theoretical aspects / hypothetical aspects.
ANS

Design Issues of Distributed System

Distributed System is a collection of autonomous computer systems that are
physically separated but are connected by a centralized computer network that is
equipped with distributed system software. These are used in numerous
applications, such as online gaming, web applications, and cloud computing.
However, creating a distributed system is not simple, and there are a number of
design considerations to take into account. The following are some of the major
design issues of distributed systems:
Design issues of the distributed system –
1. Heterogeneity: Heterogeneity is applied to the network, computer
hardware, operating system, and implementation of different developers.
A key component of the heterogeneous distributed system client-server
environment is middleware. Middleware is a set
 of services that enables applications and end-user to interact with each
other across a heterogeneous distributed system.
2. Openness: The openness of the distributed system is determined primarily
by the degree to which new resource-sharing services can be made
available to the users. Open systems are characterized by the fact that their
key interfaces are published. It is based on a uniform communication
mechanism and published interface for access to shared resources. It can
be constructed from heterogeneous hardware and software.
3. Scalability: The scalability of the system should remain ef icient even with
a signi icant increase in the number of users and resources connected. It
shouldn’t matter if a program has 10 or 100 nodes; performance shouldn’t
vary. A distributed system’s scaling requires consideration of a number of
elements, including size, geography, and management.
4. Security: The security of an information system has three components
Con identially, integrity, and availability. Encryption protects shared
resources and keeps sensitive information secrets when transmitted.
5. Failure Handling: When some faults occur in hardware and the software
program, it may produce incorrect results or they may stop before they
have completed the intended computation so corrective measures should
to implemented to handle this case. Failure handling is dif icult in
distributed systems because the failure is partial i.e, some components fail
while others continue to function.
6. Concurrency: There is a possibility that several clients will attempt to
access a shared resource at the same time. Multiple users make requests
on the same resources, i.e. read, write, and update. Each resource must be
safe in a concurrent environment. Any object that represents a shared
resource in a distributed system must ensure that it operates correctly in a
concurrent environment.
7. Transparency: Transparency ensures that the distributed system should be
perceived as a single entity by the users or the application programmers
rather than a collection of autonomous systems, which is cooperating. The
user should be unaware of where the services are located and the transfer
from a local machine to a remote one should be transparent.

Q4. One of your colleague, always states “creating a distributed system is not simple,
and there are a number of design considerations to take into account”.What could be
the reasons behind his statement..? Interpret some of the major design issues of
distributed systems, tosupport his statement.
ANS SAME AS 3
Q5. Distinguish SOAP message with attachments and without attachments with neat
diagrams for the both.
Structure of a SOAP Message without Attachments:
 1. Envelope: The root element that defines the XML document as a SOAP
message.
2. Header: An optional element that contains application-specific
information like authentication, transaction management, etc.
3. Body: The main content of the message, containing the actual data being
exchanged.

Diagram:

SOAP Message with A achments

A SOAP message with attachments (SwA) extends the basic SOAP message to include
binary data or large files as attachments. This is useful for scenarios like sending images,
PDFs, or any other binary content along with the SOAP message.

Structure of a SOAP Message with Attachments:

1. Envelope: The root element that defines the XML document as a SOAP message.
2. Header: An op onal element that contains applica on-specific informa on.
3. Body: The main content of the message, which includes references to a achments.
4. A achments: Binary data or files a ached to the message.

Diagram:
Summary of Differences:

• Without Attachments:
o Simpler structure.
o Contains only the SOAP envelope with op onal headers and a mandatory
body.
o Suitable for exchanging XML data.
• With Attachments:
o More complex structure. o Contains a SOAP envelope and addi onal
binary a achments. o Uses MIME to handle a achments. o Suitable for
exchanging large files or binary data along with XML data.

Q7. Examine the necessity of message with a achments and without a achments. Highlight
the differences between them with neat a diagrams and code snippet for the both.

ANS SAME AS 5 with their codes

Without a achment code:

<soapenv:Envelope xmlns:soapenv="h p://schemas.xmlsoap.org/soap/envelope/"

xmlns:wea="h p://www.example.com/weather">

<soapenv:Header/>

<soapenv:Body>

<wea:GetWeather>

<wea:CityName>New York</wea:CityName>

</wea:GetWeather>
</soapenv:Body>

</soapenv:Envelope>

With a achment code:

<soapenv:Envelope xmlns:soapenv="h p://schemas.xmlsoap.org/soap/envelope/"

xmlns:doc="h p://www.example.com/document">

<soapenv:Header/>

<soapenv:Body>

<doc:UploadDocument>

<doc:DocumentName>example.pdf</doc:DocumentName>

<doc:A achment>cid:a achment1</doc:A achment>

</doc:UploadDocument>

</soapenv:Body>

</soapenv:Envelope>