Slashdot Mirror

← Back to Stories (view on slashdot.org)

Apache Axis C++ v1.0 (Alpha) Released

Posted by timothy on from the kitchen-sink-and-shower dept.

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

24 comments

  1. Add CORBA and you've fufilled SOAPs single purpose by GOD_ALMIGHTY · · Score: 4, Insightful

    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
  2. Xerces? by Euphonious+Coward · · Score: 2, Insightful

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

    1. Re:Xerces? by steve_l · · Score: 1

      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.

  3. Re:Add CORBA and you've fufilled SOAPs single purp by musikit · · Score: 0

    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.

  4. Hmm... by Anonymous Coward · · Score: 0

    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?

    1. Re:Hmm... by Anonymous Coward · · Score: 0

      dont be an idiot. C++ has waay less capability and is waay slower to write code for than Java.
      Java gives you : slow, portable code with easily defined business logic and clear design, even if youre an idiot and is fine for 100% of all programmers even if theyre idiots.

      C++ gives you : really fast, semi portable code with hacked on object support which can dissolve into a huge mess if youre an idiot, but otherwise is fine for the 10% of programmers who arent idiots.

      For idiots, crunching out code and debugging it is 400% faster than if those idiots were using C++.

    2. Re:Hmm... by Paladine97 · · Score: 1

      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++???

    3. Re:Hmm... by Anonymous Coward · · Score: 0

      Rubbish, as an experienced C++ coder, I don't make the sort of silly mistakes that Java was created to prevent.

      I'll repweat the question - is there any feasible way of implementing typical J2EE projects in C++ instead of Java?

    4. Re:Hmm... by thufir · · Score: 2, Insightful

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

    5. Re:Hmm... by Anonymous Coward · · Score: 0

      I just seem to have an aversion to Java - maybe it's the old hardcore macho-ness of me preferring C/C++, but I'd rather be coding a real machine...

    6. Re:Hmm... by Anonymous Coward · · Score: 0

      Use CCM. CCM is Corba Component Model. It's J2EE for other langaugages. That will give you EJB type functionality and JMS. It doesn't address any web related tech.

    7. Re:Hmm... by piobair · · Score: 4, Interesting

      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.
    8. Re:Hmm... by js290 · · Score: 1

      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.

      --
      "Tempers are wearing thin. Let's just hope some robot doesn't kill everybody." --Bender
    9. Re:Hmm... by steve_l · · Score: 1

      '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++.

    10. Re:Hmm... by joss · · Score: 1

      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.

      --
      http://rareformnewmedia.com/
  5. Re:Add CORBA and you've fufilled SOAPs single purp by Anonymous Coward · · Score: 0

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

  6. Re:Add CORBA and you've fufilled SOAPs single purp by Anonymous Coward · · Score: 0

    So, this COBRA, its a kind of Jave?

  7. Re:Add CORBA and you've fufilled SOAPs single purp by PopCulture · · Score: 1

    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
  8. Re:Apache is dying by Anonymous Coward · · Score: 0

    What is the point of that thing? Apache is still alive and as strong as ever.

  9. YHBT YHL HAND by Anonymous Coward · · Score: 0

    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.

  10. Re:Add CORBA and you've fufilled SOAPs single purp by dwsauder · · Score: 3, Informative
    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 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.