#programming the internet

[lodiwayoflearning]

Richer Pages With AJAX

By Felipe Lodi

Google Applications took the attention of the world to a new way that Web applications could be developed. Certainly this was not approached only by Google and their great envisioners and developers but given their products are widely used, everyone could take advantage of great user interfaces. The layman user might not be able to understand what I am trying to say here but if they were able to compare functionality of Google Applications (e.g. Gmail, GoogleDocs) with interfaces that do not use AJAX, they would know.

AJAX stands for Asynchronous JavaScript and XML (W3Schools, n.d.) and it is not a programming language. AJAX brings more dynamic pages to the Web, pages that are not completely refreshed, faster pages that do not wait for an entire reconstruction every time a command is executed. With AJAX, only parts of the page are updated, only parts that really has to be updated. For instance, still using Google as my base to this article, when a new mail is received from Gmail, why to update the whole page is just one item needs to put on the Inbox list?

And here is the great idea. I am used to say that AJAX works like a cartoon production. I am not a specialist on that but I imagine that cartoons are drawn in a way that scenario, objects and actors do not need to be entirely re-drawn unless they need to be updated. Jokes apart, Web pages using AJAX also have this way of work. Technically speaking, the client-side scripting acts updating only the part of the page that was programmed to change at that moment and the server-side communication still remains the same, the requests happen in a very similar way.

Answering one of the proposed questions: yes AJAX is the great deal for Web applications, and thanks to this feature, Web applications look alike desktop applications nowadays. The AJAX application model also brings new techniques to the developers, since many third party products embed the JavaScript and XML coding used behind the scenes. It is possible to develop the functionality from scratch though, however, the usage of ready tools equalizes the benefits of using AJAX with the benefits of developing using AKAX.

Amongst countless products, AJAX Toolkit for developers is an effort between Microsoft and the Asp.Net AJAX Community in order to bring "powerful infrastructure to write reusable, customizable and extensible ASP.NET AJAX extenders and controls" (Microsoft, 2011) Using these controls, the developers do not have to bother to make AJAX layers working. They just stick the components on the page and do the proper bindings that the results are faster and more dynamic pages, like the former Desktop Windows Forms used to be.

As developer, I believe that AJAX brings the Web application to another level. As user, I ever got myself amazed with the benefits of navigating on AJAX-ready pages. I would say that I respect the page. As developer, I also believe that AJAX enables new interactivity, as the way the asynchronously requests enables multi-thread pages. As user, I think multiprocessing helps the pages to be faster, likewise Desktop Applications. And finally as developer, being able to develop richer pages and less server dependent pages bring me back to the recent world of Desktop Applications that now, I can use on the Web.

REFERENCES LIST

Microsoft, 2011. ASP.NET AJAX Control Toolkit [Online] Available at: http://www.asp.net/ajax/ajaxcontroltoolkit/samples/ [Accessed on April 23, 2011].

W3Schools, n.d. AJAX Tutorial [Online] Available at: http://www.w3schools.com/Ajax/Default.Asp [Accessed on April 23, 2011].

[lodiwayoflearning]

Web Services Collaboration

By Felipe Lodi

Web services and AJAX enhance each other but they are not the same thing. They are the perfect combination for Web development though, since AJAX has great performance to work with XML which is used as wrap for nearly all Web services. (Pruett, 2006) I would say more, I would say that Web services being called asynchronously take the Web application to another level as background processing might be happening on different servers, at the same time.

Imagine that an application that does not use AJAX but does use Web services. Let me retrieve some examples from past articles about Web services when I mentioned two widely used free Web services: Weather Forecast and Currency Converter. Imagine we have a page where the user have two forms prompting either the city that he wants to forecast and the currency he wants to convert (such application difficult to wonder since those two services do not match much but they are good for the example anyway). Without using AJAX, those two requests would be sent to the server in different moments, using different button confirmations. The page would first retrieve the data for one of the prompts, refresh the page showing the results and then prompt for the second parameter, which would do the whole communication again, refresh the page and so on. Although this could be done in just one shot too, wondering the very same page using AJAX things would be even better.

This better developed page would be using AJAX to send the requests to each different Web service as soon as the user leaves the prompt field, without considering when the response would come. Still in two different prompts, the user would receive the data from the first requests whilst he is still typing the second prompt, such time that would be wasted with refreshing on the first situation. One of the servers hosting the Web services could also be off and in this case the user would have a delay on retrieving one of the requests (while the Web service is wrapping an information from an alternative Web service) but he still would be informed on time, no refreshing, as all this processing would occur behind the scenes, asynchronously.

Therefore, in practice AJAX avails and anticipates requests and processing by different nodes (different hosts) making the Web application smarter and faster. "A service-oriented architecture is essentially a collection of services" states Douglas K. Barry (Barry, n.d.) and indeed this is true. The example above, it is a simple example but there is point where Douglas' statement fits into it. Where mentioned that one hosting could be off and the data would be alternatively retrieved from another Web service, my intention was to illustrate how a combination of Web services would collaborate behind the scenes in order to bring the data to the user. This is a little bit more complex of course, but for the sake of clarification, I wonder that my architecture would require a top-layer custom Web service on the top on the alternative ones in order to manage the requests from the user and redirect the request to the proper online Web service that would bring the correct information.

This could be extended to a even more complex architecture if the user were somehow identified, tracked down and then the Currency Converter and Weather Forecast would automatically suggest data given his location. Nevertheless, this net of Web services interacting with each other takes the Web application to different way of development, more complex indeed but even more productive. AJAX fits on it perfectly as it extends the User Interface for doing calls that have to be done oriented by events other than just mouse click. Once again, whilst the user is typing his login on the top of the page, AJAX would trigger the Web services verification for instance so the delay for an available Web service would not happen when the user really needs the data.

REFERENCES LIST

D.K.Barry, n.d. Service-oriented architecture (SOA) definition. [Online] Available at: http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html [Accessed on April 24 of 2011].

M.Pruett, 2006. Ajax and Web Services [Online] Available at: http://oreilly.com/catalog/9780596528539 [Accessed on April 24 of 2011].

[lodiwayoflearning]

Selling PHP

By Felipe Lodi

The history of PHP tells that it succeeds another product called PHP/FI. Even though I have been developing using PHP for a long time I have to say that I haven’t heard about that. Rasmus Lerdorf created that language in 1995 as a group of Perl scripts to track his Resume accesses, meaning by PHP, Personal Home Page Tools. As more complex functionality was needed, Rasmus improved that first code using C and then deployed to the world so anybody would be able to use and improve as they wish.

The second version release by 1997 had already several users contributing to the growth of the language. The third version was resembled and authored by two different guys (joined later by Rasmus) right after the second release in 1997. Andi Gutmans and Zeev Suraski were the new authors and they rewrote PHP because they thought PHP/FI 2.0 was “severely underpowered for developing an eCommerce application”. (The PHP Group, 2011)

Later on, PHP had new versions that always improved its core and it is present nowadays in many domains on the Internet given its flexibility, modularity, efficiency, strengthens and reliability. However, the latter is subjected to the user’s liability given that PHP is an Open Source language, therefore it is observed lack of supporting and language documentation is still in progress.

Within this documentation, there are lots about SQL Injection concern. “SQL Injection is subset of the unverified/unsanitized user input vulnerability”. (Friedl, 2007) Actually, HTML fields used by PHP forms can be used by threats to input SQL commands trying to breach the system. Even though the intended intruder will probably use some more sophisticated techniques, SQL Injection is the first thing to protect PHP applications from as this is widely used.

SQL Injection is not a particular issue of PHP however. Asp.Net applications are also liable to that and the Microsoft Patterns and Practices Website has interesting tips to protect Asp.Net applications that are also useful to PHP, Java or any other language used in Websites development.

The TIME Magazine brings a research of the 25 best eCommerce Websites. They do not state the languages they were developed with and further research in this sense did not bring me any satisfactory results. Nevertheless we can easily observe the trend on shopping online in different ways, in different sections and for different things. The first overall is the Amazon.Com followed by Dell and IQVC. (TIME, n.d.)

Following the online shopping trend as well as the strong points of PHP (being one of these, its free usage), we can notice a number of eCommerce products made in PHP (they are not free though). These products usually are fully customizable by the downloader. The advanced user only have to understand a little of PHP in order to leverage a whole new shopping system.

Amongst them are PHPCart (www.phpcart.net), COMDEV (www.comdevweb.com) and PHP Web Commerce (www.phpwebcommerce.com). I haven’t tested them myself but very good reviews can be found for those. These initiatives indeed make PHP as preferred platform for eCommerce businesses on the Web.

REFERENCES LIST

Friedl, S.J., 2007. SQL Injection Attacks by Example. [Online] Available at: http://www.unixwiz.net/techtips/sql-injection.html [Accessed 3 April 2011].

The PHP Group, 2011. History of PHP. [Online] Available at: http://www.php.net/manual/en/history.php.php [Accessed 3 April 2011].

TIME, n.d. The 25 Best E-Commerce Sites. [Online] Available at: http://www.time.com/time/digital/reports/ecommerce/25best.html [Accessed 3 April 2011].

[lodiwayoflearning]

View Page Source

By Felipe Lodi

We have seen before how HTML though useful is limited. We have seen also that HTML is what the Browsers interpret in the end, on the client-side, on the user side. Scripts in the other hand are very important to either change dynamically the HTML on the client-side or create dynamically HTML code on the server-side sending these results to the client-side.

Scripts can work on HTML created by scripts as long as this coding is well formed. Actually one layer does not have to be aware of another, the Web developer however takes all this into account when planning, designing and developing, so he can provide the best results on each layer, either on the server-side or client-side.

The Web developer also knows that client-side code can be easily seen by everyone. All HTML code rendered by the Browser is accessible on the Browser itself. There are some way to do this either using built-in capabilities of the Browser (e.g. View Page Source on Google Chrome) or copying and pasting the content into a Web developing tool (e.g. Microsoft SharePoint Designer). There is an option also on main Browsers to save the current page. This option on the Internet Explorer for instance, saves the current page as a HTML file as well as the accessory files such as scripts, images and style sheets in a separated subfolder.

Client-side code, for example JavaScript code, can also be seen using all of these methods. It is important to mention that JavaScript code can be put along the HTML files or on “.js” files, this is an implementation choice, but on both cases the client-side code is exposed. On the later though, the advanced user has to figure out the reference tag to the external script file and then navigate to the files using as base the root URL. Therefore there is no way to protect client-side code, HTML and scripts.

On the server-side things are different though. All scripting hardly developed to generate the HTML to be shown on the client-side is protected. Starting from the fact that the server-side scripting does not have to obey the same URL structure the end user sees on his Browser. Server-side scripts usually are also in different number than the resulted HTML as Web developers can use the benefits of Frameworks, Assemblies and Object Models.

Using CGI (Common Gateway Interface) is another way that pages can be generated by an executable file. “A CGI executable is a standard executable file but such that the HTTP server can tell it in fact contains a program that is to be run” states Herme. (Herme, 1997) By executable, we can understand this code has been compiled and therefore, even if the advanced user gets this executable, the proprietary source code cannot be seen, so it is not possible to understand how pages are created from this file.

Besides dynamically created HTML code, server-side code usually has database connectivity details, business rules data and even more information about the Company that owns the code. Therefore it is highly recommended keeping all this source code safe and protected against threats.

Therefore, even if the advanced user gets the resulted HTML pages and client-side scripts, they cannot do much with that. They will not be able to know how these pages were created as he does not have access to the source code, the server-side code. For the sake of clarity, some examples of languages that work on the server-side are PHP, Java and Asp.Net.

REFERENCES LIST

Herme, 1997. Writing basic cgi-bin applications. [Online] Available at: http://clip.dia.fi.upm.es/miscdocs/pillow/pillow_www6/node2.html [Accessed 27 March 2011].

[lodiwayoflearning]

Democratic.DOM

By Felipe Lodi

Web development though exciting is challengeable. Depending of what you want to achieve or what you want to deliver, many tools and applications must be used. Amongst these tools sometimes three or even four Browsers must be used in determined phase of the project in order to test the pages. By pages I mean the behavior of client-scripts, HTML and CSS rendering. I got myself developing for Web using two, sometimes three monitors so I can keep opened different Browsers as keep things speeding up during the development.

But why this has to be done? If you are a developer and are reading this, you know what I am talking about it. You build a beautiful page, the UI (User Interface) people do their amazing job, coders also do their scripts and in the end what happens? The page works differently on the Internet Explorer than Mozilla Firefox (than Netscape, than Google Chrome, then Safari, then Opera). I basically do not consider the latter (and project managers during the project also recommend the same), given the low audience it has, it is waste of time. Opera had 1.17% on the last February 2011. (W3Counter, 2011)

As a Web developer, there are times I have to discard some cutting edge features of HTML because of this compatibility. Be developing for the first version of the Browser to assure compatibility is not the biggest exciting (and payable) work I wanted to do as well. Therefore I need to find out a thin line between what has to be done and what can be done considering the main aimed Browsers. Usually projects have scoped the audience and the aimed Browser, so it helps to narrow my choices.

An important point to mention: we are about to experience soon WebTV Browsers. Yes, they are coming and they have to be able to render these pages too. But if the project you are being paid to develop pages to, does not include WebTV audience, one less to achieve. The problem might become bigger, I can conclude.

It might become bigger because a new Browser on the market might have a new vendor that decides by using a Document Object Model (DOM) different that the one proposed by W3C. “The HTML DOM defines a standard way for accessing and manipulating HTML documents.” (W3Schools, n.d.) In my opinion, it should be the same across all Browsers.

The DOM is so important that rules the way HTML objects can be accessed in a Webpage. Starting from the document itself, which is the first object on the page, developers can reach nested objects and change their functionality, behavior and style. They can move them and they can remove them from the page. Using the same DOM, Web Browsers interpret the pages and show what “us”, the users, see and use.

Microsoft does not use the standard DOM from W3C. Instead they propose the Dynamic HTML (or simply DHTML) on their Internet Explorer versions. They state that their version 4 of the browser the developer can access almost everything on the document and that on the version 5 “Every element is exposed”. (MSDN, n.d.) It already explains some incompatibilities.

The Mozilla Firefox uses a DOM-like based on the W3C standards. They use their Gecko Engine that parsers the Document Object Model in a same way for all Mozilla-based Browsers. (TimeMachine3030, 2011) It also explains some incompatibilities against Internet Explorer. It is true that by validating the pages during the development, the chances of these pages are working fine on the Mozilla Firefox are great. Which it is not guaranteed when using Internet Explorer.

Being made and commercialized in a proprietary way, Microsoft tries to force their own standard that though based on the W3C DOM has some differences. In my opinion, since we are discussing Web and its standards and since W3C has been elected (and respected) as the International Community, their model should be used in all Browsers, in all platforms.

As a way to, as they say on their Website: “lead the Web to its full potential” (W3C, 2011), keep using standards rather than try taking the ownership of the Web would prevent a huge amount of wasted time during development, testing and validation procedures. As well as preventing frustrated final users: The aimed audience.

REFERENCES LIST

MSDN, n.d. About the W3C Document Object Model. [Online] Available at: http://msdn.microsoft.com/en-us/library/ms533043(v=vs.85).aspx [Accessed 25 March 2011].

TimeMachine3030, 2011. Preface. [Online] Available at: https://developer.mozilla.org/en/Gecko_DOM_Reference/Preface#What_is_Gecko.3F [Accessed 25 March 2011].

W3C, 2011. ABOUT W3C. [Online] Available at: http://www.w3.org/Consortium/ [Accessed 25 March 2011].

W3Counter, 2011. February 2011. [Online] Available at: http://www.w3counter.com/globalstats.php [Accessed 25 March 2011].

W3Schools, n.d. HTML DOM Tutorial. [Online] Available at: http://www.w3schools.com/htmldom/default.asp [Accessed 25 March 2011].

[lodiwayoflearning]

Scripts Ruling the World

By Felipe Lodi

Imagine HTML as a limited (though big) set of commands that the Browsers are prepared to interpret and behave accordingly with the programmed mark-ups. As discussed before, there is no way to make HTML evolving and changing its behavior in response to users’ actions, system configuration or database content. HTML is static in the end when it reached the user’s browser, even though it might have been transformed milliseconds before.

This transformation is made by scripting languages and they happen either on the server-side or client-side. There are scripting languages that build HTML and there are scripting languages that transform existing HTML. The latter might be working on either dynamically created pages or static pages. Actually client-side scripting languages do not care how the pages they need to work with were created, as long as the HTML is well formed, they can do their job.

One of the most well-succeed scripting languages is the famous JavaScript. It is important to mention that despite of name and syntax similarity, Java and JavaScript are two completely different things. In the early 1990s when Internet was becoming popular there were basically two different Web browsers, Internet Explorer and Netscape Navigator. The latter was the first to identify that the Web pages would become interactive and they built a language called Livescript. (Chapman, n.d.)

Netscape had this embedded, and pages using this language did not need to be compiled. Users using this Browser were able to use pages developed using this language without having to install anything, differently that pages built in Java which required a plugin to be installed on the computer. What Netscape did was to take advantage of the name Java migrating Livescript to JavaScript. (Chapman, n.d.) That is just a brief history that also includes the beginnings of VBScript and Jscript, also good alternatives to client-side scripting languages.

It shows how important these scripting languages were and are to the user’s experience. Furthermore, not only end users’ experience at stake but businesses and the whole Internet concept and its evolution. The Web 2.0 for instance, would not be possible without scripting languages. Sharon Housley says on hers interesting article that in Web 2.0, “interactive content is the norm” and that the key components of the Web 2.0 are the Web itself, collaboration and syndication rather than power and complex web technologies. (Housley, n.d.)

I agree with her and I would say further that the collaboration is the strongest key. Imagine a user who wants to create his study workplace online. He first finds a (usually) free service that permits him creating an environment likewise his desk: File Cabinets, Calendars, Notepads and others tools. Scripting languages are already there on the Browser when he drags from the Web site’s tool box the desired component (e.g. File Cabinet) and drops onto the virtual desk. Then, after selecting all components he will need for his studying, he organizes his environment, putting the Calendar on the right, Notepads on the middle and File Cabinets on the left. Scripting languages are there too.

What the scripting languages do at this stage is transforming the former HTML page. This is more complex because the scripting languages also changes CSS properties dynamically at the client-side. For example, the coordinates and colors of his components are stored in helpful files called Cascade Style Sheets, that are responsible (in a well-developed Web site) for saving information regarding to positions, colors, borders, fonts and navigation amongst others.

On the other side, on the server-side, this information about his virtual desk is being saved on some sort of database (or perhaps XML files) to be properly retrieved every time he accesses the Web site. At that side, there is another role to be played by another scripting language. This coding will get the user’s information from the database, his used components, how he organized and configured them on the virtual desk and builds the HTML page to be delivered back to his Browser.

This HTML page, though built dynamically, has to keep working as it should, enabling all commands such as dragging and dropping. Therefore it has references to common client-side scripts saved on the server (meaning by “common” that all Web site users also share the same script files as they need the very same functionality). The pages are different, the users can configure as they want and save, but the functionality is common. For the sake of simplicity, they have the same enabled functionality.

Using only HTML would be impossible to build such Web site, such product. As illustrated, different scripting languages are used in different layers and steps to make this simple functionality. I do not see HTML doing this by itself. I cannot see how only HTML would, after identifying the user click, enable the dragging on the page. I cannot see either how only HTML would save the state of the page to be retrieved later.

HTML has though very important events to identify what the user wants to do. But this is the edge, I would say. After identifying what the user wants to do, HTML has to hand over to another powerful language, the scripting language. Whether only the client-side, server-side or both is a technical choice, but certainly scripts have to be there.

REFERENCES LIST

Chapman, S., n.d. A Brief History of Javascript. [Online] Available at: http://javascript.about.com/od/reference/a/history.htm [Accessed 19 March 2011].

Housley, S., n.d. What is Web 2.0? [Online] Available at: http://www.rss-specifications.com/what-is-web-2.htm [Accessed 19 March 2011].

[lodiwayoflearning]

HTML Rules the Web

By Felipe Lodi

HTML is an Application Layer Protocol. It is works above the Link, Internet and Transport layers and its main functionality is to render content on user’s browsers. Therefore what we can see when navigating in our browsers, is the interpreted HTML markup that has been travelled (and has been transformed, broken in pieces, possibly cryptographed) through all this layers.

During several years, since the first Web pages were developed, the need was for Static Pages. Corporations, professionals, stores and so on were used to create their online portfolios on the Internet basically showing Static Content. Meaning that these pages had links, navigation structure, images, forms and text but all this content were once “manually” coded.

HTML was there already. Webmasters and Web developers were used to code HTML in order to render this static content and every time the content needed to be changed, they (myself included) had to go there, open their preferred editor, make the planned changes and upload the modified files to the Web Server. There were user interaction with these static pages but the pages were not coded to respond conditionally to the user, leading him to additional pages based on what he has typed or chosen.

Natively HTML does not have a way to show conditional content nor communicate with databases and for that reason Script Languages were created in order to fill this gap. Developers and researchers realized that others interpreted and compiled programming languages could perform the task to dynamically create the HTML in another layer in response to the user’s interaction sending pages to the user’s browser as if they were manually created.

Simple? Not much. Along all this technology, the hardware infrastructure and the Website’s structures per se got even more complex than it was used to be. The pages still reside remotely in Web servers around the world, however what we store now are the Server Scripted Pages and CGI Applications (Common Gateway Interface). These files and applications are responsible to “build” the former static HTML pages, dynamically. If content needs to be changed, the Web developer no longer goes to the HTML page and make the modification, he manipulates the script that generates the HTML page. Amongst these technologies are PHP and Perl. (P & H, 2009)

These scripts are also capable to interact with databases. Therefore when a user searches for example for your Social Security Number in any e-Government Website, what the engine does is to send the value to the server (for the sake of simplicity, he just sends), the server receives his value in a scripted page or application, that connects the object model, that goes deep into the database looking for the user’s input, the object model replies to the scripted page, that dynamically renders and sends back only HTML to the end user. That is why he usually sees a fancy page with his name, address as if it were tailored for him. Imagine now whether this would be possible using static pages. It is important to illustrate though, that HTML pages and markup are still widely present on the Web server playing the role of what we call “Visual Layer”. Pieces and fragments of HTML are mixed with scripted code so common HTML tags do not need to generated by scripted code and the rendered pages can be uniform.

Along server scripted pages and their nice functionality, another complex technology is on Client-Side Scripts. These scripts were found to be faster when running on the client-side. It means that they run along the HTML on the user’s browser, sometimes they are embedded on the same file actually, but they are not HTML. HTML itself had to be adapted in the past in order to make this interactivity possible. Then we got XHTML, where the “X” stands for “eXtensible”.

These scripts also avails a lot of interactions to the users. But again, in the end what they are doing is to dynamically manipulate the HTML which is the markup the Browsers “render”. They can for example, change the background color of a page given a user’s input. In this case, when the user confirms his choice for the new color, the information does not go to the remote server. It is all done locally and that it is what this is called client-side. Amongst these languages are the famous JavaScript and VBScript. (P & H, 2009)

How all of this work is not going to be explained here, the focus is to illustrate how HTML is on the end of everything that “webs”. Therefore I do not believe HTML has outlived its usefulness at all, since that all web technologies take into account that HTML is what has to be sent to the browsers. Even with the new achievements with Web 2.0, HTML is still there. Complex pages full of Widgets, personalization and dragging and dropping capabilities still are showing HTML.

But not everything was perfect in the HTML world and there were a time when the standards needed to be defined. It is still very common rendering well a page in a certain browser and not in another one. To “try” to prevent this, the W3C organization is active defining standards to the HTML markup. This is evidence that the HTML is going to live for a long time yet. It is due to the next May 2011 the releasing of HTML 5 and a recommendation is due to 2014. (W3C, 2011)

Defining these standards, browsers vendors and technology makers in general can create their products to understand these definitions following the advances in this aspect as well. That is why we “usually” can properly see the very same page in the same way in almost every browser. W3C provides some ways to “validate” a page using strict, transactional or frameset modes. In theory after developing a page (in this case, scripted pages that have HTML fragments within), the Web developer must validate the page using one of these three modes that will rule how “tolerant” the validation will be. When validating a page, not only markups are being evaluated but, accessibility (very important nowadays), code conformity and syntax.

And this is just a briefing about HTML.

REFERENCES LIST

P, J.D. & H, M.D., 2009. In Deitel, ed. Internet & World Wide Web - How to Program. 4th ed. 198, 898: Pearsons Education.

W3C, 2011. W3C Extends HTML Working Charter: HTML5 Last Call in May 2011 and Recommendation in 2014. [Online] Available at: http://www.w3.org/ [Accessed 2 March 2011].

[lodiwayoflearning]

The Portability of Web Services

By Felipe Lodi

Object Oriented Programming (or simply OOP) is an important concept in application development. Usually a well structured application (all type of application) had on its development a great effort during the modeling. Although optional, the developer can basically create classes that have properties and execute tasks. They can interact against each other, they can be extended, inherited and instantiated.

It means that classes, their properties and methods can be used and reused, can be saved in memory, on disk and on the database. The developer usually decides (after planning) which class to use for determined achievement and when he does that, he creates an object. An object is an instance of the class and it is used taking a copy of the class usually without interfering on the original class. “A class is a blueprint for an object” interestingly states Adrian O’Neill (O'Neill, 2011)

OOP creates portability to the application. The business rules are all put on the Object Model as well as the developer has on his side, depending on the language he is developing with, countless classes to be instantiate for a determined purpose. Again depending on the language, these classes can be categorized, grouped and optionally compiled, thus becoming portable.

It becomes portable because it can be moved, shared, used and reused. It becomes portable because of its interoperability, because the possibility to use these classes across different platforms (it is not that simple) such as Java accessing .Net (Luminis, n.d.) The very same compiled class can be shared between a Web Application and a Desktop Application. It can be used for a local application and at the same time exposed to the Web.

This is the concept of Web Service, a class exposed by an URL. The developer still has to instantiate the class in order to borrow a “copy” of the class, but he does that so, making reference to a Web address. “Web Services can convert your application into a Web-application, which can publish its function or message to the rest of the world.” (W3Schools, 2011)

Being exposed through a Web address, the class can technically be accessed from everywhere in the world (most of the Web services exposed on the Web, have authentication though) and therefore the portability of these small components becomes shareable. Meaning by that, Web services can be accessed at the same time, by a Website, by a Desktop Application, by a Mobile, by an automobile and by a kitchen appliance.

The statement that the development on Web will be made with componentization it is indeed true. Small pieces of software are already spread on the Web for either free, paid or restrict usage. Companies can also expose part of their databases on the web using Web services. Services on the Web already expose (and enable) interaction via Web services.

For instance, developers intended to create interactivity with Facebook have at their disposal, Web services to do that. (Facebook, 2011) The Website WebserviceX.NET, expose for free several Web services for developers such as Currency Converter and Global Weather. (WebserviceX.NET, n.d.)

And this is the point: developers that need to convert currency on their projects do not need to develop this functionality, the same happens if they want to show current global climate. They just have to decide how to display and embed this since the data they are already able to gather from the available Web services. It is indeed easy to envisage applications using all this shared information. Web services are also ready to avail data that would be difficult to produce such as the examples above.

In my conclusion, applications will be using even more shared data. By shared I do not say the data will be free or visible to the world. By shared I mean the data is technically possible to be accessed by different devices, different companies and different users. At the same time as it was never possible before.

REFERENCES LIST

Facebook, 2011. Facebook for Websites. [Online] Available at: http://developers.facebook.com/docs/guides/web/ [Accessed 15 April 2011].

Luminis, n.d. Java.Net interoperability. [Online] Available at: http://lsd.luminis.nl/java-net-interoperability/ [Accessed 15 April 2011].

O'Neill, A., 2011. Classes. [Online] Available at: http://www.aonaware.com/OOP4.htm [Accessed 15 April 2011].

W3Schools, 2011. Web Services Tutorial. [Online] Available at: http://www.w3schools.com/webservices/default.asp [Accessed n.d. April 2011].

WebserviceX.NET, n.d. Web Services. [Online] Available at: http://www.webservicex.net/ws/wscatlist.aspx [Accessed 15 April 2011].