What I want:
Generate a service contract model from the application diagram, with the ability to regenerate the service contract model.
The first part of the addition / changing of the service factory I finished a few days ago. And I’m pretty happy about it. Still some problems and fine tuning to do, but no stoppers. So, today another challenge.
This scenario would only work when there is the ability to regenerate the service model from the application diagram without losing the information / the settings the “service modeler” has made.
So, what kind of settings should be set at service model level and what kind of settings belong to the application diagram level?
The first and most important setting: “Implementation Technology”.
I do think the decision about the “Implementation Technology” already have been made, I even think that this decision already have been made before the start of the project. But to keep in line with the idea that you should be able to make this decision as late in the project as possible, I set this property and all the properties that belong to it as a “service model level property”.
There are a few properties left:
Namespace, will this property be set on application level or at service level? And descriptions where do they belong? You can have overly long discussions about this, but for now I say they belong at application level. I will try to make more flexible so when those properties aren’t available at application level “String.Empty” I will use the service model settings.
And the latest property is the “XML Element Message Part”. At application level there is only a name of the type and that is enough for that level, at service level you can attach an “XSD Element” to it.
The reason why the “service model generator” only creates “XSD Message Types” is a long story. But the main reason is that I’m not able to put information in the “Web Services Details” window [Application Diagram] what kind of data contract it must make when I only but a name and not a .NET type in it. So, there are actually three types of data contracts XSD, Primitive and the one modeled in the service factory. When there is a .NET type I can generate a primitive contract but the other two are a problem.
We can also start a discussion if that information belongs at application level. You can add some kind of feature like “Conform type to XSD” in the “Web Services Details” window, so you would be able to import an XSD from there or even that you can model your data contract at application diagram level.
I think data contracts / messages are business data and are modeled by business analysts and not by designers, architect or developers. They use some external tool [Excel, tables in Word, Visio :-) or other] to define them. Importing them from that arbitrary format is a must have [another extensibility challenge] but at what level, I’m not sure.
Anyway, that was some thinking now the implementation...
I keep the model and only throw away the shapes that are going to be recreated. That brings me to an important decision. I don’t know when a service is renamed which service shape belongs to it. So, I’m not able to recreate a renamed service. Although it should be possible when I have a kind of change log in the application diagram which collects renaming events, for now to time-consuming. So, no recreation of renamed services, they will be created from scratch and all the added information will be lost.
The implementation checks the AD file against the service model and will delete, add or change shapes [services, service contracts, operations and message contracts] if they aren’t available anymore or when they are added at application diagram level.
A possible scenario: I draw my application and add an endpoint. I already know everything about this endpoint and fill the WebServices Details window with all the information. [See image 1].
From there I generate a service model [see image 2], add some schemas and attach those to the message parts, fill in specific “service” information and generate the projects/ code. Easy going..!
But, imagine it’s a real world project and we must add another endpoint to the application [for some kind of reason] and we haven’t got all the information, only it has to do something. So we add another endpoint to the application shape and only give it a name. [Image 3].
At this point we want to generate the service model [or an automatic process during the build]. Without the regenerating functionality added to WSSF everything would be gone and created from scratch, but now it checks what already is available in the model and only adds the extra service to it. [Image 4]
Next step… we got the information about or new endpoint. Add that to the Details window and recreate the service model. Again only the extra operation is added to the model. [Image 5]
The rest of the shapes stay the same.
Still the real world project in mind? The method must change [Image 6] recreating of the service model will throw away the operation and add a new to it. We lose all the added information [operation] and must start from scratch. This is where you should want to use a kind of “renaming” log.
Anyway, the last two pictures… just for fun.
But, also a nice example for my presentation about the service factory. During the demo recap I mention “A lot of small models where the big picture is?”. The Application Diagram is the big picture!