GC

T4 Service-oriented software engineering

Service-oriented Architectures

  • Instructor: Russell Lock, Loughborough University

Topics Covered

  • XML reprise

  • Service-oriented architectures

  • Webservices (SOAP/WSDL)

  • RESTful services

  • Service engineering

  • Service composition

  • Note: Chapters align with Chapter 18 of the course textbook

  • Micro-service architectures will not be covered in this module

XML (eXtensible Markup Language)

  • Definition: Platform-independent meta-language designed for data exchange between language systems.

  • Characteristics:

    • Data formatting

    • Human and machine-readable

    • Verbose (compromise for readability)

  • Purpose: Development towards 'The semantic web'.

  • Structure: Uses nesting and closing tags for error detection.

    • Example:

      <part number="1976">
          <name>Windscreen Wiper</name>
          <description>The Windscreen wiper automatically removes rain from your windscreen, if it should happen to splash there. It has a rubber <ref part="1977">blade</ref> which can be ordered separately if you need to replace it.</description>
      </part>

Introduction to Web Services

  • Definition: A web service is a loosely-coupled, reusable software component encapsulating discrete functionality, accessibly programmatically using standard Internet and XML-based protocols.

  • Core Concept: Service is independent of the application using it.

  • Coupling:

    • Loose Coupling: Use of interfaces to manage service interactions.

    • Tight Coupling: Less flexible, often more dependent.

  • Benefits:

    • Platform and implementation-language independent.

    • Enhances service reuse and integration across different organizations.

Benefits of Service-oriented Approach

  • Services could be internal or external to an organization.

  • Service providers make service information public for authorized user access.

  • Binding is deferred until deployment or execution (reactive operation).

  • Opportunistic Construction & Mashups: Composition of existing services into new applications.

  • Utility Computing: Pay-per-use model for accessing services instead of owning components.

    • Legacy systems can be retained and reused by wrapping them as services.

Disadvantages of a Web Service Approach

  • Development may incur overhead due to interfaces.

  • Wrapping legacy services has associated resource costs.

  • Loss of control when utilizing external services.

Web Services Standards Stack

  • UDDI: Registry of services.

  • BPEL: Controls workflow related to service use, maps to BPMN.

  • WSDL: Defines how a web service is accessed.

  • SOAP: XML-based communication protocol.

WSDL Components

  • Interface (What): Specifies operations and message formats.

  • Binding (How): Maps interface to protocol specifics, detailing communication methods.

  • Service Identifier (Where): Indicates the endpoint of the service implementation.

SOAP

  • Structure:

    <soap:Envelope>
        <soap:Header>
        </soap:Header>
        <soap:Body>
        </soap:Body>
    </soap:Envelope>
  • Messages consisting of service calls and relevant data.

Downsides to Traditional Web Services

  • XML encoding is verbose, complicating data readability.

  • Complicated stack can increase development overhead.

  • General services lead to compromises on the client side.

  • HTTP is not a guaranteed delivery mechanism, risking system reliability.

RESTful Web Services

  • Criticism of 'heavyweight' standards; REST offers a simpler architecture.

  • Definition: Architectural style based on resource representation transfer from server to client.

  • Commonly used by platforms like Twitter and Google.

  • Advantages:

    • Simpler than SOAP/WSDL for service implementation.

    • Supports different data formats (JSON preferred).

Resources in RESTful Architecture

  • Definition: Fundamental entities (data elements) like catalogs or documents.

  • Resources can have multiple representations (e.g., MS WORD, PDF).

Exchanging Data: JSON vs XML

  • JSON Example:

    { "ID": "A451", "Name": "A Person", "Email": "a.person@people.com", "Country": "France" }
  • XML Example:

    <Person>
        <ID>A451</ID>
        <Name>A Person</Name>
        <Email>a.person@people.com</Email>
        <Country>France</Country>
    </Person>
  • JSON is shorter and simpler, resembling a programming language layout.

Resource Operations

  • CRUD Actions:

    • Create: Instantiate a resource.

    • Read: Retrieve resource representation.

    • Update: Modify resource value.

    • Delete: Make resource inaccessible.

HTTP Operations for Resources

  • Operations:

    • POST: Create a resource.

    • GET: Retrieve resource data.

    • PUT: Update existing resource.

    • DELETE: Remove resource.

Resource Access through URLs

  • Data is accessed using URLs, often lighter than XML.

  • Structure of the URL is service specific.

    • Example: http://maps.googleapis.com/maps/api/geocode/json?address=loughborough

HTTP Status Codes

  • REST design incorporates HTTP codes for status reporting, but responses vary by browser.

  • URL parameters expose data but require careful handling to prevent security risks like SQL injection.

Disadvantages of RESTful Approach

  • Difficult to design RESTful services for complex interfaces.

  • Stateless nature limits contextual request references.

  • Lack of standard for interface descriptions requires non-standard documentation.

  • Users must develop monitoring for quality and reliability of services themselves.

Service Testing Challenges

  • Interaction with external services requires black box testing.

  • External modifications can invalidate tests.

  • Dynamic binding leads to unreliability in application testing.

  • Testing costs can rise for pay-per-use services.

Key Points

  • Service-oriented architecture (SOA) encompasses standardized, reusable services as building blocks for applications.

  • Services can be XML-based or RESTful and utilize http protocols for communication.

  • Standard operations in REST map to HTTP verbs: POST, GET, PUT, and DELETE.