2

I am part of a small software company that specializes in small to medium-sized business applications and my experience with distributed architectures/SOA is limited. Please let me know if I'm going about this all wrong.

We often start development on small business applications, where a distributed architecture seems like overkill and will not be implemented as such. However, in some cases, the project expands way beyond the original scope, and the preferred solution may later become a distributed one.

How do we ensure from the very beginning that this transition becomes as smooth as possible, with a minimum cost of performance and (primarily) time? Specifically, I'm looking for advice in regard to the architecture of the solution in order to achieve this.

Take this simple example:

  • At first a windows application is running on several computers, invoking all business logic locally in an assembly that is distributed along with the application.
  • Later, the business logic is moved to a central server, and the windows application must now communicate with the business layer through a WCF service.

The obvious answer here would be to just create the WCF service from the very beginning and have it run locally on each machine, but my initial thought was that this could cause undesirable time consumption on projects with strict deadlines, due to increased overhead in development (having to maintain the intermediate layer(s) etc.).

One of the concrete problems with the initial architecture is that instances of objects are passed from the windows application to the business layer, thereby creating a dependency that could break code when moving to a distributed solution.

By 'simulating' a distributed solution, we could ensure that our developers aren't unintentionally introducing these sorts of issues.

  • What is the best way to achieve this scalability?
  • Am I wrong in my assumptions regarding time consumption and performance?
Improve this question

3 Answers 3

Reset to default
2

You should think ahead which parts would be considered 'client-side' and which would be 'server-side'. The server tier would be exposed via a service layer, not necessarily using WCF or any tecnology. At first, would be just an interface (IService). In the client tier you would have a delegate layer that knows how to reach the service layer. At first it would be only one-liners to call the service layer. When you decide to change your arquitecture you can just change the service to be a WCF service and the delegate to setup endpoints and stuff to reach your service.

Hope that helps.

Improve this answer
5
  • 1
    +1 - ie - code to the interface rather than the implementation!! Makes life much easier down the road!
    – Catchops
    Aug 23, 2011 at 20:27
  • This is great advice! But what about the hands-on example of passing instances of objects between layers? Our less experienced developers may not be aware of this issue at all times (even though they know it exists) and I was hoping to come to a solution that simply prevented it - e.g. serialization of objects between layers, so the client application will never unintentionally rely on changes made to an object in the business logic that weren't meant to bleed back into the client app.
    – bernhof
    Aug 24, 2011 at 8:13
  • 1
    Yes that is a problem we face for every new-hire. It is a process of constant code review and feedback. Soon even less experienced developers will understand. One thing to remember: it is easier to teach a less experienced developer to do things your way than change a senior's mind.
    – Pedro
    Aug 24, 2011 at 13:02
  • I agree, code reviews are an important part of the learning process for new developers. So the only way to ensure that the issue would never occur, would be to actually implement a layer that serialized the objects as it would in a distributed architecture (at the cost of time and performance)? Do any tools exist that can help implement and maintain a simple layer such as this?
    – bernhof
    Aug 24, 2011 at 13:28
  • Well you could enforce the use of DTOs then, and to help with that there is a library called Emit Mapper emitmapper.codeplex.com that has a feature that allows auto mapping between entities and DTOs, very interesting.
    – Pedro
    Aug 24, 2011 at 20:11
1

You are not wrong about regarding the time factor. It will take longer to design and develop a partitioned application such as you are suggestng. However, given your past experiences you can see that the time will be well spent.

It seems to me that if you would partition the application much like a distributed application, as you suggest, you would remove dependenecies and clearly define areas of responsiblity. Using interfaces and other software, such as a message bus to decouple your components, you could build an application quickly but enable it grow if needed.

Improve this answer
5
  • By "message bus" are you referring to technologies such as WCF? So what you're suggesting is serializing objects between layers to ensure that the implementation mimics that of a distributed solution?
    – bernhof
    Aug 24, 2011 at 8:22
  • Sorry for not being clearer. I was thinking of a layer of software that would define communication paths via events and messages. This software can be local to the application process, even in the same thread, but would allow the software to be partitioned. By forcing the design but not the implementation it would enable a WCF implementation in the future.
    – Ken Brittain
    Aug 24, 2011 at 12:55
  • That makes sense. There is just one more issue that I am trying to eliminate, namely that of instances of objects being passed between layers (see my comment on Pedro's post). Do you have any input on how to handle this apart from performing regular code reviews as Pedro suggests?
    – bernhof
    Aug 24, 2011 at 13:18
  • Enforce the programming contract by using those parts available to you in the language: interfaces and classes in an established namespace or namespace pattern (such as never use classes from a Feature.Internal namespace). The implementation is hidden via internal classes and never exposed except via the interface you desire. BTW, code reviews are never a bad idea.
    – Ken Brittain
    Aug 24, 2011 at 14:18
  • I definitely agree. Thank you very much for your input!
    – bernhof
    Aug 24, 2011 at 17:40
1

I think the key is to use good OO principles and make sure your components are cohesive. Keep the business logic in the business logic layer and the presentation logic in the presentation layer and make sure they are at worst loosely coupled.

Then, if the application needs to be scaled, you can add the mechanisms for the WCF service, but you're not rewriting the logic.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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