6

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.

  • My answer to a similar question is here. The "Service" in SOA does not necessarily mean web service. – Eric King May 19 '15 at 14:55
0

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.

0

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!.

  • Our BLLs implement the same interfaces as the WCF service endpoints, so any change to the public API of the BLL would by definition mean changes to the service API, and vice-versa. Therefore, I don't see any benefit using WCF over directly accessing the BLLs. Either way, if the BLLs change, the client projects need to change, at least to be recompiled. The level of decoupling is the same in both cases. I don't see why you think that WCF is any less coupled than referencing the BLLS. – Avrohom Yisroel Mar 18 '15 at 14:36
  • I think your comments about performance are missing my point. Whatever you do with WCF, it is ALWAYS going to be slower than direct access to the BLLs. You can reduce the hit by optimisation, but you can't avoid the fact that simply adding the extra layer is going to introduce an extra delay. Let's assume we've optimised everything else, why would we want to harm the performance by adding WCF if there's no benefit? – Avrohom Yisroel Mar 18 '15 at 14:36
  • By the way, we aren't bitching. We are having a reasoned discussion, and will find a solution togther. I'm trying to make sure I got the facts right, so I can do my bit for helping us reach the best solution. That's not bitching, nor theatrical. – Avrohom Yisroel Mar 18 '15 at 14:36
  • The point about performance is: the WCF-Call itself is unlikely the bottleneck in your application. And if so, if it is "the slowest" - why care? It is fast enough (compared to the Rest), so why "optimize" further? – Thomas Junk Mar 18 '15 at 15:14
  • @Thomas_Junk - Who's talking about a bottleneck? I said that introducing WCF would slow the site down. I know that for a fact, as I've seen it. You can't help the fact that adding an extra layer, serialising and deserialising the data and sending it over HTTP are all going to take more time than just passing it between two DLLs. I want to know a justification for adding that extra delay. – Avrohom Yisroel Mar 18 '15 at 15:19
3

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?

  • Your basic understanding is correct, however there's a big point that affects what you said in your second paragraph. Our deployment process always rebuilds and deploys everything, including the WCF services, the download files for updating the WPF client, and the MVC project. Therefore, whenever we update the BLLs, the MVC project would automatically see the new version anyway, as this is part of the build and deploy process. With that in mind, it sounds like your third paragraph is more appropriate, and you agree that WCF doesn't add anything. Please confirm if I understood you correctly? – Avrohom Yisroel Mar 18 '15 at 14:04
  • Actually, I just noticed that even according to your second paragraph, given that the performance hit of including WCF would be significant, the gain of not having to worry about keeping the libs in sync (which isn't actually an issue for us, as explained in my previous comment) would not be worth the degradation of performance. – Avrohom Yisroel Mar 18 '15 at 14:06
  • »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« Not necessary: of course that is a nonsensical implentation, though "SOA"esque. It will be easy in the future to use different machines without making changes to the codebase or the architecture itself. – Thomas Junk Mar 18 '15 at 14:11
  • @AvrohomYisroel If you have a strong build / deployment process set up, then as you say, there's even less reason to worry about versions getting out of sync. So I agree with you :) – cwap Mar 18 '15 at 14:40
  • @ThomasJunk I also have to agree with your comment. The underlying basis of this problem is that even though SOA is rather well defined, its implementation is not. At the end of the day, it's all about what has most benefits at the trade-off of less cost. – cwap Mar 18 '15 at 14:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.