Lecture 5: Service-Oriented Architecture (SOA) & Web Services

1. What is Service-Oriented Architecture (SOA)?

Service-Oriented Architecture (SOA) is a software design style where services are provided to the other components by application components, through a communication protocol over a network. Its basic principles are independent of vendors, products, and technologies.

In SOA, an application is no longer a massive, tightly woven monolith. Instead, business logic is broken down into distinct, reusable "Services". For example, instead of having a billing module locked inside an ERP, you expose a ProcessPayment service that the ERP, the web portal, and the mobile app can all share and reuse.

2. Core Principles of SOA

To qualify as a true SOA environment, the architecture must adhere to several guiding principles:

• Standardized Service Contract: Services must have a clearly defined agreement (contract) detailing what they do and what data they require.
• Loose Coupling: Services maintain a relationship that minimizes dependencies. If the internal code of the ProcessPayment service changes, the systems consuming it should not break.
• Service Reusability: Logic is divided into services with the intention of promoting reuse across the enterprise.
• Service Autonomy: Services have control over the logic they encapsulate (they manage their own data and processes).
• Service Discoverability: Services must be easily discoverable by other systems, usually via a registry.

3. The SOA Architecture: Find, Bind, and Execute

The fundamental operational model of SOA involves three primary actors: the Service Provider, the Service Consumer, and the Service Registry.

4. Implementing SOA: SOAP, WSDL, and XML

While SOA is an abstract architecture, its most famous technical implementation in the 2000s and early 2010s was Web Services. These traditional web services relied on three core W3C standards:

• XML (eXtensible Markup Language): The data format used to structure the messages.
• WSDL (Web Services Description Language): An XML document that acts as the "Contract". It describes exactly what operations the service offers, where it is located, and what the input/output XML should look like.
• SOAP (Simple Object Access Protocol): The protocol specification for exchanging structured information. A SOAP message is an XML document containing an Envelope, a Header, and a Body.
• UDDI (Universal Description, Discovery, and Integration): The standard for the Service Registry (the "Yellow Pages" of web services).

5. Case Study: SOAP Web Service for Student Information

Imagine Udayana University exposing a service so the Library System can verify a student's enrollment status. The Library System (Consumer) sends a SOAP Request to the Academic System (Provider).

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope 
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
  xmlns:aca="http://api.unud.ac.id/academic">
   <soapenv:Header/>
   <soapenv:Body>
      <aca:GetStudentStatusRequest>
         <aca:StudentId>1905551042</aca:StudentId>
      </aca:GetStudentStatusRequest>
   </soapenv:Body>
</soapenv:Envelope>

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope 
  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
  xmlns:aca="http://api.unud.ac.id/academic">
   <soapenv:Header/>
   <soapenv:Body>
      <aca:GetStudentStatusResponse>
         <aca:StudentId>1905551042</aca:StudentId>
         <aca:Name>I Wayan Sudarma</aca:Name>
         <aca:Status>ACTIVE</aca:Status>
         <aca:Faculty>Engineering</aca:Faculty>
      </aca:GetStudentStatusResponse>
   </soapenv:Body>
</soapenv:Envelope>