SOA Workshops

A university runs one big application that handles everything: student records, the course catalog, enrollment, invoicing and payments, and email notifications. Every change requires redeploying the whole system, and the enrollment rush in September takes the invoicing screens down with it.

Your task: propose a decomposition into 4 to 6 candidate services. For each one, give a name, a one-sentence responsibility, and one example operation it would expose. Then answer: which piece of data is the hardest to split, and why?

Each scenario below violates one core SOA principle (standardized contract, loose coupling, abstraction, reusability, autonomy, statelessness, discoverability, composability). Name the principle and explain the damage in one sentence.

1. The Payments team publishes its service with a hand-written Word document describing the request format; every consumer integrates slightly differently.
2. Shipping reads order rows directly from the Orders service’s database “because it’s faster.”
3. CustomerLookup’s response includes the name of the internal cache library and the ID of the server that handled the call.
4. Three departments each built their own “send an email” service; none knew the others existed.
5. CartService keeps the shopping cart in the memory of the server that handled the first request, so every later call must hit the same machine.

The SOA triangle connects three roles: service provider, service consumer, and service registry.

1. Name the three interactions between the roles and who initiates each one.
2. A currency-conversion service just went live. Walk through the triangle step by step until a consumer makes its first successful call.
3. The registry crashes at noon. Which already-running integrations break, and which action becomes impossible?

Study this SOAP message, then answer the questions below.

<soap:Envelope
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <auth:SessionToken xmlns:auth="http://uni.dz/auth">
      f81d4fae-7dec
    </auth:SessionToken>
  </soap:Header>
  <soap:Body>
    <enr:EnrollStudent xmlns:enr="http://uni.dz/enrollment">
      <enr:StudentId>20260412</enr:StudentId>
      <enr:SectionId>GLCC-SOA-01</enr:SectionId>
    </enr:EnrollStudent>
  </soap:Body>
</soap:Envelope>

1. Name the three structural parts present and the one that is optional.
2. What operation is being invoked, and what are its parameters?
3. Why does the session token travel in the header rather than the body?
4. If SectionId did not exist, where and how would the service report the error?

A partner sent you this (abridged) WSDL. Without calling anything, extract what you need to integrate.

<definitions name="GradesService"
    targetNamespace="http://uni.dz/grades">

  <message name="GetTranscriptRequest">
    <part name="studentId" type="xsd:string"/>
    <part name="term"      type="xsd:string"/>
  </message>
  <message name="GetTranscriptResponse">
    <part name="transcript" type="tns:Transcript"/>
  </message>

  <portType name="GradesPort">
    <operation name="GetTranscript">
      <input  message="tns:GetTranscriptRequest"/>
      <output message="tns:GetTranscriptResponse"/>
    </operation>
  </portType>

  <binding name="GradesSoapBinding" type="tns:GradesPort">
    <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
  </binding>

  <service name="GradesService">
    <port name="GradesPortEndpoint" binding="tns:GradesSoapBinding">
      <soap:address location="https://sis.uni.dz/ws/grades"/>
    </port>
  </service>
</definitions>

1. What operation(s) does the service offer? With which inputs and outputs?
2. Which WSDL section answers “what can I call” and which answers “where do I call it”?
3. Over which transport does this service speak?
4. Historically, in which registry would a consumer have found this WSDL?

The university library needs a REST API covering: list and search books, view one book, add a book (librarians), update a book’s details, delete a book, and borrow / return a copy.

Your task: design the resource URIs and map each use case to an HTTP method, with the expected success status code. Then answer: how do you model borrowing — which resource does it create?

Using only curl (or Postman) against the free fake API jsonplaceholder.typicode.com:

1. Fetch user 3 and read the response status line and headers (flag -i). What is the Content-Type?
2. Fetch only the posts of user 3 using a query parameter.
3. Create a post with POST. Which status code comes back?
4. Request a resource that does not exist (/users/999). Which status code — and why is that better than a 200 with an error message inside?

For each scenario, choose SOAP or REST and justify with one or two criteria from the comparison slide (contract formality, security standards, tooling, simplicity, caching, audience).

1. Interbank transfer service; regulators require signed, encrypted messages and formal contracts between institutions.
2. Public API backing a mobile app that lists nearby restaurants.
3. Integration with a 2009-era ERP that only exposes WSDL-described endpoints.
4. A high-read public catalog where responses rarely change and bandwidth matters.

Each flow below exercises one primary ESB capability: content-based routing, message transformation, protocol mediation, or message enrichment. Identify it.

1. Orders over 10 000 DZD go to the fraud-check service; the rest go straight to fulfillment.
2. The CRM emits XML; the analytics platform only accepts JSON. Both stay unchanged.
3. A message arrives with only a customerId; before delivery, the bus looks up the customer’s tier and appends it.
4. The warehouse system listens on a message queue; the web shop can only make HTTP calls. They converse anyway.

Classify each design as orchestration (a central coordinator drives the flow) or choreography (services react to each other’s events), then answer the follow-up.

1. A TripBooking process calls flight, hotel, and car services in order, and cancels the flight if the hotel fails.
2. When OrderPlaced is published, Inventory reserves stock, Email sends a confirmation, and Analytics logs it — none of them is told to.
3. A BPEL engine executes a loan-approval process: credit check, then risk scoring, then human approval if the score is borderline.

Follow-up: give one strength and one weakness of each style.

An e-commerce order must pass through four services: Inventory (reserve stock), Payment (charge the card), Shipping (create the shipment), and Notification (email the customer). Constraints:

• Payment must not be attempted if stock reservation fails.
• If payment fails, the reserved stock must be released.
• The shop submits orders as JSON over HTTP; Shipping is a legacy system consuming XML from a queue.
• The customer email must go out whatever the outcome (confirmed or failed).

Your task: sketch the flow (a numbered sequence is fine), choose orchestration or choreography for the critical path and justify, and point out where the ESB performs transformation and protocol mediation.

For each scenario, decide whether transport-level security (TLS/HTTPS) is sufficient or whether message-level security (WS-Security: signing/encrypting the message itself) is required — and say why.

1. Service A calls service B directly inside one data center; no intermediaries.
2. A claim document crosses three organizations: hospital → insurance broker → insurer. Each hop must read the routing block, but only the insurer may read the medical details.
3. A signed purchase order must remain provably authentic in an archive, five years after the connection that carried it is gone.

A student portal (“the app”) wants to read your timetable from the university’s API without ever seeing your password. Here are the authorization code flow steps — shuffled. Put them in order, then name each actor’s OAuth role (resource owner, client, authorization server, resource server).

1. The app exchanges the code (plus its client secret) for an access token.
2. You log in at the university’s identity page and approve “read timetable.”
3. The app calls the timetable API with the token; the API validates it and responds.
4. The app redirects your browser to the university’s authorization page.
5. The identity page redirects your browser back to the app with a one-time authorization code.

Follow-up: why hand out a temporary code first instead of returning the token straight to the browser? And what does OpenID Connect add on top?

You join a company whose SOA grew without adult supervision. An audit finds:

• Three different services answer “find customer by ID,” built by three teams.
• Last month, the Invoicing team renamed a field in its response; four consumer applications broke the same morning.
• The ProductSearch service slows to 8-second responses every lunchtime; nobody is contractually on the hook.

Your task: name the governance failure behind each finding (the deck gives you the vocabulary) and propose one concrete corrective measure per finding.

Attribute each statement to classic SOA, microservices, or both:

1. Integration logic lives in a smart central bus.
2. Each service owns its private database.
3. The primary goal is service reuse across the whole enterprise.
4. Services should be loosely coupled and independently designed.
5. “Dumb pipes, smart endpoints.”
6. Scope is typically a single application, decomposed for scale and deployment speed.

Your company moves two SOA services to the cloud. For each, choose lift & shift onto IaaS or rebuild onto PaaS, and justify using cost, urgency, and scaling behavior.

1. DocumentArchive: stable for years, few changes planned, steady low traffic — but its data-center lease ends in three months.
2. ExamResults: idle most of the year, then crushed for two weeks each semester; the team constantly ships new features and wants zero server maintenance.

NovaMart, an online retailer, runs a well-structured monolith maintained by 8 developers. Facts:

• Deployments happen weekly without drama.
• The only real pain: product search — it eats most of the CPU at peak, and scaling means duplicating the whole monolith.
• The CTO returned from a conference asking to “replace it all with 30 microservices on Kubernetes.”

Your task: write a short recommendation (5–8 sentences). Should they adopt full microservices? Use the SOA-vs-MSA criteria — team size, deployment independence, operational cost, where the scaling pressure actually is.