I would like to have a Traffic COP or Controller WCF Web Service that doesn't do anything with data but instead gives orders to another WCF Web Service to do so.
Could someone give me an example of how this might be able to be done. It would be preferable that I was not getting into any APM stuff. Instead just an observer who later gets to spin another one way contract to a WCF Web Service when it needs to after it sees that there are no more other WCF Web Services with the same meta data in memory or processing currently.
If this is impossible please say so. Unless you know a small example of how it is done. Maybe a pointer where somebody has already covered the topic?
Thanks apolfj
I don't really understand your question, but maybe this will help:
MSE is a "service virtualization" approach
Stocktrader has a WCF load balancer included in it.
Maybe one of them will fit your needs.
Having a 'traffic cop' service that all traffic goes through before it gets to the actual web service for processing will add extra overhead to your solution. Then you also have issues like once you've logged a call going to a particular web service, how do you find out if the response was successful? Then you hvae to do more logging of some sort and finally return the result to the client. If I understand what you were saying correctly (which I'm not entirely sure I do) you would be looking at something like;
Client -> TrafficCop -> Service1
Client -> TrafficCop -> Service2
OR
Client -> Service1 -> TrafficCop
...depending on where you want the entry point and what you need to do.
I would probably remove the traffic cop web service entirely and implement some API's for your service to implement and have each web service log some information before a service operation is called and after the operation has completed. I'd recommend you take a look at this link; http://msdn.microsoft.com/en-us/magazine/cc163302.aspx which covers behaviours, operation invokers and paramter inspectors.
This way each web service can log information, check access, rules, report errors before and after execution to a database or another TrafficCop web service if you really want. But I'd probably be inclined to just stick all that information in its own database. Thus each web service (depending on what you're doing) may have connections to two databases. One for the web service itself (if that's needed) and one to the TrafficCop / logging database.
At a later date you then may choose to add a website that pulls all the information out of the traffic cop database and allows you to easily browse / search it. It could highlight warnings or other issues your web services logged.
Summary
If all you need to do is logging and related functionality I would consider having each web service log and / or check rules and other things before and / or after a service operation is invoked. At a later date you could consider adding an admin site that surfaces all this information so you can easily keep an eye on how your web services are performing. You may even like to log information like how long it takes to respond to certain requests.
If this is not what you are after I would suggest you add more information and continue to keep your original question up to date.
Related
I'm looking at converting an existing web service into a Web API. I've only worked with a WS a little bit and it was a long time ago. What I do remember is that in my project I would make reference to a service location and then use that reference to call whatever method I needed.
EX: I would reference http://mydomain/webservicename/mobile.asmx and then would call objWS.MethodName() what was coded within the mobile.asmx file.
If I convert over to using a Web API I would basically call the HTTP by going to something like http://mydomain/controllername/myMethod.
As of right now I don't have access to the client code to be able to change the way that it calls the service. That being said am I stuck with using a traditional web service vs web api?
This is an app on a handheld scanner that I believe is running Windows CE. We are having some connectivity issues/database deadlocks and I was asked to look at it and see if I can help out. The current WS code is overly complicated IMO since it's only doing either an insert or an update to a database. I would also think that going with a Web API would make it a faster app since it's depending on cellular access for it's communication. JSON should be a smaller payload than XML.
So, I would like to just re-write it using Web API 2 and Entity Framework. However, I'm afraid I'm stuck to using WS since I don't have access to the client code.
Any suggestions?
It's a fairly broad architectural suggestion, but what you're proposing certainly sounds possible and even quite reasonable.
If I understand correctly, you currently have this:
Client -> ASMX Service
And you can't change the Client, only the ASMX Service. The first thing you're going to want to do this ensure that server-side business logic is de-coupled from the platform technology:
Client -> ASMX Service -> Business Logic
The idea here is that any application host should be able to reasonably invoke the same business logic, even if that logic is nothing more than direct database access. The application host itself should be little more than a pass-through set of operations to be invoked.
At that point, you can create a second application host alongside the first one:
Client -> ASMX Service ----|
|-> Business Logic
WebAPI Service --|
So now you have two different services which expose the same business logic, using two different web service technologies. Each of them should be very thin, as application host technologies should always be easily replaceable.
At this point, assuming there are no significant gaps in the operations available between the two services, you can publish the new service's specifications to clients and begin plans to deprecate the old service. When you can deprecate it is more of a contractual issue than a technical issue. However long you've committed to maintaining it, that's how long clients will have a reasonable expectation to still use it.
If you really want to, you can even have the ASMX Service be a pass-through to the WebAPI Service, but in my personal experience that adds unnecessary layering to the whole setup and artificially complicates the abstraction of the business logic. Either way, the interface exposed by the ASMX Service wouldn't change.
The main thing here is the logical abstraction of the operations being exposed and the analysis of any gaps between what the ASMX Service can do and what the WebAPI Service can do. If that gets complex, then that's an indication that the business logic (and indeed the whole solution domain) is tightly coupled to the application technology being used, namely ASMX web services. That is the problem to be solved. Once solved, creating different application hosts and exposing different services which invoke the same underlying business operations becomes almost trivial.
You are right; you are stuck if you can't change the client and you want to change service protocols. Your client currently has a specific .asmx endpoint it is configured to point to and until you can update that endpoint and have the client stop using the proxy generated from the service, you can't change to Web API.
I'd still rewrite the service to use EF, though.
We are developing an mvc web application and UI will be responsive, so don’t see any future requirement with web services required for native app that will consume services. However if we want to use Angular js in the future on the client side then yes it is required.
Now the questions is:
Will the performance better in case we use project libraries (Service library not web api) instead of using REST services created in Web api? Or there will not be much difference if we use rest services?
I believe including reference of service project libraries would be the best option if rest services are not required. As when request from client goes to server it don’t need another http request for calling rest services.
The best of both worlds would be including reference of service project libraries, but designing them in a way where you can have a very thin layer - an ApiController - to just handle the WebService security, if any, and call the logic.
If you do it right, the controller should have next to no code aside from calling your service classes.
Other advantage: you can implement a couple of those controllers exposing your services as REST services, just to prove that you got the gist of it and that your architecture works, and then, at a later date, expose all the other services as RESTful API as you need them, when you switch to AngularJS for instance.
Web services have an overhead proportional to the number of calls. Measure it by calling a no-op service 100000 times. You probably get 1000-5000 calls per second per CPU core.
This measure does not include network latency.
Depending on how chatty your app is the perf cost can be near zero or devastating.
When adding a web service layer the biggest concern usually is productivity cost. It is significant. You can no longer share objects between layers and rely on object identity. Everything is copied. No ORM use on the client for example.
Web services are not something you add lightly. Maybe you can architect your code as a library that is later amenable to be put into a web service as well. But that's hard thanks to the rather fundamental problem that state cannot be shared.
I have a very complicated and big project. There are so many web service calls inside project. All service calls are logged in different tables on database. I need a central log mechanism to avoid all these different log tables.
I think there must be something like Soap Toolkit on client side to catch all service calls. How can I catch the calls and responses to log them to a desired database.?
First of all, it is not a good idea to log to a database. There are several reasons for it, e.g. if, for some reason, there is an exception related to database, it will never get logged.
I would recommend using Log4net from Apache. Here is a good article on how to use log4net in asp.net project. It is a highly efficient and configurable method of logging.
I have a web service; let's say that this web service does many calculations, it consumes a lot of memory resources. If my web services is call by 2 different clients, then the server will consume twice the resources. is it possible to limit my service to being used by one client, but not by using user authentication?
One idea that I have is to know when the service is being consumed, so if another user wants to use the service, it will receive a message that the service is been used by another user.
I know that one of the major goals of web services is to allow many users, and limiting the concurrent users is not a good idea. I am just curious if it is possible and how to do it, where can i find the documentation so i can learn the process.
If this is a WCF based service you can achieve the desired result by looking at the Instancing and Concurrency options available.
More info here
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.