Slashdot Mirror

← Back to Stories (view on slashdot.org)

San Mehat On Web Services & .Net

Posted by Hemos on from the looking-down-the-road dept.

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.

6 of 220 comments (clear)

  1. Re:Make .NET Open Source by RiverTonic · · Score: 5, Informative

    Mono is an open source implementation of .Net Development Framework.
    You can find it here

    --
    This is RiverTonic's sig.
  2. Re:My problem with .NET by Frostalicious · · Score: 5, Informative

    Every time I build it's basically 50/50 whether or not the compiler is going to start throwing spurrious exceptions.

    You must have a corrupt install. I've been working professionally with VB.Net for about 2 years now and have never had a compile go bad, except when it was my fault.

    The rest of the IDE, on the other hand, is about as stable as a crack ho. My favorite is when it opens up project files for me automatically and randomly, just because it decided to. Source safe integration is also a joke.

  3. He seems to be confused as to what SOAP is by Anonymous Coward · · Score: 4, Informative

    SOAP has several parts and he seems to be confusing them. Most all of the major vendors are using Schema (another W3 standard) for types and SOAP for enveloping but not encoding.

    SOAP encoding is recognized as incompatible and limiting which is why .Net does not use it by default but rather uses SOAP enveloping with Literal encoding.

  4. SOAP doesn't do much, but watch it scale by c64cryptoboy · · Score: 5, Informative
    Then there's SOAP. SOAP allows you to do a lot, but also gives you just enough rope to hang yourself. The W3C guys have generated a very, very primitive transport. You get primitive data types: ints, bools, strings, arrays, arrays of arrays. That's about it. As a result, different implementations of SOAP are not always compatible. For example, there was a problem with datestamps. Some SOAP implementations did them one way, some did them another way.

    While Mr. Mehat states this as a criticism, I going to come out saying that this is a strength. SOAP is very light weight considering its alternatives. In-so-far as you can serialize objects to W3C Schema primitive types, you can avoid the difficulties of complex marshaling one incurs with other distribute service mechanisms (the stubs/skeletons of CORBA, etc.). The W3C Schema types are a quick and easy standard that are independent of choice of language, operating system, environment, etc.

    --
    I put the 'fun' in fundamentalism
  5. And for those of us who despise VS.NET... by CrazyJ020 · · Score: 4, Informative
    Tools like Apache Axis and Visual Studio .NET help you with this, because they have these WSDL tools that look at your classes, look at your exposed interfaces, and attempt to generate a WSDL file that can be consumed. With Visual Studio .NET, it's incredibly easy. You add a web reference, aim the web reference at the WSDL, and it creates stub classes for you automatically.
    It is even easier with the free .NET SDK :
    C:\work>wsdl /nologo http://www.xignite.com/xretirement.asmx?WSDL
    Writ ing file 'C:\work\XigniteRetirement.cs'.

    C:\work>
    And also... My fellow Java developer and myself have had zero problems exchanging complex types over web services. There is no problem with XML/SOAP. The problem lies in immature proxy generators. WebSphere Studio Application Developer and the .NET SDK proxy generator have no problems creating compatible complex types, including collections.
  6. overcoming datastructure hurdles... by freejamesbrown · · Score: 4, Informative

    in my experience... if you wanna pass more complex datastructures over webservices, you send objects encoded as xml strings... then decode the xml into the native structures you want.

    sure, it's work, but so it goes.

    that's how we've gotten around a lack of standardization of higher level objects.

    i've been writing a set of java services to serve as a linux option to some .NET services already in place. the hardest stuff i've had to tackle in the interoperability between java and .NET is getting into the soap headers... and then just getting commonality between encryption classes etc. lot's of hurdles and non-overlapping block styles and things. drive me crazy!

    gosh, and then how some of those wsdl and stub generator tools in java land have changed and produce different code. shoot me now!
    m.