Web Vs Desktop application continued

Well this sounds very interesting, believe u me guys im learning on every post u send on this blog keep up the spirit. I also believe web applications are a bit easier to implement in terms of development considering the likes of myself(you all know me) managed to develop a web application for my company that is currently in use and has been adopted by mgt as a good system. I am happy about that.

Points

1. The speed, actually there are two ports that you can use for deploying a web or Enterprise application namely http port 8080 which is relatively slower and less secure compared to https port 8181. specifically to my Glassfish application server i dont need to manually set these ports during deployment i just need to provide the https://marleyz:8181/project link to my users. I have tried this and there is a difference, i also believe the difference is noticeable if pulling large amts of data

2. Ease of development, whoever is behind Netbeans i salute you........... The servlets and JSPs are easy to develop in netbeans and that allows rapid application development. I can give these two links just in case you are interested in trying http://www.netbeans.org/kb/trails/web.html

Hope my garbage wont bug the smart

Web versus Desktop Applications

This is something I picked up from the web. But the truth is, the issue is has been the subject of debate for a long time

Pros and Cons to Desktop and Web Applications:

Easily Accessible
Web applications can be easily accessed from any computer or location that has Internet access. Travelers especially benefit from the accessibility. This often means that if a traveler has access to a computer, phone or handheld with Internet connectivity they can utilize the web application.


Low Maintenance & Forced Upgrades
Desktop applications need to be individually installed on each computer, while web applications require a single installation.
Many web applications are hosted by a 3rd party and the maintenance fall under the applications hosts responsibility. The ability to update and maintain web applications without distributing and installing software on potentially thousands of client computers is a key reason for the popularity of web based applications. This can be a blessing and a curse as users of web applications on hosted systems are at the mercy of the host, if an upgrade does not go well, or the individual user doesn't want or need the new features the upgrade will still go forward.

Increased Security Risks
There are always risks involved when dealing with working online, regardless of how secure a host might say a web application is, that fact of the matter stands that the security risk of running an application of the Internet is more significant than when running an application on a standalone desktop computer. Some applications require more security than others, playing Sudoku on a web application would cause little concern, but dealing with sensitive corporate formulas or accounting details in a web environment might be determined risky.


Cost
Over the life of the software use, web applications are typically significantly more expensive over time. Desktop applications are purchased outright and rarely is their a recurring fee for the software use. Some desktop applications do have maintenance fees or fee based upgrades associated with them, but rarely is there a subscription fee associated with the software's ongoing use.

Many corporate web applications use a different model, users typically are charged monthly service fee to operate the software. Fees are considered "subscription fees". If you fail to renew your subscription you may be unable to access the data stored in the web application.


Connectivity
Web applications rely on persistent and unmanaged connectivity. If you do not have an Internet connection or if your host does not have Internet connectivity you cannot access the information. Critical applications or businesses that are time sensitive cannot risk denial of service attacks or power outages to interrupt their operations and access data that is sensitive.


Slower
Web applications that rely on the Internet to transfer data rather than a computer's local hard drive, may operate slower. The speed may also vary based on number of users accessing the application.

Backups & Ownership.
Regardless of the platform, companies need to be sure that their data is appropriately backed up. When using a web application that are hosted by a third party, companies should clearly determine who owns the data housed in the application, and be sure that privacy policies prevent that data from being used by the web host.


Ultimately the accessibility of web based applications make them very desirable। Web applications have some fundamental limitations in their functionality, and are better suited for specific tasks. Understanding the pro's and con's to each business model, will help users determine whether a desktop application or web application will better suit their needs.

I don't know fellas... What do you reckon is the better technology? Desktop or web?

Web Apllications

Hi guys 

This is my first time to make a post on this blog coz i kept on failing to register for some reason

Ritz thanx for the inititative

I know some of us guys are not involved in web applications but i am sure we have 1 or 2 to contribute. i have taken note of taps, dirk and ritz' comments on web applications....

sorry to take u back guys but what do u think is/are the MAIN advantages of web application over the windows ones.... (seriously its not trivial)

Hilarious and yet true

1) Project Manager is a person who thinks nine women can deliver a baby in One month.

2) Developer is a person who thinks it will take 18 months to deliver a Baby.

3) Onsite Coordinator is one who thinks single woman can deliver nine babies in one month.

4) Client is the one who doesn't know why he wants a baby.

5) Marketing Manager is a person who thinks he can deliver a baby even if no man and woman are available.

6) Resource Optimization Team thinks they don't need a man or woman; they'll produce a child with zero resources.

7) Documentation Team thinks they don't care whether the child is delivered, they'll just document 9 months.

8) Quality Auditor is the person who is never happy with the PROCESS to Produce a baby.

9) Tester is a person who always tells his wife that this is not the Right baby

10) Team Lead is a person actually knows how many men and women required to deliver the baby , but will not tell anyone

Web Applications in my world "Client Side"

I thought it best to write 2 seperate articles:the first (this one) focuses on the client-side (browser),and the second on the
server side (which for me, would mean PHP)

In an ideal world,web developers would be distinct from web designers.we are far from ideal and i normally find myself doing design.the tools in my arsenal include Dreamweaver,jQuery, Firefox + Webdeveloper,Firebug,Yslow plugins and Aptana studio.

i normally start off with Dreamweaver for UI design in plain HTML,switch to Aptana to incrementally fill in business logic (thankfully,php work well as a with R.A.D. language).

I occasionally have to handcraft Javascript,which could be a pain to debug without the above-mentioned firefox plugins (alert(),anybody?)

Ajax,as a technology, has it's share of critics,but if you call yourself a web developer and haven't started using it,you need to get with the program.You can choose one of many libraries and stick with it,my weapon of choice is jQuery.

Ajax has ramifications on the user experience,i think GMail has been used as an example too many times,so I'll pose a generic scenario. Suppose you have a table/grid with 1 729 rows,and the user deletes a single row- wouldn't it be too drastic, to reload the entire page just to remove single record? An async call without a page reload would be more efficient,and it's easier than you think.

Incidentally, Microsoft will be shipping jQuery with Visual Studio,for those who develop in .NET

Debugging an ajax app is similar to debugging a multi-threaded program- it can be a pain, but with the right tool set,it can be done.More so with proper planning and keeping things simple.

If there's one thing i hate on client side - it is tweaking CSS for IE to make pages render correctly.i design with Firefox in mind.If the application is for an environment i have control over (such as client LAN), i don't bother with IE support,instead,I install Firefox on every box.

Web applications in my world "LAMP stack"

In this here my 2nd post, I'll be sharing my views on Web Applications under my environment- the LAMP (Linux,Apache,MySQL,Php)

PHP has its humble roots going back to 1995,when it was invented as a 'Personal Homepage Parser' - that moniker has been since dropped and PHP doesn't stand for anything in particular anymore. Originally,it followed the CGI script paradigm where each page request would launch a seperate heavy-weight process.whilst this is still possible,nowadays it more common for php to be running inside the server as a plugin (ISAPI plugin under IIS,mod_php under Apache).this means said requests may be handled by light weight threads,without the expensive startup stage for each launch.

Whilst PHP is a scripted language,byte-code can be generated using a vendor-specific engine,such as the Zend Optimizer.

php has similar concepts to other web application frameworks - application state is stored in either session or request 'objects' (i use the term loosely,they are technically arrays)

PHP is rather flexible,it does not impose a 'php-way' of doing things.as a result,there are a number of frameworks based on PHP,some of which are rather specialised,but still extensible (Wordpress for blogs,Joomla and Xoops for content management).

There are other,real frameworks that run on PHP including some that support scaffolding (automatic code generation).For some reason,most of them (if not all) use the MVC (Model-Viewer-Controller) design pattern.

As a scripted language,there is no special 'build' or 'deploy' stages for PHP.that means deployment might be unzipping files onto your production server - which is a terrible way of doing it, by the way.

I tend to use a Subversion repository to manage my project assets and change management,once I'm happy with the testing (or more often,the deadline has approached),i deploy from the repository to production server.Apache's mod_rewrite and .htaccess files ensure only legitimate php files are served,and nothing else that could be a security risk.

mod_rewrite is quite useful for another reason - as It's name suggests,it rewrites http requests on the fly.the most common use is to url prettification.a url like http://eg.com/user/jane/photo can be mapped to http://eg.com/main.php?mod=user&id=jane&section=photo .

PHP is not without weaknesses- at times CPU-intensive processes time out,the default setting in the php.ini file sets that to 30 seconds,which is not adequate for the generation of complex reports.i use the 'Linux' part of the stack to bypass this,I schedule a script to be launched in its own shell using cron then cache the result (eg a PDF report). A PHP script launched in this way can execute at it's leisure, as it has no execution time restrictions.

That's about it for Web apps under LAMP.

Web Applications in my world "ASP.net"

ASP.NET applications

The difference between web applications and rich client applications makes a lot of sense when you consider the ASP.NET execution model. Unlike a rich client application, the user never runs an ASP.NET application directly or any web application for that matter. Instead, a user launches a browser and requests a specific URL over HTTP. This request is received by a web server. The web server has no concept of separate application; it simply passes the request to the ASP.NET process. However, the ASP.NET process carefully separates code execution into different application domains based on the virtual directory. Web pages that are hosted in the same virtual directory (or one of its subdirectories) execute in the same application domain. 

The Application Domain

An application domain is a boundary enforced by the CLR(dot net runtime engine) that ensures that one application can’t influence another. The following characteristics are a direct result of the application domain model:

1.  All the web pages in a single web application share the same in-memory resources, such as global application data, per-user session data, and cached data. 

 2.  All the web pages in a single web application share the same core configuration settings. However, you can customize some configuration settings in individual subdirectories of the same virtual directory. For example, you can set only one authentication mechanism for a web application, no matter how many subdirectories it has. However, you can set different authorization rules in each directory to fine-tune who is allowed to access different groups of pages.

 3.   All web applications raise global application events at various stages (when the application domain is first created, when it’s destroyed). You can attach event handlers that react to these global application events using code in the global.asax  file in your application’s virtual directory.

 Essentially, the virtual directory is the basic grouping structure that defines an ASP.NET application.  ASP.NET applications can include files such as: 

1.  Web pages (.aspx files)

2. Web services (.asmx files):

3. Code-behind files: If you are using the code behind  model, you may have separate source code files.

4.  A configuration file (web.config): This file contains application-level settings that configure everything including security, debugging and state management.

5. global.asax: This file contains event handlers that react to global application events (such as when the application is first being started).

6. Other components: These are compiled assemblies that contain separate components  with useful functionality. Components allow you to separate business and data access logic and create custom controls.

7.  Other files and resources that ASP.NET web applications will use, including stylesheets, images, XML files

 Application Lifetime

ASP.NET uses a lazy initialization technique for creating application domains. This means that the application domain for a web application is created the first time a request is received for a page in that application. An application domain can shut down for a variety of reasons, including if the web server itself shuts down. But, more commonly, applications restart themselves in new application domains in response to error conditions or configuration changes. This model is designed to keep an application healthy and to detect characteristics that could indicate a problem has developed or performance of the application has degraded (such as a long queue of outstanding requests, a huge amount of memory in use, and so on). Depending on your machine.config settings, application domains may be recycled based on the length of time the application domain has been running, the number of queued requests, or the amount of memory used . ASP.NET automatically recycles application domains when you change the application. For example if you modify the web.config file. Another example is if you replace an existing web-page file or DLL assembly file. In both of these cases, ASP.NET starts a new application domain to handle all future requests and keeps the existing application domain alive long enough to finish handling any outstanding requests (including queued  requests).

 Application Updates

 One of the most remarkable features about the ASP.NET execution model is that you can update your web application without needing to restart the web server and without worrying about affecting existing clients. This means you can add, replace, or delete files in the virtual directory at any time. Being able to update any part of an application at any time without interrupting existing requests is a powerful feature. However, it’s important to understand the architecture that makes it possible. It’s not  a feature of the CLR that allows ASP.NET to seamlessly transition to a new application domain. In reality, the CLR always locks assembly files when it executes them. To get around this limitation, ASP.NET doesn’t actually use the ASP.NET files in the virtual directory. Instead, it uses another technique, called shadow copy, during the compilation process it creates  copies of your files .The ASP.NET worker process loads the assemblies from this directory, which means these assemblies are locked. The second part of the story is ASP.NET’s ability to detect when you change the original files , it simply relies on the ability of the Windows operating systemto track directories and files and send immediate change notifications. ASP.NET maintains an active list of all assemblies loaded within a particular application’s application domain and uses monitoring code to watch for changes and acts accordingly.

 Application Directory Structure

Every web application should have a well-planned directory structure. Independently from the directory structure you design, ASP.NET defines a few directories with special meanings:

Bin

This directory contains all the precompiled .NET assemblies (DLLs) that the ASP.NET web application uses. These assemblies can include precompiled web-page classes, as well as other assemblies referenced by these classes.

App_Code

This directory contains source code files that are dynamically compiled for use in your application. These code files are usually separate components, such as a logging component or a data access library. 

App_GlobalResources

This directory stores global resources that are accessible to every page in the web application.

Web Applications in My World - "JSP/J2EE/SERVLETS"

From the picture above you can see the overall architecture or models on which most web applications that are done in J2EE look like.

As you can see, a normal web app done in J2ee consists of jsp web pages, servlets if necessary, and data stores. Ideally all of these should be present, but it always depends on the type and complexity of the web app i do. In other words, a web app could contain all of these or just some, but not all.

The anatomy of the web application

In web applications developed using jsp and j2ee technologies (please refer to diagram) we see the following major highlights about the architecture of web applications.
1) Most users use the web browser as a client to the web enabled applications. This could be any browser from Mozilla Firefox, Internet Explorer, Safari, Opera, Netscape, or any other browser that can send and recieve HTTP and HTTPS requests and responses. Basically this means that even though you are on linux or windows or macintosh or solaris, any browser can access the webserver and get pages. In addition, (which has been ommited on the diagram) we could also have WAP enabled devices, those that can browse WAP applications based on WML, which is a form of Markup language for WAP devices like cellphones to allow clients to browse websites from their mobile devices like phones, pda's and so on.
2) The web server is a software program normally referred to in java terms as web container, because it contains and can handle, manage, process and server jsp pages and servlet classes.
3) The web server can also host java beans which are standard java classes that can access databases, file systems, and can do all that any ordinary java program can do, including networking via eSockets and XML processing.
4) The Enterprise tier consists of EJBs (Enterprise JAVA Beans), which are a specialized JAVA classes that are supposed to make connecting to databases as easy as drag and drop, and you don't need to write any sql queries or such thing. For more info, read books on EJBs coz i can't cover them all here.

Now the most interesting part of web applications is the webserver.
The browser sends an HTTP or HTTPS request to the webserver, from any location on the internet. WAP devices like mobile phones can also send WAP requests to the webserver.
Upon reciept of a request the webserver invokes the servlet class specified from the browser to handle the request. (Note that the request string contains information of which servlet to invoke). The servlet class, which is just a java class, is simply written by the programmer in simple JAVA code, and can do anything from accessing databases, instantiating other classes (inbuilt into the java runtime, or custom made by the programmer), access files in the local filesystem, XML files, network devices via sockets and so on, as well as either redirecting the request to another servlet class, jsp page, or returning a response back to the browser.
The servlet class takes the request string from the browser or WAP request, and the programmer extracts the various request parameters like form data, links, user agent, user infomation and so on. The programmer can then use this infromation to either process data, make calculations, or perhaps even query a database from the servlet class.
When done, the servlet either redirects the request to another servlet, or it renders HTML directly to a browser, or it can invoke a jsp page, which consists of java code mixed with HTML. Either way, a response is sent to the client (either browser or WAP device).
Besides just servicing HTTP requests, and WAP requests, servlets can also serve other protocols of the TCP/IP protocol stack.

More in the next post........

GMAIL Themes

Don't you just love gmail.
I love gmail themes!!!