I'm just beginning WCF and so I don't understand exactly how the abstraction works. Can I write a WCF service and install the same thing on multiple machines, and have them communicate via some ID? I'm looking at sending/receiving commands, and continuous real-time data being sent between devices.
Any service you write can be installed on any number of machines - no problem there.
Any machine or code you run on those machines can also act as a client at the same time, calling other services, yes, absolutely, that's totally possible.
You need to define your service contract as an interface and in that service contract you describe the operations (service methods). Once that service is deployed, anyone can act as a client to that service and send it messages.
And of course, you can have an app (ASP.NET, Winforms whatever) that is both simultaneously - it offers services, but also acts as a client to other services.
Hope that helps a bit!
Related
I'm re-writing a tcp server program in .net core.
I have difficulties implementing my design.
The server has three basic functions/services:
service 1. accept and manage client connections
service 2. handle each kind of client messages and send acknowledge message
service 3. keep track of inactive clients(clients who haven't sent any message for a time) and close those connections.
I'd like to have each of these functions on a dedicate IHostedService.
But I've no idea how should these services communicate with each other.
These services are registered by AddHostedService, and seem can't be injected.
And I'm not sure if it's a correct way to expose public methods on a Hosted Service for others to call.
The most relevant SO question I've found is this one.
In my situation, it means that I should register one mediator service for each of the three services. It doesn't seem to be a clean way because these mediators are just for communication, without semantic meanings...
I'd like to know if the mediator is the only approach,
or is my design totally incorrect?
That really depends on strategy. Each hosted service could take in a configuration as part of its dependencies for communication. However, TCP port binding will need to be unique.
In a prior life, I wrote a UDP service that broadcast and which TCP services were available for communication and mediated the services in chat room sort of setup. UDP is more of a wide net whereas TCP is specific addressing.
If you were using only TCP, without configuration those services would need to know who is the mediator and what address to reach it at.
Currently I'm working on a design for a Windows Service application to fetch reports from an Oracle database, aggregate them to a message and send it to an external WCF SOAP service.
I would be grateful for some design suggestions concerning Windows services.
Should Windows Services use e.g. dedicated WAS/self-hosted WCF service (net.pipe/net.tcp) that provides data to achieve better separation / reusability?
So I would add a WCF service (net.pipe) that provides data (e.g. a GetReport method).
The Windows Service application would call GetReport and call the remote SOAP service to forward the aggregated message. The remote service and its client code are likely to change. It might be adapted for different customer projects.
If I understand correctly, your windows service will periodically fetch some data from the database and upload that data to a remote web service.
This means that your windows service is a client in terms of WCF communication and you won't need to implement any WCF server code inside it.
All you'll have to do is to connect to the remove web service and upload the data, e.g. using a client proxy generated for this remove service.
I don't think that it is required to add another WCF service that provides the data instead of querying the database directly as long as you don't have the requirement that another application will use the same WCF service. Until then I wouldn't add the service for the following reasons:
Another WCF service increases the complexity of the deployment and makes it harder to install and configure.
The connection to the new WCF service is another point that can break.
If you handle lots of data, getting them from the database directly is much more efficient instead of transferring them over a service protocol. As I understand your question, you aggregate the data in the windows service not in the database. Therefore you'd have to move the aggregation code to the new service also.
As said before, this recommendation will change once you have another potential client to the new service. In order to prepare for that, you should of course choose a design in your windows service that separates concerns well and is a good starting point to move some components later.
I am creating a client application that downloads and displays market data from Yahoo! for a university project, but that also sends out notifications to mobiles (so far using Google cloud messaging). So far it's a WPF client and the "server" is a class library - so far working. What I was wondering, is can you mix this server with a WCF service - the WCF service I was planning on using for registering devices, as well as accepting and parsing commands.
So I would call .Start() on my server object, and it will be constantly running in the background, while a WCF REST service runs alongside it - or would I be better simply having a thread running on the server that can accept input... sorry if this is confusing, but just wondering if it can, or has been done before or any advice. :)
Just to explain a bit better
The client front end and the "server" are running on the same machine - I was calling it a server because it is not only updating the front end, but sending out GCM notifications at the same time. I was wondering if maybe a WCF service could be added to make it simpler to handle adding devices to a database ("server" reads a list of device reg ids from a database, sends notifications to these) by allowing an android app to details via REST or something similiar
I would explore wrapping the class library in a Windows Service (which is essentially a process that runs continuously, and can be stopped/started/paused) and keep your WCF service as a web service for client communication.
How the WCF client service communicates with the Windows service is up to you - whether you store the data in a shared database, keep it in memory and have another WCF layer communicating between the two, etc. A shared database would be the most straightforward, especially if you want to persist the data for use by other apps/services as well.
WCF Service would be useful if you had one notification service on your server with multiple WPF client application connecting to it. If you have just one application running on the same server then not sure if it will be worth the overhead.
The usual pattern is to host WCF service in IIS, that way it always starts whenever first request is received. WCF is very flexible though, therefore you can host in in Windows Service, Console Application, etc.
The wording of the question doesn't necessarily do the issue justice...
I've got a client UI sitting on a local box with and a background windows service to support it while it performs background functions.
The client UI is just the presentation layer and the windows service does all the hard hitting action... so there needs to be communication between the two of them. After spending a while on google and reading best practices, I decided to make the service layer using WCF and named pipes.
The client UI is the WCF client and the windows service acts as the WCF host (hosting locally only) to support the client.
So this works fine, as it should. The client UI can pass data to the WCF host. But my question is, how do I make that data useful? I've got a couple engines running on the windows service/WCF host but the WCF host is completely unaware of the existence of any background engines. I need the client's communications requests to be able to interact with those engines.
Does anybody have any idea of a good design pattern or methodology on how to approach facilitating communication between a WCF host and running threads?
I think that your best bet is to have some static properties or methods that can be used to interchange data between the service threads/processes and the WCF service.
Alternatively, the way that we approach this is through the use of a database where the client or wcf service queues up requests for the service to respond to and the service, when it is available, updates the database with the responses to those requests. The client then polls the database (through WCF) on a regular basis to retrieve the results of any outstanding requests.
For example, if the client needs a report generated, we fire off a request through WCF and WCF creates a report generation request in the database.
The service responsible for generating reports regularly polls this table and, when it finds a new entry, it spins off a new thread/process that generates the report.
When the report has completed (either successfully or in failure), the service updates the database table with the result.
Meanwhile, the client asks the WCF service on a regular basis if any of the submitted reports have completed yet. The WCF service in turn polls the table for any requests that have been completed, but not been delivered to the client yet, gathers the information from them, and returns them to the client.
This mechanism allows us to do a couple of things:
1) We can scale the number of services processing these requests across multiple physical/virtual machines as the workload increases.
2) A given service can support numerous clients.
3) Through the WCF interface, we can extend this support to any client platform that we choose to support (web, win, tablet, phone, etc).
Forgot to mention:
Just because we elect to use a database doesn't mean that you have to in order to implement this pattern. You can easily implement the same functionality by creating a static request collection that the WCF service and worker service access in much the same way that we use the database.
You will just need to be very careful about properly obtaining and releasing locks on the static properties to avoid cross-thread collisions or deadlocks.
Had a look over SO but I can't see any threads which address my problem.
I have a conceptual architecture, where there is a central server, which allows clients to connect to it via XML web services. There are 2 types of client, producers and consumers.
The system is built in C# using WCF WebServices, specifically IIS webservices (though this can be changed if necessary)
Producers publish information to the server, and consumers consume information uploaded by a producer.
The conundrum... Consumers need to somehow subscribe to an event on the server, which is thrown when a producer updates the web server, downloading new content and displaying it if necessary.
I don't want to use a polling mechanism, but can't see a way to subsribe to server events in a client.
Very basic architecture... Workstations could be the same PC running 2 services, or they could be 2 separate PC's on different networks. They don't about each other, so all comms are done through the webservice.
This application is for a messaging network, based on radio paging.
Check out this Pub/Sub messaging implementation by the master himself. Depending on what type of WCF binding you can use, it might be helpful to you.