Contract-First using a custom DSL

Has been while since my last post.  There’s nothing easy about doing consulting and keep researching. The fact is, I was misplaced on contract first approach and I know I’ll put forward some conclusions.

1. Contract-first approach demands strong organization and standardization.
2. You can’t count on off-the-shelf tools.  You likely develop your own Domain Specific language.
3. I left off-the-shelf code generation tool (I’ll not post it’s name in this case) for Industry Standards. Last approach was about taking tables structure and give life to application by generating all necessary files.  I was too coupled to the database platform. Different database versions & vendors, operation systems used to gave a lot of headaches. By Tomas Erl literature I was doing a negatively case of coupling. I started to live all the promisses bad dreams by keep going on this approach. By the next image you can conclude that my code generation tool was really coupling to many different vendors technology, from the source (tables) to the engine (code generation framework) to the assets (text templates).
   

   DSL Framework Vision

4. I Start work with XML Schema Industry standard. It was need good ideas to be organized and produce high quality code. It increase the need for methodology and standardization.
   The economies of reuse was increased because it became a flexible structure.
   

   Code Generation Framework Vision based on Industry Standards

Change to Industry Standards was a good thing because it is wisdom and experienced approach recommendation  from serious institutions which researches are solid results that doesn’t keep changing every year as when we are based on technology platform which we start to accompany their bugs, different versions and releases of trial and error.

Achieving high productivity inside environments is important to understand and improve process. Build a Dialect language or Domain Specific Language based on industry standards instead on technology platform will easy lot of implementation pain as meaning of control but also will demand most talent engineering to help out on conceptions. It is not a easy path but has no better ROI.

References

• Software Product Lines: Practices and Patterns – Chapter 1,4 – Paul Clements and Linda Northrop/2001
• Software Engineering (7th Edition) – Chapter 18 – Ian Sommerville/2004
• Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools – Chapter 2,7,10,11,14,15 – by Jack Greenfield, Keith Short, Steve Cook, and Stuart Kent (Paperback – Aug. 16, 2004)
• Service-Oriented Architecture (SOA): Concepts, Technology, and Design – Chapter 10,11,14,15 – Thomas Erl/2005
• SOA Principles of Service Design – Chapter 6,7 - Thomas Erl/ 2007
• Domain Specifc Languages – Martin Fowler -http://www.martinfowler.com/bliki/DomainSpecificLanguage.html (at 06/2010)

Contract-First Approach Still

There’s one thing I want to mention about my last post on contract-first methodology.
In service inventory, Entity Services layers might be generated by a tool, as opposite to the goodness about write the contract by hand.

Last century, when I other web developers endeavors were working with JavaScript/HTML, we could notice how different code was depending on the handcraft’s origins (notepad or other advanced tools for that time).

Companies already have their system and database models. Moving to SOA is a strategy that could take years . Advantage from tools could be taken if we do generate contract from database tables and thereafter, and also generate services and users interfaces from those very contracts. For all those legacy work, this approach should be nice.

What a hell, man? You may ask now.

One thing which intrigues me is runtime coupling between objects. When using WCF to generate contracts for your services and the visual studio solution might have many services within. Of course you may want to reuse some comportment instead of creating them when you are build service compositions. But, if you need to change those objects (or contract), you will realize a horrible buildtime coupling problems and you may need to upgrade all consumer contracts instead of just release another WSDL contract version at you service.

Again, balance the situation is good. SOA has to be intrinsically with the financial economies. If the company is already established in its industry and need more power, SOA is a mandatory tool. If the company still about to grow, SOA is an option that the advantages and slows might incommodities.

Bouncing puppies for WSDL Contract First Approach

Ohh.. Bloody hell!! Contract First Approach or Not?  What about the common sense of proved advantages and what to do when we have infinite services to create and loads of business domains to take care of?

Lets take Tomas Erls books’s approach into account by imagining the following scenario:

- 50 Business Entity (which would compose something like 35 Entity Services)
- 5 Business Process (which would compose something like 10 Task Services and 10 Utility Services.

Have a look here and here and reflect about the scenario I’ve shown. To much code indeed and space for human mistakes. What about the work to convert WSDL into client and server code as shown here. That’s not simple, isn’t it?

Migration to a SOA ecosystem needs some sort Model Driven development and deal with contract-to-technology coupling if we want to things more quickly. We still need model and plan accordingly but we shouldn’t take so much time to write one or two service compositions. I know about SOA vendor option but in the first moment can be a good idea to trust a technology plataform.

Thus, I believe:

If we are within the boundaries of the enterprise or/and the services are not requested by many consumers, we may not need the contract-first approach but still need to care about governance.
if we need to communicate outside the boundaries of the enterprise, we need to do Contract-First approach so we can make sure we ‘re experience the partner experience in communication with us.

Thereafter, go with velocity!!