Over the next – possibly – 2 or 3 posts, i am going to be posting about SOA, Services and MOM’s. Then they’ll be a post about SOAP, then finally one about REST. All of which are Architectures for Computing in their own right.
However, this post will mark the start – explaining in detail what SOA really is, what a Service is, as well as MOM’s (i will try a reframe from ‘ya mom’ jokes) :)
Services
Before we get this post started, we need to define what the fundamental thing the Service Oriented Architecture (SOA) governs – and that is, of course, Services.
A service is a collection of code and data – that stands alone – which can only be accessed via the usage of ‘messages’ – that is; the only when to get in and out of a service is via messages.
Four Tenets of Services (SOA)
A tenet is basically a principle that somebody holds true. Such as the Axioms of Distributed Computing. So what is about to follow are the principles behind Service Oriented Architecture.
1. Service Boundaries are Explicit
Explicit means ‘clear’ or ‘plain’ to see. So here what we really mean is that it is explicit – it is clear to see – if a piece of code or data is inside or outside of a Service.
2. Services are Autonomous
When we defined what a service means, we stated that a service is “a collection of code and data that stands alone”. This means that a service is developed and managed independently.
This leads us to our definition of this tenet. If a service is re-written, or for some people who may moan “refactored”, then this refactoring should not affect other services.
3. Services Share Schema and Contracts
A Schema is something new here, and we will come back to it in a little bit. For now, the only thing we need to know about Schemas is that they define the messages that a service can send and receive.
A Contract defines the permissible message sequences; that is, the sequence in which messages are permitted (admitted).
4. Service Compatibility is Based on Policy
This is the final tenet for Services. And quite simply, this tenet defines the rules for the usage of Services. An example of such rules is:
- The Security Policy – This specifies who can use the Service.
Service Schemas
Remember those schemas that i mentioned earlier in the third tenet above? Well now it’s time to explain what they are! :)
From the above, we stated that a schema defines what messages a service could send and receive. Take for example the following ‘messages’:
Get a quote; Make a reservation; Make Payment; Cancel Ticket
Here we have 4 messages, all of which are related to a particular order. But how does the service know what messages to receive and send? This is where the service schema comes in.
The service schema defines the message schema for each stage of the process; where the message schema is the format of the messages that the services (program) can read. Take the example messages above. Now use humans can easily understand “Get quote” and “Make Payment”, but a computer program can’t – remember, computers are very stupid really :D
Taking a few of the above messages, the service schema defines the message schema for:
- Quote Request --> [Request message]
- Quote --> [Reply message]
- Purchase Request –> [Request message]
- Invoice --> [Reply message]
Does the above look familiar at all? We send a Request message, and then receive a Reply message :)
So now we have a human readable “Get quote” and used the service schema to define the message schema to get “Quote Request” which is computer readable.
We All Love to Share
Services love to share schemas :D . There are two types of messages, incoming and outgoing messages:
- Incoming Messages – The Service transforms the message from the shared schema and into it’s internal schema.
- Outgoing Messages – The Service transforms messages from it’s internal schema to the shared schema.
Here we can see that there are different internal schemas for each system; however, the shared schemas will have to be translated by every system into a schema that it understands. Because of this we have n x (n – 1) number of transactions, where n is the total number of services (systems).
Say for example we have 6 services, then this is:
- 6 x (6 – 1) = 6 x 5 = 30 transformations!
It’s about time we got a good picture into this! :D
So here is a visual representation of 6 services with shared schemas. With this we have 30 total transformations, but what if we had 12 services? Well this would be a staggering 132 transformations!
An Alternative is Needed!
But what is an obvious choice to use as an alternative? All we need to do is lower the total number of transformations. What we need is a Central Standard Schema; which means that now there are only 2n number of transformations. Each message goes via this central standard schema.
Using the same numbers as from above. 6 services means 12 transformations and 12 services means 24 transformations – this is a scalable solution! :D
Mapping of Schemas
Since every service has it’s own internal schema, then there can be difficulties in mapping a service’s internal schema to another (shared) schema. Unfortunately, it can sometimes even be impossible to achieve this mapping as the two schemas are so vastly different.
But what makes this mapping to complex?
- Naming – They may have the same name, but both implement different concepts. For example, we could have two schemas, both called “price”, where one implements price with VAT and the other does not.
- Structure – The structure of information is very different as to what each schema can understand. For example, addresses. One schema requires the address to be one long string; such as “18 Green Lane, Padgate, etc”. Whereas another schema requires all this information to be split up:
- <house> 18 Green Lane </house>
- <street> Padgate </street>
- <Postcode> etc etc </Postcode>
- Representation – each schema represents values differently. Such as marks, one could represent marks out of 50, and the other could represent them out of 100 (percentages).
Service Contracts
A Service Contract is a little easier to explain :) Basically, every message the service receives must be in a certain sequence, and it is the job of the Contract to determine this sequence!
The Service Contract defines the causal relationship between each message. That is – using the example messages from the service schema above – we must have a Quote Request before a Quote.
The service Contract also specifies whether or not the Quote is optional or mandatory.
Putting all of this together
So, now we finally know what a Service Schema and Contract is. How do we put all of this together? Well first, let’s take a look at a pleasing visual representation of what it all looks like:
Here we see some nice familiar stuff. We see the in and out queues that the messages join before they enter the transaction phase of the service. But what does the transaction phase look like? Well to be honest it’s really simple!
- We begin a Transaction
We then get a message from the In Queue
Then process that message
Finally we put that message onto the Out Queue
Commit (end transaction and repeat for subsequent messages)
Ontology's
Before i start, is it “Ontology’s” or “Ontologies”? Because Microsoft on accepts the first, but surely the latter is correct :S
Anyway! An ontology is a tool that is used to capture the meaning of the data or services. It is the representation of a set of concepts within a domain and it allows reasoning about those concepts. A better description is:
an ontology is a formal representation of the knowledge by a set of concepts within a domain and the relationships between those concepts. It is used to reason about the properties of that domain, and may be used to describe the domain.
No comments:
Post a Comment