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.
It depends on what parts of J2EE you are talking about. There are many pieces (Servlet, EJB, JDBC, JMS, etc...) that make up J2EE.
If you just need to create a webservice, then this (Axis c++) is all you need.
If you need your thing to run in an EJB or Servlet container, ie: your backend has to be J2EE, then you may be out of luck.
You might want to consider the course (if it's free!).
Like another poster said, it depends on what part of J2EE you're talking about here. In general, J2EE components rely on containers (specific to the component) which do a lot of lifting for you.
I'm unaware of any C/C++ implementation of an EJB container for instance. However with the Axis C/C++ implementation (notice I've segue'd back into the topic here), it opens up the possibility of a C/C++ client talking to a SOAP-wrapped J2EE server tier.
I used to be a pretty heavy C++ guy back in the day. I've been doing almost exclusively Java for the last (gawd!) 7 or so years. I really don't miss C++ at all. Especially the maintenance headaches induced by implementations of large domain models. The larger the model the more it seemed to spin out of control with C++. It still has a tendency to spin out of control with Java, but not to the same degree.
I could go on here, but I think I've said enough.
I have a second sig, I call it sig#2.
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.