Data contract apporach in WCF Service Factory???

Topics: General Discussion Forum
Jan 21, 2007 at 12:47 PM
I hope that someone can help on here and show a light from darkness of SOA strongly typed data contract bubble that is approached in WCF Service Factory.

My issues is simple, I have physical data model that is fixed in high level. However, specific parts of a physical model may change regularly depends on the implementation.

For example, Customer object has always an address subset; US address subset attributes are very different than European address attributes. Even some of the European address attributes may vary in high degree depends on the European country or the application implementation.

Is this meaning that I should implement several data contracts that covers all possible combinations of the address subsets in WCF Service Factory? If so this would lead into the strongly typed data contract maintenance hell.

In order to avoid this, it would be much more robust to define a single xml node field that contains an address subset attributes in customer object.

However, as xml field is not supported in the WCF Service Factory this raises a question how this above issue should be approached in the WCF service factory?

Ps. I agree that SOA is a great normalization from data/process design soup. SOA fits perfectly on data object contracts that possibly follow static or small object variations. However, SOA does not necessarily fit well when an application objects may have tens or hundreds of different variations as outline above.
Jan 21, 2007 at 10:54 PM
I think I understand, but before I provide my thoughts, I'll restate what I understand to be the question ... just to make sure I'm not off in left field.

DataContracts are great for defining reusable types sent to and from services, but how should it be represented if inside that reusable type, there is a high degree of variability? For example, Customer is a type reused across services and operations within a single service, but the Address type it contains can be represented a number of different ways depending on the operation or service. In other words, the Address might be in the US, Europe, Asia, etc, which would cause it to have completely different fields. Given this requirement, how should the service's contracts be defined?

If that is a reasonable restatement of the problem, then the rest of this response might shed a little light ... only about a candle's worth :)

Clearly there is complexity involved with addressing this requirement. The question you have to answer is, "where do you want this complexity?" You mentioned one option (A) which is to define all of the possible Address types and use them appropriately. This could add a maintenance complexity because of the number of similar types, but it would make the contracts very explicit from a consumption standpoint. Another option (B) would be to define the uber Address type that includes everything any Address in the world would have.

With this option, the challenge is two-fold: (1) you must provide enough clarity about the type so it will be used correctly and (2) some (de)serialization logic will have to be in place to interpret what should be sent/received by the service implementation. The first challenge can be mitigated with a clear design. Maybe the type could be internally divided into sections (common fields, european-specific fields, us-specific, etc). For clarity, you have some documentation to augment the service contract (but you should ALWAYS have this anyway). WCF provides the extensibility points to address the second challenge, but Service Factory doesn't provide any tooling to use them. So it would have to be written by hand. I think the IDataContractSurrogate and maybe some boolean IsXxxAddress fields in the type would help.

Personally, I would be more in favor of option B. It just strikes me as more elegant - better architected. With that said, Service Factory does make it easier to do option A because addressing this particular challenge was not in scope for Service Factory. Now more about option B. I also think it would be good to expose a semi-strongly-typed DataContract. What I mean by this is, be explicit about the primative types (int, string, etc) that make up the Address, but don't make any of them required. In the service's documentation, recommend some consumer-side validation rules or provide some XSDs if that makes sense, but do all of the necessary validation pre or just post deserialization using whatever validation approach makes sense. If you don't have enough Address data, throw a planned SoapFault.

This are just my initial thoughts. I'd be real interested to hear what others have to say on the topic.

In your Ps, you make some statements about SOA. I'm not a big fan of this term unless if comes with a definition about what someone thinks SOA is. So I'm not going to comment on any of that.
Jan 22, 2007 at 1:41 PM

Yes, you got my point/issue and your reply has lightened up my dark corner. ;-)
I am also (personally) more in favor of option B as it is less complex to address this issue.

I was exploring this issue on yesterday, and one way to design this in the current WCF Service Factory implementation, is to create service contract translator that would be intelligent enough to map User address properties to/from messages, and then store these in NTEXT field in SQL 2005 database table as XML field type is not supported.

I agree that the logic must be held in somewhere and this could manage in consumer-side by using the loose message contract and XSDs validation rules.

With this option, where the validation of the received message (against XSD for example) should be process? Are there any examples of this available? Can Soup-Fault be thrown in Service Contract Translator?

When storing customer address information in NTEXT field; this would probably lead into performance issues in SQL Server side. These address fields are part of the address search, and NTEXT fields cannot be use to create an XML indexes even when SQL table NTEXT field would contain an xml structures.

So this raises a question of XML field support in WCF Service Factory; would it be a big effort to change the WCF Service factory to support XML field in data contracts? Would this be WCF Service Factory template 1, 2 or 3 type of change?

Ps. I consumed all of your WCF Service Factory blogcasts, and must say that they all are really great. These blogcasts helped to understand the anatomy of WCF Service Factory in great deal.