: Re: 2. (It requires me to put out two sets of interfaces), what do you : mean by interfaces? The wsdl itself? Otherwise why different interfaces?
Yes, the WSDLs themselves. The existing separate WSDLs constitute one interface and the new merged WSDL is a second, parallel interface. It so happens that I generate my WSDLs by writing Java interface classes and running java2wsdl, so my problem really boils down to two sets of Java interfaces, but that's besides the point. : We had the same problem, and decided to have the wsdl's merged into one, : containing one service and several port(types). : We use Java2WSDL to generate the wsdl's, and after generating the first : wsdl use the --input parameter to import that for creating the second : wsdl and so on. : Then the modify the namespaces of the operations in final wsdl to allow : having methods with the same signature in different porttypes. Okay, that's interesting. I'll give that a try. : When reading this wsdl with .NET, it sees every porttype as a different : service, but puts all services/classes in one reference. This allows the : services to use the same classes. But in this case, wouldn't you have a conflict if you have operations in different services with the same signature? : Axis WSDL2Java also handles the big wsdl, and generates classes/stubs : for every porttype. : : So you can have operations with the same signature in different : porttypes, and have the same interface in one wsdl as in several wsdl's. Ah, I see. Yes, this is what I was looking for. I'll try this solution out. : I agree it is not the best to have one big wsdl, but the only way I : could find to handle properly and easily in .NET. If possible it might : be a solution to only share primitive types between services. Sadly, that's not possible... I do want some complex types to be used by multiple services. Thanks! Anand : - Arent-Jan : : -----Original Message----- : From: Anand Natrajan [mailto:[EMAIL PROTECTED] : Sent: Tuesday, June 29, 2004 7:14 PM : To: [EMAIL PROTECTED] : Subject: Re: .NET client accessing multiple Axis WSDLs : : : Re: specify the same namespace, do you mean within the WSDLs itself? I : already do specify the same namespace for the common data structure, and : it doesn't work. : : Re: specify the same namespace, do you mean within VB? Tried that, but : VB won't let you do it. It's sort of like trying to specify two : variables with the same name in the same scope - malformed. : : Re: merge all the WSDLs, yes, it is possible, and I am considering it, : but the solution is a bit unpleasant. 1. It nullifies the careful : separation I have crafted of grouping related : operations in each WSDL. : 2. It requires me to put out two sets of interfaces - one consisting of : a single merged WSDL for .NET clients, the other consisting of : multiple : WSDL files for all other clients. : 3. It requires me to resolve operation names that happen to have the : same : signature but different function in different WSDLs. : 4. Because of #3, I can't simply have the Java interface class : corresponding : to the merged WSDL inherit from the Java interfaces classes : corresponding : to the separate WSDLs. Therefore, it's up to me (and future : developers) : to ensure that the two sets of interfaces stay consistent. : : Thanks for responding though! Although your suggestion isn't ideal, it's : still the best I've got, and it made me think. (: : : Anand : : On Tue, 29 Jun 2004, Vy Ho wrote: : : : Is it possible to merge all your wsdls into a same wsdl file? Or : : specify a same namespace for all of them? : : : : : : Anand Natrajan wrote: : : : : >Hello! : : > : : >As part of my .NET and Axis interoperability work, I am facing a : piquant : : >situation. I have written multiple web services using Axis. Each of : these : : >web services defines a particular complex data structure called : Principal. : : >The definition, XML namespace and package name for this structure are : : >identical in each WSDL generated for my services. I have written : Axis-based : : >Java clients and SOAP::Lite-based Perl clients that invoke operations : from : : >multiple WSDLs within the same program. Call these clients : "cross-WSDL : : >clients" - they work perfectly, especially when I have to pass the : same : : >instance of Principal to different operations. : : > : : >Now, I'd like to write cross-WSDL .NET clients. I am using Visual : Studio : : >.NET, and using Visual Basic to write such a client. Here, I face a : : >namespace issue in the client. In order to invoke operations in a : WSDL from : : >a VB client, I have to import the WSDL as a web reference. When I do : so, : : >.NET gives the WSDL a name, somewhat similar to a package name in : Java. : : >Different WSDLs get different names. However, because of this : practice, I : : >end up with multiple definitions of Principal viz., WSDL1.Principal : and : : >WSDL2.Principal. Now, I find I cannot use a single instance of : Principal to : : >invoke operations from different WSDLs. VB's type-checking system : forces me : : >to use WSDL1.Principal when invoking operations defined in WSDL1 and : : >WSDL2.Principal when invoking operations defined in WSDL2. : : > : : >Recall, these multiple definitions are actually identical. Because of : the : : >way .NET imports and names WSDLs, I am forced to create multiple : instances : : >for the same principal and keep them consistent. How can I avoid : doing so? : : > : : >I have tried defining Principal in a common schema file and : : >importing/including it into each WSDL - that has no effect. Thinking : through : : >it, I realise that it cannot have any effect because .NET will : continue to : : >give different names to each WSDL, whether or not the WSDLs happen to : import : : >other schema files. I also tried tinkering with the namespace of : Principal, : : >to no avail. : : > : : >I have tried adding the schema file as a web reference, but that : fails : : >because .NET wants a WSDL, not an XSD file. Backing off from the : schema : : >approach, I tried casting WSDL1.Principal into a WSDL2.Principal, but : .NET : : >refused to sanction that. Is there anything else I can try? Has : anyone : : >encountered this situation before? : : > : : >Thank you for any help, and for even reading this. I will peruse this : group : : >regularly for any response, but I'd also appreciate a copy sent to : : >[EMAIL PROTECTED] : : > : : >Anand Natrajan : :
