Service-Oriented Architecture and RESTful Services: An Exercise in Software Engineering | Mitschriften Computer Vision

Exercise 3

Task 1

❖ Service-oriented software engineering

➢ Web services were developed that allowed programs to access and update resources

available on the web.

➢ A web service is a standard representation for some computational or information resource

that can be used by other programs.

➢ A web service can therefore be defined as:

"A loosely coupled, reusable software component that encapsulates discrete functionality,

which may be distributed and programmatically accessed. A web service is a service that is

accessed using standard Internet and XML-based protocols."

➢ A service should be independent and loosely coupled.

➢ They should not rely on external components that may have different functional and non-

functional behavior

➢ A web service interface is simply a “provides” interface that defines the service functionality

and parameters.

➢ Service-oriented systems are a way of developing distributed systems where the system

components are stand-alone services.

➢ Software as a service means offering software functionality to users remotely over the web,

rather than through applications installed on a user’s computer.

➢ Service-oriented systems are systems that are implemented using reusable service

components and that are accessed by other programs, rather than directly by users.

➢ Benefits of service-oriented approach to software engineering: -

▪ Services can be offered by any service provider inside or outside of an organization.

▪ The service provider makes information about the service public so that any authorized

user can use the service.

▪ Applications can delay the binding (Late Binding) of services until they are deployed or

until execution.

▪ Opportunistic construction of new services is possible.

▪ Service users can pay for services according to their use rather than their provision.

▪ Applications can be made smaller, which is particularly important for mobile devices

with limited processing and memory capabilities.

➢ Service-oriented systems have loosely coupled architectures where service bindings may

change during system execution.

➢ Building applications based on services allows companies and other organizations to

cooperate and make use of each other’s business functions.

➢ Service-based applications may be constructed by linking services from various providers

using either a standard programming language or a specialized workflow language.

➢ A RESTful approach is a simpler approach than a service-oriented architecture, but it is less

suited to services that offer complex functionality.

❖ Service-oriented architecture

➢ Service providers design and implement services and specify the interface to these services.

➢ Web service protocols cover all aspects of service-oriented architectures, from the basic

mechanisms for service information exchange (SOAP) to programming language standards

(WS-BPEL).

➢ These standards are all based on XML, a human and machine-readable notation that allows

the definition of structured data where text is tagged with a meaningful identifier.

➢ The fundamental standards for service-oriented architectures are

Unvollständige Textvorschau

Nur auf Docsity: Lade Service-Oriented Architecture and RESTful Services: An Exercise in Software Engineering und mehr Mitschriften als PDF für Computer Vision herunter!

Exercise 3

Task 1

❖ Service-oriented software engineering

➢ Web services were developed that allowed programs to access and update resources available on the web. ➢ A web service is a standard representation for some computational or information resource that can be used by other programs. ➢ A web service can therefore be defined as: "A loosely coupled, reusable software component that encapsulates discrete functionality, which may be distributed and programmatically accessed. A web service is a service that is accessed using standard Internet and XML-based protocols." ➢ A service should be independent and loosely coupled. ➢ They should not rely on external components that may have different functional and non- functional behavior ➢ A web service interface is simply a “provides” interface that defines the service functionality and parameters. ➢ Service-oriented systems are a way of developing distributed systems where the system components are stand-alone services. ➢ Software as a service means offering software functionality to users remotely over the web, rather than through applications installed on a user’s computer. ➢ Service-oriented systems are systems that are implemented using reusable service components and that are accessed by other programs, rather than directly by users. ➢ Benefits of service-oriented approach to software engineering: - ▪ Services can be offered by any service provider inside or outside of an organization. ▪ The service provider makes information about the service public so that any authorized user can use the service. ▪ Applications can delay the binding (Late Binding) of services until they are deployed or until execution. ▪ Opportunistic construction of new services is possible. ▪ Service users can pay for services according to their use rather than their provision. ▪ Applications can be made smaller, which is particularly important for mobile devices with limited processing and memory capabilities. ➢ Service-oriented systems have loosely coupled architectures where service bindings may change during system execution. ➢ Building applications based on services allows companies and other organizations to cooperate and make use of each other’s business functions. ➢ Service-based applications may be constructed by linking services from various providers using either a standard programming language or a specialized workflow language. ➢ A RESTful approach is a simpler approach than a service-oriented architecture, but it is less suited to services that offer complex functionality.

❖ Service-oriented architecture

➢ Service providers design and implement services and specify the interface to these services. ➢ Web service protocols cover all aspects of service-oriented architectures, from the basic mechanisms for service information exchange (SOAP) to programming language standards (WS-BPEL). ➢ These standards are all based on XML, a human and machine-readable notation that allows the definition of structured data where text is tagged with a meaningful identifier. ➢ The fundamental standards for service-oriented architectures are

▪ 1. SOAP This is a message interchange standard that supports communication between services. It defines the essential and optional components of messages passed between services. ▪ 2. WSDL The Web Service Description Language (WSDL) is a standard for service interface definition. It sets out how the service operations (operation names, parameters, and their types) and service bindings should be defined. ▪ 3. WS-BPEL This is a standard for a workflow language that is used to define process programs involving several different services. ➢ Services in a SOA communicate by exchanging messages, expressed in XML, and these messages are distributed using standard Internet transport protocols such as HTTP and TCP/IP.

❖ RESTful services

➢ An alternative “lightweight” approach to web service architecture has been developed. This approach is based on the REST architectural style, where REST stands for Representational State Transfer (Fielding 2000). REST is an architectural style based on transferring representations of resources from a server to a client. ➢ The fundamental element in a RESTful architecture is a resource. Essentially, a resource is simply a data element such as a catalog and a medical record, or a document ➢ Resources may have multiple representations; that is, they can exist in different formats. ➢ Resources have a unique identifier, which is their URL. Resources are a bit like objects, with four fundamental polymorphic operations associated with them. ▪ 1. Create—bring the resource into existence. ▪ 2. Read—return a representation of the resource. ▪ 3. Update—change the value of the resource. ▪ 4. Delete—make the resource inaccessible. ➢ The Web is an example of a system that has a RESTful architecture. Web pages are resources, and the unique identifier of a web page is its URL. ➢ The web protocols http and https are based on four actions, namely, POST, GET, PUT, and DELETE. ▪ 1. POST is used to create a resource. It has associated data that defines the resource. ▪ 2. GET is used to read the value of a resource and return that to the requestor in the specified representation, such as XHTML, that can be rendered in a web browser. ▪ 3. PUT is used to update the value of a resource. ▪ 4. DELETE is used to delete the resource. ➢ An important difference between RESTful services and SOAP-based services is that RESTful services are not exclusively XML-based. So, when a resource is requested, created, or changed, the representation may be specified. This is important for RESTful services because representations such as JSON (JavaScript Object Notation), as well as XML, may be used. These can be processed more efficiently than XML-based notations, thus reducing the overhead involved in a service call. ➢ A fundamental design principle for RESTful services is that they should be stateless. That is, in an interaction session, the resource itself should not include any state information, such as the time of the last request. ➢ However, there are problems with the RESTful approach: ▪ 1. When a service has a complex interface and is not a simple resource, it can be difficult to design a set of RESTful services to represent this interface. ▪ 2. There are no standards for RESTful interface description, so service users must rely on informal documentation to understand the interface. ▪ 3. When you use RESTful services, you must implement your own infrastructure for monitoring and managing the quality of service and the service reliability. SOAP-based

➢ A service can be made up of several components. Usually, a service provides one complete feature that is made up by combining different components. ➢ The service's user doesn’t need to know anything about the underlying components. User will deal only directly with the service while service internally will be interacting with the components Task 3 ❖ Specify a REST web service to manage suppliers. It should be possible

**1. Change a supplier’s phone number

Create a purchase order for a specific supplier
Delete a supplier
Retrieve all data of a specific supplier
Retrieve all suppliers with a minimum turnover in a time period. Design a URL mapping for these REST web services. Please specify the HTTP method a client must call to invoke the web service.** ➢ 3.1 PUT is used to update the value of a resource. ▪ www.transfer.com/suppliers/:id, parameter: suppliers' identifier, body: phone number ➢ 3.2 POST is used to create a resource. It has associated data that defines the resource. ▪ www.transfer.com/orders, body: supplier and order data ➢ 3.3 DELETE is used to delete the resource. ▪ www.transfer.com/suppliers/:id, parameter: suppliers' identifier ➢ 3.4 GET is used to read the value of a resource and return that to the requestor in the specified representation, such as XHTML, that can be rendered in a web browser. ▪ www.transfer.com/suppliers/:id ➢ 3.5 POST with body content: when a GET with URL encoded query parameters is not possible, a POST with body content must be used. ▪ www.transfer.com/suppliers/?startTimePeriod=date&endTimePeriod-date, Query: startTimePeriod and endTime Period ➢ Design Decisions ▪ 1. There should be a resource representing a company-specific catalog. This should have a URL of the form / and should be created using a POST operation. ▪ 2. Each catalog item should have its own URL of the form //. ▪ 3. You use the GET operation to retrieve items. Lookup is implemented by using the URL of an item in a catalog as the GET parameter. Search is implemented by using GET with the company catalog as the URL and the search string as a query parameter. ➢ This GET operation returns a list of URLs of the items matching the search. However, the Compare, CheckDelivery, and MakeVirtualOrder operations are more complex: ▪ 1. The Compare operation can be implemented as a sequence of GET operations to retrieve the individual items, followed by a POST operation to create the comparison table and a final GET operation to return this to the user. ▪ 2. The CheckDelivery and MakeVirtualOrder operations require an additional resource, representing a virtual order. A POST operation is used to create this resource with the number of items required. The company id is used to automatically fill in the order form, and the delivery date is calculated. The resource can then be retrieved using a GET operation.

Service-Oriented Architecture and RESTful Services: An Exercise in Software Engineering, Mitschriften von Computer Vision

Zugehörige Dokumente

Unvollständige Textvorschau

Nur auf Docsity: Lade Service-Oriented Architecture and RESTful Services: An Exercise in Software Engineering und mehr Mitschriften als PDF für Computer Vision herunter!

Exercise 3

Task 1

❖ Service-oriented software engineering

❖ Service-oriented architecture

❖ RESTful services