Architecture Isolation mechanisms

Question

We are currently reviewing how to isolate our core business components (in the code) from the front end development. We already have multi-tier architecture but they are referenced using dll (or webservices in some places).

What we would like to do is to outsource some part of UI to external developers. The problem is that we have to provide the dll which can be reverse engineered and the core business logic code then can be "obtained".

One way to tackle this instead of exposing BO using dll, use Webservices to expose BO. However there are few problems. for e.g. Security, Debugging, exception handling, hosting etc. To me this does not sound right for the issues mentioned above but also web services are not meant for such problems.

I am wondering does anyone has come across similar scenario? or If someone has done this? if so how?

Thanks,

score 1 · Answer 1 · answered Oct 16 '12 at 08:39

1

Provide a web service point that implements the business logic - this will be hosted by yourselves and accessible to the UI developers.

This way you keep control of your business logic and the UI team have access to the API.

If this is not possible, extract the public interfaces of your business logic into its own package and implement a set of "canned" responses - just hard coded data for the UI people to work with. This allows you to give the UI team the interface they will integrate with as well as sample data, but without your actual business logic.

answered Oct 16 '12 at 08:39

Oded

489,969
99
883
1,009

"Provide a web service point that implements the business logic - this will be hosted by yourselves and accessible to the UI developers." The problem is interfacing your whole BO in web services is not a very clever in my opinion. You will face same limitations as you do in Web service for e.g. Performance, Debugging, Exception handling etc. – activebiz Oct 16 '12 at 09:11
@Preyash - There is a price to pay for isolating the business logic. You can't have it all. This is just one option, and you can architect your application so the doesn't have to use a web service when in production (how to do that I leave as an exercise to the reader). – Oded Oct 16 '12 at 09:13
1

"If this is not possible, extract the public interfaces of your business logic into its own package and implement a set of "canned" responses - just hard coded data for the UI people to work with. This allows you to give the UI team the interface they will integrate with as well as sample data, but without your actual business logic." Problem with above is that you are not simulating the actual data which means in real world your UI response can be different to the one when you develop. For e.g. Grid with 1K rows .. inline edit... – activebiz Oct 16 '12 at 09:15
@Preyash - You can't have it all. You are trying to solve a "social" problem with technical means. The contract you have with the UI developers should disallow disassembly of your business logic code. If breached, you can sue them. That's the correct way to protect your code. – Oded Oct 16 '12 at 09:17

score 1 · Answer 2 · answered Oct 16 '12 at 15:37

The concept of interface contract seems spot-on here.

If the contracts of your interfaces are well defined (let them be DLL entry points, WSDLs, whatever), it should not be very difficult to create a mock implementation that allows the UI developers to test the behaviour.

The only precaution we took is to ask UI contractors to commit code into our SVN repository (no, no Git here :)) so that our build machine could run integration tests continuously and we could assess progresses and issues on a daily basis.

Wolfgang Fahl · Answer 3 · 2012-10-16T15:27:54.963

The y-principle might help you to get the separation of concerns you are asking for.

It is a method for separating business and technical concerns in a systematic manner.

The following character graphic depicts the approach:

  Business requirements      Technical requirements
+------   |                             |  ------+
|         v                             v        |
|  Business model               Technical model  |
\          \                            /      /
 \          \                        /       /
   \          \                    /       /
     \          > Mapping rules <        /
       \              |                /
         \            |              /
          \           v             /
           \    Implementation     /
            \         |           /
             \        |          /
              \       v         /
               Acceptance Tests

The approach can be automated if the Mapping rules are consistent and can be repeatedly applied. A reverse-y analysis can show whether this is the case.

In case the approach is applicable it will have a profound effect on efficiency. In stead of having to do the mapping of business issues to technical issues over and over again the process can be made repeatable and eventually automated.

You can find more on this on my companies webpage.

You continue to post links to your website without disclosing that fact, despite the fact that you have been warned against doing this. — Andrew Barber, Oct 16 '12 at 15:25
Sorry about this. Looks like I'll have to read the FAQ more closely. — Wolfgang Fahl, Oct 16 '12 at 15:27

Architecture Isolation mechanisms

3 Answers3