My new project has a design in which there are number windows services for performing different tasks. I have been given a task to create base class from which all of the windows service will inherit. This base class will perform common functions like creating instances of other windows services by iterating through the config file (may be like Activator.CreateInstance), do event logging on onStart, onStop etc. and may contain some more functionality.
Before I start developing stuff, wondering if there is any pattern already in place or someone has good understanding of how to implement this kind of functionality.
Any help appreciated.
I forgot to mention I am using .Net 2.0 (C#), no option for wcf
Check "A simple windows service to host WCF or WF services", I really like it.
Look in your main method , when you create windows service and you will see that the routine is not call onstart and onstop, you can create each service by createinstance and give it as a paramater to ServiceBase.Run, in your case every service will not appear as a separate service, ServiceController is a great class to start and stop services too, use it if you need
Related
Where can I find the Service Container in a Laravel project.
All the Service Providers are in single location, in the app/Providers directory, but where to find the Service Container?
Service container is a core component of Laravel framework that is ready for you to use as it is, you are not supposed to create your own service containers like you do, for example, with service providers.
You can imagine service container being an associative array where you can store dependencies (services) and logic of how to resolve them. Then you can use service container to give you what you need based on what is there using provided logic.
It would be easier to imagine that service container is a black box that is always available. Your app at first registers (puts) certain rules in there (for example, if someone wants an object that implements PriceCalculator interface then give him object of a class MyPriceCalculator). It is done in register() method of your service providers:
$this->app->bind('App\Contracts\PriceCalculator', 'App\Shop\MyPriceCalculator');
Then this black box is always available for you, so if you ever need PriceCalculator object (for example, somewhere in your cart controller to calculate price of some order) you can now instead of doing:
$calculator = new \App\Shop\MyPriceCalculator;
Ask service container to make you a proper one:
$calculator = app()->make('App\Contracts\PriceCalculator');
Note how we are asking service container to give us implementation of an interface and will in turn give us new App\Shop\MyPriceCalculator object because that is how we defined (registered) App\Contracts\PriceCalculator service earlier.
Using service container is a great way to manage all dependencies of your application since your code will be working with abstractions and how those abstractions are resolved will be always defined in one place (which means it's easier to maintain if you want to change something later on).
If you are new to Laravel I would recommend to skip service containers for now since it's a little bit more advanced topic and you are required to have a better understanding of dependency injection pattern to fully grasp it and use properly.
You can read official documentation here.
I want to consume a file which is wsdl with VB6 , anyone can help me? Or how can I convert wsdl to proxy class ?
You can look at either Microsoft's SOAP Toolkit or PocketSOAP. Might be best to look at both, but don't despair over the learning curve. Both offer simple approaches for simple situations as well as complex solutions for more complex ones.
First, you have a problem with terminology: you do not want to consume the file. The file is a description of a web service. It is the web service that you want to consume. The WSDL gives you all the information you need to consume it.
There are methods to consume a web service in VB6. In the same way you shouldn't be using VB6, you shouldn't be using any of these methods.
You should use VB.NET to create a small COM component. This component will consume the service by using "Add Service Reference" to create proxy classes. You will be able to use modern tools and techniques to develop and debug this component.
You can then consume the COM component from VB6, just like any other COM component.
Basicly you can use the SOAP moniker like this
Set oProxy = GetObject("soap:wsdl=http://server/folder/service.wsdl")
oProxy.Method "Param1"
You can check out the answers to What is the best way to consume a web service from VB6?
I use VS2008, .net 3.5.
There is an external Web Service (it is PHP implementation, but dont mind implementation -.net, java, php,...-).
In my project csproj, I want add Service Reference to WebService and I want use WCF.
When I add Service Reference in VS2008, WCF proxy is created.
Any best practices (patterns and practices) for add service reference (external service) ?
The WCF Proxy Generator (I think the same svcutil command) generates source code like this. Perhaps it will be interesting manages the code generated (ServiceContractAttribute Namespace="http://192.168.50.63/WebService" use IP address, and OperationContractAttribute(Action="http://devservername/webservice/SmoBridge.php/login" use servername).
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(Namespace="http://192.168.50.63/WebService", ConfigurationName="ServiceEasyVista.WebServicePortType")]
public interface WebServicePortType {
[System.ServiceModel.OperationContractAttribute(Action="http://devservername/webservice/SmoBridge.php/login", ReplyAction="*")]
[System.ServiceModel.XmlSerializerFormatAttribute(Style=System.ServiceModel.OperationFormatStyle.Rpc, Use=System.ServiceModel.OperationFormatUse.Encoded)]
[return: System.ServiceModel.MessageParameterAttribute(Name="return")]
string login(string SESSION_ID, [System.ServiceModel.MessageParameterAttribute(Name="LOGIN")] string LOGIN1, string PASSWORD, string COMPANY_ACCOUNT);
Update:
the Erwyn’s recommendations about the correct closing of a faulted WCF Channel.
http://bloggingabout.net/blogs/erwyn/archive/2006/12/09/WCF-Service-Proxy-Helper.aspx
Why does ClientBase Dispose need to throw on faulted state? (Or, what's the difference between close and abort?)
http://social.msdn.microsoft.com/forums/en-US/wcf/thread/b95b91c7-d498-446c-b38f-ef132989c154/
check this out:
http://www.sanity-free.com/125/php_webservices_and_csharp_dotnet_soap_clients.html
i think that one is sophisticated technique.
Regards,
Mazhar Karimi
I don't know why there would be any particular best practices around adding a reference. Having said that, the "Refresh Reference" command in Visual Studio (right-click on an existing service reference) sometimes doesn't work too well, so it can be easier to use the svcutil command manually, and have a .bat file in your solution that updates the service reference (svcutil is what "Add Service Reference" is using behind the scenes).
Also, if the service you're referencing is returning an array, you can get WCF to automatically turn it into a generic list (or some other type) - this might make things easier.
We maintain a system that has over a million lines of COBOL code. Does someone have suggestions about how to migrate to a GUI (probably Windows based) without losing all the business logic we have written in COBOL? And yes, some of the business logic is buried inside the current user interface.
If it was me I would look into something like this:
NetCobol for Windows
It should be fairly easy to wrap your COBOL with an interface that exposes the functionality (if it isn't already written that way) and then call it from a .NET application.
It took us about 15 years to get off of our mainframe, because we didn't do something like this.
Writing a screen scraper is probably your best bet. Some of the major ERP systems have done this for years during a transition from server based apps to 3-tier applications. One i have worked with had loads of interesting features such as drop down lists for regularly used fields, date pop ups and even client based macro languages based on the scraping input.
These weren't great but worked well for the clients and made sure the applications still worked in a reliable fashion.
There is a lot of different ways to put this together, but if you put some thought into it you could probably use java or .net to create a desktop based application and with a little extra effort make a web based implementation.
Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services.
If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.
For program A, you then generate a client proxy and A can now call B via a web service.
Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.
Using this approach, you can "nibble away at the edges" to move the GUI to a modern, browser based approach using something like ASP while still utilising the COBOL business engine.
And once you have a decent set of web services, these can be used for any new development which provides a way of moving away from COBOL in the longer term.
You could use an ESB to expose the back-end legacy services, and then code your GUI to invoke the services via the ESB.
Then you can begin replacing the legacy services with implementations on your new platform of choice.
The GUI need not be aware of the cut-over of back-end service implementation, as long as the interface to the service does not change - minor changes may hidden from the GUI by the ESB.
Business logic that resides in the legacy user interface layer will need to be refactored by extracting the business logic and exposing it as new services on the new platform to be consumed by the new GUI via the ESB.
As for the choice of platform for the new GUI, why not consider a web-based UI rather than a native windows platform, then at least updates to the UI will only need to be applied to the web-server rather than having to roll-out changes to each individual work-station.
I have an existing GUI application that should have been implemented as a service. Basically, I need to be able to remotely log onto and off of the Windows 2003 server and still keep this program running.
Is this even possible?
EDIT: Further refinement here... I do not have the source, it's not my application.
Windows services cannot have GUIs, so you will need to either get rid of the GUI or separate your application into two pieces - a service with no UI, and a "controller" application. If you have the source code, converting the non-GUI code into a service is easy - Visual Studio has a 'Windows Service' project type that takes care of the wrapping for you, and there is a simple walkthrough that shows you how to create a deployment project that will take care of installation.
If you opt for the second route and need to put some of the original GUI code into a controller, the controller and service can communicate via WCF, .NET Remoting or plain socket connections with a protocol you define yourself. If you use Remoting, be sure to use a "chunky" interface that transfers data with as few method invocations as possible - each call has a fair amount of overhead.
If the UI is fairly simple, you may be able to get away with using configuration files for input and log files or the Windows Event Log for output.
Has anyone used a third party product like: Always Up?
Seems to do what I need. It's the capability to keep running through login / logout cycles I need. And the capability to ignore that it's a GUI app and run it anyway.
They must be linking into the exe manually and calling WinMain or something.
You can wrap it up into srvany, though you may need to assign it an actual user account (as opposed to LocalService or some such)
I've had good experience with winsw. I was able to convert quite easily my batch files to services using it.
I've used it for nginx as well, per this answer.
Do you actually need it to run as a service or do you just need it to stay running when you aren't connected? If the latter, you can disconnect instead of logging off and the application will continue running. The option should be in the drop down list after choosing Shut Down or you can call tsdiscon.exe.
Do you have the source? In many cases the difference between a stand alone application and a service are minimal.
Most of the changes are related to hooking the code into the service manager properly. Once done, you'll know that any problems that occur are a result of your programming and not any other program.
What happens if you create a service. That service is configure to interact with the desktop. Configure it to run a some user and to start automatic. From the service CreateProcess on this other application. I'd guess this is quick to try using C# (C/C++ was alot of code to even be a service if I recall). Would that work??
BUT!
My first thought would be to create a virtual computer in a server-class virtual host (like Virtual Server, HyperV, VMWare). Those virtual machines will run as service (or whatever Hyper V does). The virtual machine would always be running - regardless of logging in and out.
Make this virtual computer auto login to windows (TweakUI can set this up) and then just launch the GUI app using a shortcut to the Startup folder. You can even remote desktop into it use the program's GUI (I bet Always Up can't do that).
You can use ServiceMill to achieve this operation.
Basically you install ServiceMill Server on your server.
Then click on right button over your executable file and "Install as a ServiceMill Service".
Next you configure some things (user/password, if you want to interact with desktop or if you prefer to hide the ui... and set the start mode to automatic).
Another tool from Active+ Software can be a solution, ServiceMill Exe Builder which allows you to create services from Command Line and this is great if you are using a Continuous Integration Server or if you plan to distribute your component as a service without having to think about service integration (plus it is royalty free).
FireDaemonPro turns most GUI apps into services; it's not free, but it might be worth getting it.
First I would have to ask why your service needs a user interface. Most likely it does not but you probably need a client that gets data from this service. The reason services don't usually have GUI's is they may not have a window environment to run in. Services can start and run without a user logged in to the machine. In this case there would be no desktop for the service GUI to run in.
Having said that you can set properties on the service to run as a user as suggested by Mark. You can also specify in the properties of the service to "Allow service to interact with desktop". Only do this if you know a user will be logged in.
A service shouldn't have a GUI, since it should run without any needing any intervention from a user, and there are all sorts of problems associated with finding and communicating with the correct users desktop.
Since, presumably the reason for asking this is to be able to remotely monitor the application, the way to do it would be to have two applications. The service side (written basically as a console application) and the client/monitoring GUI side. The service would use some remote connectivity (when I did this I used Named Pipes) to communicate with the client/monitoring application. Either should be able to run without the other, and certainly the service should be able to run with out the client.