A quick survey for customers seeking MCPD: Web Developer 4 certification

April 26, 2011 at 9:47 am | Posted in Certification Paths, Microsoft | 8 Comments

As an informal survey, how many of you developer types plan on taking the PRO exams?

  • 70-518 Pro: Designing and Developing Windows Applications Using Microsoft .NET Framework 4
  • 70-519 Pro: Designing and Developing Web Applications Using Microsoft .NET Framework 4

Also, how many of you are interested in the new Azure platform (70-583)?

Comment below, or fill in the poll. We’ve just begun developing the 70-518 exam, and we’ll be sure to update you here when it’s available.

Meanwhile, Azure developers can compete against fellow geeks in a chance to win an Xbox 360 with Kinect, gift card, or official Rock Paper Azure contest T-shirt from Micosoft: http://www.rockpaperazure.com/

Escape the Routing Apocalypse with WCF 4!

March 7, 2011 at 10:15 am | Posted in Microsoft | Leave a comment
Tags: , , , ,

Since the 70-513 practice exam has just rolled off the press here at Transcender, I thought it might be a good idea to go over some of the new WCF features in .NET 4. As reported previously, the topics covered by the 70-513 exam are eerily similar to the .NET 3.5 version. The addition of jQuery and JSON is hardly surprising, because these topics are also covered in the 70-515 exam. But considering the undead possibilities in popular movie and game culture,  there are some useful additions to the .NET Framework 4 that do merit some discussion.

WCF Routing in a Zombie Apocalypse

WCF Routing in a Zombie Apocalypse

One of these features is message routing. Although WCF has always offered a robust message filtering framework that supports XPath 1.0 queries and SOAP headers, actually routing messages based on these message filters has required manual implementation. In WCF 4.0, an automated Routing Service is provided to reduce developer effort and support message body content.

To demonstrate this difference, let’s look at a typical business scenario. Take a large, sprawling campus that requires WCF for mission-critical messages, such as a biomedical research group with four facilities: Downtown, Uptown, College, and Rural Lab. If a scientist at the Uptown office needed to send a virus report on potential combat agents to the College office, client A will need to specify the WCF endpoint at College. If, however, that same scientist must send another report on fungal antibodies to the Rural Lab location, then another endpoint will be required. If we wanted to route these messages through the headquarters at the Downtown facility, then in .NET 3.5, we would need to develop a specialized intermediary service with all of the route plumbing, not to mention the impact of an extreme communication failure like a widespread power outage, crippling protest riots, or even a zombie apocalypse. How would messages warning of an approach of the walking dead be handled so as to avoid cataclysmic consequences?

Enter the Routing Service in .NET 4. The Routing Service provides a generic mechanism to direct any SOAP messages to specified endpoints using features such as service aggregation and versioning, and priority and multicast routing. The Routing Service sends and receives messages at a designated endpoint and routes the message exchange between specified sources and destinations automatically. The only thing you have to do is specify the logical route.

In our scenario, the Routing Service at the downtown headquarters could could provide the following endpoints:

<!– Primary endpoint of Downtown Headquarters –>
<endpoint name=”DowntownReport” address=”http://Main/Reports/DiseaseReport&#8221;
binding=”wsHttpBinding” contract=”IDiseaseReport” />
<!– Other service endpoints –>
<endpoint name=”Uptown” address=”http://Uptown/Reports/DiseaseReport&#8221;
binding=”wsHttpBinding” contract=”IDiseaseReport” />
<endpoint name=”College” address=”http://College/Reports/DiseaseReport&#8221;
binding=”wsHttpBinding” contract=”IDiseaseReport” />
<endpoint name=”RuralLab” address=”http://RuralLab/Reports/DiseaseReport&#8221;
binding=”wsHttpBinding” contract=”IDiseaseReport” />

Rather than being aware of the specific endpoint, the WCF client can specify the desired destination in a SOAP header. Based on factors like message values and priority, the message is forwarded onto the appropriate endpoint. For example, the filtering could be configured as follows:

<filter name=”UptownFilter” filterType=”XPath”
filterData=”/s12:Envelope/s12:Header/custom:Destination=Uptown” />
<filter name=”RuralLabFilter” filterType=”XPath”
filterData=”/s12:Envelope/s12:Header/custom:Destination=RuralLab” />
<filter name=”CollegeFilter” filterType=”XPath”
filterData=”/s12:Envelope/s12:Header/custom:Destination=College” />
<filter name=”DowntownFilter” filterType=”MatchAll” />
<table name=”mainTable”>
<add FilterName=”UptownFilter” priority=”2″ />
<add FilterName=”CollegeFilter” priority=”2″ />
<add FilterName=”RuralLabFilter” priority=”2″ />
<add FilterName=”GenericFilter” priority=”1″ />

Using the declared filter table, WCF messages that specify destinations are directed to their respective locations, while all other messages are directed to the default service endpoint at the downtown headquarters. So, if one location goes out, the filter can be altered and messages from WCF clients can be re-routed without service interruption.  All of this is provided with only minimal configuration and no development effort whatsoever. Just because a mob of zombies looms on the horizon, there is no reason you have to work like one!

–Joshua Hester

ASP.NET development and open standards: jQuerylicious!

July 7, 2010 at 3:31 pm | Posted in Microsoft | Leave a comment
Tags: , , , , , ,

Since the introduction of Ajax in ASP.NET, the Redmond shop has become more welcoming of open-source Web standards. The addition of jQuery in ASP.NET 4 continues that tradition. jQuery is more than just quick syntax for DOM manipulation; it is the basis for a wealth of robust plugins that save valuable development time and energy. And it’s almost as much fun to say as “vuvuzela.”

Let’s start with a basic HTML form:

<form id="jQueryForm">
<select id="lstContacts" >
<option value="jhester">Joshua</option>
<option value="tmcmillan">Troy</option>
<option value="rabernathy">Robin</option>
<option value="gmonsalvatge">George</option>
<option value="alang">Ann</option>
<option value="arotella">Aima</option>
<input id="txtUsername" type="text" />
<input id="jButton" value="test" type="button" />

Let’s say that we want to access the selected option and retrieve the associated username. In vanilla JavasScript, we’d probably use code similar to the following:

var username = document.getElementById("lstContacts").value;

Of course, this script alone is testament to how far browser equality has come. Using the Ajax library, we could abbreviate our script even further:

var username = $get("lstContacts").value;

But what about if the list allowed multiple selections? In that case, we would need to iterate through the elements and format the selections. jQuery supports a CSS-style selector, so we can overcome this issue fairly easy, as shown in this example:

var usernames = "";
$("select option:selected").each(function () {
usernames += $(this).val() + " ";

But, as I said before, jQuery for DOM manipulation is only the tip of the iceberg. Using the Microsoft Ajax CDN, you have a multitude of awesome plugins available, including the jQuery validate plugin. So, let’s take an existing AJAX Web Form (with the requisite jQuery script references):

<form runat="server" ID="numberForm">
<asp:Label runat="server" AssociatedControlID="txtNumber">Type a number from 1 to 10.</asp:Label>
<asp:TextBox runat="server" ID="txtNumber" />
<asp:Button runat="server" Text="Guess" />

Sure, you could use the ASP.NET validators to solve this scenario; nothing wrong with that at all. But the jQuery validate plugin through the Validation library provides a simple, and robust validation mechanism.  The validate plugin uses rules to specify requirements and messages for customized error messages. In this scenario, you would use the following jQuery script:

$("#numberForm").validate ({
rules: {
txtNumber: {
required: true,
min: 1,
max: 10
messages: {
txtNumber: {
required: "Please do not leave blank.",
min: "Must be greater than or equal to 1.",
max: "Must be less than or equal to 10."

Look, no hands! Completely customizable and no server-side postback required!

Once upon a time, choosing ASP as your Web technology locked you into using proprietary VB scripting. Now, with the advent of ASP.NET 4, open standards are finally supported and fully embraced by team Microsoft. ASP coding has evolved from integrating these standards to simply learning how to use them.

–Josh Hester aka codeguru

Entries and comments feeds.

%d bloggers like this: