Limitations of the Modelling Infrastructure?

Topics: Service Factory Modeling Edition Forum
Feb 25, 2008 at 11:48 PM
It appears that model elements can only refer to other model elements. This means that if I need to hand-code something (which would therefore be outside of the model), that I would not be able to use it with the model. Examples:

  1. In a service contract model, you can add a Message, but you can't add a message part which is of a hand-crafted Data Contract type.
  2. In a service contract model, you can add an Operation, but you can't set the Request or Response properties to use a hand-crafted MessageContract.
  3. In a data contract model, you can create data contracts, data contract collections or data contract enumerations in the model, but you can't refer to existing data contracts, collections or enumerations.
Am I missing something, or is this a limitation of the current infrastructure?

The implication would be that if we needed these capabilities, we would not be able to use WSSF: ME.
Developer
Feb 26, 2008 at 11:05 AM
You can still use with the extensible capabilities tha has WSSF:ME. If you take a look at the Extensibility Hands-on labs (home page) you can extend the models, code generation and validation, among other stuff in order to customize it to your needs.
Feb 26, 2008 at 3:01 PM
Is there some rationale document that would tell me which features are missing because they're not best practices, vs. which features are missing because they haven't been implemented?

I found these deficiencies simply by reading through the documentation. Most of the pages I've read recently have been about WCF features that are not supported by WSSF:ME. If the documentation only showed WCF features that are supported by WSSF:ME, it would be much smaller!

I'm going to have to make some recommendations soon, and don't know what to say. I'm a big fan of the DSL tools, and of model-driven development. Yet, I wouldn't want to think that it's necessary to forgo so many features of WCF simply to use model-driven development.

Worse, since I've only just started looking seriously at WCF, I'm not sure what message I'm to take away from this. Should we be avoiding the features of WCF that aren't exposed by WSSF:ME? Is there something wrong with those features, or perhaps they'll just be implemented in the next couple of years?

Just confused, I guess.

I'll take a look at the extensibility features. I expected to use them to customize the generated code. I did not expect to use them to gain access to so many features of WCF.
Coordinator
Feb 26, 2008 at 6:01 PM
When we set out to build the modeling edition, we made a conscious decision to not broaden the technology scope beyond just adding the models and necessary factory infrastructure - and not to enable the factory to do anything with ASMX or WCF that the previous version didn't do - that's why we called the modeling edition. The primary feedback we were getting from customers was the addition of models/persistence. The result is a factory that does not expose all of the functionality of WCF - not because it is a bad practice to use those features, just because we had to manage scope or we would have never got around to shipping it. We value short release cycles and evolutionary value.

The limitations you list in your first message do exist. The ability to point a model element to an existing assembly is completely reasonable. I can see 2 good ways of achieving this: if you want it modeled, you could add an importer to the factory that would reflect on existing types (there is an exercise in the extensibility HOL for how to create an importer), and if you don't care if it is modeled, you can change the factory so you can refer directly to an assembly like we do with the XSD Message. This 2nd option could be more difficult since you would also have to add a new code generation strategy. The inability to connect data contracts in one model to DCs in a different model is also not present, but is also perfectly reasonable. One of our expert advisors has identified all of the changes necessary to add this feature - I'll encourage him to post the instructions on this community site.

We do not have a document that describes what features are missing because of best practices. I'm not sure we could even create such a document although I can certainly understand your motivation for wanting one. I don't think you need to forego WCF features to use this factory. At this point I would not encourage you to steer clear of any WCF feature if it meets your needs. Most of the features of WCF can be applied by making small as-needed changes to the factory. You can either submit features/issues on this site and wait for us to implement them in a future build or you can make the changes yourself - we provide the source code so you don't HAVE to wait for us if you don't want to.

Does this help?
Feb 26, 2008 at 8:13 PM
Thanks, Don, that helped. The main thing I didn't know before is that these are limitations of WSSF, not of WSSF:ME. I'll look at it from that point of view in the future.