Eddie Churchill - First look at Solution Designer

I was very shocked to see Eddie on Channel9 but not shocked by the shirt.   I worked with Eddie back 10 years ago on a skunkwork project for Chrysler.   I knew he moved from another dev tool company to Microsoft not too long ago but I am happy to see him at Microsoft working on a great product.  Eddie always had a great way of putting technology down to an easy level.  Looks like he has not lost the gift.

I saw the (prototype for) Solution Designer today at PDC; this thing is cool!

Eddie, can I please have CanDo! for Vista?

Glad to see you landed at Microsoft doing cool things.

Glad you liked. The Solution Designer and Mapper is a joy to show off.

adamhill wrote:

CanDo! for Vista?

Interesting idea, I will put in the queue (mind you it is a long queue;))

Great hearing from you again

cwoodruff wrote:

I worked with Eddie back 10 years ago on a skunkwork project for Chrysler.  

:OWell howdy dude, it has been a while. Brings back the memories.

Surely, all or some of BizTalk functionality is in some enterprise edition of SQL Server 2005, right?

When might we be able to see the Mapper?

Video is in the can and should be release on Channel9 within the week (or so).

Hi Eddie,

I saw your live presentation of this at PDC05.  Very cool!

Have you seen BRIDGEWERX?  A very similar visual designer built on top of BTS 2004.

http://softwareindustrialization.com/DisplayPost.aspx?PostID=36

Best regards,

Mitch

rasx, BizTalk vs. SQL Server 2005...

Ah the every popular discussion up here at Microsoft. I would say that yes there is some overlap but each are optimized for particular tasks. I would say that if you have one, use it. If you can't do what you need to, then start investigating the other one.

Mitch, glad you liked.

Just looked at BridgeWerx site, looks like nice stuff. Too bad we didn't run into each other at the PDC, it would have been nice to sync up. Till the next time...

Hey, Awesome video. Very interesting and the Solution Designer looks really cool. Would there be any efforts to make this run on the DSL designer base (or the Whitehorse AD surface). I've commented about this here on my blog and would love to know what the project team on the SD thinks about it.

Keep up the great work
Cheers
benjy

It is an ongoing discussion but at the moment they are built on top of two different visual frameworks (both built using System.Windows.Forms though). We have some rather unique needs that their framework doesn't deal with yet...

Hi Eddie,

Yes indeed, your solution looks really cool.

From my experience with BizTalk, such visual tools really help move to the next level of developer experience.

Let me pass on some of my user experiences to help move BizTalk to the next level on the functionality aspects as well.

They are as follows:

1) Enhancements on Publish Subscribe Model. (PAS)

The success of any PAS based EAI/ESB product depends mainly on the flexibilities which can be incorporated within.

a) in case of the receive shape in the orchestration, where we filter, we need to have a "XPATH" based filter option, wherein we can filter on exact XPATH conditions in the UI.

CBR based Subscription is increasingly being done inside an orchestration, whereas it can be effectively handled at the receieve shape - namely - triggering of an orchestration itself.

b) when we have a straight forward flow, say from a receive port to a send port via filter subscription, there should be a capability of 'return subscription'.

Let me explain further:

when we have a send port subscribed to a receive port - via the receive port's name, in the Filter & Maps tab of the send port, if there is a successful send, there should be a possibility of returning an ACK back to the receive location. This can be a 'K' file with the same name as the original file.

E.g: if 'file123.txt' is polled for, the K file sent back is 'file123k.txt'

c) There should be options to programatically add filters to an orchestration via API calls. This will help as follows:

if we have a 'K' file which is the trigger file and there is this another data file. Now once we receive the K file, we should be able to subscribe for the actual data file, which again differs in its naming only by one letter as shown in the example above.

This way, there can be more flexibility within BizTalk to enable a cleaner handshake and in terms of reconciliation and strict process control.

d) subscription should also be extended to the receive port. In case of two distinct receive locations, linked to two different receive ports, port A, if it is receives a message, should be able to trigger a subscription on port B and if required be able to pass some macros like %SourceFileName% etc.

With regard to point d) - the way i look at it, BizTalk should be able to create subscriptions for all artifacts including receive ports and also pipelines.

It would be really amazing to have a GUI as you have shown in your video and a way to subscribe one component to another via the GUI.

- I understand GUI is an essential part, but going by the way the industry is evolving, BizTalk needs to have a highly flexible and robust PAS model to emerge as the market leader.

Hope this helps in some way. Please provide your inputs to vsatis@yahoo.com

Thanks,

Satish.

Is There anyway to download this video. as i can't watch videos for my personal learning in office timmings so i need to download such videos for learning at home. as i dont afford faster internet connection at home. please advise.

Regards
Mubashar ahmad