In another thread, we got started talking about ABL clients versus other technologies. I suggested that I could readily understand why someone who had already paid the price for client licenses would find it attractive to stick with ABL clients, especially since the ABL GUI for .NET now allows one to make so much more attractive and fundtional user interfaces. But, since my personal focus is modernization and transformation in which potentially there are major changes to the application architecture, I wondered how often one would choose an ABL client for a new application. Certainly, a question like this requires context. E.g., an AP who is selling an application will be driven to a significant degree by market forces and may need to provide a particular client type since that is what the market requires. The AP also tends to have a bigger budget motivation to make more radical changes to architecture, including a new UI and probably, on average has a larger staff, so having UI specialists is less of an issue. Conversely, and end-user customer has really their own internal business drivers to consider so a move to a totally different technology for the client is most likely to happen in a move from ChUI than it is from existing ABL GUI clients. With ChUI, the only software on the user's machine is the telnet client, so moving to ABL GUI clients, with or without .NET is as big a change as moving to any other technology client.
One of the issues which has often been raised in discussions of this sort is license costs. Another is the overhead of having a software install on every user's system. This is, of course, one of the reasons I am fond of the WUI alternative since the only licensing and management issue is the AppServer required in any modern architecture (yes, Greg, I know you also advocate Sonic and little or no AppServer, but for simplicity sake I want to leave that out of the discussion for the present since I think the idea needs more development and specification before we know how it fits). A .NET or Java client may require the per system install, but no per user license beyond the AppServer. Conentional ABL clients require additional licensing ... unless they are Web Client.
So, what is the real story with Web Client? Are lots of people actually using it? Is it working for them to have a self-updating client? I know that there are some things about it that are broken with OO features one can't use yet ... is that a major obstacle? of are those using it still mostly pre-OO so it isn't an issue yet.
Bottom line, what kind of client would you pick for a new application (or one being so re-done as to effectively be new)? And why? And what real experience is behind that preference?
So, what is the real story with Web Client? Are lots of people actually using it? Is it working for them to have a self-updating client? I know that there are some things about it that are broken with OO features one can't use yet ... is that a major obstacle? of are those using it still mostly pre-OO so it isn't an issue yet.
I'm using it and some of my clients are using it. Self-updating works fine and with the announced changes for 10.2B (http://communities.progress.com/pcom/docs/DOC-101182) deployment should get even easier.
What OO features ARE still broken? Those that I know where broken are fixed in 10.2A01 (statics, DYNAMIC-NEW). I'm pretty sure that in my latest developments I'm using any available OOABL feature - without any issue (also in production).
tamhas schrieb:
The AP also tends to have a bigger budget motivation to make more radical changes to architecture, including a new UI and probably, on average has a larger staff, so having UI specialists is less of an issue.
Maybe less of an issue - but still an issue. Many APs have much more domain knowledge than up to date technology knowledge. The requirement for a second technology is usually a big challenge.
I don't know that there are ones still broken ... I just never heard that the previously broken ones got fixed!
So, if it is so great, why wouldn't it be the preferred way to deploy ABL clients ... or is it and people just haven't figured that out?
To be sure, I do sometimes wonder exactly what expertise some APs have .... the sins they commit in terms of bad DBA guidance are legion! I'm just suggesting that if one only has one or two programmers on staff, then one has an obvious motivation to simplify the technology mix, but if one has half a dozen or more and there are compelling business reasons, then it isn't terribly difficult to have specialists, especially since one should probably have specialists by that point anyway. If you have specialists, having one or more of those work in a different technology isn't really a lot different than having one or more who do all the ABL GUI for .NET stuff while no one else touches UI.
So, if it is so great, why wouldn't it be the preferred way to deploy ABL clients ... or is it and people just haven't figured that out?
It's mine!
Yeah, but so far a poll of 1 isn't telling me much about the larger world out there. Your perspective is certainly very interesting, particularly since this is an area in which you have particular competence, but what about the rest of the world?
Some of this, of course, is just the old problem of so much of what happens in the ABL world is invisible. While the reaction to the ABL GUI for .NET stuff has been one of the most dramatic of any reaction to new capabilities (as measured by PSDN forum posts and general buzz), really that mass of forum posts is heavily dominated by a handful of contributors. Does this mean that there are bunches of people out there working with the technology who simply don't participate for one reason or another? Or does it mean that it was a really exciting thing to a very small number of people?
I suppose Julian will now pop up and say that I am hijacking my own thread, just as he predicted ... but I think the issues are interrelated.
Does this mean that there are bunches of people out there working with the technology who simply don't participate for one reason or another?
I know bunchs of people that read PSDN threads but never post. For reasons of language and time! And I know bunchs of people that don't even read PSDN threads (or other forums) - for similar reasons- , but still are using the technology successfully. Because they are clever enough or they have hired a consultant that supports. Some may not even know how valuable these forums may be.
Yes, I know about the read, but don't post and the don't read or post due to time or lack of awareness or stupid rules on the part of management ... but the point is still that what we see visible here is an ice cube on the tip of the iceberg of what is actually going on in the ABL world. It wouldn't surprise me that you knew a number of people who were working in the area without posting if only because your expertise availability stimulates people to try it or you know them exactly because they are seeking out your expertise. There may even be a European factor as there is with UML use. We still have the problem that most of what is happening is invisible.
... but if one has half a dozen or more and there are compelling business reasons, then it isn't terribly difficult to have specialists, especially since one should probably have specialists by that point anyway. If you have specialists, having one or more of those work in a different technology isn't really a lot different than having one or more who do all the ABL GUI for .NET stuff while no one else touches UI.
I see a certain risk in depending on those specialists - and I think we need to differentiate.
One this is requiring specialists for building and maintaining frameworks and common infrastructure, templates etc.. This is not day to day development.
The other thing is requiring two different developers to develop and debug a function seen on a single screen (and very often specifications and requirements and bug reports are defined based on UI functions). Needing two developers (let's say a Java or .NET developer for the UI and an ABL developer for the backend) for that task creates a higher cost. I know, you may suggest unit testing to avoid debugging the distributed app. But the reality is, that these utilities are hard to set up and only in place at a minority of teams.
One of the concepts of agile development methods is that (almost) any developer that is available can perform a certain task on the whole application. This requires understanding of the code. Coding standards are one requirement to make this easier. Certainly the ability to understand the programming language is another requirement. Depending on only a subset of the team to do a certain job can reduce agility.
Speaking of your team of half a dozen developers: If the one Java developer in the team is on vacation (a more frequent issue in Europe, I guess) and the other Java developer is busy - the 4 remaining ABL developers may need to wait for a time slot to get some change in the UI.
I'm pretty sure, that using an ABL client reduces complexity and the need for precise development management (reduction, not elimination).
So the point should be: What speaks against ABL on the client?
- License costs: I doubt that's true when the backend is Progress
- Feature requirements: May be true for some apps (let's say multi-threading), but GUI for .NET solves a lot on the presentation layer
- Platform openness: If you really need a client running on Linux or Mac OS-X...
- what else?
One this is requiring specialists for building and maintaining frameworks and common infrastructure, templates etc.
The "toolmaker" is certainly one of the early specializations which I would advocate ... as long as one has such a person on staff. But, I think there are fewer people with those skills than there are slots.
The other thing is requiring two different developers to develop and debug a function seen on a single screen (and very often specifications and requirements and bug reports are defined based on UI functions).
With proper layering, this should be a non-issue. I.e., a business logic component may be providing interaction with a number of UI or service components and should have a contract which can and should be tested. The UI component likewise. With a clean interface, the UI developer should be able to easily determine whether or not the BL component is liviing up to its contract and either refer the problem to the BL developer or know that the problem is in the UI component. Admittedly, without such separation, it is a lot harder to make such determinations, but that is one of the big reasons for moving to layered OO architectures.
One of the concepts of agile development methods is that (almost) any developer that is available can perform a certain task on the whole application.
In 1985, it was reasonable to think that a reasonably good developer would come to be competent in all of the ABL. I don't think that is a reasonable expectation any more and hasn't been for some time. If one likes that sort of approach to development, one can still practice it within an area of expertise, but I see no reason to expect the database performance expert to whip out lovely UI work (not that I am thinking of anyone in particular...).
Depending on only a subset of the team to do a certain job can reduce agility.
It might reduce agility in terms of the agility of an individual to bounce around from project to project and yet increase the agility of the team as a whole because layered architectures, SOA, etc. produce more agile systems.
If the one Java developer in the team is on vacation (a more frequent issue in Europe, I guess) and the other Java developer is busy
Clearly a bigger problem on your patch than mine ... what's a vacation? ... but one amenable to scheduling and planning. After all, with good layer separation, the fact that the UI team is behind is really no impact on the BL or DA team ... they just keep on working and let the UI folks catch up when they are back to full strength. Yes, if there is a maintenance problem that needs addressing in the UI, then there is only one person to deal with it, but I also believe (from experience) that model-driven development, OO, and layered architectures all help to produce systems which are more stable, less likely to need maintenance, and are more easily maintained when it is required.
So the point should be: What speaks against ABL on the client?
Not necessarily. Given a layered architecture, I think that any tool has to compete openly against other tools for that layer. ABL is going to have a certain preference because of the possible attractions of being a one language shop, but that shouldn't be so strong a preference that there is a presumption of ABL unless there are sufficient grounds to displace it.
- License costs: I doubt that's true when the backend is Progress
- Feature requirements: May be true for some apps (let's say multi-threading), but GUI for .NET solves a lot on the presentation layer
- Platform openness: If you really need a client running on Linux or Mac OS-X...
- what else?
License costs can't be dismissed. Only with Web Client is there no additional license for the client. You may be convinced that every ABL client should be Web Client, but I don't think we can assume that yet. Also, Web Client locks you into AppServer, which is a definite license cost. True, AppServer seems heavily favored as a PSC solution, but there do appear to be other possibilities.
The ABL GUI for .NET certainly is a big leap forward and presumably subsequent releases will make that even more so (generics are coming, yeah!), but multi-threading is a big takeaway.
I think platform openness is a potentially big issue, especially in some contexts. It isn't just non-Windows either, but the right kind of Windows.
A self updating client certainly sounds like it would make the problem of keeping clients up to date far more manageable, but it is still a potentially lot of softtware installed on each client and a potential source of incompatibilies and such. Flyweight clients have a lot of appeal to me for low client impact, nimbleness, openness, etc.
My main issue is programming in such a way that one has not predetermined the technology of the client. If one does that and decides that for now ABL is a perfectly good solution for the client, then fine. But, when a need comes up to support remote clients on browsers or whatever, if the architecture is in place then that is just a problem of creating some new client code, not a problem of having to rework the BL layer too.
I do wish we would get some other people chiming in here on the glories or not of Web Client ... not that I don't like talking to you Mike, but I would like more viewpoints and experiences to enrichen the pot.
Don't have time or energy right now to compete with you guys on who writes the longest or the most posts
But I second Mike's opinion on the WebClient. With either Client-Server or the WebClient you have everything you need for deployment. And with .NET included in the UI with 10.2A, you really have everything you need to get the best of all worlds with modern UI and good backend with the ABL.
Except for maybe an easy modern web interface, I don't see any reason why ABL development teams should be using other technologies like native .NET for their client UI. Especially if they have lots of experience in developing applications with the ABL. I think a lot of people are getting caught up in a technology rave at the moment of developing apps with alternattive UI and backend combinations - instead of focusing on producing good stable applications that they can easily develop, deploy and maintain with the speed they are able to do this with OE.
My vote goes for WebClient ;-)
I'm with you in not wanting to go along with the .NET craze, if only because of the platform lock. Now that we have ABL GUI for .NET, if .NET client was acceptable before, it seems like ABL Web Client should be an option now ... with due proviso for the limitations which exist in AG4.N and the need for an experience base with Web Client to see if it lives up to its promise. I have to say that the "missing bits", apparently fixed with SP01, are the sort of thing that makes me nervous.
I guess I think there are several questions here that can be addressed separately.
One is, "should one be designing applications in a layered architecture such that the choice of technology is independent of the server?" That I feel is a strong yes.
Another is, "how well can an ABL4.N Web Client server to replace a .NET client?" While there is some validation needed here, it appears that it is a pretty arguable alternative, although with some notable compromises like multi-threading.
But, while .NET has a lot of buzz, there is also the question of .NET in either form versus other clients such as Java, which provides platform independence, and WUI clients which provide minimal client footprint and ubiquity.
And, I suppose one might also ask whether using ABL for the client really does mean that anyone on the "team" can do anything since it seems to me that AB4N is pretty specialized knowledge, enough that it might as well be a different language. If, for example, one had very good tools in another language, might it not be just as easy to pick that up as to pick up the specialized knowledge needed to deal with AB4.N?
What drives you that mad about others using the WebClient productively in a properly layered OO architecture?
It has survived much longer than most of the "WUI" technolgies your are talking about have and it looks like it will continue to be maintained by the vendor!
Just using a different language for the UI does not guarantee a better architecture or layering.
Kilopost!
Nothing drives me mad about Web Client.
On the plus side, it uses the same language and tools, albeit the skills needed to deal with the AB4.N stuff are not skills which pre-exist in the general ABL developer, and it appears to have this self-updating capability which avoids the usual hassle of trying to keep a large number of clients current on the software. I would like to hear some more endorsements of how well this works in practice, how often it doesn't work, and what kinds of corrective actions are required when it doesn't work.
On the minus side it does still have the client code installed on the client machine and the skills required are different enough that the transferrence is somewhat questionable. Also, there are limitations which don't exist in native .NET clients, although some of these will apparently go away in 10.2B. One is, however, pretty well guaranteed to be behind the curve since new controls will take a while to make it through the PSC beta and release process. And, of course, one is still locked into a Windows client.
I think part of the issue here is coming at things from a different direction. You, having gotten involved early and deeply into the AG4.N development have been able to make it shine and have had contexts in which you have taken existing ABL GUI clients and made them much nicer. For my part, I have done very little with client code for a few years now and it isn't something that interests me especially, but I did have the experience a few years back of doing a Siebel installation and being very impressed with what they produced in terms of a very rich client running in a browser with a nominal, automatic download of a few components as needed. It wasn't perfect since they required IE, but that was a while back so it may mean that some of the annoying difficulties of browser incompatabilities are somewhat improved. And, that was before all the Ajax toolkits and such became available.
I don't know about the static OO stuff (yet) but our report as a mini-company (and hence maybe a typical Progress shop) with the WebClient could explain why we just love it: For almost 4 years now we've been doing SaaS and have experienced the same productivity and stability as we've always been used to with C/S or host-based Progress apps. I'd say that if capacity (or money) is a parameter a single skill-set for all development must be a big plus!
So, your comparision is Web Client as a means of deployment versus other ABL clients, yes? Well, provided that Web Client didn't have any downsides, I can see that being an attractive comparison since you have presumably gotten rid of the deployment problem typical of ABL clients, but you haven't really had to change anything except the deployment technology. Seems like it should be a fairly obvious win.
Has there been any downside?
A down-side was the additional work we decided we had to put in to roll our own components for communicating with the AppServer, rationalize gui and server programming and deploy the app.
Now - maybe that has turned to an up-side since we have good control of the most of the delivery chain.
As I recall we've only had one serious issue with the infrastructure: When downloading large blobs we had to split them to avoid loosing the AppServer connection. There might be a parameter to solve this but the extra day or two of programming around it gave a hopefully permanent solution.
The downside sounds like it was just getting you to modernize the application ... which I would think was actually an upside. Since my whole question is asked in the context of modernization, some kind of modernization of the client is a given.
As for the BLOBs, is this an issue with production use rather than sofware update? If so, is it a problem specific to WebClient or is it an issue with any AppServer use?
Yes - we are actually proud of our little toolkit that came out of the process. Also that we figured out that the framework offerings available from PSC maybe weren't always the best fit - before they discovered that themselves..
Actually the BLOB issue was both a deployment and production issue so we're really glad that it could be handled.
we figured out that the framework offerings available from PSC maybe weren't always the best fit
Well, I think I will let that slide by without comment ....
So, the BLOB thing is a general purpose problem of sending overly large chunks, whether code or data? Does PSC tech support acknowledge the problem?
Data is the only issue (we deploy from a database so I have no experience with Intellistream). It's been a while so I don't recall details from how Tech support was involved. I think I got hold of some routine somewhere as a starting point.
tamhas schrieb:
we figured out that the framework offerings available from PSC maybe weren't always the best fit
Well, I think I will let that slide by without comment ....
Congratulation Brynjar - I guess nobody achieved that before ;-)
Can anybody help me out: Do Java or .NET Clients support message compression (-mc parameter on the Progress (Web-) Client)?
That greatly enhances the performance of data retrieved from the AppServer. Especially in a SaaS environment with clients distributed over a WAN a big, big plus.
Oh, I don't comment more often than I do ... that was just such an obvious straight line lead-in that I had to take notice.
> yes, Greg, I know you also advocate Sonic and little or no AppServer, but for simplicity sake I want to leave that out of the discussion for the present since I think the idea needs more development and specification before we know how it fits)
It's not the product, but the architecture. I still use the AppServer, but for a different purpose. I use it to make an OpenEdge listener multi-threaded. There are three distinct advantages to using a messaging architecture over an AppServer architecture in an OpenEdge environment.
The biggest problem with WebClient is packaging; it is very easy to write ABL code which will not package correctly for WebClient, which leads to bloated installations.
Programming for a stateless AppServer is not quite as involved as programming for a messaging environment, but programming for a state-free AppServer is every bit as involved and has none of the messaging advantages.
I still use the AppServer, but for a different purpose. I use it to make an OpenEdge listener multi-threaded
Interesting. Does this imply one AppServer per listener?
Would I be right in guessing that the listener itself basically grabs the message and then fires off an asych AppServer process to do the work and goes back to listening. That sounds attractive. Mind you, a multi-threaded client would be more direct, but it gets the job done.
I would imagine this doesn't take a particularly large pool of agents per listener except for high volume, complex transaction environments.
I'm guessing that this means one licenses AppServer just like one does the DB, i.e., the same way one would if one was using the AppServer directly.
I guess with this architecture you are inherently not sending ABL objects across the bus, so one of the debates about PDS or TT between client and agent is moot. What about between the listener and the AppServer? Are you doing that with ABL objects or passing XML? And have you done any new performance testing between the two?
tamhas wrote:
I still use the AppServer, but for a different purpose. I use it to make an OpenEdge listener multi-threaded
Interesting. Does this imply one AppServer per listener?
No. There is no inherent correlation between the number of AppServers and the number of listeners. There is no specific correlation between the number of listeners and the number of distinct message types. Though, from an architectural point of view, design is done assuming each messagetype has it's own listener independent of all other listeners.
An AppServer is a set of services. Some services may require sustantially more resources than other services. The services' resource requirements determines the number of distinct AppServers. The demand for the services will determine how many agents are allocated on each AppServer and how many AppServers are started of each type.
tamhas wrote:
I still use the AppServer, but for a different purpose. I use it to make an OpenEdge listener multi-threaded
Would I be right in guessing that the listener itself basically grabs the message and then fires off an asych AppServer process to do the work and goes back to listening. That sounds attractive. Mind you, a multi-threaded client would be more direct, but it gets the job done.
That is true for a simple listener. More complex listeners are possible. If the number of events is expected to be small, a listener might handle several messages types and could, in theory, provide some routing capabilities.
Some listeners may be service providers themselves, particularly if they use a .Net component.
tamhas wrote:
I'm guessing that this means one licenses AppServer just like one does the DB, i.e., the same way one would if one was using the AppServer directly.
I assume so, but I'm not involved with licensing.
OK, perhaps I said that too quickly ... what I was referring to was the sort of AppServer per service area concept we have talked about before. Certainly, if one had multiple of the same service for load distribution, those could use a common AppServer or not depending on load and where the load was handled. And, multiple listeners I could see would have compatible enough services that they could share an AppServer. But, conceptually, there is a relationship between a listerner and its AppServer that one could move around for scalability.
So, sometime you might have the listener handle the low impact services itself, handing off to the AppServer only for the longer or heavier tasks?
Seems like one needs to take licensing into consideration when making a design.
But, I'm pretty sure that is how it would work under the current rules.
So, what is the UI technology? I know it could be anything, but what are you using?
tamhas wrote:
I still use the AppServer, but for a different purpose. I use it to make an OpenEdge listener multi-threaded
I guess with this architecture you are inherently not sending ABL objects across the bus, so one of the debates about PDS or TT between client and agent is moot. What about between the listener and the AppServer? Are you doing that with ABL objects or passing XML? And have you done any new performance testing between the two?
A prodataset may only be passed through a synchronous procedure call. In those instances where the message is a prodataset, the prodataset is converted to xml at the source (write-xml), sent to the listener and (typically) routed to the AppServer as a longchar where it is transformed (read-xml) and processed.
It is not always true that the ds / tt format used at the server is the same as that used at the client. The decision as to who gets/sends which format is normally made on a messagetype by messagetype basis. Some messages normally only go to one client, typically that client does the transformation. Some messages are sent to many clients, typically those messages are transformed at the server.
tamhas wrote:
Seems like one needs to take licensing into consideration when making a design.
That's the intreresting part about a messaging based architecture. If I was told tomorrow that I can't use AppServers, I could be out of them in very short order. I replace the AppServers with additional listerers and move the AppServer functionality into the listener.
If I was told I couldn't use Sonic, I could drop in FUSE, or XMPP, etc in short order. No fuss, no muss. It might not perform as well, but that's not the fault of the architecture. While it's not always true that more money buys more performance, it is usually true.
tamhas wrote:
OK, perhaps I said that too quickly ... what I was referring to was the sort of AppServer per service area concept we have talked about before. Certainly, if one had multiple of the same service for load distribution, those could use a common AppServer or not depending on load and where the load was handled. And, multiple listeners I could see would have compatible enough services that they could share an AppServer. But, conceptually, there is a relationship between a listerner and its AppServer that one could move around for scalability.
Or, perhaps more technically correct, there is correlation between the messagetype, the message listener, and the message processing (typically on the appserver) which, for design and architectural view purposes can be looked at as 1-1 (1-1-1?).
Another way of thinking about it is that a message messageHandler; a message needs a message handler, a message handler needs a message. The listener, the messagetype designation, the appserver, the appserver processes and procedures are all implementation details meant to exploit the OE10 framework to its fullest without breaking it or becoming irrevocably bound to it.
Yes. Years ago, when I first started looking at this architecture, I considered using only the listeners, and having them do all the work. However, the architecture uses a one-way message flow, a messagehandler never sends a reply, only a new new message. Since data is never returned, there is no need for a callback procedure, no need for the listener to keep track of which messages come from where or where they went or what they're doing. Fire and forget. As implemented, an appserver will typically never return data to the process which called it, it will instead post the message forward to a listener, which may (or may not) be the endpoint for the data. This makes the asynchronous state-free appserver a threading device; each call, whether its from the same or a different listener, is an independent session.
Interesting ... seems like something that would be better done with multi-threading, but I guess one has to work with what one has.
If everything is fire and forget, how do you handle multi-part transactions? E.g., something like committing stock to an order where one needs to impact stock available to ship in inventory and order status as part of the same transaction.
Well, of course, there is that performance concern ... one clearly has to be very careful about how one slices things up.
This is all very reminiscent of the way one designed Forté apps and they had some wonderful tools for shoving around the pieces in order to address performance issues ... just change the diagram, push the button, and now it was deployed that way.
Their core messaging was a protocol whose name I have forgotten now, probably something that morphed into JMS when it grew up. Later, they had the Fusion Bus, which was essentially and ESB, but I think I was the only one proposing to build multi-part apps on top of it.
I don't understand the point you're trying to make.
In a distributed environment, one can no longer rely on a simple DB transaction enclosing all of the work, so one needs to have a mechanism to handle transactions that are going out to multiple services, but which are logically part of a single business transaction. One way to do that, if the services are reliable, is to get back a validation message and then when all have been received, go ahead, or otherwise deal with reversing messages or whatever as necessary. Another alternative is fire and forget, but that means that if a component of the larger transaction fails, one needs a message indidcating that failure and a process that knows how to back out the consequences. Etc.
I'm asking what your approach is to this class of problem.
If you have a lot of distributed transactions, I would suggest you need a full-fledged ESB. If there were a few, however, I'd designate a listener to be a transaction coordinator, have it designate itself as the endpoint for all messages, have it fire off the various partials, collect the responses, send the commitend or rejectend messages and finallly send out any commital/rejection notification to the original endpoint. The endoint, however, would typically not be waiting for the commitend/rejectend message; it would have moved on to something else, though I don't see why this wouldn't be a programmable option.
Unlike a full ESB where services are BUS services, my architecture listeners are very focused, they don't generally handle all messages. It's designed to avoid unnecessary complexity, but to be able to deal with isolated pockets of complexity in a straight forward manner. My architecture is not for every shop or every scenario. My focus is on providing an easy to use, comprehensible, working architecture for SMBs, not Fortune 2000.
If you have a lot of distributed transactions, I would suggest you need a full-fledged ESB
What aspect of an ESB makes a difference with distributed transactions?
Here's another voice to add to the babble. We too are using the WebClient plus GUI for .NET in our Semi-disconnected PoS, a brand new project. It gives us an up to date UI that is easy to sell to (most) customers, but enables us to continue using our existing skills for the development of the business logic, enables us to reuse well-structured business logic from our legacy PoS application where appropriate and satisfies the customer's requirement for easy deployment. Like Gregg, we are also using Sonic messaging but for a different purpose, namely to allow the PoS to be "semi-disconnected".