Rockford Lhotka

 Wednesday, February 11, 2004

Applications or Components?


When you create a system with web services, are your web services components or are they standalone applications?


While this might seem like a semantic question, it is actually a very big deal, with a lot of implications in terms of your overall application design, as well as the design of the web services themselves.


I specifically argue that web services are the ‘user interface’ to a standalone application. Any other view of web services is flawed and will ultimately lead to a seriously flawed application environment.


Another, simpler, way to put this is that “a web service is an application, not a tier in an application”.


Perhaps the key reason this is such an important thing to realize is that almost anyone can use a web service. It isn’t like we get to pick which other apps will call our web service. Web services are discoverable, and someone, somewhere in our organization (or outside) will discover our web service and will start using it.


If we designed the web service as a tier in our application, we would design it to trust our higher level tiers. If the higher level tier did a bunch of calculations or validations, it would be silly to replicate that functionality in a lower level tier.


On the other hand, if the web service is a standalone application that merely has an XML interface (as compared to a GUI or HTML interface), it must implement its own calculations and validations. It would be silly for an application not to implement this type of functionality.


So let’s get back to the component vs application thing.


Components are generally viewed as entities that live within applications. A component provides some functionality that our application can use. But components often have a high degree of trust in the application, and the application certainly has a high degree of trust in the component.


Think of Windows Forms controls, ActiveX controls, encryption libraries, data access (like ADO.NET) and so forth. These are all examples of components, and it is pretty clear that there’s a high level of trust between them and their hosting applications.


Viewing a web service as a component implies that it is part of an application, rather than actually being an application. This implies a higher level of trust than can be granted to something that is essentially a public API that can be invoked by any application in our organization (or beyond).


Applications, on the other hand, don’t trust each other. They trade data, they send messages, but they don’t trust. We’ve probably all be burned (multiple times) by having too much trust between applications, and we know that it is a bad thing.


By viewing a web service as an application, we can apply full application design principles to its creation. It has a presentation tier (the XML web service itself), a business tier (hopefully a set of business objects, or at least a business DLL), and a data tier (whatever that might be). It is self-contained, doing its own calculation, validation, authentication and so forth.


Other applications can use our web service as a data source, or however they choose. But our web service will be internally consistent and self-protecting.


This ultimately means that the web service will be reliable, useful across multiple applications and in the end will be a good investment in terms of development dollars.

Wednesday, February 11, 2004 4:00:44 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, February 5, 2004

After all the cool WinFX demos at the PDC there's been a lot of speculation about what WinFX and XAML (the XML dialect used to describe forms for WinFX) mean to all of us. One thing I've heard time and time again is that XAML represents a common programming model for Windows and the web.

You can take this concept two ways.

One is to say that there'll be a common model because both web developers and Windows developers will have a cryptic tag language to describe their displays, and will write code behind those tags to drive the UI. And this interpretation appears to be quite accurate - but its not very sexy.

The other is to say that XAML will allow us to write a single client application that can run in either the browser or on a smart client. Somehow the XAML would become HTML for a browser, and would become highly animated Dirext3D code for Windows. I don't buy this view at all, and here's why:

Bridging the gap in capabilities between the terminal-based browser world and the smart client world is a non-trivial exercise.
I've been thinking for a long time (years) about what must occur for this to be transparent across Windows and Web clients.
On a Windows client all the code behind the form will run right there on the client. Not just the animation stuff, but our UI intelligence and very likely our business logic. In fact, running our business logic (in whole or part) on the client is the whole point of having a smart client, so this point is pretty key. So our UI logic can interact with the full WinFX API. It can also interact with our business objects (or data objects) in a very rich way, since everything is running in a single memory space on the client.
At the same time, we want this to degrade all the way back to a terminal-based browser. In this scheme nothing can run on the client. The client is merely a display vehicle - a colorful 3270 terminal. After all, HTML isn't evolving, so web pages and browser rendering in 2007 will be essentially the same as today (which means the web, or at least HTML, is as good as dead, but that's another topic :-) ).
So where does all our UI code and/or business logic run in the degraded model? It must, by definition, run on the web server. But our code is written to this super-rich WinFX object model, while the user is seeing a dumbed-down terminal representation. In order to fake out our code, the web server will have to give the illusion to our code that it is running within a full-blown client. That way our code can interact with the same objects in the degraded world as it does in the real world.
A web server engine that can translate between a simulated WinFX client (for our UI code) to and from HTML (for the user's terminal) would be really something to see. I very much doubt that something this ambitious is in the works for Longhorn, but it is the only way to provide high-end functionality on Windows with the same code base that could also drive the terminal-based browser experience.
If they went this route, they'd probably need to create at least a couple simulators - one for HTML 3.2 and one for IE 6+ capabilities. Maybe more.
Following this to the extreme, someone could also create a Flash simulator that translated the WinFX reality into something that could be rendered in shockwave. Of course none of our UI code itself could run in shockwave, because our code would still be in .NET assemblies, so the Flash stuff would be pretty lame compared to real Flash work or compare to our actual WinFX UI... Still, it could probably do a limited subset of the WinFX animations, just without any client-side validation or user interaction code.
So while a XMAL->HTML converter could probably be created, that doesn't really solve anything. The real problem is how to make our UI code continue to run when (presumably) the client isn't even running WinFX, or maybe isn't even on the same machine where our UI code is running.

Thursday, February 5, 2004 2:20:56 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, February 4, 2004

 Dev Days in Minneapolis.
 VS Live in San Francisco
 VS Connections in Orlando
 VS Live in Toronto

... and more to come. Please go to my presentations page for a full list of topics and locations.


Wednesday, February 4, 2004 2:33:09 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

I've been rather skeptical of the whole blogging thing. However, the technology has been evolving, and blogs are becoming more and more integrated into the fabric of the web and the way we all communicate via the web. Due to this, I've finally decided to create a blog.

I don't anticipate that this will replace my primary Rockford Lhotka web site, which is where I provide continuing information and updates about my books and articles. Instead, I anticipate that I'll use this blog as a way to communicate more general thoughts and ideas over time.

Hopefully as time goes on this will evolve into a useful and interesting site.

Thanks for visiting.



Wednesday, February 4, 2004 11:35:01 AM (Central Standard Time, UTC-06:00)  #    Disclaimer