New Zealand Silverlight Development… Are you Doing It?

New Zealand Silverlight Development… Are you Doing It?

by | Sep 23, 2007 | BizTalk Community Blogs via Syndication

Take a trip to http://silverlight.net and you will see



This is testament to the work that Jay and Niall have done but also the strength of the All Blacks brand (especially during a world cup). I worked with the guys to choose whether to convert a WPF version of this gadget to Silverlight 1.0 to take it cross platform. Niall was able to convert it in a 48 hours period which confirms that you can go WPF->SL, albeit harder than going SL->WPF.


Some of my favourite quotes from the press release and online about this solution.


“The All Blacks are high performance innovators both on the field and on the web. Silverlight allows allblacks.com the opportunity to leverage its existing online investment to deliver a deeper user engagement. New Zealanders are looking for simple methods of interaction with their team. The All Blacks gadget delivers a rich user experience and provides users with real time access to the latest content.”
Mark Vivian, Broadcasting and Content Manager, New Zealand Rugby Union

Silverlight is fast, cross platform and allows developers to more readily meet sophisticated user expectations. The rich application space is rapidly evolving and Silverlight is definitely leading the charge.”
Mabode director Jay Templeton

Having done a fair bit of WPF (and knew XAML pretty well) – the learning curve for me was non existent for Silverlight – and really was just a matter of remember what elements/attributes/functionality weren’t supported. (and learning the ways of the javascript plugin object).

The bit that I originally perceived to be the hardest/most tedious – conversion of WPF XAML to Silverlight XAML was actually made really really simple using Expression Blend. The ‘Convert to’ function was the real timesaver – and allowed me to quickly convert things like StackPanels (which had no Canvas.Top/Canvas.Left values) – into Canvases.
Niall Ginsbourg mobilewares.net

Anyone else interested in technical details, this example is Silverlight 1.0 served from a Cold Fusion site running on Windows.

Just over three months ago I first showed Ian Taylor Silverlight. Ian got very excited by it’s potential and that lead to an article being printed in Computerworld titled Flash and Silverlight go head-to-head in Dunedin.

At the time Ian was quoted in a TVNZ press release for the launch of the-hub.tv

“Everyone has talked about merging traditional broadcast media with user generated content and the web. What I see in Microsoft Silverlight is that dream finally coming true. It is one of the most exciting technologies that I’ve seen in my 30 years in the broadcasting industry,” says Taylormade CEO Ian Taylor.

Taylor and his team have plenty of ideas of where they plan to take the-hub.tv and the Mission-On message but it wasn’t until he saw Silverlight that he recognised the platform that will bring those ideas to life.

The interesting part in this tale is that person tasked with building the Silverlight presence on http://the-hub.tv is Clinton Rocksmith a Flash, PHP, Mysql, Java open source designer/ developer. Back in early August Clinton wrote in an email to me (he has given me permission to post his words here)…

Sent: Monday, 6 August 2007 12:17 p.m.
To: Nigel Parker
Subject: Silverlight update

Hi Nigel,

Just wanted to say how impressed I am with Silverlight, I’m REALLY getting into it in a rather large way.  I’ve always dealt with programming in Flash since version 3 in Australia for doing interactive websites and I always felt that the web experience should be more about interactivity, but the programming model in flash makes the workflow difficult and the timeline just gets too long, and complicated.  It’s just yuck.

Through the University of Otago the computer science department there, instills a general feeling of Anti-Microsoft, but I think that the Expression tools that are available, complete with excellent tutorials and blogs and forums, that Microsoft is on a real winner with Silverlight.

Now, I’ve never used Visual Studio because of the University stance, but after speaking with other Microsoft guys here at Taylormade, I’m starting to come around to the possibilities of the dot net framework as opposed to the PHP Mysql Java open source mentality, something that I would probably not even entertained if Silverlight and XAML required Windows Servers only without plugging into all the others as well.

Just thought you’d like to know that while many people are quick to jump on the anti-Microsoft bandwagon of development, that with Silverlight and the way Microsoft has approached it with open attitude that it has converted one guy and quite possibly more as the application delivery of Silverlight becomes widespread.

Clinton

This was a GREAT piece of feedback for me. In fact when I took Silverlight on a university student day tour around the country this month I found that the people that heckled us at Canterbury last year during Brett Roberts presentation on Microsoft and open source actually called out “Holy S***” during one of my demos; the evals have been fantastic… I have presented Silverlight to 2961 people over 34 sessions in the last three months in New Zealand and the average eval score has been 87%!

Clinton has done a great job “enhancing” The Hub GYM with Silverlight. Ian showed this at the end of his talk at A New Future for Broadcasting Conference last month and I showed it at the MSNZ partner conference last week.

The Silverlight Gym will be available shortly at http://the-hub.tv for people to try (I’ll post an update when it is there) but in the meantime check out this screen cast… the jerky video is caused by the low frame rate on the screen capture tool.


Nas did a great job with the inaugural http://zamdes.com user group meeting and next months http://www.microsoft.co.nz/expression event in Auckland has over 150 registrations (still not too late for you to book your place).

The other activity that is getting people up to speed with Silverlight locally is a recent Intergen Silverlight competition…Glenn Conner one of the winners traveled to Web on the Piste with us to deliver a session. Check out the vidcast of Glenn (Scott and I) below… sorry about the wind sounds during the snow sections I did my best to fix it up… use headphones to listen… next time I definitely will need an external Mic for this sort of thing. I still can’t believe Glenn drew the picture that shows as his Windows background!


Watch with Silverlight (18 1/2 mins) or download WMV from skydrive (48.5MB)

After watching the vidcast check out the preview of Glenn’s Tarantula demo application.

There are more stories to share from NZ embracing Silverlight and I will update you when they come to life, please also contact me if you have a Silverlight project that you wish to profile. As Sean said in the partner conference keynote last week. New Zealanders are installing the Silverlight 1.0 plug-in at an amasing rate.

I wonder if Peter Jackson’s recent work and tomorrows global Halo3 launch in New Zealand have anything to do with it 😉

Enjoy

Follow up to Error -1040

by | Sep 23, 2007 | BizTalk Community Blogs via Syndication

In following up to this entry: restarting the Host Instance does not automatically restart the HIPAA EDI service, you have to manually have to go into the services and restart this service to clear up.

I was under the impression that the Host Instance, upon restarting, will automatically restart the child services, but it does not.

Goodbye DNJ

Goodbye DNJ

by | Sep 22, 2007 | BizTalk Community Blogs via Syndication

Well,after 3 years here its time to say goodbye to DNJ. Im moving to WordPress and the new link is http://santoshbenjamin.wordpress.com

I’ve had some great conversations here but im getting rather tied down by the poor editing facilities etc as i’ve said on many an occasion. I’ve also decided that its time for a change to befit my new status in life as i have explained on the wordpress site.

Anyway, im leaving the posts here as an archive (and also because i cant find any tools to move the content across. if you do know of any, do let me know). I will be visiting the aggregate site cos theres still some great content here.

Hope to see some of you at my wordpress site.

cheers,
benjy

Blogging Again

by | Sep 22, 2007 | BizTalk Community Blogs via Syndication

So its been a long absence from the blog world. Havent had much to write from a Biztalk perspective as i was only involved in the analysis and design phase for a new project that is now underway. But the other reason, definitely more important, is my change in status. Im now the proud dad […]

BizTalk Server 2006 – Enterprise Production Considerations – Part 3 – Clustering

by | Sep 22, 2007 | BizTalk Community Blogs via Syndication

I have had this recurring conversation with customers and partners.  Clustering is not a simple concept, and neither is BizTalk.  If you put them together you seem to have a perfect storm.  There’s lots of confusion, which I hope to be able to dispel with this post.

Also, I would like to have a link to send people, just so that I don’t have to have the conversation again 🙂

The Summary

  1. The SQL servers hosting the BizTalk databases can be clustered for high availability.
  2. The Enterprise Single-Sign On Master Secret Service (MSS) can be clustered for high availability.
  3. The BizTalk hosts can be clustered for the following reasons:
    1. They are hosting something (i.e. Receive Port) that has to be single instance, but still highly available.
    2. If you have BizTalk instances running on the same nodes that are running a clustered instance of the MSS.

FAQ

  1. What parts should I cluster? 
    You should cluster the SQL instance(s) holding the biztalk databases, the ENTSSO Master Secret service, and the BizTalk Hosts that require on a single instance running at a time, but still needs to be highly available.
  2. Is a non clustered-BizTalk host still Highly Available?
    If you have at least two host instances running in the same group for this host, then YES.  It behaves more like an NLB cluster than an MSCS service.

The Easy Part

I say that the SQL clustering is the “Easy Part” not because it is simple, but because I don’t feel compelled to explain the nitty gritty details in this post. I will give some of the BizTalk specifics here, and dedicate the next post to SQL cluster configuration. For now, as a rule, go with SQL 2005 Active/Active/Passive.

  1. Separate the MessageBox and Tracking Database among separate LUNs and separate SQL instances.
  2. The “Other” databases can often be place on the same node running the tracking DB.  If you are heavy on BAM or BAS you might want to break off the respective databases to a separate instance.
  3. All the databases should have at least 2 LUNS (data log), often they have more, but that gets into mount points and that is a tanget.

The Somewhat Easy Part

Clustering the ENTSSO MSS is pretty simple and the procedure is posted here. Basically, this is just a running service of the ENTSSO that also takes on the responsibility of distributing the Master Secret Key. This is the key that all the ENTSSO services running on other machines need to read the encrypted information in the SSO Database.

  1. This should be clustered.  Unless you don’t care about high availabilty. This can really mess up BizTalk if it goes down.
  2. This is not really a resource intensive service (typically) so it often piggy-backs on the SQL server nodes runing the clustered instances of SQL Server.
  3. You don’t want this clustered on the BizTalk boxes as a rule of thumb. (reasons covered later in this post)

Ok, now the meat.

BizTalk hosts generally have instances on more than one box, as such they are already highly available. This means that clustering a BizTalk host is not generally necessary to ensure high availability. If one goes down the others will pick up the work, out-of-the-box standard config.  The problem comes in when you REALLY don’t want to have mutliple instances of a host running at the same time.  The classic example of this is a receive port for an adapter that can not gracefully handle two threads reading it at the same time (i.e. FTP). It also happens when you need to be certain that all of the messages are picked up and processed sequentially and you don’t want to code around the problem.

So you want an FTP port receive, but you can not affort duplicate message reads.  That means you can have only one instance of the host, but that kills the out-of-the-box high availability.  Now you need to cluster that host instance, that is the only way to ensure that exactly one instance of the host will be running (so long as at least one of the BizTalk app servers is running)

The Very Wierd Part

This is the one that people scratch their heads over.  It does not happen much, and its not really all that complex.  But it is not intutitive, so it messes with people’s heads. 

For this to really make sense, I have to back up a step and explain how the ENTSSO service generally works in a mutli-box BizTalk installation.

  1. All of the BizTalk App servers have an instance of the ENTSSO service running on the machine. It is this service that obtains the secret key from the ENTSSO Master Secret Server and then uses it to independently access the info in the SSO Database.
  2. One of the ENTSSO servers is setup as the Master Secret Server. This means that it will distribute the secret key to the other ENTSSO service instances, in addition to being the standard ENTSSO service for the local box.  This is the service instances that needs to be configured for High Availablity because all of the other ENTSSO service instances depend on it.
  3. The BizTalk host instances have a dependency on the ENTSSO Service running on the same box as them. This is because they need desperately need it to give them info from the SSO DB. This information is typically configurations for their ports that is stored in the SSO DB for safe keeping.

Figure 1 – Standard Multi-Box ENTSSO Strategy

Lets say that you have only 2 production servers. They will be running both SQL and BizTalk.  Like a good boy/girl you decide to cluster SQL and the ENTSSO MSS.

Now you try to configure BizTalk host instances, and you find that they don’t want to work quite right. That is because they have a dependency on the ENTSSO service, they always need it.  Now that the ENTSSO service is clustered, only the host instances running on the active (ENTSSO) node actually have access to the service they need. All the other instances will fail based on dependencies.

Figure 2 – BizTalk Hosts with Broken Dependency

An an extra bonus you have messed up the High availability of the MSS as well. The clustering service detects that the host instances are depending on the ENTSSO MSS service and probably will not allow it to failover to other nodes.

…NICE…

Option 1 is to not cluster ENTSSO MSS in a 2 box scenario

Bottom line is that, if you have only budget for two prod boxes, you probably don’t want to cluster the ENTSSO MSS. But this is really the only time I can think of that clustering that service is bad.  If it is not clustered you better be a “Johnny on the spot” with MOM and implement a way to have MOM do a poor man’s failover when it detects that the ENTSSO MSS server is down.

Option 2 is to also cluster all BizTalk host instances that depend on a clustered ENTSSO service.

If you really do want to cluster the ENTSSO MSS, then you also have to cluster all of the BizTalk hosts as well. This ensures that as the ENTSSO Service “flips” from one box to the next, the Microsoft Clustering Service can ensure that the BizTalk host instances flip at the same time and don’t come crashing down.

BizTalk Server 2006 – Enterprise Production Considerations – Part 3 – Clustering

by | Sep 21, 2007 | BizTalk Community Blogs via Syndication

I have had this recurring conversation with customers and partners.  Clustering is not a simple concept, and neither is BizTalk.  If you put them together you seem to have a perfect storm.  There’s lots of confusion, which I hope to be able to dispel with this post.

Also, I would like to have a link to send people, just so that I don’t have to have the conversation again 🙂

The Summary

  1. The SQL servers hosting the BizTalk databases can be clustered for high availability.
  2. The Enterprise Single-Sign On Master Secret Service (MSS) can be clustered for high availability.
  3. The BizTalk hosts can be clustered for the following reasons:
    1. They are hosting something (i.e. Receive Port) that has to be single instance, but still highly available.
    2. If you have BizTalk instances running on the same nodes that are running a clustered instance of the MSS.

FAQ

  1. What parts should I cluster? 
    You should cluster the SQL instance(s) holding the biztalk databases, the ENTSSO Master Secret service, and the BizTalk Hosts that require on a single instance running at a time, but still needs to be highly available.
  2. Is a non clustered-BizTalk host still Highly Available?
    If you have at least two host instances running in the same group for this host, then YES.  It behaves more like an NLB cluster than an MSCS service.

The Easy Part

I say that the SQL clustering is the “Easy Part” not because it is simple, but because I don’t feel compelled to explain the nitty gritty details in this post. I will give some of the BizTalk specifics here, and dedicate the next post to SQL cluster configuration. For now, as a rule, go with SQL 2005 Active/Active/Passive.

  1. Separate the MessageBox and Tracking Database among separate LUNs and separate SQL instances.
  2. The “Other” databases can often be place on the same node running the tracking DB.  If you are heavy on BAM or BAS you might want to break off the respective databases to a separate instance.
  3. All the databases should have at least 2 LUNS (data log), often they have more, but that gets into mount points and that is a tanget.

The Somewhat Easy Part

Clustering the ENTSSO MSS is pretty simple and the procedure is posted here. Basically, this is just a running service of the ENTSSO that also takes on the responsibility of distributing the Master Secret Key. This is the key that all the ENTSSO services running on other machines need to read the encrypted information in the SSO Database.

  1. This should be clustered.  Unless you don’t care about high availabilty. This can really mess up BizTalk if it goes down.
  2. This is not really a resource intensive service (typically) so it often piggy-backs on the SQL server nodes runing the clustered instances of SQL Server.
  3. You don’t want this clustered on the BizTalk boxes as a rule of thumb. (reasons covered later in this post)

Ok, now the meat.

BizTalk hosts generally have instances on more than one box, as such they are already highly available. This means that clustering a BizTalk host is not generally necessary to ensure high availability. If one goes down the others will pick up the work, out-of-the-box standard config.  The problem comes in when you REALLY don’t want to have mutliple instances of a host running at the same time.  The classic example of this is a receive port for an adapter that can not gracefully handle two threads reading it at the same time (i.e. FTP). It also happens when you need to be certain that all of the messages are picked up and processed sequentially and you don’t want to code around the problem.

So you want an FTP port receive, but you can not affort duplicate message reads.  That means you can have only one instance of the host, but that kills the out-of-the-box high availability.  Now you need to cluster that host instance, that is the only way to ensure that exactly one instance of the host will be running (so long as at least one of the BizTalk app servers is running)

The Very Wierd Part

This is the one that people scratch their heads over.  It does not happen much, and its not really all that complex.  But it is not intutitive, so it messes with people’s heads. 

For this to really make sense, I have to back up a step and explain how the ENTSSO service generally works in a mutli-box BizTalk installation.

  1. All of the BizTalk App servers have an instance of the ENTSSO service running on the machine. It is this service that obtains the secret key from the ENTSSO Master Secret Server and then uses it to independently access the info in the SSO Database.
  2. One of the ENTSSO servers is setup as the Master Secret Server. This means that it will distribute the secret key to the other ENTSSO service instances, in addition to being the standard ENTSSO service for the local box.  This is the service instances that needs to be configured for High Availablity because all of the other ENTSSO service instances depend on it.
  3. The BizTalk host instances have a dependency on the ENTSSO Service running on the same box as them. This is because they need desperately need it to give them info from the SSO DB. This information is typically configurations for their ports that is stored in the SSO DB for safe keeping.

Figure 1 – Standard Multi-Box ENTSSO Strategy

Lets say that you have only 2 production servers. They will be running both SQL and BizTalk.  Like a good boy/girl you decide to cluster SQL and the ENTSSO MSS.

Now you try to configure BizTalk host instances, and you find that they don’t want to work quite right. That is because they have a dependency on the ENTSSO service, they always need it.  Now that the ENTSSO service is clustered, only the host instances running on the active (ENTSSO) node actually have access to the service they need. All the other instances will fail based on dependencies.

Figure 2 – BizTalk Hosts with Broken Dependency

An an extra bonus you have messed up the High availability of the MSS as well. The clustering service detects that the host instances are depending on the ENTSSO MSS service and probably will not allow it to failover to other nodes.

…NICE…

Option 1 is to not cluster ENTSSO MSS in a 2 box scenario

Bottom line is that, if you have only budget for two prod boxes, you probably don’t want to cluster the ENTSSO MSS. But this is really the only time I can think of that clustering that service is bad.  If it is not clustered you better be a “Johnny on the spot” with MOM and implement a way to have MOM do a poor man’s failover when it detects that the ENTSSO MSS server is down.

Option 2 is to also cluster all BizTalk host instances that depend on a clustered ENTSSO service.

If you really do want to cluster the ENTSSO MSS, then you also have to cluster all of the BizTalk hosts as well. This ensures that as the ENTSSO Service “flips” from one box to the next, the Microsoft Clustering Service can ensure that the BizTalk host instances flip at the same time and don’t come crashing down.