I developed a web service (asmx) that is used to expose a proprietary system.
To send messages to my system I create a connection that is very expensive so I'd like to create this connection object once to reuse as many times as possible.
How to survive to web service lifecycle to achieve my goal?
Usually (in normal Windows application) the object is stored in a static variable.
The Object-pool pattern is your friend here. A pool contains a number of already created objects that are returned to the pool after used. On the other hand, instead of creating a new object, a one from the pool is taken if available.
There are number of different implementations easily googlable, find one and modify to suit your needs.
Related
I am trying to consume a third party API based on REST and SOAP based web services. Now before i send any request to them i need to first obtain a session by using one if it's WebService Request. It will create a session for me and give a unique identifier. Now i need to store and use this unique identifier for all of my subsequent requests and close the session when user is done. (Acts same as connect to database, execute command and close connection)
Now this seems fairly simple but there is some limitation. I can only have a finite number of sessions simultaneously and as i am implementing this on web i don't know how many people will use the web application at a time and do actions that will use third party API. I need to pool these connections same as SQL pooling is done in ADO.NET .here is what i think need
I need to have open connections so that user requests are immediately
served
I need the session/connection to be keep-alive.(I have to ping it
once in a while so that id doesn't times out)
Control max number of connections for peak hours (increase & decrease the limit)
I've searched for this but i am unable to find anything solution for this. I saw c sharp object pooling pattern implementation & is http connection pooling possible but these are having a different context.
What I'm wondering is there any API/Package available that i can implement and achieve this functionality or .NET has any classes I can inherit / use to help me build a pooling system. I'd rather not re-invent the wheel if I could use some proven solution or inherit from one.
I have two applications using the same wcf service instance. These two applications will always be started in pairs, so I can have a second, third, or fourth instance of these two. Does this mean I need to have one wcf service being hosted by say a Windows Service, IIS, or console app using a common endpoint address for all four of the instance pairs? Or if I dynamically hardcode the endpoint addresses such that each individual pair has it's own and self host in one of the two applications, does that mean each pair has access to it's own service?
I could probably benchtop test this, but I figure someone with experience could save me quite a bit of coding time just trying to figure it out.
Update (for clarity):
The reason for this question is due to the particular situation I'm working with. The scenario is that the two applications involve one client exe that I am developing and a third-party exe that I have no control over. I can develop a dll that the third-party exe can load. Between my third-party app dll and the client exe the WCF service is intended to bridge the process space to allow the two to communicate transaction information. This will allow the client exe to control the third-party exe and the files it manages.
This is partly an answer partly a long comment. :)
One way to think of a WCF service is that it passes messages back and forth between two separate applications. At a very general level, although there are plenty of good reasons to make a stateful service, it is generally accepted that it is better to be stateless. This means that each time you call it you pass all the info it needs to do what it does, and the service does not need to remember what was done earlier.
The fact that you are worried about separate instances suggests to me that your service has state. I do not think multiple endpoints is the way to go for your situation.
I would suggest that when an application "pair" starts up the first thing it could do would be to request a unique ID from the service. From that point on all messages to the service would contain this ID and the service would process them accordingly. If the service application is maintaining state it would use this ID as a key to identify what information to access to process the call.
At this point you end up with One service application on one server and multiple client applications which is how most WCF systems are designed.
Updated, I think you should google "WCF: Instance Management Per-Call and Per-Session"
Your client should be able to open a connection from the client and keep it open. WCF will automagically create a new instance on the server for you. This would mean you don't need the "application pair ID" but you would need to keep the session open.
I have a WCF with Windows service hosting for a background DB operation. I have included the client part also in the same windows service with a timer instead of creating a seperate windows service for the client part.
I would like to know is there any drawback with this approach.
Have to agree with #Kek why have a WCF service at all if there are no outside callers :) Other than that there is no real drawback compared to using 2 windows services, your approach uses less memory and there is only one service to manage (start, stop etc).
I agree with #Tommy Grovnes in most cases: no drawback if things are done correctly.
I'd like to point out something though:
If service and client are in the same process, certainly the later depends on the former... and you may be tempted to call service methods directly (without using WCF actually)... Try not to do that.
If you do, your data is not serialized : so it is faster, but it may not behave the exact same way compared to a client in another process.
This is particulary true if you use mechanisms such as EF Self tracking entities. These entities change their state when they are deserialized. Avoiding the serialization may lead to unexpected errors when you actually call your service from another process.
I have created a C# application that I want to split into server and client side. The client side should have only a UI, and the server side should manage logic and database.
But, I'm not sure about something: my application should be used by many users at the same time. If I move my application to a server, will WCF create another instance of the application for every user that logs in or there's only one instance of the application for all users?
If the second scenario is true, then how do I create separate application instances for every user that want to use my service? I want to keep my application logic on the server, to make users share the same database, but also to make every single instance independent (so several users can use the WCF service with different data). Someting like PHP does: same code, new instance of code for every user, shared database.
By default, WCF is stateless and instanceless. This basically means that any call may be issued by any client, without any clients or calls knowing about each other.
As long as you have kept that in mind while designing the service, you're good to go. What problems do you expect to occur, given how your service is built at this moment?
The server-side (handled by WCF) will usually not hold any state at all: all method calls would be self-contained and fairly atomic. For example, GetUsers, AddOrder etc. So there's no 'instance' of the app, and in fact the WCF service does not know that it's a particular app using it.
This is on purpose: if you wanted to write a web app, or simple query tool, it could use those same methods on the WCF service without having to be an 'app', or create an instance of anything on the server.
WCF can have objects with a long lifetime, that are stateful, a bit like remoting, but if you're following the pattern of 99.9% of other designs with WCF, you'll be using WCF as a web service.
Edit: from the sounds of your comments, you need to do some seriously and potentially in-depth reading about client-server architectures and the use of WCF. Start from scratch with something small, then try to apply it to your current application.
I'm creating an application that I want to put into the cloud. This application has one main function.
It hosts socket CLIENT sessions on behalf of other users (think of Beejive IM for the iPhone, where it hosts IM sessions for clients to maintain state on those IM networks, allowing the client to connect/disconnect at will, without breaking the IM network connection).
Now, the way I've planned it now, is that one 'worker instance' can likely only handle a finite number of client sessions (let's say 50,000 for argument sake). Those sessions will be very long lived worker tasks.
The issue I'm trying to get my head around is that I will sometimes need to perform tasks to specific client sessions (eg: If I need to disconnect a client session). With Azure, would I be able to queue up a smaller task that only the instance hosting that specific client session would be able to dequeue?
Right now I'm contemplating GoGrid as my provider, and I solve this issue by using Apache's Active Messaging Queue software. My web app enqueues 'disconnect' tasks that are assigned to a specific instance Id. Each client session is therefore assigned to a specific instance id. The instance then only dequeues 'disconnect' tasks that are assigned to it.
I'm wondering if it's feasible to do something similar on Azure, and how I would generally do it. I like the idea of not having to setup many different VM's to scale, but instead just deploying a single package. Also, it would be nice to make use of Azure's Queues instead of integrating a third party product such as Apache ActiveMQ, or even MSMQ.
I'd be very concerned about building a production application on Azure until the feature set, pricing, and licensing terms are finalized. For starters, you can't even do a cost comparison between it and e.g. GoGrid or EC2 or Mosso. So I don't see how it could possibly end up a front-runner. Also, we know that all of these systems will have glitches as they mature. Amazon's services are in much wider use than any of the others, and have been publicly available for much years. IMHO choosing Azure is a recipe for pain as they stabilize.
Have you considered Amazon's Simple Queue Service for queueing?
I think you can absolutely use Windows Azure for this. My recommendation would be to create a queue for each session you're tracking. Then enqueue the disconnect message (for example) on the queue for that session. The worker instance that's handling that connection should be the only one polling that queue, so it should handle performing the task on that connection.
Regarding the application hosting socket connections for clients to connect to, I'd double-check on what's allowed as I think only HTTP and HTTPS connections are allowed to be made with Azure.