|
Ralf poses the question: What is an application?
Maybe I´m naive or dumb, but the more I think about it, the less I know what an "application" - an application in software development - is. Can you help me? Who can give me a simple answer?
[...]
What is a distributed application? Is it one application whose parts run on different machines? Or are these parts in themselves applications?
[...]
It seems the term "application" is either overloaded with many meanings. Or it is underspecified.
I absolutely agree that application is a rather overloaded term. It becomes even more complex if the solution you have created uses the combination of, say, InfoPath, some custom .NET components, BizTalk, a standard ERP solution, a custom-built .NET-based CRM solution to achieve a single goal.
I personally usually end up referring to whatever is contained in one single Visual Studio SLN file as "the application". The reason is that I see these components as rather strongly coupled as I use them in more of a white box than black box approach. A certain solution - or system - however might easily consist of several applications. (And, yes, in some cases I ended up with SLN files which contained more than one application. This is especially true in the prototype phase of new projects because interfaces tend to be more flexible at that time.)
In terms of services and applications, I have noticed another interesting situation: at least in the projects I've worked on, I've seen two very different kinds of services. On one hand, I very often see simple CRUD-based services which make it necessary to move a lot of business knowledge to the client tier. They often only act as thin wrappers over INSERT, SELECT, UPDATE, DELETE SQL statements or the respective stored procedures. I usually regard these kinds of services as parts of one application. (Simply because the re-use pattern is rather limited as the client developer has to know a lot about the internal business requirements and about how certain facts are expressed with your back-end data structures.)
My favorite illustration for this is the service infrastructure of a mobile communication provider. If your use-case is to "allow the user to activate GPRS for a given phone number", you could for example create a web service which exposes methods like GetCustomer() and StoreCustomer(). In this case, the client application would need to know that it has to use an approach like the following to activate the GPRS service:
Customer cust = svc.GetCustomer(1234);
cust.Contracts[0].Services.Add(21, true, null);
svc.StoreCustomer(1234);
On the other hand, you might see use-case driven web services, exposing methods like SetGPRSState(bool active, string phoneNumber) for this particular case.
In terms of applications, I would usually refer to a collection of reusable and use-case driven services of the latter type as separate applications. Simply because they contain nearly the same logic as a real, GUI-based application. Services like these somehow seem to be a first-tier technology.
But the question is: is it important to know what an application is? I think it is, because the components of a single applications can be more tightly coupled than the interfaces between two different applications would call for. Or, to map it to Microsoft's current prescriptive guidance for distributed systems: today, it might make a lot of sense to use ASP.NET web services to communicate between different applications. But if you communicate within one application, go ahead and use Enterprise Services, .NET Remoting, MSMQ, ASP.NET web services, or whatever else seems suitable.
|