Orcas Team Architect and Biztalk
I have always been fascinated by the VSTS Team Architect and the potential the design surfaces have. I kinda looked on from the sidelines at VS2005 from TechEd 2004 onwards cos I was still stuck in VS2003 land and actually that remained the case till the middle of this year. So although I installed the stuff on VPC’s and tried playing around with things I never got very far, but I did read enough TechNotes and followed along with the newsgroups to gather that while the Application Designer promised a lot, it probably didn’t go far enough or at least, the extension and customization wasn’t for the faint hearted.
I was also disappointed with the lack of support for Biztalk. Sure, there is a prototype for an external Biztalk webservice, but thats ok if you are an ordinary app trying to connect to a Biztalk service. Actually, that also raises an important question. Why have a prototype for a “Biztalk” web service as though Biztalk web services are any different from ordinary services? What does it matter whats behind the webservice? If you are a Biztalk developer, then a prototype which helps you implement that web service makes sense because you may choose to publish a schema as a web service or a orchestration, but from the consumer standpoint, its all the same but the prototype doesnt do anything for the BTS developer (If anyone knows the rationale behind that prototype, drop me a line. I’d like to know what they were thinking of when they designed it). Since there wasn’t much Biztalk there, I left it without going any further. However automating Biztalk development and deployment is my idea of development nirvana so I have been looking at various options and i have written some posts on my earlier DNJ blog about these topics.
But, back to the present, I’ve been reading up on the future of VSTS and the features in Orcas, Rosario, Hawaii etc (all code names for the next releases of VS and VSTS). I came across the VS Team Architect blog and I was particularly taken with the features such as Top Down System Design and the Conform to WSDL. The enhancements to Importing & Exporting Custom Prototypes also looks like a great addition. I dashed off a note to the Team Architect team (and also one to Marty Waz) to quiz them on the level of support for Biztalk and what plans they have in that area. I also downloaded Beta 2 and will get cracking on investigating these features as soon as possible.
I think that Biztalk could do with more GUI’s and wizards. This will definitely make it more easy to use and lower the steep learning curve the product currently has. When you are running a team with vastly different skill levels, you cant have enough of automation. No amount of documenting your “standard patterns” helps when you are trying to get everyone at a common level and meet tight deadlines. Automation is definitely no silver bullet, but its a huge bonus for the harried architect.
I have grumbled many times in the past that the Solution Designer promised for the “vNext” never materialized and there’s absolutely no info on whether thats completely dead or if we can expect something in the next version (perhaps in 2010)? I dislike the lack of support in BTS for contract first development or to be more specific WSDL first development. A lot of the implementations I do now require a WSDL to be defined first with the third parties and then for development to proceed on that basis. But there is no out of the box feature for Biztalk to do this. Aaron Skonnard wrote an article in MSDN magazine a long time ago about contract first development, but the options to get Biztalk to conform to a WSDL are messy to say the least. There’s a BPEL import wizard but no WSDL import wizard. Why? Surely more developers care about WSDL than about BPEL!! I know they position the product as fully supporting BPEL4WS + some extensions and so the BPEL import will score some points there, but why not a WSDL import?
Its this area where I think that some integration between Biztalk and the Orcas Team Architect would be very powerful. I think it would be liked a dream come true to be able to feed a WSDL into a wizard and choose if we want a schema based web service or orchestration based web service and have it generate the orchestration. Of course it cant generate the “business logic” of the orchestration but it could generate the Facade which links to the ASMX or SVC interface and contains the correct handling of incoming messages, validations, returning of SOAP faults etc. The “inner” orchestrations can be hand coded or a stub could be created where the facade either calls the inner orchestration directly or through the message box or any other mechanism.
The TopDown system design would also be a great feature and the prototype import/export could easily link in with Jon Flanders Pattern Wizards tool (with a prototype encapsulating a project template or one of the pattern items).
We could go even further. How about an adapter factory that can generate WCF based adapters or a regular one? At this point currently we have an adapter framework & some wizards, but then there are also some adapter base classes to use (and there’s some pretty detailed guidance in a whitepaper on writing transactional adapters) and we have to plow through numerous options and figure out the correct interfaces to implement. After that we have to consider how to link in with SSO and all that. This area is ripe for a guidance package.
Also consider the amount of guidance in the end to end scenarios. Getting them all up and running and wading through the docs and code is not a trivial effort, but making all that guidance executable would be such a bonus.
I think a Biztalk solution software factory makes a lot of sense and when you look at the kinds of stuff coming out from P&P (the service factory, the new modeling edition of the service factory), a Biztalk offering would be really cool and would be able to leverage the advances in GAT, DSLs etc. Maybe a community effort to build something like this would be worth exploring. Biztalk, having such a wide range of applications, would probably need more than one factory (SOA, BPM, CBR etc + some horizontal facilities- adapters, pipelines, deployment etc) and a factory to build solutions on top of the ESB toolkit would also be great. These kind of things would take Biztalk usability far beyond its competitors.
What do you think? would this be worth starting up as a community effort? let me know. I came across this post from someone who is working on something similar and have pinged him to enquire if thats a private effort or something intended to be bigger. Lets see what comes up.