Service-Oriented Architecture and SaaS, Explained

UPI Study › Courses › Software Engineering › Free lessons › Lesson 15.4 Free with a free account

Service-Oriented Architecture and SaaS

Software Engineering · Chapter 15: Distributed Systems, Services, and Sociotechnical TopicsSection 15.4 · lesson 98 of 1037 min · free with a free account

← Architecture Patterns for Building Distributed SystemsNext lesson: Engineering Services: From Definition to Delivery →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

An architectural style, and a delivery model - often together, never the same.

  • Define service-oriented architecture and its core principles
  • Define SaaS, and how it differs from SOA
  • Weigh the benefits of each against real trade-offs
  • Recognize where composing services adds clear value

Transcript

Everything said in the video, section by section (876 words). Read along, or search it.

Distributed Systems, Services, and Sociotechnical Topics

Service-Oriented Architecture and SaaS

Transparency, concurrency, and scalability describe what a good distributed system should achieve. They do not say how to structure one. This section covers one influential answer, service-oriented architecture, and a closely related idea that is often confused with it, software as a service.

From Principles to Structure

2 Related Ideas

Service-oriented architecture, or S O A, is an architectural style. It builds a system as a collection of independent services, each exposing a defined interface, that can be discovered, reused, and combined into larger applications. Software as a service, or SaaS, is closely related, but conceptually distinct. It is not an architecture at all. It is a business model for how software gets delivered to customers. And it frequently relies on S O A internally.

SOA

Independent Services, Defined Interfaces

In S O A, a service is a self-contained unit of functionality, exposing a well-defined interface. Other parts of the system can call it without knowing how it is implemented internally. Services are loosely coupled, interacting only through their defined interfaces. And they are reusable, built once and called on by many different consumers. They are discoverable, so a consumer can find and understand what a service offers. And they are composable, so a larger business process can be assembled by combining several independent services.

Figure 15.4A

A Process Composed From Services

Here is a process composed from independent services. Order fulfillment calls on four of them. Inventory, shipping, payment, and notification. Now a completely different process, subscription renewal, needs to charge customers and notify them. It simply reuses the same payment and notification services. That reuse, by an entirely different process, is exactly the payoff loose coupling is meant to provide.

SaaS

Software as a Service

Software as a service is a delivery model. An application is hosted centrally by a provider, and customers use it over the internet, typically in a web browser, rather than installing it on their own machines. SaaS is usually multi-tenant. Many customers share the same application instance and infrastructure, with each customer's data kept separate. And it is typically billed as an ongoing subscription, rather than a one-time purchase. So SaaS shifts both where the software runs, and how the customer pays for it.

Easy to Conflate

Different Questions

S O A and SaaS are easy to conflate, but they answer different questions. S O A is an architectural choice, about how a system is structured internally. SaaS is a business choice, about how finished software reaches its customers. A SaaS product is very often built using S O A inside. But the two ideas do not require each other. And S O A itself should sound familiar. It is component-based construction, applied to independently running, networked services.

Benefits and Trade-offs

What SOA Gives, and Costs

Composing systems from independent services brings real advantages. Reuse across an organization. Faster development, by composing rather than custom building. And independent scaling of each service. The trade-offs are just as real. There are more moving, independently failing parts to monitor and coordinate. And there is a real dependency risk. Every consumer of a shared service is affected if that service changes, or goes down.

SaaS Trade-offs

What the Customer Gains, and Gives Up

For SaaS specifically, the customer gains a lower upfront cost, and automatic maintenance. They can adopt capable software without owning and maintaining the infrastructure it runs on. In return, they give up some control over customization, accept an ongoing subscription cost, and depend on a third party to host their data responsibly. Email and productivity software, customer relationship management, and accounting software are now commonly delivered this way.

Table 15.4

SOA and SaaS at a Glance

Here are the two side by side. S O A is an architectural style for structuring a system. SaaS is a model for delivering software to customers. S O A's core idea is independent, reusable, composable services. SaaS's core idea is centrally hosted, subscription-based access. S O A's key benefit is reuse and independent scaling, at the cost of more moving parts and dependency risk. SaaS's key benefit is lower upfront cost and automatic maintenance, at the cost of less control, and an ongoing bill.

Apply It

The Payment Service Changes Its Interface

Let's apply that. The payment service changes its interface, without warning. What happens to the subscription renewal process? It breaks. And so does order fulfillment, because it depends on the same service. Every consumer of a shared service is affected by its changes. Loose coupling only protects consumers while the interface they depend on holds steady.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Service-oriented architecture structures a system as a collection of independent, reusable services with defined interfaces. A service is a self-contained unit of functionality behind a well-defined interface. Loose coupling means services interact only through defined interfaces, without depending on each other's internal details. Software as a service is a delivery model where an application is centrally hosted, and accessed over the internet, typically by subscription. And multi-tenant means many customers share the same application instance and infrastructure, with their data kept separate.

Key Takeaways

What to Carry Forward

To pull this together. S O A structures a system as loosely coupled, reusable, discoverable, and composable services. SaaS is a delivery model. It is conceptually distinct from S O A, even though SaaS products are often built on it. S O A's reuse and independent scaling come with more moving parts, and shared-service dependency risk. SaaS trades customer control and an ongoing cost, for lower upfront investment and automatic maintenance. And composing services into a larger process is component-based construction, applied at the level of networked services.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About Service-Oriented Architecture and SaaS

What is service-oriented architecture (SOA)?
Service-oriented architecture is an architectural style that builds a system as a collection of independent services, each exposing a well-defined interface. Services are loosely coupled, interacting only through those interfaces, and are reusable, discoverable, and composable. A larger business process, such as order fulfillment, can be assembled by combining services like inventory, shipping, payment, and notification.
What is the difference between SOA and SaaS?
SOA is an architectural style for structuring a system internally, while software as a service (SaaS) is a business model for delivering finished software to customers. A SaaS product is very often built with SOA inside, but the two ideas do not require each other. SOA centers on reusable services; SaaS centers on centrally hosted, subscription-based access.
What does multi-tenant mean in SaaS?
Multi-tenant means many customers share the same application instance and infrastructure while each customer's data is kept separate. It is typical of SaaS, where a provider hosts the application centrally and customers use it over the internet, usually in a browser and on an ongoing subscription. Customers gain lower upfront cost and automatic maintenance but give up some control.
What are the risks of sharing services in a service-oriented architecture?
The main risks are more independently failing parts to monitor and coordinate, and dependency risk: every consumer of a shared service is affected if it changes or goes down. If a payment service changes its interface without warning, every process that calls it, such as order fulfillment and subscription renewal, can break. Loose coupling protects consumers only while the interface holds steady.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →