So, I'd like to create a behavior that I can apply to my WCF services to return a "dashboard" of sorts. By applying the behavior, I could say goto http://localhost/MyService/MyService.svc/dashboard and get returned a list of statistics for the server that I'm interested in.
I'm not sure where to hook in and override the default service page, there must be an extension point, I'm just not sure where to look. Any thoughts?
EDIT: I've seen ways to do this using HttpGet and Message, but this causes me to modify my existing services. I want a behavior that I can apply across to any service at the configuration level, so that I do not have to modify the services whatsoever.
Related
I need to remove WcfContrib from a WCF service.
In a nutshell, it is a library to "max out" all the parameters of a WCF channel (timeouts, message size, etc...).
Now, to ensure I don't break the service, I need to be 100% sure that after I remove WcfContrib I keep all the current parameters maximized.
Therefore, I am looking for a way to log/display on a page the "runtime values" of a channel.
I am also open to alternative solutions/suggestions.
Thanks in advance
I've never seen that kind of tool before. But I have an idea about this.
You can develop a WCF endpoint behavior extension for this. This endpoint behavior can get these values that you are interested and log to somewhere.
This way you don't have to change your service code or something. You will just add this endpoint behavior to web.config of your application.
I'm trying to figure out why the WebAPI implementation of OData doesn't consistently output all actions and procedures to the service document. I would also prefer if the URLs output in the service document would include required & optional parameters.
I will first elaborate the issue I'm hitting with an inconsistent service document:
For example, hitting:
http://services.odata.org/V4/(S(r30qiqlnwgbfi2sgesu5l25w))/TripPinServiceRW/
will not include the unbound action "ResetDataSource". And running it locally, I actually don't even consistently see the GetNearestAirport function appear consistently.
When I inspect my IEdmModel, the function shows that it should be included in the service document:
var desiredElem = edmModel.EntityContainer.Elements.First(e => e.Name == "GetNearestAirport") as EdmFunctionImport;
Console.WriteLine(desiredElem.IncludeInServiceDocument);
Can anyone tell me whether or not it is possible to override the generated service document, and whether or not I am missing something as to why the service document is not consistently generating the same output?
For reference, you can also see the github code sample for the TripPin service here
I do not experience the behavior you are seeing regarding the ResetDataSource action and the GetNearestAirport function not appearing in the Metadata Service Document. I have not heard of anyone having that issue. Will chat with the OData team this week about it.
In regards to the overriding of the Metadata Service Document, I do not believe there is any way at this time to change it. Allowing changes to the MSD would not follow the OData protocol but that is a protocol discussion and not a technical. I don't think the OData team thought of a good reason to allow that from a technical aspect.
I was thinking ,
The WebApi along with routing mechanism works in such way that it reads the http verb ( GET POST etc...) and then searches for matched method names / parameters :
For example :
If it's GET and the URI is api/Customers/5:
method should start with Get
if it has ID so search a method which accepts int as parameter.
etc. (there are more rules).
I mostly believe they did it using reflection.
Question :
Isn't it a performance hit , for every URI request - to search all this data just to attach a method ?
Where I could easily send a very short string from a client which will imply on the method on the server side ?
Why not doing it the simple way ? Ok cause we want to use http verbs as meaning. OK. but so much operations just to execute a method
example #1
get api/Customers/5
could be
a.ashx?m=gc&id=5 (method=GetCustomer & id=5)
example #2
put api/Customers/5?v=123
could be
a.ashx?m=uc&id=5?v=123' (method=UpdateCustomer & id=5 & value=123)
mine is even shorter.
Dont get me wrong. I believe this api was done by very smart people who knew what they talk about.
Just want o know what am I missing.
Web api has a lot of options that you don't have with HTTP Handler if you don't code it
Full list: http://www.asp.net/whitepapers/mvc4-release-notes#_Toc317096197
OData support (via Queryable attribute)
Content Negotiation
Filters
Model binding and validation
Ability to self host outside of IIS
Link generation to related resources that incorporates routing rules
Full support for routes/routing
Ability to create custom help and test pages using IApiExplorer
Performance comparison HttpHandler vs WebAPI: http://www.west-wind.com/weblog/posts/2012/Sep/04/ASPNET-Frameworks-and-Raw-Throughput-Performance
As always, you need to choose the the technology that suits you best, if you want performance go with Http Handler. If you want flexibility and rest go with Web API. You might want rest if you expose web services that other will consume
My applciation works as follows
[user]----username/password/domain----->[WCF service]
then i access the domain server to see to which actual DB the user is associated,
after getting that, i validate the user in his actual DB(DB is per domain)
the problem is that i need a place to store the domain name for the following requests against the db.
for example,if the users calls a WCF service operation:
Test()
first the validation procedure is called, (WCF UserNamePasswordValidator) which validates the user password(which is sent as part of the header for REST or as part of the SOAP), and the next function to be called is the Test, but by then i cant tell the domain of the user(to actually serve the request agains that domain..)
I dont want to change the signature of each domain to
Test(string domain)
I cant simply access the headers since i expose the same methods both as REST and as SOAP and the authentication is different for each of them..(one is with headers as with Amazon S3 and the later is using the SOAP standard)
so basically i'm looking for a global, per call storage.(i want to avoid the Per-Call initiation method)
thanks.
EDIT:
Maybe i should use the ThreadStaticAttribute? will that work?
This will not work. You can't store anything in UserNamePasswordValidator. It even doesn't have access to OperationContext because it runs on different thread.
The way to do this is create custom message inspector and extract the information from custom message header to custom operation context extension as Frank mentioned.
WCF knows a Current OperationContext. You can write your own extensions for it. Unrelated to this issue, I used the same mechanics in this NHibernate Session management here, which may work in its concept for you as well. It accesses the InstanceContext, but the concepts are similar.
This question is about “informational messages” and having them flow from a “back end” to a “front end” in a consistent manner. The quick question is “how do you do it”?
Background:
Web application using WCF to call back end services.
In the back end service a “message” may occur. Now, the reason for this “message” may be a number of reasons, but for this discussion let’s assume that a piece of data was looked at and it was determined that the caller should be given back some information regarding it.
This “informational” message may occur during a save and also may occur during retrieval of information. Again, the message is not what is important here, but the fact that there is some informational messages to give back under a number of different scenarios.
From a team perspective we all want to return these “messages” in a standard way all of the time. Now, in the past this “standard way” has been done different ways by different people.
Here are some possibilities:
1) Every operation has a “ref” parameter at the end that contains these messages
2) Every method returns these messages… however, this only kind of works for “Save” methods as one would think that “Retrieve” methods should return actual data and not messages
3) Some approach using the call context so as to not "pollute" all message signatures with something; however, with WCF in the picture this complicates things. That is, going back to the messages go on a header?
Question:
Back to my question then… how are others returning “messages” such as what was described above back through tiers of an application, over WCF and back to the caller?
I think you basically have two proper ways of doing this:
add a InfoMessage : string field to all your DataContracts, which can hold an informational message (or not) back from the server
If you don't want to put that into the DataContracts, then create a header which you populate on the server before the message goes back to the client, and on the client, you can inspect that header and retrieve it if present
In order to automagically add headers to WCF messages, typically the mechanism of MessageInspectors is used - little chunks of code that can be configured or added by means of an attribute on your operation contract, that will add the header on the one end, and inspect the incoming message for that header (and extract it, if present) on the other end.
There are a number of pretty good blog post out there showing you how to create a message inspector:
Richard Hallgren's WCF postings
Writing a WCF message inspector
Automatic Culture Flowing with WCF by using Custom Behaviour
Those mostly go from client to server, e.g. the client sends along a header with some "meta-information" for the service - but it works just fine the other way around, too.
Check out the two relevant interfaces to implement:
IClientMessageInspector on the client side, which has a BeforeSendRequest and AfterReceiveReply message to implement
IDispatchMessageInspector on the server side, which has a AfterReceiveRequest and BeforeSendReply method to implement