Startup: Ajax Portal Technology - Towards Next Generation Enterprise Portals
As often happens, the Ajax Portal technology appeared by chance, as a synthesis of the two Enterprise Portal and Ajax technologies when building the "engine" for a corporate site. As a result, something new appeared that could give a second wind to the enterprise portals.
For about 5 years I worked in the Minsk division of a major European concern. As part of my work, I was involved in Intranet (developing new applications and supporting old ones). The goal was to develop some kind of integrating tool that would integrate disparate applications into a single information space. The specificity of this work was that the applications were developed using various Web technologies and were physically located on different servers. From a technical point of view, there was only one solution in order to “make friends” of these applications - to apply HTML frames. HTML frames are a set of HTML tags that allow you to split the browser window into several parts, in each of which you can display any Internet sites, Web applications and Web pages. The highlight of this approach was that one of the frames (one of the independent parts of the browser) contained a set of links in the form of a simple list or tree, the other frame displayed Internet sites, Web applications, Web pages, PDF documents, MS Office documents (Word, Excel, PowerPoint, etc.), photos, etc. (in the future we will call this content or Internet resources). At the same time, there was no difference where the displayed content and the type of content were located.
Outwardly, it looked like this: the browser window was divided into two unequal parts (frames). On the left side (narrower), links were displayed in the form of a list or tree, and on the right, the content related to the selected link from the left was loaded. Thus, a console of applications and documents was created, which combined disparate applications and documents into a single information space. The console also allowed searching, navigation, and even information protection.
Based on the developed solution, I offered to release a product for creating corporate sites, which did not find my support from the management. The typical reaction of a large company manager to any innovation is well described in Jack Trout's book “Feeling a Horse”. However, I did not give up trying to create a new product by working in the following two companies. At the same time, each time the “engines” for the corporate website became more and more perfect.
Over time, the use of HTML frames has come to be seen as “bad practice” in building Web applications. An exception was made only for the IFRAME HTML tag, which allows you to add an independent browser window anywhere on the Web page and display any content in it. As a result, I started experimenting with pages with a built-in link tree and an IFRAME tag. At the same time, when a link was clicked in the tree, the content was loaded inside the IFRAME tag. Naturally, the tree soon became dynamic based on JavaScript, with levels loaded as needed. There was even a version in which the tree was replaced with a set of “icons”.
With the advent of Ajax technology, the idea came up to load HTML / XHTML content using Ajax technology, and then display it by inserting content through the JavaScript property innerHTML (in general, the DIV tag). This worked perfectly for related applications - applications using the same CSS and JavaScript files.
The next step was the idea of extracting all the necessary CSS and JavaScript files related to the loaded HTML / XHTML document (content) and inserting them into the main document. Cool idea, simple at first glance. I spent a lot of time before covering most of the possible situations, browser differences, etc. The result of the work was the ajax4all JavaScript library, which allows using JavaScript to insert almost any HTML / XHTML document (Web application) into another HTML / XHTML document (Web application), and then work with one and the other with virtually no problems ( remark: of course, there may be a problem with the same names for CSS classes and JavaScript methods and classes, but even this problem can be solved programmatically by changing the names of CSS classes and JavaScript classes and methods).
It so happened, while working on a project that would later be migrated to the WebLogic Portal, I became acquainted with portal solutions. As a result, the main thing happened - two passion ideas combined, and as a result, Ajax Portal appeared.
Portals allow you to create your pages based on portlets, which are small independent applications. Portlets are displayed as small independent windows on a portal page, which can include several to several dozen portlets. If necessary, portlets can communicate with each other (interportlet communication). Using portlets allows modular software development.
Portals also allow you to aggregate (combine) data from different sources within a single portal page, which allows you not to search for information among several applications, but to see it within a single browser page (if necessary, several pages). This makes it possible to expedite decision making.
The next advantage of portals is customization - the ability to customize portal pages: it becomes possible to move portlets, add new ones, delete old ones, minimize and expand portlets, i.e. customize the desktop (workspace) without involving programmers. This allows you to provide the greatest comfort when working with information and its processing.
What the Ajax Portal gives the developer of enterprise portals:
All that I cited above ultimately leads to a reduction in the cost of creating software and lowering the fixed costs of its maintenance. This is all basically achieved using the ajax4all library. She is the heart of Ajax Portal.
When creating the ajax4all library, I was faced with the need to convert all relative links to images, styles and scripts into absolute links. Otherwise, getting into the portal page, the real address of each relative link began to be calculated by the browser relative to the address of the portal page. The only serious problem is the relative addresses "wired" in the JavaScript code. In this case, the solution is only to adapt the Web application (introducing best practice for Web applications that are supposed to be used as portlets).
The second task in creating the ajax4all library was to convert regular hypertext links into Ajax request calls, followed by replacing the content in the portlet window.
Most Web applications still use HTML forms, i.e. it turned out to be insufficient to simply “isolate” the content of the Web application used as the portlet and paste it into the portlet page. It was also necessary to change relative links in HTML forms. In turn, the question arose, what to do with the functionality of the forms themselves? –Any submit HTML form by Submit button or using JavaScript usually led to reloading all the portal pages, instead of reloading the content in the portlet window.
A way out was found through the use of the Ajax Submit pattern, which became the de facto standard. The essence of this pattern is to replace the usual submit HTML form with a request using Ajax and then receive a standard server response, convert it and insert it into the portal page inside the portlet window. It sounds simple, but it took several months to find an acceptable architectural solution. The complexity of the task was the significant differences in the browser DOM model. Moreover, the most moody browser when writing JavaScript turned out to be Internet Explorer, and not Safari, as is usually believed.
Initially, I intended to support both types of aggregation: on the client side (in the browser using JavaScript) and the classic approach on the server side (portal server). Practice has shown that the approach using conventional Web applications is too good, and the branch supporting aggregation on the server side was abandoned. Maybe I will return to her, but later ...
Having lost the classical Java Portlet API (100% compatible with JSR-168 and JSR-286 standards), I achieved the main thing: Ajax Portal is built on the basis of HTML, CSS and JavaScript. This means that there is no dependence on the platform (including the programming language) of the server part of the portal. As a result, Ajax Portal can be considered a cross-platform solution. Java Web application development was supported through a JSP tag library. Once the library is stabilized and new tag attributes cease to appear, it will be possible to create a JSF component library. In June of this year (2011), I was joined by a .NET developer who made a library for .NET. With the advent of the PHP version - it will be possible to proudly declare that Ajax Portal is an absolutely cross-platform solution. There is an idea to make a library for Perl, but this is a distant prospect.
As an alternative to the Portlet API in Java, the project can offer the MicroServlet Java MVC framework. This was an example for my book on Java, which allows you to build a full-fledged Web application literally on the basis of one class (based on HttpServlet). The framework supports bean forms and JSP pages. Widely used Java annotations. This is the perfect solution for creating a portlet that can have just one or two methods. Users will give their answer "to be him or not to be." I like. While the MicroServlet framework is getting closer and closer to Spring MVC. I have not yet figured out whether this is good or bad. The latest trend is the new Portlet API based on the MicroServlet framework. It will be convenient for users to show time.
Often, portal solutions are associated with CMS. I consider it absolutely not advisable to create my own implementation of CMS, because many startups are trying to occupy an already crowded niche. There are enough solutions, both commercial and free open source. On the other hand, the architecture of Ajax Portal allows you to use the portal as a CMS with reduced functionality. I think it will be necessary to devote a separate article to this.
I came across another interesting fact - when creating real applications, potential customers want to use their developments for the authorization and authentication systems already used in the enterprise. Therefore, questions on the implementation of the security module are still open.
Each version of Ajax Portal, in addition to the ajax4all library and the Portlet API based on the MicroServlet framework, brings some innovations. For versions 1.0. *, Such an innovation is the dynamic transformation of regions (the portlet container on the portal page). State pattern applied. Transformation is done using CSS. CSS markers are used as markers. With the same structure of HTML / XHTML code, depending on the marker, the representation of the region and portlets changes. A region can be converted from a standard view (each portlet is displayed in a small window) to an accordion or bookmark system. In addition, it is possible to present the entire region as a single window without highlighting porlets. There is also a view in which there is no all-round decoration of portlets and the region.
Over the past few years, many companies have left the portal solutions market. Many startups and open source solutions have been abandoned. In my opinion, the main reason is that the JSR-286 standard was not able to realize the potential of Ajax technology. The JSR-286 standard, released after the introduction of Ajax, actually only expanded the capabilities of JSR-168, but did not bring anything new. It is these problems that the ajax4all library is designed to solve.
The latest fashion trend is a smooth transition of portal solutions towards mashups. I think this is a topic for a separate article. Ajax Portal is located in the niche between enterprise portals and mashups. The result is a cross-browser cross-platform Web 2.0 portal / mashup with support for customization and personalization.
The main question for any startup is its analogues. I searched for a long time and searched well, but have not yet found. If you, readers of this article, know them, I will be very grateful if you indicate them to me. Please note that this is:
And the second question that usually arises, and why this has not been done before? - Previously, there was no standard “ Cross-Origin Resource Sharing, ” which specifies the ability to send Ajax requests outside the current domain. Ajax Portal for remote portlets also supports proxy.
I “dissected” many popular solutions, including iGoogle, and found that they all basically use the HTML IFrame tag. Therefore, the ajax4all library is the only alternative I know of with the HTML IFrame tag for remote portlets. When using ajax4all in the Ajax Portal, it becomes possible to naturally fill the selected area with content and proportionally stretch it vertically, exactly what cannot be achieved using the HTML IFrame tag.
Continuation:
http://habrahabr.ru/blogs/AJAX/125568/
For about 5 years I worked in the Minsk division of a major European concern. As part of my work, I was involved in Intranet (developing new applications and supporting old ones). The goal was to develop some kind of integrating tool that would integrate disparate applications into a single information space. The specificity of this work was that the applications were developed using various Web technologies and were physically located on different servers. From a technical point of view, there was only one solution in order to “make friends” of these applications - to apply HTML frames. HTML frames are a set of HTML tags that allow you to split the browser window into several parts, in each of which you can display any Internet sites, Web applications and Web pages. The highlight of this approach was that one of the frames (one of the independent parts of the browser) contained a set of links in the form of a simple list or tree, the other frame displayed Internet sites, Web applications, Web pages, PDF documents, MS Office documents (Word, Excel, PowerPoint, etc.), photos, etc. (in the future we will call this content or Internet resources). At the same time, there was no difference where the displayed content and the type of content were located.
Outwardly, it looked like this: the browser window was divided into two unequal parts (frames). On the left side (narrower), links were displayed in the form of a list or tree, and on the right, the content related to the selected link from the left was loaded. Thus, a console of applications and documents was created, which combined disparate applications and documents into a single information space. The console also allowed searching, navigation, and even information protection.
Based on the developed solution, I offered to release a product for creating corporate sites, which did not find my support from the management. The typical reaction of a large company manager to any innovation is well described in Jack Trout's book “Feeling a Horse”. However, I did not give up trying to create a new product by working in the following two companies. At the same time, each time the “engines” for the corporate website became more and more perfect.
Over time, the use of HTML frames has come to be seen as “bad practice” in building Web applications. An exception was made only for the IFRAME HTML tag, which allows you to add an independent browser window anywhere on the Web page and display any content in it. As a result, I started experimenting with pages with a built-in link tree and an IFRAME tag. At the same time, when a link was clicked in the tree, the content was loaded inside the IFRAME tag. Naturally, the tree soon became dynamic based on JavaScript, with levels loaded as needed. There was even a version in which the tree was replaced with a set of “icons”.
With the advent of Ajax technology, the idea came up to load HTML / XHTML content using Ajax technology, and then display it by inserting content through the JavaScript property innerHTML (in general, the DIV tag). This worked perfectly for related applications - applications using the same CSS and JavaScript files.
The next step was the idea of extracting all the necessary CSS and JavaScript files related to the loaded HTML / XHTML document (content) and inserting them into the main document. Cool idea, simple at first glance. I spent a lot of time before covering most of the possible situations, browser differences, etc. The result of the work was the ajax4all JavaScript library, which allows using JavaScript to insert almost any HTML / XHTML document (Web application) into another HTML / XHTML document (Web application), and then work with one and the other with virtually no problems ( remark: of course, there may be a problem with the same names for CSS classes and JavaScript methods and classes, but even this problem can be solved programmatically by changing the names of CSS classes and JavaScript classes and methods).
It so happened, while working on a project that would later be migrated to the WebLogic Portal, I became acquainted with portal solutions. As a result, the main thing happened - two passion ideas combined, and as a result, Ajax Portal appeared.
Portals allow you to create your pages based on portlets, which are small independent applications. Portlets are displayed as small independent windows on a portal page, which can include several to several dozen portlets. If necessary, portlets can communicate with each other (interportlet communication). Using portlets allows modular software development.
Portals also allow you to aggregate (combine) data from different sources within a single portal page, which allows you not to search for information among several applications, but to see it within a single browser page (if necessary, several pages). This makes it possible to expedite decision making.
The next advantage of portals is customization - the ability to customize portal pages: it becomes possible to move portlets, add new ones, delete old ones, minimize and expand portlets, i.e. customize the desktop (workspace) without involving programmers. This allows you to provide the greatest comfort when working with information and its processing.
What the Ajax Portal gives the developer of enterprise portals:
- Client-side content aggregation (in the browser using JavaScript) is more efficient than classic server-side content aggregation, which is based on the JSR-168 and JSR-286 standards.
- Reduce the load on the portal server. Content and data are sent directly from the portlet server (the server on which the portlet application is running) to the browser, bypassing the portal server. Traffic reduction occurs approximately ten times - twenty times and depends on the number of portlets on the portal page.
- Any change in a portlet occurs without reloading the entire portal page, including adding a new one or deleting an old portlet. As a result, everything works faster.
- Portlets can open new and close old portlets (delete from the portal page) without reloading the entire portal page.
- Simplified data exchange with other portlets (interportlet communication). This can be done either through the core of the portal page, or through a portal or portlet server.
- The need for a processAction method has disappeared.
- There is no need to support bulky bridges based on the JSR-301 and JSR-329 standards, and as a result, a single way to download content and resources has appeared.
- Now you can use regular Web applications as portlets (in the particular case of mashups, this will be discussed in one of the following articles). In addition, the use of porjax (Web applications with portlet descriptors) can be considered a special case.
- As portlets, you can use versions of the Web application for mobile devices that are designed to be displayed on screens with relatively low resolution. This is ideal for displaying such applications in portlets (for example, mobile versions of Odnoklassniki social network applications or ATO.BY geo-services ).
- The lack of a specific API. As a result - cheaper affordable skilled labor (this is more interesting to the manager or architect).
All that I cited above ultimately leads to a reduction in the cost of creating software and lowering the fixed costs of its maintenance. This is all basically achieved using the ajax4all library. She is the heart of Ajax Portal.
When creating the ajax4all library, I was faced with the need to convert all relative links to images, styles and scripts into absolute links. Otherwise, getting into the portal page, the real address of each relative link began to be calculated by the browser relative to the address of the portal page. The only serious problem is the relative addresses "wired" in the JavaScript code. In this case, the solution is only to adapt the Web application (introducing best practice for Web applications that are supposed to be used as portlets).
The second task in creating the ajax4all library was to convert regular hypertext links into Ajax request calls, followed by replacing the content in the portlet window.
Most Web applications still use HTML forms, i.e. it turned out to be insufficient to simply “isolate” the content of the Web application used as the portlet and paste it into the portlet page. It was also necessary to change relative links in HTML forms. In turn, the question arose, what to do with the functionality of the forms themselves? –Any submit HTML form by Submit button or using JavaScript usually led to reloading all the portal pages, instead of reloading the content in the portlet window.
A way out was found through the use of the Ajax Submit pattern, which became the de facto standard. The essence of this pattern is to replace the usual submit HTML form with a request using Ajax and then receive a standard server response, convert it and insert it into the portal page inside the portlet window. It sounds simple, but it took several months to find an acceptable architectural solution. The complexity of the task was the significant differences in the browser DOM model. Moreover, the most moody browser when writing JavaScript turned out to be Internet Explorer, and not Safari, as is usually believed.
Initially, I intended to support both types of aggregation: on the client side (in the browser using JavaScript) and the classic approach on the server side (portal server). Practice has shown that the approach using conventional Web applications is too good, and the branch supporting aggregation on the server side was abandoned. Maybe I will return to her, but later ...
Having lost the classical Java Portlet API (100% compatible with JSR-168 and JSR-286 standards), I achieved the main thing: Ajax Portal is built on the basis of HTML, CSS and JavaScript. This means that there is no dependence on the platform (including the programming language) of the server part of the portal. As a result, Ajax Portal can be considered a cross-platform solution. Java Web application development was supported through a JSP tag library. Once the library is stabilized and new tag attributes cease to appear, it will be possible to create a JSF component library. In June of this year (2011), I was joined by a .NET developer who made a library for .NET. With the advent of the PHP version - it will be possible to proudly declare that Ajax Portal is an absolutely cross-platform solution. There is an idea to make a library for Perl, but this is a distant prospect.
As an alternative to the Portlet API in Java, the project can offer the MicroServlet Java MVC framework. This was an example for my book on Java, which allows you to build a full-fledged Web application literally on the basis of one class (based on HttpServlet). The framework supports bean forms and JSP pages. Widely used Java annotations. This is the perfect solution for creating a portlet that can have just one or two methods. Users will give their answer "to be him or not to be." I like. While the MicroServlet framework is getting closer and closer to Spring MVC. I have not yet figured out whether this is good or bad. The latest trend is the new Portlet API based on the MicroServlet framework. It will be convenient for users to show time.
Often, portal solutions are associated with CMS. I consider it absolutely not advisable to create my own implementation of CMS, because many startups are trying to occupy an already crowded niche. There are enough solutions, both commercial and free open source. On the other hand, the architecture of Ajax Portal allows you to use the portal as a CMS with reduced functionality. I think it will be necessary to devote a separate article to this.
I came across another interesting fact - when creating real applications, potential customers want to use their developments for the authorization and authentication systems already used in the enterprise. Therefore, questions on the implementation of the security module are still open.
Each version of Ajax Portal, in addition to the ajax4all library and the Portlet API based on the MicroServlet framework, brings some innovations. For versions 1.0. *, Such an innovation is the dynamic transformation of regions (the portlet container on the portal page). State pattern applied. Transformation is done using CSS. CSS markers are used as markers. With the same structure of HTML / XHTML code, depending on the marker, the representation of the region and portlets changes. A region can be converted from a standard view (each portlet is displayed in a small window) to an accordion or bookmark system. In addition, it is possible to present the entire region as a single window without highlighting porlets. There is also a view in which there is no all-round decoration of portlets and the region.
Over the past few years, many companies have left the portal solutions market. Many startups and open source solutions have been abandoned. In my opinion, the main reason is that the JSR-286 standard was not able to realize the potential of Ajax technology. The JSR-286 standard, released after the introduction of Ajax, actually only expanded the capabilities of JSR-168, but did not bring anything new. It is these problems that the ajax4all library is designed to solve.
The latest fashion trend is a smooth transition of portal solutions towards mashups. I think this is a topic for a separate article. Ajax Portal is located in the niche between enterprise portals and mashups. The result is a cross-browser cross-platform Web 2.0 portal / mashup with support for customization and personalization.
The main question for any startup is its analogues. I searched for a long time and searched well, but have not yet found. If you, readers of this article, know them, I will be very grateful if you indicate them to me. Please note that this is:
- about an alternative to the HTML IFrame tag and replacing it with Ajax requests,
- implement Ajax Submit patterns for standard Web applications without their special preparation (offline).
And the second question that usually arises, and why this has not been done before? - Previously, there was no standard “ Cross-Origin Resource Sharing, ” which specifies the ability to send Ajax requests outside the current domain. Ajax Portal for remote portlets also supports proxy.
I “dissected” many popular solutions, including iGoogle, and found that they all basically use the HTML IFrame tag. Therefore, the ajax4all library is the only alternative I know of with the HTML IFrame tag for remote portlets. When using ajax4all in the Ajax Portal, it becomes possible to naturally fill the selected area with content and proportionally stretch it vertically, exactly what cannot be achieved using the HTML IFrame tag.
Continuation:
http://habrahabr.ru/blogs/AJAX/125568/