-
1. Re: Microsoft .NET interop.
Hello,
generate files yes.... did you try to get it to work? I could not inspect or use any generated complex type on the .Net side (using VB 2003) when I tried in middle March with RPC/literal. I think I used the .Net 2.1 version then.
I had to convert our RPC/literal to doc/literal to get the communication going...
Further more, I have just learned (bitterly) that exceptions is thrown only through a wrapped microsoft constructed SOAP exception on the .Net side. The "real" exception's message is located inside this "new" exception. This means that it is impossible to do a typed 'catch' on the client side! You are left with error codes in the message. Very frustrating indeed...
/Georg -
2. Re: Microsoft .NET interop.
Well, I was able to create a C# client to a basic rpc/literal service that just returned a String. No complex types, or exceptions... using .NET 2.2 and Visual C# 2005 express edition beta 2.
But I keep running into stumbling blocks... what you said about exceptions has me worried, I haven't played with that yet in .NET, so that sounds like it will also be a pain in the butt!
I already tried to sneak into my design that .NET clients would not be supported, unfortunately that didn't fly, so I have to figure out a way to support them somehow :-( -
3. Re: Microsoft .NET interop.
The documentation is out-of-date, they are supporting rpc/literal. Earlier versions used to error say that rpc/literal wasn't support. IMO though, unless you want to run beta software on the client, use doc/literal.
-Jason -
4. Re: Microsoft .NET interop.
This is the really hard decision in my case. I've read plenty of articles supporting the use of only doc/lit, some supporting use of RPC, some "wrapped"....
The way I see it, each type of service has it's place and it's pros and cons. I don't really understand why you should ALWAYS use doc/lit. My service is not document based, it is RPC based request/response, like calling an add() method. doc/lit is for document based services, rpc/lit for rpc based services. This is also how it's generally explained in documentation from Sun.
I think that for my implementation, using doc/lit adds unnecessary complexity to the interface usage and implementation, so I'd prefer to use RPC. Even MS who only supports doc/lit uses "wrapped" style to expose an RPC interface to their doc/lit service implementation!
Of course this currently conflicts with MS who currently don't support rpc/lit. However, if they will support it in future releases (which should be available by the time my product is out there), then maybe I'll use RPC after all.
Finally, I have one other concern with doc/lit: A doc/lit SOAP request doesn't contain the method name (unless it is wrapped style), so this makes it impossible to have multiple methods in your interface with the same set of parameters doesn't it? I read about this in an article, haven't tried it yet, but it makes sense. -
5. Re: Microsoft .NET interop.
You can have multiple methods in doc/literal even in unwrapped style. Basically the method corresponds to an operation on a portType, and that operation has a unique input message. So the server identifies the operation based off of the root element. The reason why document/literal is better than rpc/literal is that you can actually schema validate the message. You have to chop up an rpc/literal message and validate each portion. to gaurantee correctness. I do agree with you that rpc/literal is easier to work with on the java side, but this will change when we produce better tools.
-Jason