Web Service Mod for Apache

Michael writes "In the article "Will Open Source Lose the Battle for the Web?" a lot of people wondered what role Apache will play in a future that might be dominated by .Net. The company for which I work created a mod for Apache called NetHesive that converts a standalone library or application into a web service. NetHesive provides a wire format that's cleaner than SOAP and allows expert conversion between native data and the public interface. Most importantly, it supports SOAP 1.2 along with custom XML procedure calls. We're not sure we ever want to develop for .Net but we want to leave that possibility open. We thought other developers might feel the same way, so we created a method for deploying a web service that doesn't lock us out of any future frameworks. We're curious about Apache fans' reactions to NetHesive. Does this answer some of your concerns about Apache's future?"

Comments

Portability

[Anonymous Coward]

Does it run on Windows .NET?

aka

Windows 2002 Server

Waiting for evaluation

[dbuttric]

I am excited about this. Is it going to use the Apache license, or will it be a binary module, that I have to license from you?

Re:Waiting for evaluation

[NetHesiveMike]

We're not sure which distribution method we are going to use. We'd love your input: tell us what you think!

I don't get it

[Ian Bicking]

I looked at a little demo y'all put up, and I'm way underimpressed. This configuration file is supposed to make my life easier? I mean, for something on the level of "hello world" that takes a hell of a lot of typing.

Maybe I'm missing the point when it comes to SOAP and all that -- but I've yet to see a really good description of why the hell I (as a web developer) should really care. It's not like I can't communicate over the net already. This makes the communication a bit more robust, perhaps... or maybe more easily integrated. But you can put a wrapper around all the various protocols you need and get the same thing. And you can do that now, with systems that are set up now, everywhere. That's why we use real programming languages and not XML.

The website also seems to imply that NetHesive will be closed source. In other words, I care as much about it as I do about web-enabled COBOL environments. If you can get people to use it and buy it, fine. But you aren't saving anyone. You won't be part of any revolution -- there are already more than enough niche commercial web products around. Hell, there's more than enough niche OSS web products around... but they usually whither and die more quickly, leaving the space more clean.

If there's a salvation for OSS, it's in the fact that people who actually get things done will still be doing things. Hell, if 44% of attempts to purchase online failed, I don't think web services are where attention needs to be focused. A good website/service is not a commodity yet, and most of the problems aren't things SOAP/.NET/NetHesive address.

Re:I don't get it

[NetHesiveMike]

Most of your comments are accurate, but I do think you missed one point. The developer who uses the release version of NetHesive will not need to write the configuration file by hand. We have some nice tools coming online to do that for you. Does that make your life easier? =)

The question about licensing is also a very good one. We recognize that OSS is changing the world in many significant ways. Contrary to the assumptions in one of the posts here, the web site does not specifically state whether NetHesive will be open or closed source. We're still debating which way to go. Why don't you share your thoughts in our survey?
Click here to participate!

We're listening and want your input. Tell us how we can maintain an open source product, control quality and keep paying our developers! (And yes, we've read the many many posts about that exact topic on Slashdot. Consider our ongoing debate an indicator of how well those posts answered this question.)

Re:I don't get it

[Ian Bicking]

Well, I just don't see what I can do with NetHesive that I can't do with my current tools -- and I don't think NetHesive looks like it will be any easier.

I'm not going to program web applications using C or Fortran or VB. I don't need to -- Python can interact with whatever legacy code that's around just fine, and if there's something that needs to be in C, I'll program a module for Python, not for the web at large.

I'm sure NetHesive could speed up development in languages like C, C++, and VB. But you can do this stuff pretty easily in Python already. Perl probably has this stuff already, and PHP will eventually -- PHP has a pretty messy foundation, but if the incentive is there it'll happen. I bet even funny little languages like Pike and Erlang could get onboard. If this XML/SOAPish interaction is so great, there's no reason it can't be duplicated N times for N languages. If it's a meaningful standard then duplication isn't harmful.

Maybe the problem is component-think. We don't need components in an OSS world. We don't need blackbox objects with certain particular interfaces. When the source is available and freely copiable in part or in whole, you are free to make the interface as good as possible. And because people share things so freely, even if it isn't as easy as it might be to create that nice interface/abstraction, collectively it will still get done.

So, no, I still don't get it. I haven't seen the detailed example that I can believe that justifies Web Services. There's always a really fuzzy part, like "the original service finds a complementary service"... uh, sure. That's a big, gaping whole to paper over. How are real people actually going to use this stuff? Without that justification, I'll stick with quality incremental improvements. I'll leave the next-best-thing-since-Push technology to others.

Re:I don't get it

[NetHesiveMike]

We're Python fans too. Python is a great language and makes sense in many applications. At the same time it does not make sense for every developer in every project. We believe that many people will find NetHesive to be an easy and effective way of moving their applications onto their intranet or onto the web.

NetHesive is not necessarily part of the component-think that you reject so thoroughly. It is a way to communicate with a new or existing application over HTTP. We provide the functionality to *allow* developers to connect their projects to component frameworks, but it is not required in any sense.

Your disdain for components and web services is certainly justifiable for your work environment and your projects. NetHesive encourages flexibility by providing XML-over-HTTP functionality without locking the developer into any particular framework.

Perhaps you will better "get it" once we have our tools available online. It might be difficult for some people to understand how NetHesive simplifies development without seeing screenshots and other demonstrations.

As people interested in the way our product relates to the rest of the development world, we posted the /. article somewhat early in the release process. Your feedback has been extremely valuable; we look forward to introducing the release version of NetHesive in the coming months.

Apache already plays well with SOAP

[Paul Bain]

[A] lot of people wondered what role Apache will play in a future that might be dominated by .Net.

Not I, because I am aware that the Apache Software Foundation has been working on SOAP for sometime. Besides, Microsoft cannot dominate the future because, in the future, interoperability between systems will require open standards and open protocols that are not determined by a single corporation or business interest.

Does this answer some of your concerns about Apache's future?

Not at all. I am not concerned about Apache's future. I know that it will continue to thrive. Apache 2.0 has been in beta since March and will probably soon be released. Other Apache projects also kick butt, e.g., Tomcat 4.0, whose release is also imminent.

The NetHesive product seems primarily a savior for legacy applications, not the Apache web server.

Errr..

[Jon Peterson]

This looks likes SOAP that's been embraced and extended. Am I missing something? And why is the language support so limited? The great benefit of SOAP is that it allows and encourages language independence.

I'm not sure what the benefit of this is, beyond writing your own SOAP stuff, which doesn't seem to be that hard to me.

SOAP::Lite

[Anonymous Coward]

We've had great success using the mod_perl soap/xmlrpc extention SOAP::Lite aka. Apache::SOAP. Its called 'Lite' because its so damn easy to configure + use. Once you get into it, though, its _incredibly_ powerful.