Discussions

News: Rant of sorts on multiple .Net Web references

  1. Rant of sorts on multiple .Net Web references (12 messages)

    Scott Balmos, in A Rant of Sorts on Multiple .Net Web References, admits that Visual Studio 2005 is a nice IDE, but when it comes to working with complex SOAP-based applications which have multiple endpoints and shared core, it can be a pain. Balmos discusses his experiences with the Web References system that transparently manages the annoyance of generating type stub and proxy classes from a WSDL file.
    When it comes to Web Services, more and more systems are becoming increasingly complex. Many of them offer multiple endpoints - commonly one per major sub-application - while sharing a common core endpoint for initial authentication, session management, etc. Likewise, these endpoints share a common set of core datatypes, again usually a User, Session, and other such types. But trying to use these complex endpoints with Visual Studio is a downright pain. The Web References function insists on creating separate .Net namespaces for each different endpoint, even if the WSDL files for the two endpoints share a common XSD file that defines the shared core datatypes. Consequently, .Net refuses to acknowledge that a User or Session object retrieved from the core authentication endpoint really is the same User object that is supposed to be passed as a parameter in the billing, or personnel management, or other such sub-application endpoint.

    Threaded Messages (12)

  2. bla bla[ Go to top ]

    i think this should have been posted to theserverside.net
  3. Re: bla bla[ Go to top ]

    i think this should have been posted to theserverside.net
    yes, indeed !
  4. Re: bla bla[ Go to top ]

    i think this should have been posted to theserverside.net


    yes, indeed !
    Besides that, I do not thing that it is a fault of the ide, working with Soap generally is a pain. The tools just ease it somewhat.
  5. Re: bla bla[ Go to top ]

    It´s not on the Theserverside.Net because there is a big lack of posts........
  6. In any case, the author's remark that: The Web References function insists on creating separate .Net namespaces for each different endpoint, even if the WSDL files for the two endpoints share a common XSD file that defines the shared core datatypes. Consequently, .Net refuses to acknowledge that a User or Session object retrieved from the core authentication endpoint really is the same User object that is supposed to be passed as a parameter in the billing, or personnel management, or other such sub-application endpoint. is not true. Assuming the author of the post was trying to use either ASP.NET Web Services or Windows Communication Foundation, both of these technologies have command line tools (wsdl.exe in the case of the former, and svcutil.exe in the case of the latter). Visual Studio 2005 simply invokes these tools via GUI interfaces. More importantly, the point I was trying to make was that both the wsdl.exe and the svcutil.exe tool provide options to "share" types that are common across different services. Thus you avoid type duplication by only having one set of types common across multiple services. And it is relatively trivial to have the Visual Studio IDE pass optional parameters to the wsdl.exe/svcutil.exe to avoid type duplication. -krish
  7. And it is relatively trivial to have the Visual Studio IDE pass optional parameters to the wsdl.exe/svcutil.exe to avoid type duplication.
    And why there is a need to pass parameter at all if included XSD is the same?
  8. And why there is a need to pass parameter at all if included XSD is the same?
    An IDE cannot always second guess what the developer's intention in that context is. In any case, like I said, the IDE gives you the control to change what the default behavior is. -krish
  9. An IDE cannot always second guess what the developer's intention in that context is. In any case, like I said, the IDE gives you the control to change what the default behavior is.
    I expect that IDE and software in general use "make sense" defaults and allow me to override that behavior if necessary. In this case it seems like default does not make sense.
  10. This is not a .NET community[ Go to top ]

    I don't think this post belongs on TheServerSide.com.
  11. Re: This is not a .NET community[ Go to top ]

    I don't think this post belongs on TheServerSide.com.
    Well, at least it got some posts. :)
  12. This is experience of mine. Don't know You have same? All visual helpers/wizards seems to be appealing at the beginning. Helps You do easy or average things very easy. But when it comes to something serious and really complicated (which is the case in most real projects) - all that thighs handled under covers by IDE, without Your full control becomes serious pain. It's why we always use ant as Our build tool - doesn't matter what IDE we use for development. At the end of day, project SHOULD build using ant. I'd been using VC++ 6.0 around 1997 and I have very bad experience with legacy, long maintained project built with VC. Lot's co binary configurations, problems with versioning, with synchronizations within team, and - sometimes - You just couldn't really do what You exactly wanted. No flamewar, but it's why I like Eclipse. It just helps You do core things with excellent visual support (Editor, XML, JDE) and gives You freedom to do harder Your way. Artur
  13. serious ANT[ Go to top ]

    use ant as Our build tool
    Yes, I agree. For this reason I like NetBeans because its build system is based on ANT and the best thing is that you can modify and tweak project build process as you like. In one of recent projects we decided to migrate from SJAS to JBoss, but the produced EAR could not be deployed on JBoss. It required only some minor changes like different switches for web service compilers and JBoss specific archive names (sar). Fortunately with NetBeans I just had to modify existing ANT file, instead of rewriting whole build script. Do you wonder why we had to use JBoss instead of SJAS ? Because SJAS in Linux uses too many file descriptors. And guess what... Today I installed latest Glassfish and JDK 6 to test how it works and I found that this behavior hasn't changed a bit. I started glassfish and opened admin console and, lo and behold , lsof shows more than 300 open file descriptors!