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.