CSC510 Lecture 10

Towards Services
(20260925)

Transcript

1. CSC 5100 Modern Software Engineering Lecture 10. Towards Services Dr. Javier Gonzalez-Sanchez javiergs@calpoly.edu www.javiergs.info ffi o ce: 14 -227
2. REST, MQTT, interfaces, and the Temperature example Existing Feature 2 Communication Integration
3. Where We Are Going Sprint 1 Feature works locally Sprint 2 Expose + consume • Keep the domain behavior that already works. • Add communication responsibilities without duplicating the core logic. • Integrate independently owned stories through an agreed contract. 3 Later Deploy + operate
4. The Core Idea REST Adapter TemperatureService get / set temperature Temperature value + unit • One source of domain logic. • REST and MQTT are ways to reach or move that functionality/data. • Adding an interface should not require rewriting the feature. 4 MQTT Adapter
5. Temperature Example: Responsibilities 5 Temperature Data object value, unit TemperatureService Core/domain logic stores and returns current temperature TemperatureRestServer REST provider HTTP endpoint → service TemperatureRestClient REST consumer HTTP request → response TemperatureMqttProvider MQTT provider service → publish TemperatureMqttConsumer MQTT consumer subscribe → deserialize
6. REST: Request / Response TemperatureRestClient CONSUME HTTP TemperatureRestServer PROVIDE • GET /temperature → retrieve the resource. • POST /temperature → send a new representation. • Java 17 provides HttpServer and HttpClient; Jackson handles JSON. 6 method call TemperatureService CORE
9. MQTT: Publish / Subscribe The broker is the communication infrastructure. TemperatureService CORE MQTT Provider PUBLISH MQTT Broker • Topic: csc5100/example/temperature • Provider serializes Temperature as JSON and publishes it. • Consumer subscribes and reconstructs the Temperature object. • Eclipse Paho is the MQTT client library; the broker is external infrastructure. 9 MQTT Consumer SUBSCRIBE
10. REST and MQTT Are Different Contracts REST MQTT • Consumer asks for something. • Publisher sends without knowing consumers. • Provider answers that request. • Subscribers listen to topics. • Natural for queries, configuration, commands. • Natural for telemetry, events, streams. • Contract: path + method + JSON + status. • Contract: topic + payload + QoS/behavior. Same feature ≠ same communication style 10
11. Sprint 2: Team Structure PROVIDE Feature REST provider + MQTT provider agreed contract CONSUME Feature REST consumer + MQTT consumer • Each student owns one GitHub Feature. • Both students must coordinate before coding. • Both REST and MQTT must work between the paired implementations. • The GitHub Feature contains the feature-specific architecture and Acceptance Criteria. 11
12. The Six Sprint 2 Teams 12 Message Storage REST preferred Robot Data MQTT preferred Eye / Gaze Data MQTT preferred Data Activity REST preferred Availability Monitoring REST preferred Encryption Local library ultimately; REST + MQTT practice
13. Before You Code • Read your assigned Feature and your partner's Feature. • Review the existing classes identified in GitHub. • Agree on the REST endpoint, method, JSON, and status behavior. • Agree on MQTT topic(s), payload, publisher/subscriber behavior. • Create Tasks as sub-issues of your Feature. • Then implement. Do not build two sides independently and hope they integrate later. 13
14. Reuse Before Replacement REST responsibility Existing Feature Partner's Feature MQTT responsibility • Refactor when necessary. • Add classes for genuinely new responsibilities. • Do not duplicate core logic in REST and MQTT implementations. • Think OCP and SRP. 14
15. De inition of Done for Sprint 2 • Your individual Feature satisfies its Acceptance Criteria. • Tasks exist as sub-issues and reflect the work performed. • REST communication works with your partner. • MQTT communication works with your partner. • Existing/domain functionality is reused rather than duplicated. • Tests, JavaDoc, documentation, and Astah UML are updated. 15 f • A Pull Request is submitted and instructor feedback is addressed.
16. CSC 5100 Modern Software Engineering Javier Gonzalez-Sanchez, Ph.D. javiergs@calpoly.edu Fall 2026 Copyright. These slides may be used only as study material for CSC 5100 within the California State University system. They may not be distributed or used for any other purpose.