Service Oriented Architecture

8 minute read

Updated:

Architectures

One-tier Architectures

  • We take all 3 layers and build that into ONE system that combines all thee software system layers (=legacy systems)
    • Very long code that runs in one system – system will combine 3 software system layers- PAD
    • Represented as a mainframe host – where we had the host directly connected to one big machine, which is connected to a unintelligent terminal (a dumb terminal: accepts data from CPU but almost no processing capabilities)
  • Idea is that it emphasizes a lot on the efficiency of the machine (CPU, system) – monolithic, and it doesn’t provide entry point when interacting except through dumb terminal

Two-tier Architectures

  • Take 3 layers, and one has to go out – separate presentation layer
  • Simply says with the advance of the PC, you can think about you sitting in pc (1), and pc connects to a server(2)
    • Server does app and resource management
    • U move presentation from server to client

Three-tier Architectures

  • Why can’t you just map 3 system into 3 diff system?
  • application logic layer – sits on a middle tier that interacts with client and backend resources
  • application logic layer will facilitate many abstractions and infrastructure that supports the development – this is supported through middleware
  • Key concept is the concept of middleware – that makes it look like a one coherent system

N-tier Architectures

  • If we apeopley 3 tier model to full generality, we expect many servers at the app logic, many servers in resource management
  • What’s interesting is that app logic layer becomes itself a server to the presentation, but a client to the resource management layer
  • N- tier architecture arise from:
    • Situations when resource layer itself not only includes a simple resource like database, but when it also includes a fully-fledged two or three tier system
      • In the sense that resource management has db, network, storage data in itself can be implemented in the app or resource layer itself
    • Additional tier is created when you incorporate one server as part of the presentation layer
      • Meaning that you as a user is sitting at the presentation, presentation layer itself is regarded as a separate layer due to high complexity of the web service. These days its unlikely that when you interact with web server u. only interact with one – virtual server, two or three
      • E.g. Quick search on google – search is handled by different servers

N-tier Architectures II

  • N tier is Very much a full generalization of 3 tier archi, where the tiers can be a tier of itself
  • U realize that you can implement them and rely on middleware to make it work. BUT ur gonna rely on standard for the interoperability of the system
    • Standards are iMPoRtant!!
  • So, you may demonstrate the large amount of middleware to integrate multiple systems.
  • Finally, the fact that ur app logic is distributed across in multiple machine – and if app logic is distributed in diff machine and they have diff middleware too → then you need a system to integrate them all.

Comparing the architectures

  • Thesedays it could be 3 or N tier
  • Hw – you can look at the diff btwn 4 archi in terms of
    • Dependency
    • Complexity
    • And scalability

Trends in system evolution

  • Software evolved from monolithic → complex and decoupled n tier systems
    • EMPHAIZE decouple!! – no of components with diff functionality but they interact to provide diff functionality to you
  • Trends
    • Software is becoming complex
    • And it has to integrate with all sorts of systems, such as legacy system that is managed by diff administrative domains and reside in diff organisations
      • Tricky when all components are all over the place and you wanna integrate them – to address this → SOA

Problems Addressed by a Service Oriented Architecture

  • SOA - Simply means that today if we 200 studs that have software component, and his job is to integrate these components into a new app - we all have in java, python and etc. So why don’t you turn ur component into a SERCVICE??? If it’s a service, we could just give an API to him, and u’d be able to integrate it all

  • As a SERIVCE

Service-Oriented Architectures

  • Is an architectural style
  • What app that uses SOA do deliver, is a functionality through services. And is used when building applications and services can be integrated when using apps
  • To ease the development, the apps are:
    • Dynamic - can change overtime
    • Loosely coupled – no dependency btwn them. Invoke first service then second service
    • Potentially interorganisational system– the eg with 200 students, I can simply look at what’s available. Google, amazon
      • what they do as an organization is that they provide services so that we can integrate it in our own applications
  • Paradigm shift from object-oriented systems to message oriented system -Is invoked through invocation
    • message to server→ server is gonna interpret and invoke service reply
  • Interesting is that all this works through ‘platform independent interface description’
    • We have no idea how the service is implemented thanks to the interface
    • What we need is the description of the interface so that we can use it and reply back

SOA Vision

  • Resources- All the resources on the web that is available can be accessed

  • Service – once resource e is known, it provides services. Before we access it, we need to discover it (know it exists)

  • Connectivity – you could put whatever you like in the world, as long as you know that there’s a service that can be invoked

  • Technologies – you have a tool that you can build the services, make them available and that they can be discovered and accessed. Then people can use these services, invoke it and integrate it as a part of their app

  • Communities – you have communities, with operational procedures where services can be invoked and can be used by the entire world

Power Grid Inspiration for Computing

  • This comes from the real world, we got the inspiration from power grid
    • Electricity is generated in a similar way – in a sense that its transparent.
    • If we plug it to a socket we don’t know where the electricity comes from - wind turbine? Nuclear plant?
  • Anyways the fact that its transparent is similar

What is a ‘Service’?

  • Reusable service component that can be used as a building block – and by using this, it could be THE app or the part of an application – interact w invocation
  • Service may be as simple as ‘get this for me’ or complex as ‘process a disbursement’
    • E.g. in module what web service is like
      • Anything you can think of – weather forecast, stock quote, etc
  • → Software component is supported in this logic and can be integrated thanks to an interface.

The Cloud Computing Metaphor: Service Access

  • The way we access the service is transparent– one side of the wall is me and u. we dunno what’s happening on the other side of the all
  • impORTNACE OF transparency is key
    • behind the wall there are all sorts of machines – sensor, supercomputer etc
    • this is where the services get deployed so that it can be invoked on the other side

Service-Oriented Architectures II

  • 1
  • Start by the service provider – who owns the service. Since it owns it, it needs to publish the service so that you and me can discover it.

  • So the service is described and is stored in a directory service

  • Service requester – would like to invoke the service
    • Search for the service through directory service→ gets the interface of the service → invoke the service by interacting directly with the service provider

Service Provision and Consumption

  • 2
  • Service consumer is LHS, and service RHs
    • Policy - Service itself before it gets published, needs to be governed by a policy – you use it this way!! And consumer adheres to it that you invoke in this way.
    • End point – service exposes itself, through end point (e.g.URI- address where service is invoked) consumer than binds to the end point
    • Contract – service publishes a contract aka, service agreement that is understood by the consumer
    • Messages–the business logic itself is implemented through msg passing, and consumer sends messages, service is invoked and result of invocation is sent back to the consumer as a message.

Service-Oriented Architectures III - Decentralised middleware

  • To implement this, we need a middleware – client is talking to server transparently
  • There’s no obvious place to place middleware in 3 or n tier.

  • With SOA, middleware itself for interservice discovery and communication, is present within the hosting environment – it’ll be very ez for the provider to say I’m hosting a middleware env, such that when you invoke my service, I’m able to respond.

  • → middleware is decentralised, its not in one place

Service-Oriented Architectures IV - Emphasis on loose coupling

  • In SOA it’s loosely coupled – interdependency btwn the services are NOT there
  • Due to the no dependency, you can easily add, replace, change services. → easy, dynamic and well structured
  • One thing to be careful is – if sth fundamental thing changes in the service, we need to ensure that the interface DOESN’T change!! Coz then ud have to change it for all clients
  • Modifications are much less likely to adversely affect existing services – flexibility is good.
  • Services once they exist, invoked, re-invoked, used and aggregated easily in diff ways

Service-Oriented Architectures V – adherence to well-supported standards

  • Standards
  • With SOA, we ain’t gonna reinvent all sorts of things
    • We will look at traditional system – the way we integrated them is by standards, that necessitates middleware to act as a bridge btwn diff middleware systems.
  • With SOA since we have services form diff organisations, we can look at standardisation to make the invocation a bit easier
    • SOA organisations that has looked at SOA standardisation – OASIS and W3C.
  • → no need to reinvent the wheel but still there are organisations that are contributing to having a standard

Summary

  • History, 1,2,3, N-tier to SOA architecture with service provider, finding and interacting, Emphasis on middleware, loosely coupled and adherence to standards.
  • SOAs been there for long, and its mainstream when it comes to building and integrating apps.

Leave a comment