Re: Walk a mile in their thongs (Oz footware - if some find the imagery disturbing :-)
- From: "Richard Maher" <maher_rj@xxxxxxxxxxxxxxxxxx>
- Date: Mon, 17 Dec 2007 06:59:40 +0800
Hi Jan-Erik,
Now, say that :
1. There is a server having an SOAP API/interface
out there on the net somewere. It's not your
server and you have no control over it att all.
The only thing you have is the WSDL definition.
2. You'd like your VMS server to act as a client
against that API.
Now tell me, is Tier3 usable here ?
No, your point is valid (but I've agreed with you before on this, yes?)
Tier3 can't talk SOAP, XML/RPC, Java RMI, CORBA, or Swahili either.
And if not, is there any easier tool the gSOAP
to use to run against those API's ?
I don't know, (but I'm becoming irritated enough to find out :-) What did
your sales/account-rep tell you? God-forbid that you could find out such
stuff from a HP/VMS website. Hold on, this looks like it fits the bill as
another developmental slush-fund for the IMM team: -
http://h71000.www7.hp.com/openvms/products/ips/axis2/index.html
But then Axis probably isn't what you'd describe as "easier" which may,
quite rightly, lead one to ask "Who the hell aksed for Axis to be ported to
VMS in the first place?" let alone "Why did *we* have to pay for it?". But
it's based on "Industry-Standards" Jan-Erik, and that's the main thing! I
guess no one at HP cares what you *are* doing, it's what Gartner tells them
you *should* be doing that's important.
So you don't want to have to run ODS-5 volumes, or configure a JVM(s), a
garbage-collector(s), and all the associated bloatware that goes with it?
Sounds pretty reasonable to me! (Especially, if you don't have and need nor
desire to develop Java apps on your VMS boxes or implement one of the "many"
ISV Java apps for VMS)
I am not without sympathy for your plight. In fact, I believe you to be in
the vast majority of existing VMS customers that are still with us today.
Which makes me curious as to how you feel about the ROI opportunities from
the JBOSS, Tomcat, WSIT and Axis endevours?
I've no idea why you're mixing up gSOAP with the old
tools Rally, Forté, Bridgeworks and other,
Too old for you eh? How about WSIT (Waste of Substantial Investment in
Technology), is that contemporaneous enough for you? The first
production quality "customer release"? (Now with u-beaut Axis integration)
My point, if you're interested in it at all, is that the Web, and
Application
Middleware Requirements in general, were not invented today, yet for well
over a decade DEC/Compaq/HP-VMS middle-management appears to have done
nothing more than squander billions on failed project, after debacle, after
self-indulgent orgy of misappropriation. If HP/VMS continues to give
succour, overtly or otherwise, to gSOAP then how can cutomers have any faith
in the longevity of WSIT and Axis on VMS? (Or their commitment to Java/VMS
for that matter!)
If gSOAP on VMS were to be restricted to client-only then maybe it'd go
somewhere toward allaying customer fears that they were going to end up like
Bridgeworks users. (But then I'd still rather see it incorporated in some
RTL. LIB$ maybe?) Sadly, the IMM team will not stop at client-only
functionality and need a five year plan to take them through to retirement
and more importantly, provide a distraction from the pending WSIT
"deliverable". To this end HP employees with HP funding are today, and have
been for some time, actively persuing the VMS customer base for gSOAP
guinea-pigs. If they can get that critical-mass up before we all realize our
wallets are missing then WSIT, like BridgeWorks, will be a mere memory and
who'll really care?
It's not just the gazillions thrown down the toilet on crap products that
upsets me (although that's certainly enough) it's the opportunity-cost to
VMS itself and to the other, more worthy, fee generating, products that
truly demoralizes me. Not to mention the decade of customer-attrition
due to unrequited love and the inability to integrate with their
web-facing infrastructure :-(
besides
of that you don't know what you're talking about.
That's as maybe, but you definitely don't know what I'm talking about :-)
From your requirements above, you plan to utilize less than 5% of gSOAPfunctionality and are willing to turn your back on what happens with the
other 95% as long as they make the trains run on time. You seem quite happy
for HP to continue to fund a replacement product for WSIT, which in turn
was the replacement product for BridgeWorks as long as you get a SOAP client
that is Java-free? So, apart from the client call and the WSDL generation,
which of the following do you forsee a need for: -
- The gSOAP Web services development toolkit offers an XML to C/C++ language
binding to ease the development of SOAP/XML Web services in C and C/C++.
- Includes stand-alone HTTP/1.1 and HTTPS secure Web Server.
- gSOAP's memory management uses garbage collection so (deserialized) data
can be cleaned up without a hassle.
- Client and server (HTTP Web server and SOAP/XML engine included)
- Offers Apache_mod, IIS, WinInet, CGI, and FastCGI interfaces.
- Architecture features:
integrated memory management with automatic leak detection in debug mode
compiler-based XML serialization of native C and C++ data structures
custom serializers and DOM support
plug-ins for extensions (message logging, statistics, etc.)
- The toolkit automatically serializes pointer-based data structure graphs,
including cyclic graphs and pointers to derived class instances to support
polymorphism.
.. . . and how much, if anything, are you willing to pay for the privilege or
the support?
Me? I've wanted IPsec support in VMS's own TCP/IP services but that's been
dragging on for years due to lack of resources :-( I wonder where all the
money and manpower are going? Others may want an up to date Java 6 on VMS,
or how about a PL/I compiler? But it appears that only the IMM cronies can
get entire teams of erstwhile idle HP employees seconded to them.
Let me spell it out (again), those same incompetent, self-serving,
trough-snouting charlatans that extorted the VMS license-payers dollars
for years to "deliver" BridgeWorks and WSIT, are once again employing
slight-of-hand in order to come up with plan-17 to solve your middleware
requirements. gSOAP *is* their idea of a replacement arse-saving parachute
for not being able to *give* their software-fruits away, and you're buying
into it :-(
[I'm sure I haven't offended any of them as they're usually off-pisting it
in Colorado this time of year with their new skidoos, and have never
given a Monkey's about what customers thought anyway.]
I do agree on one point, it would have been better
if gSOAP would have been part of the official
"WEB Services" offerings from HP for OpenVMS.
Who are you agreeing with? I think you'll find that for many, SOAP
compatibility within VMS will be about as relevant as POSIX compliance,
while for others it is some sleeping giant that has been snoring away for 10
years and has now become a essential business requirement. Either way, I
strongly doubt that VMS needs half a dozen seperate implementations, do you?
If gSOAP is *so* important to VMS then I'm sure market forces will play
their part and, at the next HP fat-trimming, the newly liberated ex-HP
employees will be able to form a startup company that will make a fortune
from supporting gSOAP/VMS. I wish them well. But if HP insists on throwing
more VMS license dollars on this (or whatever their gSOAP replacement will
be) then I demand that they at least recruit some engineers from the market
that haven't been screwing VMS middleware over for the last 15 years. Surely
a troupe of trained gibbons couldn't do any worse? Just as long as not one
cent more goes into the pockets of those incapable of finding employment
outside of the sheltered-workshop that is VMS middleware!
Regards Richard Maher
PS. I miss Munich! Every 20mins they're just there. Though not as much fun
as South West Trains' seemingly random forays into London :-)
PPS. Why are there still so many pointers on the HP/VMS website to products
that no longer exist or are supported? Bridgeworks, ACMSxp, SOAP Toolkit,
etc, etc, If it was to build up the volume of software available then it
certainly has the reverse affect if you follow the links :-(
I take it WebLogic is also no longer available for VMS then?
"Jan-Erik Söderholm" <jan-erik.soderholm@xxxxxxxxx> wrote in message
news:uc05j.1269$R_4.845@xxxxxxxxxxxxxxxxxx
Richard Maher wrote:
a lot of fun reading, as always, but...
intend to sneak gSOAP through the
back door via stealth!
Now, say that :
1. There is a server having an SOAP API/interface
out there on the net somewere. It's not your
server and you have no control over it att all.
The only thing you have is the WSDL definition.
2. You'd like your VMS server to act as a client
against that API.
Now tell me, is Tier3 usable here ?
And if not, is there any easier tool the gSOAP
to use to run against those API's ?
I'm currently using gSOAP to read from a SOAP
based API (an online auction site), and it works
just fine.
I've no idea why you're mixing up gSOAP with the old
tools Rally, Forté, Bridgeworks and other, besides
of that you don't know what you're talking about.
I do agree on one point, it would have been better
if gSOAP would have been part of the official
"WEB Services" offerings from HP for OpenVMS.
Jan-Erik.
.
- References:
- Walk a mile in their thongs
- From: Richard Maher
- Re: Walk a mile in their thongs
- From: Jan-Erik Söderholm
- Walk a mile in their thongs
- Prev by Date: Re: "snapshot" backup and HBVS
- Next by Date: Re: VMS 5.5-2 patch question
- Previous by thread: Re: Walk a mile in their thongs
- Next by thread: WANTED: PDSDUMP information from VAX 780 (c1987)
- Index(es):
Relevant Pages
|
