26. November 2007
In an ideal "SOA" world, business-services have a business driver or at least some one from the business who is responsible for it [knows something about the data and operations that service exposes] and has information who is consuming, is going to consume the service and who is allowed to consume. With that, takes the initiative to ask the development department to make that business-service.
The real "SOA" world: the business thinks in GUI's and not in services. So, they ask for applications and let the decision which service to make to the development department.
That's no problem, till more and more applications are going to be build and more and more services are created.
For example the first application needs customer data. So, this project team start with the creation of a customer-service. Meanwhile an other request for an application enters the development floor, which also needs to consume customer data.
Two situations can occur:
- The project-managers from the different projects are getting a fight about who is responsible [budget] for the creation of that service. Projects will wait for each other till there is a compromise and peace. You have been chosen to be the Deadlock victim..! [I like that SQL Server message].
- The different projects both create their own customer-service. Bad, bad solution... but very common in the real world.
It's the responsibility off the development department to define, create and deploy services, also when the business defines them it's the development department's responsibility to take control in this process.
So, what should be a solution from a development point of view.
- Make Partitioned Solution Structures..!
See "Solution Explorer" image, this is a normal solution structure. I think you can see what kind of problems we get when an other project also needs the customer-service.We got a deadlock for this project, they have to wait till this project finished the development of this service or they have to make one them self.
With a Partitioned Solution [image below and links a the bottom] you're using multiple solutions, each representing a sub-system in your application. So, each service will have his own "solution". Developers can focus on this single service-project and this service-project should have his own build and TFS project environment. So, if the business won't separate them... we do it our self!
- Although we are making a Partitioned Solution structure, there is still a challenge left... What about projects who need that service and are also under development? this is where Team Architect can help [see image]
With Team Architect you can model your systems and define the endpoints operations and types. So, when we define all this service provider information the consumers also know what kind of operations and types they can expect. With that we can generate some basic implementations for the service agents.
What will happen when there is an other project which will consume a service in this project... just add it.
With the Service Factory we have control in which way the projects are created.
In the "Master" solution I let it create only the models and on the background it creates the "Partitioned" solutions, with the project specific models from where the development of that services can continue.
[At this moment I create for every endpoint service provider and consumer a separated model, I think this will change... for the provider "service contract" model that's fine but for the service agents I'm going to change it to one model per service instead of per endpoint]
[The single service project. the good thing is that the master solution still is in control about the operations and types this service exposes, so all the agents are updated automatically]
[The service agent, which will generate a mock / stub for service in development and a real service proxy for existing services]
Still some challenges ahead but I think it's in the right direction [any comment?].
Anyway, time to look for Microsoft Visual Studio Team System code name "Rosario" November 2007 CTP, Rob Mensching just published a post that it will be released today [pacific time] and more important it will have a WiX Toolset. [good job..!]