SOA Architecture understanding

0
votes

I have been asked to work on a project, based on SOA, using WCF. I have dabbled with WCF (Creating and consuming), but never with SOA. Am I right in saying that a single service would have the usual service layer, business layer and data access layer (if one's needed). The service layer would then expose methods.

Can Service A reference Service B, and service B reference service A?

And then a UI can access these services, via references - and that's essentially SOA? I am battling to find up to date, recent tutorials (Youtube), and the 'guides' I see online seem extremely complicated.

2
c#.netwcfsoa
My understanding was that WCF implements SOA as well as various WS-* specifications. The service would encapsulate business logic, and hence would have a business layer and optionally a DAL. The service could be consumed by a UI or even other services. – aquaraga
And yes, Service A can consume Service B and vice-versa - although the design is highly questionable. – aquaraga
The Wikipedia entry is pretty clear I think? en.wikipedia.org/wiki/Service-oriented_architecture – Belogix
A 'Person' service wants a list of Bank accounts (So, person service references account service)... but when you view a list of overdrawn bank accounts, it needs to access the person service to get the person name? Sorry - best quick example I could think of... – Craig

2 Answers

2
votes

This Wikipedia entry is pretty clear I think?

Lets try a simple example. Say we have Library application that lets you check books in and out.

If you look at the "traditional" non-SOA way to approach n-tier systems then you have a service called MyService that has methods called something like CheckOutBook. This would go away and internally have a Book class and a Person class and would perform say Book.IsAvailable = False and Person.NumberOfBooks.

That is fine, but say you now have another application that wants to work with People. You can't just use the above service because the logic is tightly coupled with what you are doing, i.e. Library transactions. Instead you would have to copy / paste code into a new service "BookShop".

With SOA you would have a Book service and a Person service. The Person service would have an action such as Person.AssociateWithBook that both Library and BookShop could use without having to alter as it is simple enough to do the minimum. It is then down to the application to call the right service(s) to do the job required. This means that it is reusable without needing to modify the various services.

This is very simplistic but hopefully shows the architectural differences and get you going?

1
votes

I'd skip question about SOA, since each one can call SOA whatever he understand SOA (Service Oriented Architecture) is. I mean, each architecture, using services, can be called SOA...

From technical aspect, I'd build it in next way:

IMO, Services by themselves should have as less logic as they can (like facade pattern), all there logic should be moved down to Business logic.

Service A using ServiceA.BusinessLogic, calls service B (proxy for service B is available for ServiceA.BL).

Same for Service B, calling service A.

This will give you bi-directional communication, without issues of Duplex (broken callbacks, ...).

UI should access the services as well - using UI.BusinessLogic ( I usually prefer think about service communication as sort of Communication Data Access Layer).