Model Service Agents with the Service Factory

A Service Factory Modeling Edition Extension To Enrich Team Architect’s Application Diagram Feature “Implement Application”


A service on the Application Diagram can have a one or more .NET Service Endpoints which are service providers, they expose operations. These "Service Providers" can be/ should be implemented with the Service Factory, but what about the other endpoints a service can have?

A service must gets its data from somewhere, from a database, from an excising service or from a “not yet excising ”service. So called "service consumers".


A connection with a database is easy, just a connection string in the configuration file and for further modeling the ADO.NET Entity Framework.

But what about the other two? Just add an service reference and start coding is not the best way to go we need some more sophisticated Service Agents and for the “not yet excising” service we even can’t add a service reference.

A Service Factory isn’t complete if it can’t handle that ;-) a service is not only exposing but also consuming things.

So, I added an Service Agent Model to the Service Factory Modeling Edition. Hoorays’ for the P&P group, they really made an easy extensible architecture, a kind of pluggable one… you want this, plug it in and it works.

Anyway, I created a new DSL project in a different solution, designed the DSLDefinition and added these projects to the Service Factory Solution.


After that, you have to change the Strong Name Key File to the Service Factory SNK File, add values to some classes and recipes and add the templates to the guidance package. Olaf explains this in depth in the Extensibility Walkthrough.

Following you can start designing the code generation within the Service Factory. Not completly finished that, also not finisched the service Agent DSL [just enhough for this pilot, see image above].

Within the Service Agent code I use P&P’s EntLib ObjectBuilder. Which made it easier to replace functionality and to develop functionality independently. That’s what we need, when we have to make a service agent for a “not yet finished” service where we don’t have a WSDL and aren’t able to generate the Service Proxy.


I don't think you can read this picture, if you want to look at the implementation... it's almost the same as the implementation used within the WCSF reference application. 

Because we can extract the operations and types from the Team Architect’s Application Diagram we are still able to generate a “skelton” service agent for a “not yet finished” service. With enough implementation code [service operations and message contracts] to start developing business functionality.

Within the “red” swim lane there is the ability [a recipe] to import the models from the AD. It generates the services shapes and their operations with the request and response types. For a existing service the WSDL is collected from the AD. So, for further code generation it can generate the service proxy and web reference. For a “not yet finished” service it also creates the services shapes and their operations.

From there we can start modeling [the green swim lane] the Service Agent operations, parameters and point them to the service operations. On this swim lane is the generate code recipe.

Still some challenges ahead [what if a “not yet finished” service is finished], but I think a nice starting point for further development. For example the connections between the two operations actually are the translators between the types. Right mouse click on that line and fire another diagram where you can define the mappers [pdf]… just an idea :-)

Add comment