I said in my last post that the benefit of using Whitehorse has been marginal so far. To my surprise, I never got a single email refuting this. I still stand by that comment, although I am being a little hard on Whitehorse.

At this stage in the design process, I've painted a picture of my application design, and a picture of my logical datacenter design. I use the word picture explicitly, because that is what it is. It is a visual representation, without any additional information (metadata) attached. Kind of a flat representation of a 3D world. Today, I'm going to describe how I started to add that additional information, initially to the application design.

If you refer back to the application design in my previous post, you'll see I started by selecting one area of functionality we would be delivering (point-of-sale customer and sales order), and then built up an application design. To the basic POS system, I added some additional features to support further development, like an event publisher to allow new systems to be attached to the application, and a library of common services (InfrastructureLibrary). Remember also that my application utilises published SAP Web Services, which in my initial design I emulates using an ASP.NET Web Service (SAPWS).

The first thing I did today was to try to access the real SAP Web Services. I consulted the SAP API documentation and found the address of the WSDL files that described the Web Services I planned to utilise. Then, within the Application Diagram, I deleted the dummy ASP.NET Web Service (SAPWS), and added an External Web Service instead. When I did this, I got a dialog, which allowed me to specify the path to the WSDL file for the SAP API I wanted to use. I entered the URL, and this created an external Web Service in the Application Designer.

At this point I bumped into a couple of issues. Firstly, SAP exposes each API call as a separate web service, instead of a single web service with multiple web methods. This meant that I had to create a total of 8 separate external web services in the application designer, one for each SAP API I planned to call. This could make for a pretty cluttered Application Design if you planned to access a large number of SAP APIs.

The second issue came up when I looked at the signature of the SAP web services. These were RPC/encoded web services, rather than document/literal. I wanted to stick to document/literal web services, following the guidelines of the WS-I Basic Profile. I believe that later versions of SAP provide better web service interfaces. However, it became apparent that putting a web service faade across the front of the provided SAP web services was going to be a good idea.

You can see my Application Design above. Note that I cropped it a bit, to focus on the area of interest. At this stage, I had linked to each of the SAP web services, and I had defined the web services (and web methods) for my SAPFacade (a less granular set of business web services,  implemented in terms of native SAP web services). I still need to define the rest of my applications, but at this point I thought I'd have a little fun.

I checked everything into Visual Sourcesafe (I'm working stand-alone off my laptop, so no Team Server L), labelled the version, and then checked it all out again. Then I right-clicked on SAPFacade, and selected "Implement Application". VSTS created the ASP.NET Web Service project (in C#), automatically added web references to all of the SAP web services I had linked to in my Application Design, and created stubs for the methods of the two web services I had defined. Selecting one of the web methods, I was then immediately able to write the following code, with completion etc.

At this point, I really began to see some benefits from Whitehorse. Usually when I'm working with corporate customers, I don't get the luxury of completely "green fields" development. What I mean by that is that I invariably have to link my applications to existing applications/systems, and that I need to deploy those applications onto existing (sometimes shared) infrastructure (more about that next week). With a "static" design tool like Visio I typically can't pull in definitions from existing systems, and integrate them with my evolving design (although to be fair, I can pull in web services definitions in some other design tools). My Application Design was now starting to capture significant meta-data behind the visual elements, and more importantly, this meta-data is automatically transferred to the application developer (in the form of class definitions etc). I was beginning to get hooked!

One last really COOL feature! I talked above about the fact that I wasn't that happy with the exposed SAP web services, and I implemented a faade to those services which provided a web service interface that better suited me. Now of course as I continue to develop this application, I will build up a pretty comprehensive SAPFacade (a number of web services, grouped around specific business entities, such as SalesOrders, and Customers). Of course within my customer, other designers will be working on related applications, and these designers will benefit from the work I have done providing business level wrappers around the SAP web services. SO, what I can now do, is right-click on the SAPFacade application within the Application Designer, and select "Add To Toolbox". Now this component will be available on my toolbox, for re-use in other application designs (and I can export it for others to use as well). Of course I can use this to add other enterprise wide common components, like InfrastructureWS. Now that ROCKS!

More next week, as I start to "flesh out" my logical Datacenter Design.

My post yesterday didn't work very well because I posted the pictures of the designer onto a web site that had download limitations. The result was that most people who tried to view the post couldn't see the pictures. Now fixed, thanks to Nigel Parker, who loaned me some webspace. Thanks Nigel

Tomorrow, I'll post the second article in this series.

As a result, I was both excited, and a little bit worried, when one of my corporate customers asked me to help them architect and design a new series of applications they were going to build using VSTS. Excited, because I was finally going to get a chance to really exercise this cool technology, and a bit worried, because I wondered just how much value it would actually add to the design process, and whether it would really work as promised (it still a beta after all).

This blog is the first in a series where I'm going to try to explain how I went about using Whitehorse, and how effective I found it.

The customer had already developed an enterprise architecture which covered off the major applications they needed to build in the coming months, and also provided a whole lot of guidelines around how those applications should be architected (leading towards a SOA). The customer also already had some applications deployed using VS 2003, in an existing datacenter environment.

We started by identifying a candidate application. This was a retail POS application which was going to be browser based, and would provide retail customer management, and order creation/update. At the back-end, this functionality was all provided by SAP. We planned to integrate with SAP via SAP Web Services.

We started by laying out our initial application design. You can see the initial design below. The various applications are laid out in tiers, with a presentation tier containing the POS web site (CustomerSalesOrder), an application tier containing process level services (StoreOpsPS), another application tier containing the more atomic web services (SAPFacade, StoreOpEvents, and InfrastructureServices), and a data tier.

The key applications for the retail POS system are the CustomerSalesOrder web site, and the StoreOpsPS higher level services. As we started looking at those more closely, we realised that there were going to be some common services which would be shared by various applications. We decided to group these as InfrastructureServices, and these included things like auditing, authentication etc. We also wanted to be able to add integration with other systems easily, so we decided to implement an event publisher (StoreOpsEventPublisher), which applications could subscribe to. This was not required for the initial application, but we felt it would come in handy later on.

At this stage, we did not have access to the SAP system, so we mimicked that with a ASP.NET Web Service called SAPWS. We put a couple of Web Services into this proxy based on the SAP documentation. Later we'll replace this with the actual SAP web services.

At this stage, we talked to the infrastructure team, and got them to help us lay out the existing infrastructure using the Logical Datacenter Designer. That diagram is shown here

As you can see, they have two logical tiers, with presentation and application in the WebZone, and then several "data" tiers (SAPZone, DatabaseZone, and MainframeZone). From my perspective, although SAP and the mainframe have application logic, I only access them as data servers.

One thing that was not immediately apparent to me was that I needed to actually connect up endpoints even within a zone. So, when I first built this it would not validate against my Application Design, because I hadn't specified the LocalWS, or the EventQueue (OK, so I should RTFM). I found that I could connect up various Web Services, database connections, and generic connections, and then set constraints around them. For example I was able to specify that the protocol for the EventQueue had to be MSMQ. Cool.

At this point, I created a deployment diagram, and then spent some time putting all the applications into the appropriate servers, and linking up these within and across the zones. This took an hour or so, mainly due to my incomplete understanding of how it all worked. I also laid out the operations on each of the Web Services, ready for these to be created.

So, after all this, did Whitehorse help me design this system? At this stage in the process, I'd have to admit the benefit was still marginal. It did help, in that it forced the various interested parties to cooperate, and design not only how the application was going to work, but also how it was going to be deployed, but at this stage, we could have done all this with Visio.

HOWEVER, stay tuned for my next blog, when I'll describe how we continued to work with these design views, and make them much richer than they are here...

As I said in my previous post, I've been trying out a lot of beta software recently. One of the things I've been working with a lot is Visual Studio Team System. I reckon its pretty cool (actually, I'd have trouble going back to the previous version now), and really wish I'd had something like it in some of the projects I've done in the past.

To encourage you all to try it as well, we (the Microsoft New Zealand Developer and Platform team) have decided to run a competition to encourage you to try it out. The competition comes in two flavours, to appeal to both individual developers, and to development teams, and the prizes are pretty cool. There's about $100K in prizes up for grabs, for New Zealand developers only, so you have a great chance to win. Plus you get the chance to become world famous in New Zealand, because the winners get drawn at TechEd, which will give you some great exposure to the New Zealand development community.

To find out more, go to http://www.microsoft.co.nz/msdn/competition. Oh, and if you haven't already, get the VSTS beta here

Best of luck...