Would ya tie it up with wy-er. . .just to keep the show on the road? Hey true blue,. . . I'm aaasking you. . .

From: Richard Maher (maher_rj_at_hotspamnotmail.com)
Date: 11/14/05 

Date: Mon, 14 Nov 2005 17:36:41 +0800

Hi Kerry,

"Main, Kerry" <Kerry.Main@hp.com> wrote

[Lots of stuff about Web Services that I am in violent agreement with. But
you really must read up about WS-Transactions to appreciate the true horror
of what is being proposed! The one thing I will slightly disagree with you
about is .NET. Only 'cos from first hand experience in London and Perth,
there's a lot of it about. Don't know what exactly is being done with it,
just that there sure is a lot of it!]

"Main, Kerry" <Kerry.Main@hp.com> then stuck the stylus in the same old
groove and banged on relentlessly :-)

> RTR is a good solution that raises OpenVMS cluster very HA capabilities
> to software fault tolerant levels. Hence, even if a cpu dies and a
> system crashes, the RTR middleware ensures the committed transaction is
> re-tried on another system to ensure it gets completed.

Once again the keywords being "a COMMITTED transaction is RE-TRIED"! What if
the re-try can no longer succeed???

Let me tell you how it's supposed to work. A transaction simply cannot
COMMIT unless all participants (Resource managers like Rdb and SQL Server
and Transaction Managers like hotTIP and MTS/DTC) replied "Too bloody right
I can!" when they were asked if they were able to PREPARE. Now come hell or
high-water, earthquake or Tsunami, all transaction participants conspire to
preserve the ACID properties of this beautiful distributed transaction. If
the link to the coordinator is down then hotTIP and MTS/DTC will continue
attempts to re-establish communication so that the outcome of the
transaction can be resolved. In the mean time Rdb steadfastly refuses to let
anyone have access to what could well be invalid data. (As an optimization,
SQL Server has already Committed because its Transaction Manager is also the
Coordinator and it knows that everyone has voted PREPARED.)

Transactions can be resolved manually or heuristically in isolation if (even
in this HA world) communication cannot be re-established in an acceptable
time interval.

Yep, DECdtm is a brilliant product! Why don't you ever have a good word to
say about that?

Now, as we both agreed earlier, this functionality is by no means a
requirement of everyone or every application, but it should be mandatory for
a lot more of them than it is today! I'm sure there are plenty of successful
transactionless systems out there and even with transactions, different
isolation levels can aid concurrency and boost performance if business rules
allow. No one size fits all. Even fencing-wire and gaffa-tape have their
place - Just stop telling us it's a Silk Purse!

>Here is a pointer to some additional RTR info that you can review:

Yeah, and here's the address of the State Reference Library :-) Come on
Kerry, the Reader's Digest version if you please! Just show me the site that
isn't using RTR for Store-and-forward and isn't using DECdtm and I promise
to read every bit of it!

"What does the RTR part of the application do?" and "Why are they
replicating?".

Can you please also provide us with pointers to the MQSeries testimonials.
Doesn't it have a very useful store-and-forward capability? I believe
MQSeries is also used in one or two sites of note. What is it with your RTR
fettish?

Cheers Richard

PS. "The best way to replicate data is not at all." - Mark Bradley (Rdb
engineering something or other)

PPS. Looking at all those sites using RTR filled me with joy in the
knowledge of all of the lovely license dollars that come flowing back to VMS
development. What's that? It's so good a product and in such demand that you
decided to give it away for free? I'm not a business guru and I'm sure it
makes cents?

"Main, Kerry" <Kerry.Main@hp.com> wrote in message
news:FD827B33AB0D9C4E92EACEEFEE2BA2FB70CC54@tayexc19.americas.cpqcorp.net...
> -----Original Message-----
> From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]
> Sent: November 13, 2005 9:10 PM
> To: Info-VAX@Mvb.Saic.Com
> Subject: Re: Will Rich Marcello either come clean or do some
> proper marketingand
>
> Hi Kerry,
>
> > RTR has the ability to find alternate network routes to complete a
> > transaction. Hence, if one link or router went down, it will find
> > another path.
>
> OK. If that was the analogy you were making to Tandem's fault
> tolerance then
> I misunderstood.
>
> > And if they are using true 2PC,
>
> And *IF* they are using "true 2PC" then they are using
> DECdtm! Even if RTR
> sits on top of it. Let me make something clear the diffence
> between products
> such as RTR and true transaction managers such as (MTS/DTC, hotTIP and
> DECdtm) is that the later speak directly to the resource
> managers (Rdb, SQL
> Server,10g etc) whereas RTR speaks to your specific
> application code. via
> SYS$VOTEX (or whatever the name is. It's been a long time
> since I looked at
> it too :-) So for RTR to "work" correctly one must apply the
> convention of
> *only* modifying the data source with RTR-aware applications.
> (Once again,
> unless it's using DECdtm)
>
> No one's told Rdb that RTR will be replaying this txn until
> its receipt is
> acknowledged, so Rdb is quite happy to let every bloke and
> his dog rape,
> pilage and plunder the target data.
>
> > . . .and the application error handler kicks in
>
> Or, the way I personally like to see it, a combination of
> Resource Manager
> and Transaction Manager error handling kicks in to guarantee the ACID
> properties of a true two-phase commit, and preserve data integrity.
>
> > Keep in mind that many stock exchanges use this today,
>
> Whoopdidoo! And so bloody what? I'll have you know that the top 500
> companies in the world all use Post-it notes! Are you
> suggesting that their
> backup strategies involve transcribing the overnight run to
> those little
> yellow bits of paper? They probably have a lot of Excel
> spreadsheets as
> well, is that also supposed to impress me or have me shaking
> in my boots?
>
> These types of "Amazon does millions of web transactions a
> day! and then
> there's Ebay!" arguments are beneath you Kerry but, sadly,
> that's about as
> much science as we get out of Rdb and VMS conferences these
> days when it
> comes to web transactions :-(
>

Richard -

I have seen and heard all the Web Services religion discussions. Great
stuff. It will solve world hunger if only the application developers of
the world would just drop what they are doing and get on board with
either .Net or J2EE.

In some respects, this Web Services religion is not unlike the "Windows
and Linux are going to take over the world" religion. Lots of passion,
lots of religion, lots of heated arguments.

While there certainly is a place for Web Services, the problems I see
with the technology is as follows:

1. Regardless of whether you choose .Net or J2EE, both are object
oriented programming languages which means a huge, huge learning curve
for all of those Fortran, Cobol, C, Basic and yes, even Visual Basic
programmers out there. I am sure you know that VB.Net is a totally
different and totally incompatible language than VB6.

Yes, tools help, but only to a small degree as a Web Services program
implemented poorly is no different than any other program implemented
poorly - there will be major problems.

2. Security with Web Services is only now becoming acceptable for most
large corporations. The common joke around Web Services is the guy with
the label "security" on his back chasing the train that has already left
the station.

3. The benefits of Web Services sharing re-useable code is at best
theoretical as most large corporations do not work like this. There are
typically many different App development groups and the sad truth is
that they just do not talk to each other - let alone develop long term
application sharing strategies and web services code using UDDI type
technologies.

Quick question from the past - ever try and get a common data dictionary
implemented in a large company?

That is the challenge facing web services with all of its benefits of
shared library code. Great in theory and it would be wonderful if it was
done, but we both know what a pain a common data dictionary was to get
established in any company. The issues are not technical but political
and cultural ones.

4. Last, but not least, it is possible, but extremely difficult to
integrate web services code with existing code that is running the
business. This is especially true if the existing code does any type of
terminal or screen based IO.

By the way, I love the typical answer I have heard about the VB6
developer complaining about the fact that VB.Net is incompatible with
the tons of VB6 code they have in their company - "VB.Net is so easy to
use and has so much more flexibility that you would be better off to
simply re-write all that VB6 code in VB.Net."

Now, think about that and consider the previous points.

Again, I am not saying Web Services does not have a place, but there are
some real challenges facing any company embarking on this new road. One
just needs to fully understand what it is they are getting into before
they simply drink the kool-aid and jump in.

> I've never worked at a Stock Exchange but I have worked at a
> few banks and
> other prestigious financial institutions in London, and I think I know
> enough about the finance industry in general, to not hold it up as the
> bastion of best-IT-practice, any more than any other industry. As you
> alluded to in another note, it all seems to hang together
> betwen twelve and
> two and if anything goes wrong it's just tough-titties! "Tell 'em the
> figures are a day old and not to quote anything without
> checking systems a,
> b and c.". But then, the banks have managed expectations to
> such an extent
> that I can xfer GBP in one account to AUD in aother at the
> same bank and
> have it take 3 days to get there. And I just take it :-(
> Where else can you
> get away with *** like that?
>
> > so are you are
> > stating that you know something they don't?
>
> Maybe. You tell me what *exactly* they're doing with RTR and
> I'll be very
> happy to cast a critical eye over it. I for one would be
> *very* interested.
> If they have a store-and-forward or guranteed-delivery
> requirement then I'm
> sure that RTR hits the spot nicely. Or maybe BMQ, Tibco or
> MQSeries for
> portability. The right tool for the job.
>

Here is a pointer to some additional RTR info that you can review:
http://www.hp.com/products1/rtr/literature.html

> > Keep in mind that in many critical cases, you are talking
> about using
> > RTR in conjunction with a multi-site OpenVMS cluster with host based
> > volume shadowing, so the data will always be consistent
> between sites.
>
> So why do you keep singling out RTR and banging on about how
> wonderful *it*
> is.

RTR is a good solution that raises OpenVMS cluster very HA capabilities
to software fault tolerant levels. Hence, even if a cpu dies and a
system crashes, the RTR middleware ensures the committed transaction is
re-tried on another system to ensure it gets completed.

[snip...]

Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-592-4660
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)

OpenVMS - the secure, multi-site OS that just works.