The .NET enterprise system I work with, has disparate web-services all over the place.
Some of them with test stubs/benches and excellent maintenance...and many others without.
The objective is to aggregate all the web services (asmx & svc) together and have them under a live test bench with smoke tests & unit tests to ensure their functionality. Preferably in an automated way too.
Is there an service aggregation software/system that caters to this aspect in .NET? What would be the best approach?
You need to check out SO-AWARE. It is a web service management tool that can manage SOAP or REST WCF-based service across your organization. Further it has a Test Workbench!
Here are a couple of videos that show it off too:
Part 1
Part 2
I'm not sure there is something like this in .net. All your services are made of different technologies asmx, wcf, rest ... and also different business.
First, you have to be able to fully isolate (code, reference, bdd) all these services for testing.
One solution for your problem could Visual Studio Virtual Labs : A lab environment is a collection of virtual and physical machines, which you can use to develop and test applications. It can contains multiple roles needed to test multi-tiered applications, such as workstations, web servers, and database servers. You can also use a build-deploy-test workflow with your lab environment to automate the process of building, deploying, and running automated/load tests on your application (full compatible with TFS)
A good start is msdn
One option would be to put a facade web service in front of all the separate web services. It may done programatically as a master pass through service or maybe even possible to use the WCF relay binding for this. I would also suggest taking a look a BizTalk. You should be able to setup canonical web services that maps to internal web services with proper mapping. You can even setup choreographed and orchestrated web service methods that as composed of multiple internal service methods. Security policy and logging can be applied centrally as well.
For testing I would seriously look as using SOAPUI PRO. I am extremely happy with this product. The only disadvantage is that it doesn't suport net.tcp binding. But you can have all your services exposed as basicHttpBinding in a test environment and run the test cases.
Related
I have a project I am working on where I need to create an app and service package for Windows. I would like the service process to run as SYSTEM or LOCALSYSTEM so that credentials are irrelevant. The application frontend will be installed and executable by any user on the machine. Data from the frontend application will be passed to the service - most likely paths to directories selected by users. Once started the service will listen for a command to do some action while accepting the aforementioned paths.
I'm using C# on the .NET platform and I've looked into creating a standalone service and a standalone application separately as well as creating a WCF service library and host application - that's as far as I've gotten.
All of these methods seem overly complex for what I am trying to achieve. What is modern convention when attempting something like this? I'm willing and able to learn the best method for moving forward.
Edit: This was flagged duplicate. I'm not looking for information on HOW to communicate with a Windows service. That's remedial and not at all what I'm asking. I'm looking for validation that I'm on the right track and if I'm not, I'm looking for suggestions. I've been told that I'm on the right track and pointed towards named pipe binding.
Windows Service is certainly an option for hosting WCF, although it kind of is a deployment nightmare. It really depends on your environment and the capability and support of your system admins as I've had many clients where deploying a windows service, as you need admin rights to install and update it, was simply not practical.
Console applications may sound like a terrible idea but the practicality of being able to drop them on a share and run a powershell script to start them is very compelling.
But frankly IIS hosting has the most advantages in my mind as the product is designed for ease of deployment and up time. And you can use any transport binding in IIS that you can use in a Windows Service or Console.
As for the binding itself named pipe is not really a popular option in many enterprise scenarios as it is incompatible with anything but .NET. Although the same can be said for binary which is one of the more performant bindings. The WSHttpBinding is probably the most popular binding in scenarios that require unknown callers. WebHttpBinding is an interesting option as its HTTP/REST based, although that requires further decoration of your operations and honestly if your going that route you should really be using Web API.
We have lot of applications running on our server that uses Enterprise Library to log. We want to develop a logging service that can serve as a common logging service all these applications can call and that way they will all be logging to a single log file and a central logger will control all the configuration. I was looking for some design solutions for what this service should look like. Should it be a windows service with a .net remoting or WCF interface exposed?
I would recommend using .NET Remoting with an IPC channel.
Here is a tutorial/example: http://www.codeguru.com/csharp/csharp/cs_syntax/remoting/article.php/c9251/NET-Remoting-Using-a-New-IPC-Channel.htm
I've used this method for interprocess communication between several apps/services many times.
Also, have you looked into using something like log4net? It's very powerful.
http://logging.apache.org/log4net/
I'm not too familiar with EntLib's logging code, but log4net is great.
Another option would be to just build a single shared assembly/project that all your apps utilize - that way you don't need a service running in the background, but the code is the same across all apps.
Enterprise Library has a Remote Logging Service that you could use: http://nuget.org/packages/EnterpriseLibrary.Logging.Service/.
It was originally released with the Silverlight Integration Pack but is just a WCF service.
I have a service that runs in a privileged mode but occasionally the user who is unprivileged will need to configure it (selecting relevant hardware etc). I need to provide a simple visual interface for this.
As services can't interact with the visual environment by creating windows etc, I'm wandering what the best way to provide this interface is. Are there any good methods or patterns that people have used in the past?
Cheers,
Richard
I have used WCF to provide a very similar interface in the past. It has several advantages but all normal IPC are also available to you. If it is going to be on the same machine you can allow a service to interact with the desktop.
add a wcf self hosted service to your windows service.
publish in this service the method required, and create a client app to call this methods.
I have written a commercial WCF web service.
I would like to give the service to another person to test independent of the application that will be using the web service. This is because a third party is going to be building that app and we don't have access to it at the moment.
Another thing to remember too is that the person I want to hand this off to for testing is a non programmer. That is important.
So are there any tools out there that can subscribe to a WCF web service, and recognise what data needs to be inserted, and create a GUI to try out different combinations of data?
Thanks.
I typically use SoapUI for that purpose. You can also create test suits with it and it's free. Alternatively you can use the Microsoft WcfTestClient.exe that comes with Visual Studio since version 2008 I guess...
WCF Test Client (WcfTestClient.exe)
You can find the WCF Test Client (WcfTestClient.exe) in the following location: **C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE**
Using the WCFTestClient Tool to Test Service Operations
You can consume a web service with Office InfoPath, or write a simple test application in C#.
In general, you need to publish the web service meta data (normally as a wsdl end point) - this metadata should enable any client to get all the information needed to make calls to your web service.
This may help: http://msdn.microsoft.com/en-us/library/ms734765.aspx
As may this: http://keithelder.net/blog/archive/2008/01/17/Exposing-a-WCF-Service-With-Multiple-Bindings-and-Endpoints.aspx
Update:
From the comment, is appears that you need non programmers to be able to test your service and are looking for a user interface that can be used to work directly with your web service (and automatically adapt to changes). As far as I know, there is nothing built it that will do this for you (though the old asmx services created web forms that could be used).
So you are looking for application that will create UI for manual testing of your service? Not sure if something like that is available for free. SoapUI PRO is able to do that but in contrast to common SoapUI it is not free. Basic SoapUI version requires tester to write XML messages directly.
You should think about your requirement. You want tester without any programming knowledge to test artificat which is for programmers - not for end users. You probably have to buy some tool or write your own solution to support such test.
Is it possible to create a C# EXE or Windows Service that can process Web Service requests? Obviously, some sort of embedded, probably limited, web server would have to be part of the EXE/service. The EXE/service would not have to rely on IIS being installed. Preferably, the embedded web service could handle HTTPS/SSL type connections.
The scenario is this: customer wants to install a small agent (a windows service) on their corporate machines. The agent would have two primary tasks: 1) monitor the system over time and gather certain pieces of data and 2) respond to web service requests (SOAP -v- REST is still be haggled about) for data gathering or system change purposes. The customer likes the idea of web service APIs so that any number of clients (in any language) can be written to tap into the various agents running on the corporate machines. They want the installation to be relatively painless (install .NET, some assemblies, a service, modify the Windows firewall, start the service) without requiring IIS to be installed and configured.
I know that I can do this with Delphi. But the customer would prefer to have this done in C# if possible.
Any suggestions?
Yes, it's possible, you may want to have a look at WCF and Self Hosting.
Yes, it is possible (and fairly easy).
Here is a CodeProject article showing how to make a basic HTTP server in C#. This could easily be put in a standalone EXE or service, and used as a web service.
One technology you might want to check out is WCF. WCF can be a bit of a pain to get into but there's a great screencast over at DNRTV by Keith Elder that shows how to get started with WCF in a very simple fashion.
http://www.dnrtv.com/default.aspx?showNum=135
You could take a look at HttpListener in the .Net framework.
I would highly recommend WCF. It would fit very well into a product like you are describing. There are a good number of books available.
Sure, you can do that. Be sure to change the Output Type of the project to Console Application. Then, in your Main function, add a string[] parameter. Off of some switch that you receive on the command line, you can branch to ServiceBase.Run to run as a Windows Service or branch to some other code to run a console application.
This question is somewhat older but since I needed something similar some time ago it felt like this question is still relevant.
I wrote a small Rest-API with NancyFx and OWIN. OWIN is a standard interface between .Net applications and web servers. With OWIN it is possible to create a self-hosted WEB-API. Nancy on the other hand is
a lightweight, low-ceremony, framework for building HTTP based
services on .NET ยน
The combination of those two makes it possible to create a self-hosted C# Web service.
I am quite sure that there are many more possibilities to create something like this by now but since I used it like this I thought the Information might be useful to someone.