Chapter 18 Service Oriented Engineering

Thursday, 12 June 2025 12:52 PM

Objective:
- Service oriented engineering as a way of building distributed applications using web services
- Understand web service, web service standards, and service oriented architecture.
- The idea of RESTful services and the difference between RESTful and SOAP based services
- Understand the service engineering process to produce a reusable web services
- How workflow service composition can be used to create service oriented software that supports business
process.
Contents:
- Service oriented architecture
- RESTful services
- Service engineering
- Service composition

Web Services:
- The development of web revolutionized organizational information exchange.
- Client computers could gain access to information on remote servers outside their organizations
- However, access was solely through a web browser, and direct access to information by programs was not
practical.
- So, web services were developed that allowed programs to access and update resources available on the web.
- Using a web service, organizations that wish to make their information available to other programs can do so by
defining and publishing a programmatic web service interface.
- This interface defines the data available and how to be accessed and used.
- A web service is a standard representation for some computational or information resource that can be used by
other programs.
- These information resources may be:
○ Parts catalog
○ Computer resources
○ Processors, storage resources
- For example, an archive service could be implemented that permanently and reliably stores organizational data
has to be maintained for many years.
- A web service is an instance of a more general notion of a service
○ An act or performance offered by one party to another.
○ Although the process may be tied to a physical product, the performance is intangible and does not normally
result in the ownership of any factors of production.
- Services are a natural development of software components where the component model is a set of standards
associated with web services.
○ 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.
Distinction between a Service and Software component:
- Services should be independent and loosely coupled
- They should operate in the same way irrespective of their execution environment
- They should not rely on external components that have different functional or nonfunctional behavior
- Web services do not have a "requires" interface.
- A web service interface is a "provides" interface that defines a service functionality and parameters.
Service oriented systems:
- A way of developing distributed systems where the system components are stand-alone services.
- Executing on geographically distributed computers.
- Services are platform and implementation-language independent.
- Software systems can be constructed by composing local and external services from different providers with
seamless interaction between services in the system.
Difference between Software as a Service and Service oriented systems:
- Software as a service
○ means offering software functionality to users remotely over the web
○ Not through applications installed on user's computer
- Service oriented systems
○ Systems that are implemented using reusable service components that are accessed by other programs
○ Not directly by users
- SAAS may be implemented using service oriented system
- You don’t have to implement software in a way to offer it as a user service
Benefits of Service oriented approach:
- Services can be offered by any service provider inside or outside of an organization.
○ Assuming these services conform to certain standards, organizations can create applications by integrating
services from a range of providers.
- Service provider makes information about the service public so that any authorized user can use the service.
○ The provider and user do not need to negotiate about what the services does before it can be incorporated
in an app program.
- Applications can delay the binding of services until they are deployed or until execution
○ Therefore, an application can dynamically change service providers while the system was executing
 - You don’t have to implement software in a way to offer it as a user service
Benefits of Service oriented approach:
- Services can be offered by any service provider inside or outside of an organization.
○ Assuming these services conform to certain standards, organizations can create applications by integrating
services from a range of providers.
- Service provider makes information about the service public so that any authorized user can use the service.
○ The provider and user do not need to negotiate about what the services does before it can be incorporated
in an app program.
- Applications can delay the binding of services until they are deployed or until execution
○ Therefore, an application can dynamically change service providers while the system was executing
○ Applications can be reactive and adapt their operation to cope with changes to their execution environment.
- Opportunistic construction of new services is possible.
○ A service provider may recognize new services that can be created by linking existing services in innovative
ways.
- Service users can pay for services according to their use rather than provision.
○ Instead of buying expensive components that are rarely used, the application can use an external service
that will be paid for only when required.
- Applications can be made smaller, which is important for mobile devices with limited processing and memory
capabilities.
○ The computationally intensive processing and exception handling can be offloaded to external services.
Services Scenario:
- Some systems will be solely build using web services
- Others will mix web services with locally developed components
- Different providers in different places offer these services.
- When the system is deployed or programmed, you don’t have to decide what service provider should be used or
what specific services should be accessed.
- As the car moves, the in car software uses service discovery services to find the most appropriate information
service and binds it
- Building applications based on services allows companies and other organizations to cooperate and make use of
each other's business functions.
- Thus, systems with intensive information exchange can easily be automated.
- Service based applications may be constructed by linking services from various providers using a standard
programming language or specialized language workflow.
Service-Oriented Architecture:
- SOA is an architectural style based on the idea that executable services can be included in applications.
- Services have well-defined, published interfaces
○ applications can choose whether or not these are appropriate for them.
- Important idea in SOA:
○ the same service may be available from different providers
○ The applications could make a runtime decision of which service provider to use.

- Service providers design and implement services and specify the interface to these services
- They also publish information about these services in a registry
- Service requestors/clients who wish to make use of a service discover the specifications of that service and locate
the service provider.
- They can bind their application to that service and communicate with it using a standard service protocol.
- Internationally agreed standards avoid the incompatibilities where suppliers maintain their proprietary version of
the technology.
Fundamental standards for service oriented architecture:
- SOAP:
○ Message interchange standard that supports communication between services.
○ It defines the essential and optional components of messages passed between services
○ Services are called SOAP based in SOA.
- WSDL:
○ Web service description language
○ A standard for service interface definition
○ It sets out how the service operations (operation names, parameters, and their types) and service binding
should be defined.
- WS-BPEL:
○ A standard for a workflow language that is used to define process programs involving several different
services. (service composition)
- XML:
○ Extensible markup language
○ Markup language and file format for storing, transmitting, and reconstructing data.
UDDI (Universal Description, Discovery, and Integration):
 service and locate the service provider.
- They can bind their application to that service and communicate with it using a standard service
protocol.
- Internationally agreed standards avoid the incompatibilities where suppliers maintain their
proprietary version of the technology.
Fundamental standards for service oriented architecture:
- SOAP:
○ Message interchange standard that supports communication between services.
○ It defines the essential and optional components of messages passed between services
○ Services are called SOAP based in SOA.
- WSDL:
○ Web service description language
○ A standard for service interface definition
○ It sets out how the service operations (operation names, parameters, and their types) and
service binding should be defined.
- WS-BPEL:
○ A standard for a workflow language that is used to define process programs involving
several different services. (service composition)
- XML:
○ Extensible markup language
○ Markup language and file format for storing, transmitting, and reconstructing data.
UDDI (Universal Description, Discovery, and Integration):
- Discovery standard defines the components of a service specification intended to help users
discover the existence of a service.
- This standard is meant to allow companies to set up registries with UDDI descriptions defining
the services they offer.
- But users preferred standard search engines to find services.
- All public UDDI have now closed.
Standards that support SOA:
- WS-Reliable Messaging: ensure messages will be delivered once and once only
- WS-Security: security policies
- WS-Addressing: how address information should be represented
- WS-Transactions: how transactions across distributed services should be coordinated.

Service Components in SOA:

Message exchange
- An important mechanism for coordinating actions in a distributed computing system.
- Services in SOA communicate by exchanging (in XML) and these messages are distributed using
a standard internet transport protocol such as HTTP and TCP/IP.
- A service defines what it needs from another service by setting out its requirements in a
message which is sent to that service.
- The receiving service parses the message, and carries out the computation and when
completed, send a reply to the requesting service.
- This service then parses the reply to extract the required information.
- Message(requirements) -> receive (parse message) -> carry out computation -> finish (reply to
request service)
- Unlike software components, services do not use remote procedure or method calls to access
functionality of other users.
To use a web service
- You need to know where the service is located (Unified resource identifier URI) and the details
of the interface.
- The details of the interface:
○ Are provided in a service description written in XML called WSDL
○ WSDL defines three aspects of a web service
§ What the service does
§ How it communicates
§ Where to find it
WSDL (Web service description language):
- What: called an interface
○ Specifies what operations the service supports and defines the format of the messages
sent and received by the service.
- How: binding
○ Maps the abstract interface to a concrete set of protocols
○ It specifies the technical details of how to communicate with a web service.
- Where: location
○ Location of web service implementation (its endpoint)
○ Expressed as URI

RESTful Services:
Why Restful started?
- The general approach of SOA allows the development of complex services, dynamic service
 -

RESTful Services:
Why Restful started?
- The general approach of SOA allows the development of complex services, dynamic service
binding, and control over quality of service and service dependability.
- Some services emerged that were single function services with relatively simple input and
output interfaces.
- Service users were not interested in dynamic binding
- The problem is that web services standards are heavyweight that are overly general and
inefficient.
- Implementing these standards requires considerable amount of processing to create, transmit,
and interpret the XML messages.
- This slows down communications between services
- Sometimes additional hardware may be required as well.
- In response to this problem, an alternative lightweight approach to web service has been
developed.
- REST architectural style.
What is REST:
- Representational State Transfer
- Architectural style based on transferring representations of resources from a server to a client.
- A style that underlies the web and has been much simple than SOAP/WSDL for implementing
web service interfaces.
- Fundamental element in RESTful architecture is a resource.
- A resource is a data element such as a catalog or a medical record, or a document.
- Resources may have multiple representations and exist in different formats.
- Ex: this book chapter has 3 representations: MS word for editing, PDF for web display, and
InDesign representation for publishing.
- Resources have a unique identifier which is their URL.
- They are bit like objects with four fundamental operation associated to them
○ Create - bring a resource to existence
○ Read - return a representation of the resource
○ Update - change the value of the resource
○ Delete - make the resource inaccessible
Web Example:
- The web is an example of RESTful architecture
- Web pages are resources with a unique identifier of a web page URL
- Web protocols HTTP, HTTPS are based on four action
○ Post
○ Get
○ Put
○ Delete
RESTful Continued:
- All services operate on data
- SOAP execute actions on this database to return a value from it
- RESTful access the data directly.
- When RESTful is used, the data is exposed and is accessed using its URL
- RESTful services use http, https protocols with the only allowed actions being POST, GET, PUT,
DELETE
Difference between SOAP and RESTful:
- RESTful services are not exclusively XML-based.
- When a resource is requested, created, or changed, the representation may be specified.
- Representations such as JSON or XML may be used
- These can be processed more efficiently than XML notations
- Thus reducing the overhead involved in service call
RESTful Continued:
- Widely used because of the use of mobile devices
- These devices have limited processing capabilities, so the lower overhead of RESTful is better
for the performance.
- They are also easy to use with existing website like RESTful API for a website.
RESTful Disadvantages:
- When a service has a complex interface and is not a simple resource, it is difficult to design a set
of RESTful serices to represent this interface.
- There are no standards for RESTful interface description, so users must rely on informal
documentation to understand the interface.
- You have to implement your own infrastructure for monitoring and managing the quality of
service and reliability. While SOAP based services have additional infrastructure support
standards such as WS-reliability.
Dual Approach of RESTful and SOAP based interfaces:
- Common for cloud services from providers such as Microsoft, google, and amazon.
- Service clients can choose the service access method that is best suited for their application.
 documentation to understand the interface.
- You have to implement your own infrastructure for monitoring and managing the quality of
service and reliability. While SOAP based services have additional infrastructure support
standards such as WS-reliability.
Dual Approach of RESTful and SOAP based interfaces:
- Common for cloud services from providers such as Microsoft, google, and amazon.
- Service clients can choose the service access method that is best suited for their application.

Service Engineering:
- The process of developing services for reuse in service oriented applications
- Much common is component engineering
- Ensure that the service represents a reusable abstraction that could be useful in different
systems.
- Must design and develop generally useful functionality and ensure that the service is robust and
reliable.
- They have to document the service so that it can be discovered and understood by potential
users.
Three stages in service engineering process:
1. Service candidate identification:
- Identify possible services that might be implemented
- Define service requirements
2. Service design
- Design the logical service interface and its implementation interfaces
- SOAP based and/or RESTful
3. Service implementation and deployment:
- Implement and test the service
- Make It available to users
Service Candidate Identification:
- Services should support business processes
- As every organization has a wide range of processes, many possible services may be
implemented
Three fundamental Types of services:
- Utility services:
§ Services implement some general functionality that may be used by different
business processes
§ Ex: currency conversion service from dollars to euros
- Business services:
§ Services associated with a specific business function
§ Ex: a university like registration of students to a course.
- Coordination services:
§ Support more general business composite processes that involve different actors
and activities
§ Ex: an ordering service that allows orders to be placed with suppliers, goods
accepted, and payment made.
Task and Entity oriented services:
- Task oriented services:
▪ Associated with some activity
▪ Utility, business, or coordination
- Entity oriented services:
▪ Associated with a system resource
▪ Resource is business entity
▪ Ex: job application form
▪ Utility
▪ Ex: document translator, web form to XML converter
▪ Only utility and business
Service Classification:

Questions to identify Services:

- Entity oriented service,
▪ Is the service associated with a single logical resource that is used in different business
processes?
▪ What operations are normally performed that must be supported?
▪ Do these fit with RESTful operations CRUD?
- Task oriented service,
▪ Is the task one that is carried out by different people in the company?
Questions to identify Services:
- Entity oriented service,
▪ Is the service associated with a single logical resource that is used in different business
processes?
▪ What operations are normally performed that must be supported?
▪ Do these fit with RESTful operations CRUD?
- Task oriented service,
▪ Is the task one that is carried out by different people in the company?
▪ Will they be willing to accept the inevitable standardization that occurs when a single
support service is provided?
▪ Can this fit into RESTful model, or should it be redesigned as an entity oriented service?
- Is the service independent?
▪ To what extent does it rely on the availability of other services?
- Does the service have to maintain state? Is a database required?
- Could the service be used by clients outside the organization?
- Are different users of the service likely to have different non-functional requirements?
Output of selection process:
- Set of identified services and associated requirements for these services.
- Functional requirements: what the service should do
- Non functional requirements: security, performance, etc.
___________________________________________________________________________________
_
REST APIs are Stateless:
- Each request from a client to the server must contain all the information needed to understand
the request
- The server does not store any session or context information about client between requests
- The server does not remember anything about previous requests
- All requests are independent
- The client must send all necessary data with every single request
Example REST API are stateless:
- Imagine a user logs into a system and wants to access their profile
- First, the client logs in and gets a token (JWT)
- Then, to access the profile
- The server uses the token to authenticate and authorize but it doesn’t store session data
between requests
Why Statelessness is Good For REST?
- Scalability:
▪ Easier to scale since no session memory is stored on the server
- Reliability
▪ Each request is isolated, if one fails, others are unaffected
- Simplicity:
▪ Easier to understand and maintain
- Load balancing:
▪ Any server can handle any request since there's no stored session state
___________________________________________________________________________________
_

Service Interface Design:

- Defining the operations associated with the service and their parameters/
- SOAP based, design input and output messages
- RESTful based, think about the resources required and how standard operations should be used
to implement the service operations.
Abstract Interface Design:
- Identify entities an the operations and their inputs and outputs, and the exceptions
- How the abstract interface is realized as SOAP or RESTful services
SOAP Based - Design the structure of the XML messages that are sent and received
approach: by service
- Operations and messages are basis of interface description written in
- WSDL.
RESTful approach - Design how the service operations map onto RESTful operations
- What resources are required
- Also include exceptions that may arise when operation is invoked
- No need to be specific in detail at that stage of design
- Informal description of what the service should do
Add more detail Design:
- Show the inputs and outputs that shows the functional description
- And exceptions
▪ Define exceptions that report incorrect inputs to the service client
▪ Leave exception handling to the user of the component
▪ Service developed should not impose their views on how exceptions are handled.
- Sometimes, a textual description is all that is required
- Other times a more detailed design with UML or JSON is required.
Dilemma of which architecture to use:
- Whether RESTful or SOAP based
- Entity based service, represented as a resource which suggests RESTFUL
- However, the operations are not simple GET operation, which suggests SOAP
 - And exceptions
▪ Define exceptions that report incorrect inputs to the service client
▪ Leave exception handling to the user of the component
▪ Service developed should not impose their views on how exceptions are handled.
- Sometimes, a textual description is all that is required
- Other times a more detailed design with UML or JSON is required.
Dilemma of which architecture to use:
- Whether RESTful or SOAP based
- Entity based service, represented as a resource which suggests RESTFUL
- However, the operations are not simple GET operation, which suggests SOAP
- Usually, local circumstances, expertise are a major factor in the decision of which approach to
use/
RESTful Interface:
- Decide on the set of resources that will be used to represent GET, POST, PUT operations on
these resources.
- There should be a resource representing a company-specific catalog
▪ URL <base catalog>/<company name>
▪ Created using POST operation
- Each catalog item has its own URL
▪ <base catalog>/<company name>/<item identifier>
▪ Use GET to retrieve items
- Ppt continue

Service Implementation and Deployment:

- Once you have identified candidate services and designed their interfaces, implement now.
Implementation:
- Programming the service using a language such as Java or C#.
- Both these languages include libraries with extensive support for developing SOAP and RESTful
services.
- OR
- You can implement services by creating service interfaces to existing components or legacy
systems.
- 1 Software assets that have already proved to be useful can therefore be made available for
reuse. (components)
- 2 Legacy systems, means that the system functionality can be accessed by new applications
- 3 You can also develop new system by defining compositions of existing services.
- Once the service has been implemented, it has to be tested before it is deployed.
Testing:
- Involves examining and partitioning service inputs and creating input messages that reflect
these input combinations, then checking the outputs expected.
- You should always try to generate exceptions during the test to check how the service will cope
with invalid inputs.
- For SOAP, testing tools are available that allow services to be examined and tested, and that
generate tests from a WSDL specification
▪ However, These tools can only test the conformity of the service interface to the WSDL
▪ They cannot test the service's functionality behavior
Deployment:
- Service deployment is the final stage of the process.
- It involves making the service available for use on a web browser
- Most server software makes this operation straightforward
- You install the file containing the executable service in a specific directory
- Then it automatically becomes available to users.
Service Description:
- Information about your business, contact details, etc.
▪ Important for trust reasons
▪ External users of a service have to be confident that it will not behave maliciously
▪ Information about service providers allow users to check their credentials
- Informal description of the functionality provided by the service
▪ Helps potential users decide if the service is what they want
- Description of how to use the service
▪ For simple services, informal textual description that explains input and output
parameters.
▪ For more complex SOAP services, WSDL description must be published.
- Subscription information that allows users to register for information about updates to the
service.

Service Composition:
- Underlying principle of service oriented engineering is that you compose and configure services
to create new, composite services.
- 1 These may be integrated with a user interface implemented in a browser to crate a web
application
- 2 They may be used as components in some other service composition
- The services involved in the composition may be specially developed for the application,
business services developed within a company, or services from an external provider
- Both RESTful and SOAP can be composed to create services with extended functionality
- Some companies converted their applications into service oriented systems where the building
block is a service rather than a component.
- This allows for a widespread reuse within the company.
 to create new, composite services.
- 1 These may be integrated with a user interface implemented in a browser to crate a web
application
- 2 They may be used as components in some other service composition
- The services involved in the composition may be specially developed for the application,
business services developed within a company, or services from an external provider
- Both RESTful and SOAP can be composed to create services with extended functionality
- Some companies converted their applications into service oriented systems where the building
block is a service rather than a component.
- This allows for a widespread reuse within the company.
- Service composition may be used to integrate separate business process to provide an
integrated process offering more extensive functionality.
- Final result is a single service that integrates services from different providers.
- Think of this process as a sequence of separate steps.
- Information is passed from one step to the next
- This sequence is called a workflow
- Workflow: set of activities ordered in time, with each activity carrying out some part of the
work.
- A workflow model is a model of business process to reach a particular goal
- IRL, service composition is more complex
- You have to consider possibility of a service failure and include exceptions managements to
handle these failures.
- Also take into account he nonstandard demands by users of the application
- Compensation action are used to undo actions that have already been completed but that must
be changed as a result of later workflow activities.
Design with reuse:
- Designing new services by reusing existing services
- Involves requirements compromises
Six Stages of Construction by Composition:
1. Formulate outline workflow:
- Take the requirements for the composite service as a basis for creating an "ideal" service
design.
- Create an abstract design with the intent of adding details once you know more about
available services.
2. Discover Services:
- You look for existing services to include in the composition
- Maybe involved in local service catalog or search for trusted service providers.
3. Select possible services:
- Select possible services that can be implement workflow activities.
- Your selection criteria will include the functionality of the services offered.
- Also include the cost and quality of services
4. Refine workflow:
- Adding detail to the abstract description
- Adding or removing workflow activities
- You may repeat the service discovery and selection stages
- Once a stable set of services has been chosen and the final workflow design established
move to next step
5. Create workflow diagram:
- Abstract workflow diagram is transferred to an executable program and the service
interface is defined.
- Using programming languages like Java or workflow language BPMN
- May involve the creation of web based user interfaces to access service from web
browser
6. Test completed service or application
- Complex testing later
Workflow design and implementation
- WS-BPEL is an XML standard for workflow specification
- However, WS-BPEL are long and unreadable.
- Graphical workflow notations such as BPMN are more readable and WS-BPEL can be generated
from them
- In inter-organizational systems, separate workflows are created for each organization and
linked through message exchange
- Workflows can be used with both SOAP or RESTful
BPMN:
- Rectangles with rounded corners represent activities.
▪ An activity can be executed by a human or by an automated service.
- Circles represent discrete events.
▪ An event is something that happens during a business process.
▪ A simple circle is used to represent a starting event
▪ a darker circle to represent an end event.
▪ A double circle (not shown) is used to represent an intermediate event.
▪ Events can be clock events, thus allowing workflows to be executed periodically or timed
out.
- A diamond is used to represent a gateway.
▪ A gateway is a stage in the process where some choice is made.
▪ For example, in Figure 18.15, a choice is made on the basis of whether or not rooms are
available.
- A solid arrow shows the sequence of activities
a dashed arrow represents message flow between activities.