I'm taking a Masters capstone course early and doing my project in C# while everyone else is doing theirs in Java. The project has 4 services and requires a name server that maps service names to sockets. The instructor is suggesting that the students use RMI to build this registry. Since I'm not very familiar with Java, and the instructor is not very familiar with .NET, we weren't able to come up with an equivalent in C#. Anyone out there aware of one?
Update:
I'm looking for a way to discover a WCF service without explicitly knowing its socket.
Update 2:
I will be demoing the project on my XP laptop using VS 2008/WebDev server.
You can use the UDDI server that comes with Windows Server 2K3/8. This will give you discovery of your services. Other than that you would need a 3rd party package or roll your own.
RMI Registery in java works as a container where you can lookup services by a key. This mechanism is similar to resolving services/objects via ServiceLocator (e.g. ServiceLocator pattern) where you use a dependency injection engine, and ask it to resolve an instance of the service (i.e. by a known name, by interface, etc.):
IMyService service = ServiceLocator.Resolve<IMyService>();
or
IMyService service = (IMyService)ServiceLocator.Resolve(typeof(IMyservice));
WCF works only in a single service vs. single service host fashion, meaning each single service requires a separate service host. You can write a service container that aggregates the service hosts, opens the port, and registers them in DI container, and later simply ask for an instance of the service as mentioned above.
I am no expert on Java Remoting.
I think what you are looking for is called in WCF terms Service Endpoint.
This can be done either in a config file or via code .
For an overview on WCF I would refer you to this link:Windows Communication Foundation Architecture
Read about TCP Port Sharing, new technology in Windows Server 2008, it could helps you
Related
I've recently discovered Azure Relay and it seems very powerful. I have a basic project using it now to expose a WCF Windows Service. I've read in the documentation about how it can be used to expose RESTful services, but I'm having trouble understanding if it can be used to expose a SOAP web service. I can't seem to find any examples of that and the closest I can is this post about exposing the WSDL. I have an extremely simple SOAP web service with a single method that takes in 5 strings as arguments. I know WCF Services can be hosted in IIS but my client's requirement is that no firewall ports are opened so here's my actual question:
Is there a way to use a Relay to expose an internal IIS WebService publicly? Is there another method I might have overlooked to get around opening a port in the firewall?
I would be very open to exposing the service I have or rewriting it completely since it's so simple, I'm just not sure what my options are.
You could try to re-implement the service as RESTful service or as a Web API and then use Azure's API Management to expose it to the outer world.
Hope it helps!
I have a server I've written in C#. I need to interface with it so I can reconfigure things, purge caches, disconnect users, view a run console, etc. I can't shut the server down to do any of these things.
The two available options, interface with the server via a Tcp connection or use the Windows conventions (some WCF?).
Which is one more reliable or a "best practice":
Tcp connection and issue requests (only let admin/maintenance requests come from localhost of course) OR
use WCF to somehow access admin/maintenance methods inside the assembly?
Thanks in advance for the nearly always useful feedback.
EDIT: Can anyone offer any alternatives to WCF? The server itself is literally 65kb. It's tiny. And all I'm trying to do now is issue a few admin/maintenance commands to the server. I'm not trying to be the server, it's already done. I just want to interact with from a local host userland application.
EDIT 2: Problem solve: I'm just using a very very small Tcp client to issue requests to my already built out protocol. It's only a couple hundred lines and no bulky overkillish WCF had to be used. WCF just seems like...too too much. That said I need to learn it anyway (and am right now), thanks for the feedback!
I would definitely recommend using WCF. You define your endpoints and the contract, then using binding you configure how the communication is done (TCP, XML SOAP, Named pipes, message queues...).
This technology is pretty convenient: if you want to move for instance from TCP to HTTP SOAP, then you just update your configuration files and it's done; no code to update. Also it's totally interoperable as you can configure WCF to use HTTP (SOAP messages) and consume your services from any language/platform. You'll also find plenty of tutorials and examples on the web.
Here's a nice article about how to host WCF (TCP communication in the example, but you can use something else by modifying the configuration) within a Windows service
You can host a web service inside windows service. It would be TCP of course but without socket level programming on the client.
You can have then a restful interface on top of it. WCF always seemed too heavy to my liking
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!
Anyone have a pointer to a C# configuration class that a .NET service can use to do configurations via an admin socket or other control port? I'd rather do this than a filewatcher on the app.config file.
We have some long running C#/.NET services (24h X 6.5 days/week) that may need to be re-configured on the fly. I'm looking for a good way to push out config changes to a .NET service
Any pointers appreciated.
Craig
How about exposing a WCF service for configuration purposes? That way you can get a nicely typed API for configuration of the service.
To expand on Manga's answer;
I'd recommend hosting a WCF endpoint on the same IIS box hosting your long running C#/.NET services. This endpoint run on an arbitrary port.
Its responsiblity would simply be to change the appconfig(s) of your running service(s). You could specify a config type decorated with DataContract to allow for a nice configuration API exposed to the client responsible for pushing the config changes.
I'm not experienced with WCF, but I've typically solved this problem by rolling my own API via RPC. Expose some methods to add/remove/update certain configuration items, throw some sort of UI on top of it, and you can update your service on the fly.
Simple issue. I'm working on a proof-of-concept for an application with additional database connection, so I will create a WCF service to wrap around the database. Multi-user environments will get this service installed on a centralized server with a client application on their local system. These users will automatically have to deal with firewall issues, so this is acceptable.
But the single-user environments will have the service and client application running on a single system. The service host doesn't have a definite shape right now, but it's likely that it will be hosted within the application itself or as a Windows service.
Unfortunately, the client application is a WIN32 Delphi application which needs a simple way to access the service. Preferably, the single-user version should use the same technique to access the server as the multi-user version, which means that it behaves like a SOAP client, with a WSDL imported and converted to Delphi code.
Still not a problem, but I have to consider possible problems that we can encounter in this setup, with the most important issue: possible firewall that closed the connection port.
So, does anyone know about any firewall problems that can occur in this single-user environment?
You haven't mentioned which WCF channel you're using- I'll assume basicHttpBinding. Generally, if your local service is bound to 127.0.0.1 using self-hosting, and the on-box client accesses it that way, you should be fine. No firewalls I'm aware of will screw with your loopback adapter. If you bind the service to the machine's IP though, you may subject yourself to firewall fun.
If you have WCF 3.5 available on the client on both ends (sorry, I don't know anything about Delphi), have a go with netNamedPipeBinding.
You didn't mention which version of Delphi you use but I once had hard time making Delphi 2005 import a WCF service with basicHttpBinding. As the WSDL is split among many pages, the SOAP import wizard in Delphi wasn't capable of understanding it. I finally ended up writing an ASMX wrapper around the WCF service for Delphi clients.