I have N quantity of "clients", and each one has to implement a web service for my .Net app to consume. I dont want to add a service reference for each client because they can change at any moment, as well as the URLs, so I store the URLs on a database and dinamycally create the endpoint depending on which client I want to access.
I was wondering if I have to force my clients to write the same type of services(either WCF or JAX-WS) or I can still connect to one or another without writing some kind of conditional logic.
ie. If JAX-WS then "do this" ELSE IF WCF "do other stuff"
Also I was wondering if adding WS-*(wshttpbinding) security would add more complexity for the interoperability(or interchangeability) of the two technologies.
Any comments about this approach would be greatly appreciated.
It's possible to implement this without having to use an if-else , all clients/implementations (.NET and Java) must to use the same contract (WSDL) which should not be a big issue.
For the WS-* this is quite easy using only .NET BUT it's hard (not impossible) to get it working from .NET to Java so I usually end up doing basicHttp using SSL with either basicauthentication (username/password) or certificates. This is a lot easier than wsHttpBinding from .NET to Java.
Like Cheeso says, start with the WSDL, i.e. create a client and service in .NET, this will give you a WSDL, then take that WSDL and use it to implement the Java clients.
Start with WSDL first. If you don't know what this means, google it.
This does not guarantee interoperability but it gets you a long way on the path.
As for adding WS-*, yes, that introduces an additional level of interop challenge.
Related
Here's my situation: I'm writing a SOAP client using WCF. I am going to invite 3rd parties to develop services that my client can consume. This is kind of backwards from the norm, I think. As the client develper, I'm creating the specification, and the server developers are following it.
When it's the other way around, and the server developer is using C#/.NET, the process would go something like:
1) Service developer creates C# interface, a service type that implements it, and a host to serve it.
2) Service developer uses its server to generate WSDL and provides it to client developer.
3) Client developer uses WSDL document to generate a proxy and uses the proxy to consume the service.
However, I'm completely at a loss as to how to do this in reverse. So far, the only thing I've been able to thing of is to do step 1 as a mock, generate the WSDL for my mock, and provide it to the service developer. I'd prefer not to have to go through the work of doing this. Plus, I'm not sure how feasible it is for the service developer to generate a service based on a a WSDL document, especially since the service developers would probably not be using .NET. They could be using any number of SOAP frameworks and languages. I'm afraid that their service implementations would end up differing enough that my client application wouldn't be compatible with all of them at the same time.
I want this to be as easy as possible for the service developers, to encourage them to write them, but I want to have a single client, without having to modify my client code for each server.
I'm not really familiar with SOAP frameworks, other than WCF, so I don't really know how much is the same/different from WCF implementation.
Ideally, I'd like to just provide them with the C# interfaces, or run them through some tool that would generate information that they can use to implement their services in their language/framework of choice, and perfectly implement my specification.
What would be the best way to accomplish this?
What is the most current (.NET 4) way to send a raw XML request to a web service? Does it differ between asmx and wcf services?
I want to build XML via a front-end interface and have the ability to send it to different endpoints. These endpoints could be asmx or wcf. What is the best approach to get started doing this?
I think we mean the same thing; I usually prefer not just to send XML but to work with objects and let the WCF engine to decide in what format itll pass it to the service/client (which might depend on the protocls you and your service providers support). In the terms of WCF, it means defining classes as Data Contracts, and working with their instances only, and not the XML they might represent.
If the other side supports ASMX only, it limits the supported protocols WCF can use to work against to WS-I Basic Profile 1.1 (if Im not mistaken with this), but whatever technology You choose/work against, the concept, in my opinion, should remain the same: in .NET work with classes, and let the underlying communication technology to decide how to serialize and pass it to the other side. Of course, its also more secure than just to send raw string as xml (though you can probably solve some of the security issues by validating against a schema the received xml)
Can I write a web service that implements the same methods and returns the same custom objects using both C#/WCF and also Java Web Services? And if so, can I then access the web services using a single web reference but with different addresses?
I'm asking because I have to host a web service that has a GetCitations and GetTerms method for publically exposing our database content. We are on IIS, so I was going to do it with WCF. However, other partners in the project also have to host an equivalent service and they are all Java based.
We are then building a software app that needs to connect to any number of these services (as defined at runtime by a user). I am expecting that we can have one set of classes to connect to these services (but with different endpoitn addresses), but am not sure whether I'm right in expecting this to work.
Is this possible?
And what considerations/restrictions are there?
Thanks.
It shouldn't be a problem, if you make sure that both services have equivalent wsdl files and you use http/soap binding.
I am not sure about using the binary (net.tcp) one with WCF, though. It might be a problem.
One way to do it is to use JAX-WS (Java 6) to expose a method as a web service.
The JAX-WS stack allows for automatically generating the correct WSDL at runtime.
The .NET team can then take that WSDL, and use standard tools to create a mock implementation of that WSDL. This mock implementation is then used as the actual .NET implementation, and you then use standard tools to generate the WSDL for that web service.
You now have to web services with the same semantics each with their own WSDL.
Both Java and .NET can implement a SOAP compliant web service, so the answer is yes, you can write a .NET and a Java webservice that implement the same WSDL.
I am new to RESTful web services. We are taking the REST route for building our public web services to be consumed by out clients.And i had a few questions.
Are there any kind of limitation with pure REST webs services? and if yes then would a hybrid REST web service take care of those limitations?
I am thinking about using SSL + Hash Message Authentication Code (HMAC) in Authorization header for security along with IP based based filtering. what do you guys think about it?
Are there any good client side tools for testing?
Currently i am using the following
http://code.google.com/p/rest-client/
And what about some kind of client side code generation tool?
The following links are my source of info.
http://msdn.microsoft.com/en-us/library/dd203052.aspx
Link
The first thing to keep in mind is that a REST service should be stateless, which is very different when compared to a SOAP/RPC type of service interface. Using REST methodology requires you to rethink how you want your clients to interact with the service, breaking down the interactions into clear and concise method calls.
REST
+ Lightweight messages, very little overhead (other than the XML itself)
+ Easily readable results, can easily test with a web browser
+ Easy to implement
- Looser interface, loose type checking
SOAP
+ More rigid, with a strict contract definition
+ Plenty of development tools available.
Looking through the WCF MSDN documentation, WCF SOAP support was integrated from the start while REST support is a recently added feature. I myself am having a hard time finding documentation for authentication/security for REST services, as most of the documentation is directed towards SOAP.
Client side generation tools: I haven't come across any for REST services as REST doesn't define a service contract as SOAP does. WADL is an attempt to do that for REST services.
http://en.wikipedia.org/wiki/Web_Application_Description_Language
http://wadl.codeplex.com/
I'm interesting in reading more responses dealing with authentication and security, as I'm looking into that myself.
This is a good starting point of a WCF REST WebService:
REST / SOAP endpoints for a WCF service
(BTW: Stackoverflow has nice REST kind of urls.)
You can test a REST service with just a web browser (Go to the url and get the XML or JSON). Fiddler is also good tool, and FireBug-plugin for FireFox. I usually make a thin service-interface project and a separate (unit-tested) logics-project.
For authentication I would first generate a Guid and a timestamp. Then based on those a hash (.NET supports SHA256 and SHA512). The Guid can be stored to server (database table) to map it some concrete numerical id. Then you can have a rest url like:
/myobject/1?timestamp=20100802201000&hash=4DR7HGJPRE54Y
and just disable the hash & timestamp check in development environment (e.g. with AOP). With timestamp I would check that the stamp is between 15 minutes back and forward in time (=should be enough to prevent attacks).
Will your service be visible to the public/internet and is your client a jQuery or Silverlight -client? Then you still have a problem: You don't want to include a secret key in the client software code.
So you need to generate hash in server and some kind of cookie to store the client session. (This can be done e.g. with a separate login-page/application in a folder with different config-file.) I remember that this book did have something on the topic:
If you want to enable the HttpContext when using WCF, you need to set <serviceHostingEnvironment aspNetCompatibilityEnabled="true"> under <system.serviceModel>.
Then you can check current user identity from HttpContext.Current.User.Identity.Name.
However, if you want to make a pure REST service then you don't use cookies, but a HTTP Basic Authentication coupled with SSL/TLS for each call.
I think that it's easy to make a client with just LINQ2Xml or jQuery so maybe client generation is not needed.
Or you can also have both, a SOAP and a REST interface, and use a service reference to make a client.
One thing to keep in mind is that you can take REST as a philosophy (everything should be reachable by a clean URL, without hidden strings attached) or as a dogma (you have to use PUT and DELETE even if that means a lot of hardship down the line).
The emphasis is on simplification - like using simple data types for params instead of stuctured pileups, nor clobering interface for superfluous reasons (like towing giant page "title" in a url), not using headers which are not well known and de-facto standard.
So, you can design perfectly RESTful interface using just GET and retain usability and testability from web browsers. You can also use any standard authentication methods or several of them for redundancy depending on your actual target audience. If you are making an app to run on a corpnet with standardized credentials and tokens you can continue using that. If you are doing something for very general access you can use combination of GET args and/or cookies - keeps your URL-s clean for 99.99% of users.
You can even serve both JSON and XML (like Google maps for example) and still be RESTfull, but you can't do full scale SOAP (complex input types etc). You can do limited SOAP - simple types for requests, always expressible as GET args, people still get WSDL for documentation.
Hope this paints flexible enough picture - the way of thinking above any strict dogma.
Ok, all these methods of getting data in a Silverlight control are confusing me.
I've looked at ADO.Net Data Services, Web Service and Silverlight-enabled WCF services.
I'm just not sure when one is appropriate to use over another. What pros/cons do each offer?
I've built a web app, and a Silverlight control. I will be adding one of those 3 options to my web application and consuming it from my Silverlight component.
From the silverlight perspective, WCF is heavily constrained anyway, so most of the usual benefits of WCF don't apply. However, it is still a fairly nice, consistent programming model.
WCF is primarily a SOAP stack, so it is very good at presenting data as rigid operations. ADO.NET Data Services is a REST stack, and allows very expressive queries to be performed dynamically over the wire.
I don't know how it is in Silverlight, but a regular ADO.NET Data Services proxy (the bit on your client app) has very rich support for both query and data changes back to the server. Note that applying changes requires either a: Entity Framework, or b: lots of work. But you should get query and update very cheaply with this approach.
With WCF, you get a much more controlled stack, so you will need to code all the distinct operations you want to be able to do. But this also means you have a known attack surface etc; it is much harder to exploit a locked down API like a fixed SOAP endpoint.
Re regular web-services (pre-WCF): only go down that route if you want to support very specific legacy callers.
I know this is old, but I just wanted to add my 2 cents.
I would highly recommend using WCF; and use the WCF Service Library project over the Silverlight-enabled web service. They are both essentially the same, but the Silverlight-enabled web service changes the binding to basic instead of ws*. It also adds an asp.net compatibility mode attribute.
WCF is usually faster: See "A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies" # http://msdn.microsoft.com/en-us/library/bb310550.aspx
WCF encapsulates asmx, wse, msmq, enterprise services, and remoting.
WCF services can be included and run within iis, windows forms, etc.
WCF isn't restricted to using HTTP, but with minimal configuration can also use tcp, named pipes etc.
complex data types are easier to expose and serialize.
WCF just scales really well. Plus, they can be used to incorporate workflows from WF.
There's probably not a wrong technology to use, but it seems as if Microsoft is going to be moving forward with WCF. Plus, it's just so much easier to write one code base that can be exposed so many different ways with just a few configuration changes to the WCF service.
I recommend not using the Silverlight-enabled web service, just because the programming structure is set up a little better with the WCF model, but this is probably a matter of opinion.
If you have to choose between a web service and a WCF service, my advice is to go with WCF. It's more modern and more powerful technology. As for ADO.Net Data Services - you can use that if all you need is to retrieve/commit some data from/to a database back on the server.