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."

Add CORBA and you've fufilled SOAPs single purpose

[GOD_ALMIGHTY]

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.

Re:Add CORBA and you've fufilled SOAPs single purp

[PopCulture]

no, my man, COBRA was a godsend to me and most my laid off friends.

Consolidated Omnibus Budget Reconciliation Act of 1986 [dol.gov]

and slightly off topic but there are people [heritage.org] trying to end it...

Re:Add CORBA and you've fufilled SOAPs single purp

[dwsauder]

Why not CORBA?

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

Xerces?

[Euphonious Coward]

Please tell us that it doesn't depend on Xerces-C++. That would make the whole thing useless.

Re:Xerces?

[steve_l]

It certainly needs an XML (SAX) parser; I dont know what its exact dependencies are. Axis Java is primarily tested on Xerces, crimson and the oracle one is trouble.

One problem with SOAP is that it (especially doc/lit calls) depends very heavily on XML Schema rather than DTDs. As XSD is an overdesigned by committee nightmare, SOAP is very fussy about parsers.

Re:Hmm...

[Paladine97]

The first thing you state is 'don't be an idiot.' Then you go into a tyrade about how idiots need Java because they can't handle C++. So if you want the guy to not be an idiot, shouldn't he be using C++???

Re:Hmm...

[thufir]

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!).

Re:Hmm...

[js290]

From my limited experience, it appears that servlets simply wrap cgi functionality into a nice little package. Why not consider using cgicc (http://www.gnu.org/software/cgicc/cgicc.html) for C++ applications.

Re:Hmm...

[piobair]

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.

Re:Hmm...

[steve_l]

'J2EE' is a very loaded term. I would not point you near Enterprise Java Beans as despite the hype, they make little sense.

Java Servlets are simple and easy to work with; you can get started with them and JSP pages (or Velocity) pretty simply.

bite the bullet, go on, learn a bit of Java. It is easier than learning C++.

Re:Hmm...

[joss]

Well, I came from your perspective a couple of years ago and had to go down J2EE route. I wish I hadn't but then again, I may well have had greater regrets if I had stuck with C++. EJB overhead is pretty horrendous but does provide locking, persistence, transactions, concurrency, caching, DB pooling, security, clustering.

I dont think clustering would be necessary without huge overhead introduced by J2EE, but its no picnic either way.