SOA Confusion

[wikramasingha]

I have been working on a number of projects in differnet client co for the last few years and I have noticed the same pattern being implemented incorrectly in my opinion.

I would like to bring this up for discussion as I have to admit that this is just my perspective and I may not be necessarily correct.

Why is business logic in a service layer always hosted in a WCF/web service? This business logic is always specific to the application domain so will not have any other consumers.

Surely hosting this service in another process and serializing everything to xml before squirting it across the wire is inefficient yet everyone seems to do it.

Unless this business service is very generic and will likely tohave other consumers I would always keep it in process. When I mention this though it tends to raise eyebrows.

Does anyone have any views?

[jmo21]

The theory is the exact opposite of what you've seen.

Sticking the logic in services is supposed to make it then usable by lots of different applications.

The reality in a lot of places I've (and you) seen is SOA for the sake of using SOA.

There's a lot to be said for keeping one eye on the future when other apps may need similar data, but so often the services will be built in a way that couples them to the first consumer.

[wikramasingha]

If use is to be made of this logic by other appliacions, why not redistribute the dlls? This must be better from a performance perspective no?

[jmo21]

If use is to be made of this logic by other appliacions, why not redistribute the dlls? This must be better from a performance perspective no?

I can't disagree from a performance perspective, in process will always be better.

There are other reasons to separate out of course.

Consuming apps could be non .Net for a start.

Having that dll embedded would mean recompiling and updating all client apps should a new version be rolled out

With a service, so long as the interface doesn't change, client apps could get updated functionality without rebuild eg an underlying data source changes, but the data being output fits same interface.

What you and I have seen is SOA for the sake of SOA. A pointless waste of time.

[original PM]

I have seen this also - it seems that SOA is the new buzzword and so everyone decides to try and shoe horn it into every project without really seeing if it the best fit...

where ever you put business rules etc as soon as you decide to change one app out for another the interfaces always come into scope and will need changing - so this dream of being able to 'plug n play' does appear to be nothing more than a dream....

but time will tell!

[Notascooby]

There's a time and a place - it's like when the world went OO and everything was inherited from 50 absratct classesand interfaces making code totally unmaintainable.

If there's a BPM engine in there somehwere, then having everything as services is brilliant. Distributing dlls is a royal pain in the arse when you replace an application only to find that 3 others have hard dependancies on it.

Exposing interfaces through SOA or even a public stored procedure is infinitly better than tightly coupling applications, which at the time seems obvious and sensible but in 5 years time will be a support nightmare.

I agree that having publically available services that are too finely grained or not production strength in terms of non-functional requirements is pointless but it's better than point to point coupling.

[eek]

I agree that having publically available services that are too finely grained or not production strength in terms of non-functional requirements is pointless but it's better than point to point coupling.

You can argue that even a tightly coupled webservice wrapper SOA is better than nothing as it allows you to test the business layer separately to the web form.