The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

SOA and Avalon (XAML)

For all the other folks doing MS tool oriented and other enterprise type software - where are Microsoft and others  going with Service Oriented Architecture?  I still don't think I get the concepts behind it; web services seem like a good idea for certain types of situations (and indeed services within a very large organization) but this hardly seems the rule for most development projects.  I understand the needs for "distributed" architecture - something which CORBA, DCOM, COM+, and .NET Remoting have resolved to provide but this is hardly the rule: how would software like Fogbugz benefit from such tools?

For example, I have been thinking about cloning Moveable Type with the .NET framework, and I found some guys who were writing a new blogging engine using "Whidbey" (Microsoft's new ASP.NET) but where would the service orientation help us?

And then there's XAML which is a part of Avalon, Microsoft's new windows programming framework. It seems like a take off of XUL, a Mozilla project that seemed like a solution looking for a problem.  There's a markup language for GUIs which can then be programmed against in an almost identical approach as HTML/Javascript.  I understand why this is a good approach, I've been working with web development since I copied other people's HTML for a homepage in 1994.  But instead of coming up with new symantics for buttons (that can automatically transition from red to blue!), drop down lists and so on, why not push existing technologies and standards?  Of course the idea is to be proprietary, but why not a proprietary technology that leveraged HTML/Scripting in a Windows client?

ARGV, any comments/frustrations? Or, perhaps, can anyone help me understand more?
David Seruyange Send private email
Saturday, February 19, 2005
 
 
The big thing about XAML is that it's encapsulating the *entire* Windows GUI, in a way that's identical for web apps and local apps. You get all the functionality provided by Windows, and you can run the same program locally or remote. It's not (reasonably) possible to extend an existing technology to do this.
Chris Nahr Send private email
Sunday, February 20, 2005
 
 
Why can't XUL be used as a base?

Except for the obvious reasons - a) not an accepted standard which people demand, and b) not controlled by microsoft.
Ori Berger Send private email
Sunday, February 20, 2005
 
 
Can XUL access all GUI elements in Win32 and WinFX? Does it cooperate with .NET localization?
Chris Nahr Send private email
Sunday, February 20, 2005
 
 
> The big thing about XAML is that it's
> encapsulating the *entire* Windows GUI

It's not really encapsulating the entire Windows GUI - the Avalon system is a completely new GUI system.

A button in Avalon is not the same as a Win32 Button window, for example.

One of the reasons why it is new is that it is trying to provide services that the current Windows GUI doesn't have, such as layout containers.
Michael
Monday, February 21, 2005
 
 
> Why can't XUL be used as a base?

> Except for the obvious reasons - a) not an
> accepted standard which people demand, and b)
> not controlled by microsoft.

Of course, those are reasons enough for Microsoft's upper management not to want to use it as a base.

But there are other reasons - currently it doesn't seem to me that XUL is complete and extensible enough to form a complete GUI toolkit. The part that especially seems to be missing is the ability to program custom controls and take over stuff like drawing the control completely. I've seen this mentioned  for future versions of XUL, though.

Also, Avalon is trying to leverage fancy graphics cards features to provide whizzy animations and stuff like that, XUL doesn't provide that. That's another reason why they would have wanted to do their own completely new thing instead of be based off of XUL too.

I actually think that is a strategic error on the part of Avalon's design, though - it would have been much better if Avalon was not built for fancy graphics capabilities, and just concentrated on doing more simple GUI controls well, and also provided services to native code with managed wrapper similar to GDI+, and then they should have shipped something simple like that already and been working on the next version of it by now. Instead they have pretty much jumped the gun targeting managed only and also too much fancy graphics.

If XUL can become more extensible, it could turn into a really nice cross-platform GUI system.
Michael
Monday, February 21, 2005
 
 
"It's not really encapsulating the entire Windows GUI - the Avalon system is a completely new GUI system."

Yes... and XAML completely wraps this new GUI system. The point is that you can do anything that the rich client can do, not whether you'r using Win32 or Avalon buttons.
Chris Nahr Send private email
Monday, February 21, 2005
 
 
> Yes... and XAML completely wraps this new GUI system.
> The point is that you can do anything that the rich
> client can do, not whether you'r using Win32 or
> Avalon buttons.

Yes, and the same thing applies to Mozilla / XUL. Mozilla implements a GUI system, and XUL completely wraps the Mozilla GUI system...

XUL is its own GUI system, XAML is its own GUI system, that's why your question of whether XUL provides access to all of the same stuff as XAML doesn't really make sense - each one is separate, and neither XUL nor XAML provide access to every single GUI system that you can use on the client, they provide access to their own GUI systems.
Michael
Monday, February 21, 2005
 
 
So you're saying there's absolutely no difference between having full access to the rich client's native GUI, and having full access to the GUI provided by a particular third-party browser? Okay then...
Chris Nahr Send private email
Tuesday, February 22, 2005
 
 
Service Oriented Architecture is really a tool more focused on enterprise IT.  It's for exposing a companies "business logic" through software.  It's not really a concept for applying to a stand alone application like fogbugz or Word or whatever.

If you're a company who has a business such as finance, healthcare etc, you have an IT department who has built custom software which contains your business logic.  For many reasons you want to expose that business logic in a generic way so that it can be easily consumed:
1) by other pieces of internal software
2) by external software of your clients
3) by partner companies or companies your might merge with
etc...

I don't know what XAML really has to do with SOA.  XAML is about user interface where SOA is about business rules interface.
chris
Tuesday, February 22, 2005
 
 
> So you're saying there's absolutely no difference
> between having full access to the rich client's
> native GUI, and having full access to the GUI
> provided by a particular third-party browser?
> Okay then...

Like I already said, Avalon is not currently the native GUI of Windows, that's Win32 and XAML does not provide "full access" to it.

I guess if the new Avalon toolkit is successful, then I suppose it could eventually become the "native GUI" of a future version of Windows... On XP, I don't see how you would classify Avalon as the "native GUI" since 0 percent of the OS is written in it. How is that native? Just because the same corporation happened to write it?

But to answer your question - if you need to do normal, straightforward GUI stuff like buttons and text-entry fields and such, then yes, there won't be much difference. If you need to do fancy stuff like animated spinning buttons, then XAML will have an edge. Of course, a design that has such things will probably be annoying to use and will probably run very poorly on weak machines, so there are problems with taking that road.
Michael
Tuesday, February 22, 2005
 
 
In response to Chris:

SOA and XAML are two of the new marketing "buzz" words I'd heard from MS recently; I didn't mean to imply that they went hand in hand.

>Service Oriented Architecture is really a tool more focused
>on enterprise IT.  It's for exposing a companies "business
>logic" through software.  It's not really a concept for
>applying to a stand alone application like fogbugz or Word
>or whatever.

So I guess the question is whether Enterprise IT apps are more like the distributed "service oriented" nature or whether they are standalone, unintegrated systems that work but don't talk to each other.  So I follow up with the following questions: do people always want their unintegrated systems to talk to each other (is this often worth the effort?) and what sort of gains are made for standalone software development in the wake of all the marketing on SOA?

Regarding XAML, it seems to just be another way of getting UIs done. I emailed Dan Appleman and he mentioned that it probably wouldn't affect people who use designers too much, but code generation might be easier.
David Seruyange Send private email
Tuesday, February 22, 2005
 
 
"I guess if the new Avalon toolkit is successful, then I suppose it could eventually become the "native GUI" of a future version of Windows..."

Unless Microsoft fumbles monumentally there's really no question of "could". Avalon was originally planned as a Longhorn feature, after all.

"On XP, I don't see how you would classify Avalon as the "native GUI" since 0 percent of the OS is written in it. How is that native? Just because the same corporation happened to write it?"

You are correct that Avalon isn't currently the native Windows GUI, but its functionality is a superset of the current native GUI. And like any new Windows GUI generation, it looks hipper and cooler and prettier than the current one. XUL doesn't, and even if it did Microsoft would never tie the appearance of its OS to a competing web browser. So let's put it like this: there's no way that XUL *could* be a native Windows GUI, ever. Avalon can be, and is expected to be.

On the prettiness point, I disagree that "spinning buttons" etc. will be irrelevant to Avalon's success; many people inside and outside of software development *love* pointless shiny things on their monitors! "Skinning" software has already become a widespread addiction, and XP's huge success was partly due to its new "rounded" and colorful appearance.
Chris Nahr Send private email
Wednesday, February 23, 2005
 
 
> <..> but its functionality is a superset of
> the current native GUI.

No, this is untrue as of yet. There are various holes in Avalon at the moment, for instance lacking a treeview control. The XP version that they released was even missing some of the functionality from the Longhorn version, such as media support.

It has a ways to go yet before it is finished up and actually provides as full a toolkit as the current native GUI. That is their eventual goal, though.


> Unless Microsoft fumbles monumentally there's really
> no question of "could". Avalon was originally planned
> as a Longhorn feature, after all.

Well, they've already fumbled monumentally on WinFS, if you remember that was also originally planned as a Longhorn feature as well. Do you think that being "originally planned as a Longhorn feature" somehow automatically validates it?

Avalon is not really in quite as much danger as WinFS, but it has some similar pitfalls in its design, such as ignoring performance details and relying too much on continuously evolving hardware speed improvements which have failed to materialize.


> On the prettiness point, I disagree that "spinning
> buttons" etc. will be irrelevant to Avalon's success;
> many people inside and outside of software development
> *love* pointless shiny things on their monitors!

The people who have hardware that can run it love it. The people who are running a low powered laptop with less CPU and video power won't love it when that same app displays the pointless shiny thing at 1 frame per second and makes it slow and difficult just to click through basic GUI screens.

That's the biggest danger of the Avalon stuff, there will be a wave of people who go overboard on it (since the Avalon designers are basically encouraging that anyway), and it will be a problem when those apps run like crap on lower end hardware.


> So let's put it like this: there's no way that XUL
> *could* be a native Windows GUI, ever.

This is correct that XUL will never be the native Windows GUI. But really, so what? It doesn't really make any difference. If XUL provides easy to use GUI elements such as buttons and text entry forms, that are easy enough for users to understand and use to do regular things, then who cares? People are already used to doing a tremendous number of tasks through non-native GUIs, since they interact a tremendous amount with Web-based stuff.

XUL has a huge advantage that Avalon will never have, which is being inherently cross-platform.

Right now, XUL has the biggest chance of being the next major GUI toolkit, if it can evolve in a few more directions and provide more extensibility it will be there. It is not over-shooting the mark and trying to excessively complex things like Avalon.

But the Mozilla people just don't have as much experience as Microsoft at providing application developer toolkits. They might not be able to deliver enough proper extensibility to make it work really well... We'll see how they do.


> "Skinning" software has already become a widespread addiction

One of the strengths of a markup and stylesheet based mechanism like XUL is that it is easy to skin. You can get different skins for Mozilla, for instance.


> XP's huge success was partly due to its new "rounded"
> and colorful appearance.

Only in a very small part. The lion's share has more to do with combining the 100 times more robust NT kernel with enough usability features to make it work for a consumer desktop.


You'll notice that XP, like all previous releases of Windows, runs on a very modest hardware requirements, it is only somewhat more RAM hungry than earlier versions. Longhorn and Avalon are breaking this, they have way higher hardware requirements than any previous GUI mechanism from Microsoft. This is a big change, and has the potential to cause a lot of problems, I think it is a pretty big strategic error. We'll see...
Michael
Wednesday, February 23, 2005
 
 
>do people always want their unintegrated systems to talk >to each other (is this often worth the effort?) and what >sort of gains are made for standalone software >development in the wake of all the marketing on SOA?

Certainly people do not always want their unintegrated systems to talk to each other.  For security reasons and a variety of other other reasons.  However, integrating your disparate systems can be a way to create a competitive advantage for your company.  If you can have your AR, reconciliation, order processing, reporting and marketing systems all talking to one another you can provide features to your staff and customers which helps them get their work done faster and more reliably.

Some of these things are easier or harder depending on what your company does and what the state of those systems are.

As far as stand alone software goes... I don't really see a big gain.  SOA is essentially building another layer (or more) between your applications and its data and business logic.  Any time you do this you have a chance of taking a performance and reliability hit (though you can usually scale better).  With a stand alone application like Word, you want speed, reliability/stability and compactness.  SOA can be a hinderance to those things.

I've added my email address if you'd like to talk more about this.
chris Send private email
Thursday, February 24, 2005
 
 
XUL "a Mozilla project that seemed like a solution looking for a problem"

Hmmm. No. it is what Mozzila and Firfox are buit with. IT was created as a tool to build these applications, not a technology looking for a solution. Firefox is a very successful XUL application.

See http://discuss.joelonsoftware.com/default.asp?joel.3.83384.15
fool for python
Friday, February 25, 2005
 
 
Well, given that both XUL and XAML contain that magic acronymn 'XML', couldn't a web developer design a GUI in XUL and then apply a stylesheet to create a definition in XAML?  Then, based on what browser is detected, the user is served the appropriate interface.
Tim Clemons Send private email
Friday, March 11, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz