Slashdot Mirror
Apache Axis C++ v1.0 (Alpha) Released
BSD Forums writes "The Apache Axis team is proud to announce the release of Apache Axis C++ v1.0 (Alpha). This implementation of a C++ SOAP engine provides a stable platform for developing Web services using C/C++ as well as a client side library for developing C/C++ client applications. New features include SOAP engine with both client and server support; partial support for both SOAP 1.1 and SOAP 1.2; WSDD based deployment with dynamic deployment tools and more. Both binary and source are available at Apache mirror sites."
Seriously, slap a CORBA orb on that puppy, embed it in Apache and shuffle the stuff you need exposed via SOAP back and forth over CORBA. Let the C/C++ engine do the nasty work of serializing/deserializing XML and let the Java backend concentrate on business logic.
After you write this piece, we shouldn't ever have to write another bit of SOAP on the server end of things. SOAP requires all the understanding of distributed components while adding all the overhead of XML. Pure genius. Can someone please fill me in on why we don't use CORBA instead?
SOAP isn't any easier, it's more bandwidth and computationally expensive. CORBA has much more mature services and is proven in mission critical apps. There are a ton of Open Source and commercial ORBs for every language and platform. Why are we using SOAP? Send IIOP over TLS over port 80 if you really, really need a hole in your firewall.
Arrogance is Confidence which lacks integrity. -- me
Please tell us that it doesn't depend on Xerces-C++. That would make the whole thing useless.
Can someone please fill me in on why we don't use CORBA instead? because CORBA is a 20 year old word and XML is a 5 year old word which stands for worthless technology used to replace technology that was fast better and not broken to begin with. actually some feel that by using XML that they can be interoperable with anything out there. i can't wait for another 3-4 years to go by and what the development costs increases shown for using XML. maybe then people will back off of it.
I'm a C++ coder whoose boss needs him to go on a course to learn J2EE/JBoss for an upcoming project. The thing is, I'd much rather stick to C++ if I can - is there any feasible way of implementing typical J2EE projects in C++ instead of Java?
I don't want to start a holy war here, but what is the deal with you Apache fanatics? I've been sitting here at my freelance gig in front of a Apache box (a P4 2.4 w/1024 Megs of RAM, on an Qwest OC3) for about 20 minutes now while it attempts to copy a 17 Meg file from one directory on the hard drive to another user. 20 minutes. At home, on my Pentium Pro 200 running NT 4/IIS 4 (On a dual T1, no less!), which by all standards should be a lot slower than this Apache box, the same operation would take about 2 minutes. If that.
In addition, during this file transfer, PHP will not work. And everything else has ground to a halt. Even mod_perl is straining to keep up as I type this.
I won't bore you with the laundry list of other problems that I've encountered while working on various Apache machines, but suffice it to say there have been many, not the least of which is I've never seen a Apache box that has run faster than its Windows counterpart, despite the Apache machines faster chip architecture. My 486/66 cable modem router with 8 megs of ram runs faster than this 2400 mhz machine at times. From a productivity standpoint, I don't get how people can claim that Apache is a "superior" server.
Apache addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use a Apache over other faster, cheaper, more stable httpd daemons.
because CORBA is a bloated piece of shit that had "bloat" "manager" "groupthink" and "committee" stamped into it. OIDs are the most ridiculous "workaround" imaginable and the ugly shit should die as fast as it can be buried.
in contrast SOAP is really easy to code for, really really slow with huge bandwidth overhead and works fine. just like java. which is ok for 99.99% of us who code in the Real World(TM).
So, this COBRA, its a kind of Jave?
Netcraft confirms
IIS is a poor competitor
Get the best server OS
Get Apache
Everything will "just work"
Really, trust me!
Yet another crippling bombshell hit the beleaguered *Apache community when recently IDC confirmed that *Apache accounts for less than a fraction of 1 percent of all servers. Coming on the heels of the latest Netcraft survey which plainly states that *Apache has lost more market share, this news serves to reinforce what we've known all along. *Apache is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *Apache's future. The hand writing is on the wall: *Apache faces a bleak future. In fact there won't be any future at all for *Apache because *Apache is dying. Things are looking very bad for *Apache. As many of us are already aware, *Apache continues to lose market share. Red ink flows like a river of blood. FreeApache is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeApache developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeApache is dying.
Let's keep to the facts and look at the numbers.
OpenApache leader Theo states that there are 7000 users of OpenApache. How many users of NetApache are there? Let's see. The number of OpenApache versus NetApache posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetApache users. Apache/OS posts on Usenet are about half of the volume of NetApache posts. Therefore there are about 700 users of Apache/OS. A recent article put FreeApache at about 80 percent of the *Apache market. Therefore there are (7000+1400+700)*4 = 36400 FreeApache users. This is consistent with the number of FreeApache Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeApache went out of business and was taken over by ApacheI who sell another troubled OS. Now ApacheI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *Apache has steadily declined in market share. *Apache is very sick and its long term survival prospects are very dim. If *Apache is to survive at all it will be among OS hobbyist dabblers. *Apache continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *Apache is dead.
Fact: *Apache is dead
no, my man, COBRA was a godsend to me and most my laid off friends.
Consolidated Omnibus Budget Reconciliation Act of 1986
and slightly off topic but there are people trying to end it...
Here's to finally giving Bush his exit strategy in November
The hand writing is on the wall: *Apache faces a bleak future. In fact there won't be any future at all for *Apache because *Apache is dying.
CORBA, DCOM, Java RMI, .NET remoting, and similar technologies are tightly coupled and try to hide the network boundary. In contrast, the direction SOAP is headed is loose coupling with the network boundary explicit. This was all explained clearly in a talk from Don Box at the Microsoft PDC.
If A is a service that is used by B, C, ..., Z, tight coupling means that if A is changed, then it breaks B, C, ..., Z. SOAP, when used in a smart way, means looser coupling, so that A can be updated without breaking the dependent apps. Therefore, for services that could potentially be used by a large number of applications, loose coupling is an absolute necessity.
Hidden network boundaries mean that we don't plan to take the performance hit when a request must traverse a network boundary. With explicit network boundaries, the architect takes the performance hit into consideration. Requests that cross network boundaries have a large granularity, to lessen the performance impact of the network traversal.
Search for some of Don Box's writings on the web for a better analysis of the direction of SOAP vs. the old object-oriented RPCs.