Is this breaking SOA?

Question

We're havng a bit of a disagreement in our team, and I would like to hear other people's views. We have a mature solution that uses an Entity Framework model, which is accessed by a repository layer, which is in turn accessed by a business logic layer. The BLL classes implement interfaces, which are also implemented by services in a WCF project. The WCF services are very thin wrappers around the BLL classes, and each service call is basically a one-liner that passes the call through to the BLL. We have a WPF project that uses the WCF services for its data access.

We have recently added an ASP.NET MVC4 project to the solution, to provide web access to some of the features in the WPF project. As the web server is on the same local network as the SQL Server database and the WCF web folder, I added a reference to the BLL project from the MVC project, and did the data access directly between the MVC controllers and the BLL classes.

Our senior technical chap objected to this, and said I was breaking SOA. He wants me to add WCF service references to the MVC project, and access the data via WCF.

My argument against this is that going via WCF does not add anything of benefit to the MVC project, but hurts the performance (I know this for a fact, as I tried it). Given that the WCF services just pass the calls straight throuh to the BLL classes, which implement the same interfaces, I don't see how it is any more SOA to use WCF than to call the BLL methods directly. Furthermore, performance is critical in this MVC project, and I don't want to do anything that will impact the performance unless there is a very good reason to do so. I can't see any good reason here. Even if we optimise the WCF project, it is still always going to be slower than accessing the BLLs directly.

According to the definitions of SOA that I've seen (for example, see the Definitions section in Wikipedia's SOA article http://en.wikipedia.org/wiki/Service-oriented_architecture), our BLLs are definitely within the pattern. I don't see any requirement to use web services to call it SOA. Sure, web services are a form of SOA, but they aren't the only form. As far as I can see, a layered approach, which ours defintely is, is completely compliant with the principle of SOA. Now I realise that I may not have put his argument very strongly, but that's mainly because I can't understand it. I'm hoping that some people who are more knowledgeable than me can come along and offer some comments one way or the other. We have a meeting to discuss this tomorrow, and I;m sure he's going to pressrue me very strongly to use WCF instead of referencing the BLLs directly. If he's right, then fair enough, we'll have to suffer the performance hit. However, if there isn't any benefit to using WCF in this case, then I need to be able to explain why the way I've done it so far is fully SOA.

I would appreciate any comments.

Answer 1

Let me just make sure I got my assumptions correct before trying to give my opinion: If I understand it correctly you have deployed a server which exposes its interfaces through WCF, and these interfaces matches those of your BLL. Now, you want to deploy a website that lives side-by-side with your WCF services, and that access your DAL through the BLL?

If the case is as I understood it, then I agree with your senior technical chap, simply because you will now have to make sure that the BLL libs that are deployed in both the WCF server and the ASP.NET project are always in sync. However, if the performance hit is noteworthy, then I would object against this approach since the gain is much smaller than the cost.

If however, what you want to do is have the WCF services and the ASP.NET site live side-by-side in the same IIS/Website/AppPool, then I think your senior got it wrong, and I (personally) think he got SOA all wrong. A 'normal' service should live its own life, and - depending on how large the service is - could have a normal n-layered architecture. In an n-layered architecture you have one-or-more views, a domain, some BLL and one-or-more DAL. In this case you are simply adding a view: "Yesterday we exposed our application-logic through WCF, but now we also expose it through ASP.NET". In my opinion, going through WCF in this case, would be the same as adding a REST/JSON layer on top of a WS/SOAP layer and doing all the translation necessary between them. Why would you do this if they are really just different views of the same application?

Answer 2

Let's step aside and deal with simpler terms: Whether or not, your system's architecture fits the SOA-paradigm, let's deal with »distributed systems« and »client-server-architecture«.

What is the main goal, choosing a distributed system? Decoupling. Since you are using a database server and the business logic is the client, your system is (slightly) decoupled and may be called distributed.

If I get your architecture right, you have a database, which is used by a business layer to perform certain operations on the data. The business layer itself is (only) accessible via WCF. So this assures a wide decoupling of components:

1) Database

2) Business Logic

3) A presentation layer (WPF)

If you want, you could go one step further and split (2) into smaller components without disturbing (1) or (3): Say you have one endpoint for accounting another endpoint for employees, changes are transparent to (1) or (3). The only coupling-point is the endpoint; so you could even do a split in half, one independent application is doing the accounting another the employees without making changes to (1) or (3).

If you now add »a reference to the BLL project from the MVC project, and did the data access directly between the MVC controllers and the BLL classes.« you are tighten the decoupling again. Every major change in the BLL forces changes in your MVC-Project.

Our senior technical chap objected to this, and said I was breaking SOA. He wants me to add WCF service references to the MVC project, and access the data via WCF.

He is right.

My argument against this is that going via WCF does not add anything of benefit to the MVC project, but hurts the performance Au contraire: it looses the coupling, which has clear advantages as said above.

If it hurts your performance, your problem sits probably elsewhere.

Furthermore, performance is critical in this MVC project, and I don't want to do anything that will impact the performance unless there is a very good reason to do so.

Go and fix your performance problem before discussing any further.

Even if we optimise the WCF project, it is still always going to be slower than accessing the BLLs directly.

Yes. That will always be the case. But that is not relevant. The http traffic itself is mostly the fastest factor - if not go to your ops-guy. Most of the time the problem is an unperformant query or slow businesslogic. Do your homework there first and you won't care about the overhead caused by a WCF-call.

I don't see any requirement to use web services to call it SOA

The point is: independent from its name, its purpose is decoupling.

Aside: Why are you bitching around?

If he's right, then fair enough, we'll have to suffer the performance hit.

This is nonsense (in the first place) and more: it's purely theatralic. Go and ask him for his reasons, utter your concerns and find a solution together!.

Answer 3

I can sympathise with your view, Ive been in a similar position with too many WCF layers all on the same box, each one passing the same call down the stack.

However! the point of SOA is that you can orchestrate your services. if you skip a layer then you have lost that flexiblity.

eg. I want any calls to logic X also trigger logic Y. I can add the extra call to the service or add extra routing to my orchestration. But if your app calls logic X directly it will skip my logic Y injection.

Just because you dont currently have logic Y dosnt mean the service has no value.

Performance: WCF is not going to be adding a significant amount of time to your web call. If it is something is wrong, and going through the service gives you caching and scaleablity options.