San Mehat On Web Services & .Net

A reader writes: "There's an interview with San Mehat in regards to .Net & Webservices. He has some interesting comments about what will work and what won't work, and where things are going." San is well known for his Netwinder work, as well as being a good DJ. And, in the interest of full disclosure, San does work for VA Software, the parent company of OSDN, as is DevChannel.

Comments

First Post!

[Anonymous Coward]

Hi Everyone!!!!

sp

[Anonymous Coward]

SECOND POST YEAH!

Full Text

[slyxter]

A Conversation With San Mehat posted by eekim on Thursday May 29, 2003 - [ 08:00 AM GMT ] Section: Web Services : Feature Topic: Web Services

San Mehat has a long history with Linux. As a senior engineer at Corel, Mehat designed the BIOS and firmware for its Netwinder network computer, and pushed the company to adopt Linux as its operating system. Following his stint at Corel, Mehat joined VA Linux (now VA Software), and worked on the Linux kernel. Mehat recently shifted his focus to Microsoft's .NET platform, as he develops Web Services for the upcoming release of Sourceforge Enterprise Edition. Mehat shared his experiences with Web Services and .NET with Web Services DevChannel Guide Eugene Eric Kim.

DevChannel: What are you working on right now?
San Mehat: I am adding Web Services adaptors to Sourceforge Enterprise Edition (SFEE). These adaptors interface with the application server components of SFEE, creating a SOAP Web Services interface that will allow a Web Services client to consume all of the services of Sourceforge Enterprise Edition. That's step one.

Step two is writing some .NET client code to consume those Web Services -- a whole Sourceforge Enterprise Edition .NET client, whether it's pieces of a native client or adapters to other Microsoft applications like Excel, Project, Visual Studio .NET, or Outlook. .NET works very very well with DCOM and COM. It doesn't put you in a sandbox, so you can effectively go and do whatever you need to do. You can do some interesting plug-in design and cross-platform development. It's really kind of neat.

DC: How did you get involved with Web Services and .NET?
SM: After VA got out of the Linux business, I went on a sabbatical for a while, visiting friends and family. At the same time, I was watching Microsoft start its .NET initiative. These patches were coming down to my Windows XP installation, and, I was thinking, "What the hell is all this? Why am I downloading this 22 MB patch? What is this .NET framework thing?"

As I started following .NET, I thought, if they can pull it off on the Microsoft platform, that's a huge coup over the technology they had been using before -- COM, DCOM. At the same time, if they can actually get enough industry adoption over this thing -- they appeared to be pretty open about the standards -- if they could get over the psychological hump in people's minds that this was a Microsoft technology, therefore they didn't want to use it, Microsoft would be very successful. Or at least, the industry would be able to pick .NET up and run with it, very much the way that people did with Java.

DC: What is an example of a Web Service that you've exposed in SFEE?
SM: I've got a Web Service that allows you to connect to SFEE, authenticate, and get a list of projects that you're a member of. You can query for a list of bugs, get them back, and then request to drill down deeper than that. In terms of Enterprise Edition integration, this could be applied to a standalone application. You would run it, rather than using a web browser, and would get the Sourceforge interface. Or, you could integrate it with something like Outlook, so in your Outlook Today box, you get this Sourceforge Today thing. You click on it, you see all your bugs, you see what's going on, you see any changes that have been made to your projects, that kind of stuff. It would look exactly like Outlook.

DC: What are some of the challenges you've faced in developing these Web Services?
SM: In .NET, there are two main ways of doing remote procedure calls. One is called .NET Remoting, where you make a connection and you send .NET metadata over the wire. It's very tightly bound. It's similar to Java RMI. Then there's SOAP.

SOAP allows you to do