I have a very complicated and big project. There are so many web service calls inside project. All service calls are logged in different tables on database. I need a central log mechanism to avoid all these different log tables.
I think there must be something like Soap Toolkit on client side to catch all service calls. How can I catch the calls and responses to log them to a desired database.?
First of all, it is not a good idea to log to a database. There are several reasons for it, e.g. if, for some reason, there is an exception related to database, it will never get logged.
I would recommend using Log4net from Apache. Here is a good article on how to use log4net in asp.net project. It is a highly efficient and configurable method of logging.
I have a developed a application that is gonna to be used at multiple places.
So how should i maintain one database for all?
Or is there only one way of using remote database for this software.
If i use remote database, i am facing problem with loading controls in forms.
Please Suggest Solution.
Thanks
Typically you'd design a system leveraging multi-tiered architecture, which often consists of:
Front-end user interface
A database back-end
Middle tier/business layer that let's your web pages access the database and provides additional business logic (perhaps a web service?)
You don't give much to go on as far as details go, but it seems like you have several physical locations that need to access a single database. So you can:
Develop an (web or desktop) application that handles the front-end UI and the middle tier (which will access data and do other stuff)
Develop an application that handles only front-end UI, but calls a web service that accesses a database and does other stuff. In this case, you may have several locations with different front-end applications that consume the same centralized web service.
My current project structure is made to do logging of exceptions and such into the database instead of log files.
In order to log down details, it goes through web services of another project (logToDBService).
So I'm wondering that if by chance the web service fails, I will not be able to log down new message.
To counter this, for those failed logs, I thought of logging it down into csv so it can be uploaded into the database manually.
And for this to handled by the system without configuring additional permission, what I can think of at the moment is to introduce a web service (logToCSVService) directly in the same asp.net application, so when the logging at the logToDBService fails, it execute logToCSVService.
I use log4net. It can handle database, files, email etc.
We've used ELMAH for logging errors to a database and also to an email address as a backup. It works quite well and has a lot of developers supporting it. Check out more about ELMAH here:
http://code.google.com/p/elmah/
I'm building a traditional .NET MVC site, so I've got a natural 3-tier software architecture setup (presentation in the form of Views, business layer in the controller, and data layer in the models and data access layer).
When I've deployed such sites, it usually goes either on one server (where the web site and db live), or two servers (a web server and a separate db server).
How does one go about a 3-server architecture (WEB, APP, and DB)? Would the web server just have the presentation (e.g. the physical View/aspx pages), the app server would hold the config file and bin folder, and the db server would remain as is?
My question is essentially, can you simply move the /bin and all app logic onto a separate server from the presentation views? If so, how do you configure the servers to know where to look? If there's a good primer somewhere or someone can give me the lowdown, I'd be forever indebted.
MVC is not a 3-tier architecture. Not every solution needs to be 3-tier or n-tier, but it is still important to understand the distinction. MVC happens to have 3 main elements, but those elements do not work in a "tiered" fashion, they are interdependent:
Model <----- Controller
\ |
\ v
---- View
The View depends on the Model. The Controller depends on the View and Model. These multiple dependency paths therefore do not function as tiers.
Typically a 3-tier solution looks like:
Data Access <--- [Mapper] ---> Domain Model <--- [Presenter/Controller] ---> UI
Presenter/Controller is somewhat optional - in Windows Forms development, for example, you usually don't see it, instead you have a "smart client" UI, which is OK too.
This is a 3-tier architecture because each of the 3 main tiers (Data, Domain, UI) has only one dependency. Classically, the UI depends on the Domain Model (or "Business" model) and the Domain Model depends on the DAL. In more modern implementations, the Domain Model does not depend the DAL; instead, the relationship is inverted and an abstract Mapping layer is injected later on using an IoC container. In either case, each tier only depends on the previous tier.
In an MVC architecture, C is the Controller, V is the UI (Views), and M is the Domain Model. Therefore, MVC is a presentation architecture, not a system architecture. It does not encapsulate the data access. It may not necessarily fully encapsulate the Domain Model, which can be treated as an external dependency. It is not tiered.
If you wanted to physically separate the tiers then it is usually done by exposing the Domain Model as a Web Service (i.e. WCF). This gives you improved scalability and a cleaner separation of concerns - the Domain Model is literally reusable anywhere and can be deployed across many machines - but comes with a significant up-front development cost as well as an ongoing maintenance cost.
The server architecture mirrors the 3-tier diagram above:
Database Server <----- Web Services <----- Application
The "Application" is your MVC application, which shares a Domain Model with the Web Services (through SOAP or REST). Web Services run on a dedicated server (or servers), and the database is, obviously, hosted on its own server. This is a 3-tier, 3-server architecture.
In some circles, I have seen this discussion phrased as the difference between n-tier and n-layer where a "layer" in this context potentially represents another machine. In order to have a middle layer using this definition, it must be hosted. For example, if you had a service layer which the presentation layer called to get its data, then the service layer could be on a different machine than the presentation or database. However, that service layer is hosted either as a windows service or as a web service. I.e., there is a process listening for requests on that machine. Thus, you cannot simply move the bin folder to different machine and hope to have this work. I would look at WCF (Windows Communication Foundation) for creating these types services.
ASP.NET MVC does not help you in setting up a 3tier system. This is realy only a frontend pattern.
The main issue you have to solve implementing a multi tier system is the transport of objects from one server to another. You have to find a way to serialize all objects depending on the transport channel. This gets slow and development gets more complicated.
There are reasons to have a separate app-server: You might have logic in it that other application need or the app-server might have different permissions than the Webserver. But its hard to imagine a high traffic website, where all requests lead to a call to a remote app - server.
Next logical scale up would be two web servers and one database server.
Eventually after adding many web servers it might be worth adding a service layer.
You might also want to add a distributed cache, session state server, email server, and other specialized servers at some point too as you scale.
So your questions seems to be ...
"can you simply move the /bin and all app logic onto a separate server from the presentation views?"
If I am understanding correctly, I believe the files in your bin folder will be the compiled code behinds for your asp.net pages. If that is the case then, no, I believe they need to be on the same machine as the asp pages.
If you want to have your business logic on a seperate machine from the presentation layer you would need to wrap that code into a seperate dll and expose it via soap or some other protocol .. and then call those SOAP exposed dlls on the other server from the code in your presentation layer.
I would like to have a Traffic COP or Controller WCF Web Service that doesn't do anything with data but instead gives orders to another WCF Web Service to do so.
Could someone give me an example of how this might be able to be done. It would be preferable that I was not getting into any APM stuff. Instead just an observer who later gets to spin another one way contract to a WCF Web Service when it needs to after it sees that there are no more other WCF Web Services with the same meta data in memory or processing currently.
If this is impossible please say so. Unless you know a small example of how it is done. Maybe a pointer where somebody has already covered the topic?
Thanks apolfj
I don't really understand your question, but maybe this will help:
MSE is a "service virtualization" approach
Stocktrader has a WCF load balancer included in it.
Maybe one of them will fit your needs.
Having a 'traffic cop' service that all traffic goes through before it gets to the actual web service for processing will add extra overhead to your solution. Then you also have issues like once you've logged a call going to a particular web service, how do you find out if the response was successful? Then you hvae to do more logging of some sort and finally return the result to the client. If I understand what you were saying correctly (which I'm not entirely sure I do) you would be looking at something like;
Client -> TrafficCop -> Service1
Client -> TrafficCop -> Service2
OR
Client -> Service1 -> TrafficCop
...depending on where you want the entry point and what you need to do.
I would probably remove the traffic cop web service entirely and implement some API's for your service to implement and have each web service log some information before a service operation is called and after the operation has completed. I'd recommend you take a look at this link; http://msdn.microsoft.com/en-us/magazine/cc163302.aspx which covers behaviours, operation invokers and paramter inspectors.
This way each web service can log information, check access, rules, report errors before and after execution to a database or another TrafficCop web service if you really want. But I'd probably be inclined to just stick all that information in its own database. Thus each web service (depending on what you're doing) may have connections to two databases. One for the web service itself (if that's needed) and one to the TrafficCop / logging database.
At a later date you then may choose to add a website that pulls all the information out of the traffic cop database and allows you to easily browse / search it. It could highlight warnings or other issues your web services logged.
Summary
If all you need to do is logging and related functionality I would consider having each web service log and / or check rules and other things before and / or after a service operation is invoked. At a later date you could consider adding an admin site that surfaces all this information so you can easily keep an eye on how your web services are performing. You may even like to log information like how long it takes to respond to certain requests.
If this is not what you are after I would suggest you add more information and continue to keep your original question up to date.