Working with Whitehorse…

ulrichr — Tue, 12 Jul 2005 05:37:00 GMT

I've done my fair share of technology presentations, and recently a lot of those have centered around the designers in Visual Studio Team System (aka Whitehorse). Now when you do a presentation, it's hard to really exercise the technology. You tend to stick to specific scripts, and avoid concepts that are complex, and take too long to explain (unless you want your audience to fall asleep).

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...

A nice analogy

ulrichr — Thu, 17 Feb 2005 11:21:00 GMT

I’m a sucker for a nice analogy! I find they are a great way to help you to understand complex ideas and systems, by referencing stuff you understand well. Of course there is the danger that you can carry one too far, but I still find I understand and remember stuff better when someone provides a nice vision for me. For example, I’ve always liked Pat Helland’s analogies about IT, first the Emissaries and Fiefdoms, and then the Growth of American cities aligned to the development of IT.

Yesterday I presented at the Service Oriented Architecture conference here in Auckland, and I also sat in on a session by Mark Colan from IBM. Mark made a nice analogy between the way systems were originally developed in a monolithic fashion, then object-oriented, and then SOA, likening it to walls (bear with me here).

Mark started the analogy by showing us an ancient wall, composed of irregular bricks, with large mortar chunks in between, and even some pieces that had been added on years later, and cemented into place. This was analogous to our monolithic applications, held together by code, which largely could not be changed, although some retro-fit did happen, tacked into place by more custom code. The next picture was a more modern wall, composed of bricks that were all the same size, still obviously held together by mortar. This was like o-o, because the components fitted together well, but you still needed code to hook them together, and once hooked together, rearranging them is impractical. The last picture Mark showed was of a Lego “sculpture” of Harry Potter (you can see it if you ever fly into or out of Auckland Airport). This was SOA. Bricks still the same, but they could easily be composed in a lot of interesting ways, and even after being built, they could be rearranged into new compositions. Kind of licke the cement was now re-useable, as well as the bricks.

The other point Mark made was that the guy who built the Lego sculpture had several attempts at it before he got it right, which parallels the potential rapid development style possible with SOA.

Nice one Mark!

Ulrich's SOAP Box : SOA

Working with Whitehorse…

A nice analogy