Service Design (WCF, ASMX, SOA)

Question

Soliciting feedback/thoughts on a pattern or best practice to address a situation that I have seen a few times over the years, yet I haven't found any one solution that addresses it the way I'd like.

Here is the background.

Company has 3 applications supporting 3 separate "lines of business" that are very much related to each other. Two of the applications are literally copy/paste from the original. The applications need to be able to grow at different rates and have slightly different functionality. The main differences in functionality come from the data entry fields. The differences essentially fall into one of the following categories:

1. One instance has a few fields that the other does not.
2. String field has a max length of 200 in one instance, but 50 in another.
3. Lookup/Reference fields have different underlying values (i.e. same table structures, but coming from different databases).
4. A field is defined as a user supplied, free text, value in one instance, but a lookup/reference in another.

The problem is that there are other applications within the company that need to consume data from these three separate applications, but ideally, talk to them in a core/centralized manner (i.e. through a central service rather than 3 separate services). My question is how to handle, in particular, item D above. I am thinking a "lowest common denominator" approach might be the only way. For example:

<SomeFieldName>
  <Code></Code> <!-- would store a FK ref value if instance used lookup, otherwise would be empty or nonexistent-->
  <Text></Text> <!-- would store the text from the lookup if instance used lookup, would store user supplied text if not-->
</SomeFieldName>

Other thoughts/ideas on this?

TIA!

Answer 1

So are the differences strictly from a Datamodel view or are there functional business / behavioral differences at the application level.

If the later is the case then I would definetly go down the path you appear to be heading down with SOA. Now how you impliment your SOA just depends upon your architecture needs. What I would look at for design would be into some various patterns. Its hard to say for sure which one(s) would meet the needs with out more information / example on how the behavioral / functional differences are being used. From off of the top of my head tho with what you have described I would probably start off looking at a Strategy pattern in my initial design.

Definetly prototype this using TDD so that you can determine if your heading down the right path.

Answer 2

How about: extend your LCD approach, put a facade in front of these systems. devise a normalised form of the data which (if populated with enough data) can be transformed to any of the specific instances. [Heading towards an ESB here.]

Then you have the problem, how does a client know what "enough" is? Some kind of meta-data may be needed so that you can present a suiatble UI. So extend the services to provide an operation to deliver the meta data.