//Web Service Monitor Client and Server
My web service monitor put simply is a way of determining what is going on with a web service thats running in a production mode. I needed a way to monitor the calls which a web service was making without being intrusive to the system, because I do not want to have any impact on the system while I am monitoring it I couldn’t simply write information to disk or a database or anything of those sorts. I instead opted for an even similar solution. I am in the process of writing a web service extension which intercepts all the calls being made and sends out a UDP packet with a few different message types allowing for future flexibility. Currently I have only a single side of this equation working; I can send messages at the moment and receive them in a rudimentary client.
A full release of the client will include the ability to group message types, filter, sort, search, and save incoming messages. The client will also tell you how much data is being sent and received as well as how many incoming and outgoing messages are being sent. As a result of accepting other message types I intend to be able to send direct log messages as well. Currently most systems write their errors to a system where you can’t really see the error in real time. With this system you will be able to see errors as they are being logged and try to better determine what Web service calls were made around that time.
This system will also support the ability to send the information to more then just one system. If several systems are in the configuration file then several systems will receive the messages. Now because the messages are sent via UDP packets there is not much I can do in the way of potential message loss but I wanted a non intrusive system which meant opting for UDP over TCP. This is especially true because the web service I intend to attach this system to for monitoring receives somewhere in the neighborhood of 5,000 to 7,000 messages per minute. Trying to make that many connections to potentially more then one monitoring system would cause a ton of system overhead that I would like to avoid at all costs.
//Distributed File Storage
Distributed File Storage Services is not to be confused with Distributed File System create by Microsoft. Instead Distributed File Storage Services (DFSS) is a .NET Web Service driven application that allows data to be evenly distributed amongst several back end storage servers. This system was created to give small companies and hobbyists the ability to create sites similar to DeviantART.com or iStockPhoto.com that require huge amounts of storage over time. Such companies usually do not have very large budgets or would rather not spend their entire budget on setting up a Storage Area Network (SAN), enter DFSS.
The DFSS will allow the creation of a storage farm from basic servers which will help not only to distribute the files across several servers for load balancing but will also create a high availability storage facility in case of a hardware failure. This system can help to create a very large storage array with a very low budget since it does not require the use of $10, 000.00 SAN disk modules; instead it only requires a simple 1U server to get started. The other beauty of this system to the truly budget minded company is the ability to use the server as a dual-purpose server. It is not limited to only being a storage array; the same server running the storage farm can also act as the primary web server.
DFSS works quite well as a single instance server as well as an n server instance. A storage farm can be expanded at any time without the worry of impacting data integrity. In fact if a storage farm is set up with replication not only can a server be added to the farm at any time but one can also be removed, be it from intentional removal or a hardware failure the DFSS system will continue to function without interruption. In the event a server is lost or removed DFSS will continue to retrieve files but it will still allow the storage of new files; assuming that enough storage servers are running to maintain the replication being requested by the client storing the file.
DFSS only current limitation that is a direct result of DFSS’s design and coding is the use lack of file permissions. Currently the system is dependent upon the front end verifying user permissions prior to allowing access to the data store. This feature will be included later on in the project but all current implementations do not require such features. Other limitations to which DFSS must adhere are standard file system limitations. Rules set forth by Microsoft that govern file name length and folder name length still apply to this storage system.