I plan to start developing web-service client using Delphi XE. It looks like creating web-service client on delphi is easy to do.
Is there any bugs or problems when creating WebService on Delphi XE?
Is there any problems with other versions of Delphi (not XE) ?
(To create web-service i plan using WSDL-importer dialog)
Please, place Delphi version, you used to create web-service in answer.
I have created several webservice-clients in Delphi, all by using the wsdl. I have not encountered any problems so far. I have encountered some small problems, but nothin that couldn't be resolved with Google or Stackoverflow :-)
It depends. To answer your last question first, later versions of Delphi are better at generating a Web service client than earlier versions.
As for your first question. I have also created a number of Web service clients (and servers) using various versions of Delphi (most recently, Delphi 2007 and Delphi XE, though I also used Delphi 6, Delphi 7, and Delphi 2005). When the Web service methods use simple data types in its method parameters and return values (strings and integers), Delphi often does a good job of generating the client code using the WSDL importer. When complex data types are involved (objects, for example), it might be more challanging. For example, if the Web service uses complex types, and the WSDL is the only source of information about those types (you did not create the Web service, there is no documentation, or you cannot get the source code to it), it might take more work. It really depends on how complex the complex type is.
Additionally, if the Web service employs additional features such as authentication or other specialized headers, you will have to manually modify the code created by the WSDL importer. However, as birger noted, most of these issues can be resolved with research.
On the other hand, if the Web service was created in Delphi, it is usually very easy to create the Web service client.
Related
What is the reason why hitting, for example, http:///_vti_bin/UserGroup.asmx?wsdl gives me a not full wsdl specification (if compared with http://msdn.microsoft.com/en-us/library/dd965659%28v=office.12%29.aspx)?
What I mean about not full: it does not contain some of complex types definition, e.g. User (unlike the full one), so this types are no generated by the wsdl.exe.
I have a question in regard of this: is it safe to generate c# web service stub basing on specification from MSDN or this approach is dangerous due to possible changes in contract?
For your first question as to the WSDL not being the same: it really should be equivalent and contain all the types! Whenever you append /_vti_bin/UserGroup.asmx?wsdl to your site's URL, SharePoint should definitely display the FULL WSDL, including the complex type definitions, etc. I just tried it now against my own SharePoint instance and the WSDL returned from http:// mysite.com/ ...snip... /pierre/_vti_bin/UserGroup.asmx?wsdl is pretty much the same size as the one from http://msdn.microsoft.com/en-us/library/dd965659%28v=office.12%29.aspx and a quick check to make sure complex types are in both places confirm that.
To answer your second question: I think you should NOT create your Web Service stubs and skeletons based on the WSDL in the documentation. Instead use the WSDL returned from your site. If you're not getting all the complex types in the WSDL returned from SharePoint, you should fix that issue first.
First thing I would try: download SOAPui (free) and simply plugin the URL that ends with ?wsdl and create sample requests. Maybe you'll run into access issues (UAG or other) but at least you'll know that the WSDL is well formed. If SOAPui can generate the client code based on the WSDL, you can too (using wsdl2java or the wsdl2dotnet equivalent; I can't remember the name of the .net version).
And yes, it's dangerous to copy the WSDL from the docs but I'd be more worried about some things being abbreviated or documentation going stale, etc.
As for the contract changing, I'm using the UserGroup.asmx?wsdl endpoint since 2009 and it still works on newer versions of SharePoint (even after the upgrade to SP2010). And I'm using java as the client code. Microsoft really nailed the Web Services in SharePoint, it was surprisingly easy to integrate our java stack and make calls to/from the SharePoint web services. And it was also very inter-operable with the other tools we use to test Web Services like SOAPui, etc.
One of our product publishes a webservice using contract-last approach. This has becoming a real problem as all of our clients (ws clients) have to rebuild their client apps as soon as we release a new version of our product. This is due to all namespace changes that comes as a cost with auto-generated wsdls. We use Axis1 for javatowsdl. I've been seeking for a good methodology/ tool to develop backward compatible webservice for this.
i.e. version 9.3 clients can still hit the 10.0 service, of cause they will miss some of the functionality, that is fine. But they should be able to function without breaking.
I do understand the whole problem is due to our contract last approach (Pls. correct me if I'm wrong). Therefore, if the solution is to go for contract-first webservice what are the tools and technologies I could use? Also what are the best practises around contract-first?
Thanks in advance.
As you already realized, the recommendation is to use a Contract-First (or Top-Down) approach to develop Web Services. That implies a manual definition of your WSDL interface and generate a Java Skeleton of the Web Service based on this document using automatic tools.
Is important that your WSDL complies to the WS-I standart to assure interoperability between clients on different platforms. You can use SOAP-UI to test whether your WSDL is compatible with the standard or not.
For the Skeleton generation, there are several Web Service Runtime API's that you can use: Like Apache Axis and JAX-WS. I personally prefer JAX-WS because is a Java Standard and is supported by all Java EE Containers. Each container provides tools for the Skeleton generation, Weblogic has some nice Ant Task for that but there's also WS-Import that is Container neutral.
In the place I work there are some software written in C# and some written in C++ (the most important ones). Some time ago we decided it would be a good idea to track any possible problem in the software, by sending stack trace and exception information over a web service. So I came with a WCF Service, that gets the information and store them on a database and send an automatic e-mail. It worked, we had to secure it through password, it's done, but now I want our other software, the one written in C++, to use this webservice (this software is used both on windows and linux, so we can't just make a call to another software in the user machine).
I've googled about it, and found this tutorial on how to use gSOAP, which so far didn't help me very much (lots of errors, it is not very detailed, and the web.config file is impossible to read). I was wondering if is there any other way to achieve this. In adition, since I'm using authentication on my webservice, it now has a wsHttpBinding (which AFAIK isn't supported by gSOAP).
Can you guys help me out?
Since your WCF service is in C# with .NET, and the only issue is getting the C++ application to be able to talk to it, one way is to follow the advice in REST / SOAP Endpoints for a WCF service and related articles.
Your C# programs continue to have the full SOAP access to your service.
Your C++ programs could do something like this for REST access:
"Browse" to the HTTP GET URL for the service command you wanted.
Then toss (or parse and use) whatever response came back.
It is a pretty minimal change to your WCF service to offer both SOAP and REST.
The REST ability opens your service to JavaScript as well as C++ clients.
You may need to restrict the interface to simple data, or class objects that are easy to parse in C++.
Will the machines running the C++ applications have the .NET Framework installed?
Check out: Create WCF service for unmanaged C++ clients
I'm looking to a way to connect a COM+ legacy application to a WCF Service, i have been researching this since a couple of days and i haven been lucky to find any useful information, can anyone point me into the right direction on this?
I Need the old COM+ component to make calls to a new C# WCF Service so I Need some kind of proxy in the COM Component that abstracts the communication with the Service.
Thanks in advance, i really appreciate any help.
I assume you mean that you have a WCF service, and that the code that runs your WCF service needs to make calls to your legacy application and send that data in/out of the WCF service, correct? If that's the case, then the WCF facet of your question is actually irrelevant.
What you're trying to solve is how to get your .NET application to speak COM to your legacy application.
Check out: Introduction to COM Interop and COM Interop Tutorials.
You'll need to generate type libraries for your COM component, reference them and System.Runtime.InteropServices in your C# project, and then you can make your calls across into COM boundaries of your legacy application code. There are a lot of other examples and tutorials out there if you search for COM Interop Tutorial, for example.
EDIT:
I thought more about your problem. You need to implement a proxy by creating a server that "looks" just like your old server (all the same COM+ interfaces etc etc), and then forwards the request (by crafting a new request) to your WCF service. You can do this in C#. I whiteboarded (archive) the basic idea around it from your original whiteboard.
The WCF service moniker can auto-generate a COM proxy for your WCF service. Your C++ code can call this proxy directly without the need for you to write any C# proxy code or explicit COM interop code.
Look at http://msdn.microsoft.com/en-us/library/ms729739(VS.85).aspx for details.
I particularly recommend this feature primarily because I owned the feature at Microsoft.
I apologize if if this is a bonehead question.
I've used WSDL to generate code to talk to web services, but my question is about using it to actually generate web services.
Let's say that I have a device that is going to communicate with a web service. The web service in question doesn't actually exist and is out of my control. That is, the party wishing to process messages from my device must implement the service.
The service in this case is extremely basic. It's simply a small collection of methods that receive messages and return status codes. It's basically a middleman between my device and 3rd party software.
It would be really cool if I could supply something like a WSDL 2.0 document that they could then use to actually generate the boilerplate code for the service and methods they are required to implement...preferably in Java (Axis) and .NET friendly frameworks.
In other words, I want to use WSDL to generate the service, not the client. Or maybe I don't want WSDL at all. What techniques would you recommend to make this as painless as possible?
SvcUtil.exe for the Windows Communication Foundation technology in .NET 3.0+ can do some of what you're asking, i.e. generation of contract interfaces and basic client code using a predetermined WSDL as input.
Now, this will not fully generate the actual service, just the contract interface. I don't know of an easy way to do this as it is probably not a very common case. Essentially what you're asking is a slightly more automated version of what Visual Studio does when you create a class and use the "Implement interface" feature (which I believe is accomplished mostly through VS templates).