Friday, August 6. 2010
Integrating Terminal Services into a Portal
At the end of 2009 I participated in a pre-sale involving a portal migration in a governmental environment. The portal had some content management, portlets and an uncommon feature: citrix. This customer worked in a quite special way, their employees usually were out of their own installations but they needed regular access to some internal applications. The problem was part of these programs were very old dos/windows desktop applications which could not be easily moved to the web (customer had upgraded some to new web technologies but a lot of them still worked following this old-fashioned way). The portal used an old version of Citrix XenApp to place these old windows applications the customer really needed inside the portal. Besides that, typical requirements in a portal developing were demanded (sso, cms, eye-candy,...). An one more thing, customer wanted to change citrix for other solution and themselves also talked about the new features of windows Terminal Services.
Remote Desktop Protocol or RDP is a proprietary protocol developed by Microsoft to provide graphical interface access from one computer to another remote one. This technology is also known as Terminal Services because of the former name of Microsoft RDP server software (now called Remote Desktop Services or RDS). Windows 2008R2 introduced the new 7.0 version of the protocol at the end of the last year but the main improvements were done in the jump between 5.2 and 6.0/6.1 versions. Let's summarize the changes:
So now RDP alone accomplishes all common client requirements. Remote Applications gives to the user a seamless desktop integration, TS Gateway moves RDP and Remote Applications to the internet, Web Access moves again RDP to the web and finally it seems there have been several bandwidth improvements to make a better experience (Microsoft published a good whitepaper about RDP bandwidth when 6.1 version was released).
Now the main problem is how to integrate RDP inside a portal. The easiest way is just using the TS Web Access inside an iframe (the same technique I used in the sudoku entry to show you the html design). Liferay for example has an IFrame portlet that lets you point the portlet region to another page (TS Web Access server in our case), integrating TS web application easily in your portal. But, in my opinion, TS Web Access is not the best option because it works using an ActiveX element which directly bans any OS different than Windows, any web browser different than internet explorer, any RDP client different than windows Remote Desktop Connection (RDC).
As always my solution is maybe more complex but I am sure it is more open and funny. Based on the fact that RDP connection settings can be saved in a RDP file (this way these files can be easily edited, copied, and distributed), my idea is developing a little portlet which shows to the user the remote applications configured and, when clicked, a generated rdp file is downloaded to be executed by local remote desktop client. This way the solution works in any system that has a RDP compatible application. Microsoft has free Remote Desktop Connection 7.0 for windows OSes and Microsoft Remote Desktop Connection 2.0.1 Client for Mac (it supports RDP 6.0). In a similar way I did with Skype, browser can be configured to open rdp files (application/x-rdp mime type) with the selected client-side application. Linux and other *nix OSes are another question and I will try to face this problem in a future post.
The solution is a simple JSF 2.0 portlet (deployed on liferay 6.0.2) that uses cassandra as repository to store the application data (remember I already commented this to you in a previous entry about cassandra database). Portlet implementation saves the complete rdp file (the same that is generated and exported from TS Remote Administration application) in the database. When you click the application link the rdp file is fetched from cassandra and downloaded to the client.
This time the video shows the following: on the right a Windows 2008 60-day evaluation version configured as TS Server; on the left my Windows XP with RDC 7.0 installed; using IE8 I access to liferay and search for Notepad application; after clicking on it the rdp file is downloaded from my portlet and the browser asks to open it; accepting the offer RDC client remotely opens Notepad; when a simple text file is saved on administrator desktop it can be shown on windows 2008 server. Take into account I could not install 2008R2 (cos Microsoft only distributes 64 bit version and my laptop is i386), so the server only supports protocol version 6.1. This version lacks new SSO features and TS client application does not ask for user and password cos I locally saved my credentials before and it is reusing them.
Clearly notepad is a useless program but integrating this kind of remote applications can be very very important in some environments (legacy applications, programs with expensive licenses, binaries with local limited access,...). RDP protocol and its new features open up a lot of new possibilities and portlet integration makes its management easier for end users.
Finally I want to point out the use of cassandra as repository and portletfaces bridge as portlet/JSF 2.0 joint. I already stated the worth of the first one in the commented cassandra entry but I had never talked about the second piece of software. Neil Griffin heads this java project to create a portlet bridge for the new JSF 2.0 specification. I used alpha 1 version in my skype/pidgin VoIP solution and alpha 3 in this TS portlet, and I have to mention the outstanding progress. Good job Neil!
Remote Desktop Protocol or RDP is a proprietary protocol developed by Microsoft to provide graphical interface access from one computer to another remote one. This technology is also known as Terminal Services because of the former name of Microsoft RDP server software (now called Remote Desktop Services or RDS). Windows 2008R2 introduced the new 7.0 version of the protocol at the end of the last year but the main improvements were done in the jump between 5.2 and 6.0/6.1 versions. Let's summarize the changes:
- Version 6.0 (November 2006 - Windows Vista):
- Terminal Services Remote Applications. Remote Programs are a feature of Windows Server Terminal Services that lets client computers connect to a remote computer and execute programs that are installed on it instead of the complete windows desktop. The experience is the same as running a program that is installed on the local computer. An administrator must first publish the programs for end-users to access them.
- Terminal Services Gateway servers. TS Gateway server is a type of gateway that enables authorized users to connect to remote computers on a corporate network. TS Gateway uses RDP together with HTTPS protocol to help create a more secure, encrypted connection. A TS Gateway server uses port 443 and transmits data through a Secure Sockets Layer (SSL) tunnel. TS Gateway opens usual RDP intranet solution up to the world wide web.
- Improved bandwidth tuning for RDP clients.
- Terminal Services Remote Applications. Remote Programs are a feature of Windows Server Terminal Services that lets client computers connect to a remote computer and execute programs that are installed on it instead of the complete windows desktop. The experience is the same as running a program that is installed on the local computer. An administrator must first publish the programs for end-users to access them.
- Version 6.1 (February 2008 - Windows Server 2008):
- Terminal Services Web Access. TS Web Access is a service that makes Windows Server programs (TS RemoteApp) available to users from a Web browser. TS Web Acces is a kind of application inside IIS that lets user start remote applications from a web browser. This feature is not a protocol improvement but a new feature of the windows server and client.
- Network level server authentication. Technology that requires the user to authenticate himself before a session is established with the server. Originally the server loaded the login screen for the remote user, this used up resources on the server, and was a potential area for denial of service attacks.
- Terminal Services Web Access. TS Web Access is a service that makes Windows Server programs (TS RemoteApp) available to users from a Web browser. TS Web Acces is a kind of application inside IIS that lets user start remote applications from a web browser. This feature is not a protocol improvement but a new feature of the windows server and client.
- Version 7.0 (October 2009 - Windows Server 2008R2 and Windows 7):
- Web Single Sign-On (SSO) and Web forms-based authentication. Web SSO makes sure that after a user is logged on, no additional passwords are required for RD Gateway, RD Web Access, RD Session Host servers and RemoteApp programs.
- Multiple improvements in bandwidth (aero glass composed desktop support, smooth fonts, audio and video redirection).
- Multiple features to Virtual Desktop Infrastructure or VDI integration (virtual desktops and pools).
- Web Single Sign-On (SSO) and Web forms-based authentication. Web SSO makes sure that after a user is logged on, no additional passwords are required for RD Gateway, RD Web Access, RD Session Host servers and RemoteApp programs.
So now RDP alone accomplishes all common client requirements. Remote Applications gives to the user a seamless desktop integration, TS Gateway moves RDP and Remote Applications to the internet, Web Access moves again RDP to the web and finally it seems there have been several bandwidth improvements to make a better experience (Microsoft published a good whitepaper about RDP bandwidth when 6.1 version was released).
Now the main problem is how to integrate RDP inside a portal. The easiest way is just using the TS Web Access inside an iframe (the same technique I used in the sudoku entry to show you the html design). Liferay for example has an IFrame portlet that lets you point the portlet region to another page (TS Web Access server in our case), integrating TS web application easily in your portal. But, in my opinion, TS Web Access is not the best option because it works using an ActiveX element which directly bans any OS different than Windows, any web browser different than internet explorer, any RDP client different than windows Remote Desktop Connection (RDC).
As always my solution is maybe more complex but I am sure it is more open and funny. Based on the fact that RDP connection settings can be saved in a RDP file (this way these files can be easily edited, copied, and distributed), my idea is developing a little portlet which shows to the user the remote applications configured and, when clicked, a generated rdp file is downloaded to be executed by local remote desktop client. This way the solution works in any system that has a RDP compatible application. Microsoft has free Remote Desktop Connection 7.0 for windows OSes and Microsoft Remote Desktop Connection 2.0.1 Client for Mac (it supports RDP 6.0). In a similar way I did with Skype, browser can be configured to open rdp files (application/x-rdp mime type) with the selected client-side application. Linux and other *nix OSes are another question and I will try to face this problem in a future post.
The solution is a simple JSF 2.0 portlet (deployed on liferay 6.0.2) that uses cassandra as repository to store the application data (remember I already commented this to you in a previous entry about cassandra database). Portlet implementation saves the complete rdp file (the same that is generated and exported from TS Remote Administration application) in the database. When you click the application link the rdp file is fetched from cassandra and downloaded to the client.
This time the video shows the following: on the right a Windows 2008 60-day evaluation version configured as TS Server; on the left my Windows XP with RDC 7.0 installed; using IE8 I access to liferay and search for Notepad application; after clicking on it the rdp file is downloaded from my portlet and the browser asks to open it; accepting the offer RDC client remotely opens Notepad; when a simple text file is saved on administrator desktop it can be shown on windows 2008 server. Take into account I could not install 2008R2 (cos Microsoft only distributes 64 bit version and my laptop is i386), so the server only supports protocol version 6.1. This version lacks new SSO features and TS client application does not ask for user and password cos I locally saved my credentials before and it is reusing them.
Clearly notepad is a useless program but integrating this kind of remote applications can be very very important in some environments (legacy applications, programs with expensive licenses, binaries with local limited access,...). RDP protocol and its new features open up a lot of new possibilities and portlet integration makes its management easier for end users.
Finally I want to point out the use of cassandra as repository and portletfaces bridge as portlet/JSF 2.0 joint. I already stated the worth of the first one in the commented cassandra entry but I had never talked about the second piece of software. Neil Griffin heads this java project to create a portlet bridge for the new JSF 2.0 specification. I used alpha 1 version in my skype/pidgin VoIP solution and alpha 3 in this TS portlet, and I have to mention the outstanding progress. Good job Neil!
Sunday, March 28. 2010
Integrating VoIP into a Portal
In the previous entry a proof of concept (PoC) about Skype portal integration was performed. Now we know presence and direct browser interaction to VoIP application are the two main requirements around instant messaging web integration. But Skype is not a intranet solution (it is a global VoIP service), so this entry is dedicated to present my little custom solution.
First of all the VoIP instant messaging client application have to be chosen. If you remember the preceding post besides presence and browser interaction, other features like multiplatform, audio/video support and open source license are required. At that time I studied several VoIP applications (empathy, ekiga, qutecom, spark/sparkweb with red5 extension, SIP communicator,...) but no one convinced me completely. Nevertheless a few months later pidgin released his new 2.6 version with new brand features: voice & video.
Pidgin (formerly named gaim) used to be the traditional instant messaging jabber/XMPP system for all the linux distributions and, although it has strong competitors now, I am dare to say it continues to be. The advantages of pidgin are a lot:
Once the userspace application is chosen the server side takes the turn. In this matter I am a complete newbie so I have just selected the easy option: OpenFire. It is a java XMPP server with GPL license which has several good features:
Comparing with Skype portal integration, the open source solution has some limitations. Starting a call directly is not possible because XMPP uri specification does not cover jingle (only message tag is available), and I suspect purple-url-handler is also unable to start an audio or video call against pidgin (it uses dbus communication and there are no methods for that). The purple-url-handler script does not start pidgin either (if the program is not already running I mean) but this behavior can probably be fixed modifying the python script.
So this time the video is simpler: I search myself in the whitepages portlet; then the add button is clicked which opens the new contact pidgin window up; after cancel that, chat/message link is used to start a conversation with myself; finally the video call is started but using pidgin conversation menu instead of a web page link.
Comments are welcome.
First of all the VoIP instant messaging client application have to be chosen. If you remember the preceding post besides presence and browser interaction, other features like multiplatform, audio/video support and open source license are required. At that time I studied several VoIP applications (empathy, ekiga, qutecom, spark/sparkweb with red5 extension, SIP communicator,...) but no one convinced me completely. Nevertheless a few months later pidgin released his new 2.6 version with new brand features: voice & video.
Pidgin (formerly named gaim) used to be the traditional instant messaging jabber/XMPP system for all the linux distributions and, although it has strong competitors now, I am dare to say it continues to be. The advantages of pidgin are a lot:
- Pidgin is GPL licensed and it is free.
- Pidgin is available in all Linux distros by default (official repositories), its web page has a installer for Windows and fink distributes it for Mac users. Besides we always have the chance of compiling it for our own. So the portlet can be deployed with instructions about how to use it or install it over the different OSes.
- With the new features (audio and video) the technical specs of the solution are also satisfied. Pidgin multimedia is integrated using GStreamer, so remember the configuration command is gstreamer-properties for any device selection.
- Pidgin comes with a python script purple-url-handler which interprets standard XMPP/Jabber uri protocol and can be integrated in the browser the same way I did with Skype. And, in this case, debian iceweasel installation was very easy, xmpp protocol was recognized by the browser and it let me choose purple-url-handler as executor script.
Once the userspace application is chosen the server side takes the turn. In this matter I am a complete newbie so I have just selected the easy option: OpenFire. It is a java XMPP server with GPL license which has several good features:
- Jingle support. Jingle is a XMPP extension that implements peer-to-peer (P2P) session control (signaling) for multimedia interactions such as in Voice over Internet Protocol or videoconferencing communications. In other words, it supports pidgin voice and video. Jingle let me also get rid of SIP servers which are always very complicated for a novice like me.
- Clustering support (commercial feature). OpenFire can be installed in a cluster environment. Two OpenFire servers can run at the same time improving scalability and availability.
- STUN server support. OpenFire has an embedded STUN Server that can be used to provide Public Address Discovering and help p2p clients in Jingle.
- Media proxy for Jingle. OpenFire acting as media proxy or TURN server can relay packets from one client to another, this will help clients using NAT.
- Presence plugin. There is a presence plugin that can be interrogated by the portlet in a similar way I did with Skype.
- It is extremely easy to install. Although OpenFire supports several databases or ldap authentication, it can be installed using a internal HSQLDB in an incredible easy installation process (only for test purposes). As you can imagine this was an important point for me.
Comparing with Skype portal integration, the open source solution has some limitations. Starting a call directly is not possible because XMPP uri specification does not cover jingle (only message tag is available), and I suspect purple-url-handler is also unable to start an audio or video call against pidgin (it uses dbus communication and there are no methods for that). The purple-url-handler script does not start pidgin either (if the program is not already running I mean) but this behavior can probably be fixed modifying the python script.
So this time the video is simpler: I search myself in the whitepages portlet; then the add button is clicked which opens the new contact pidgin window up; after cancel that, chat/message link is used to start a conversation with myself; finally the video call is started but using pidgin conversation menu instead of a web page link.
Comments are welcome.
Wednesday, March 24. 2010
Integrating Skype into a Portal
Some time ago I thought I was going to be involved in a intranet portal development. The portal had a lot of different parts but the most complicated one was, at first sight, a instant messaging integration with chat, voice and video requirements. The whole project needed be done with open source (customer meant to say free) solutions and selected VoIP client had to be multi-platform (at least windows, mac and linux). Although finally I was not involved a little investigation was performed and... What better place to summarize it than here!
The topic of this entry is web/portal instant messaging integration. So client software, sound or image quality, sip or jingle protocol, codecs or any other technical features of the VoIP solution are not taken into account. Following these factors the main question is: What does a portal need from the instant messaging software? I decided to search the answer looking what a enterprise quality solution gives. And who implements a good, tested, spread VoIP solution...
Skype was my reference.
A typical whitepages portlet needs to know the status of the user in the messaging solution (online, offline, eager to chat, do not disturb me or whatever) for showing it.
Skype mystatus.skype.com site lets anybody to share his status (online status needs a privacy option to be set in Skype client application). Service complete reference is available in a pdf provided by Skype but a quick summary is the following:
The whitepages portlet needs to interact with the VoIP userspace client application. Operations directly clicked from the browser have to be available in any portal solution: start a chat, a call, request authorization, etc. This way, when a work mate was found and displayed in the whitepages portlet we can, first, know his status (presence), and second, start a conversation or request/add him as our contact.
Skype uses for this purpose its own uri protocol. The complete detail for this little protocol is again in Skype developer site but its basics are very very simple:
Finally a little whitepages portlet is presented. It was deployed on a liferay 5.2 java portal running on tomcat 6 application server. The portlet accesses mystatus skype site using HTTP from the server side (web service like solution) and depending user status the rest of the options (chat, call,... ) are shown or hidden. The following video shows how I search myself in the portlet and start a call, from my brother skype account of course.
Long Live Rock 'n' Roll!
PS: A second entry about this topic is on schedule. An open source based VoIP solution will be used behind my little whitepages portlet.
The topic of this entry is web/portal instant messaging integration. So client software, sound or image quality, sip or jingle protocol, codecs or any other technical features of the VoIP solution are not taken into account. Following these factors the main question is: What does a portal need from the instant messaging software? I decided to search the answer looking what a enterprise quality solution gives. And who implements a good, tested, spread VoIP solution...
Skype was my reference.
Presence
A typical whitepages portlet needs to know the status of the user in the messaging solution (online, offline, eager to chat, do not disturb me or whatever) for showing it.
Skype mystatus.skype.com site lets anybody to share his status (online status needs a privacy option to be set in Skype client application). Service complete reference is available in a pdf provided by Skype but a quick summary is the following:
- http://mystatus.skype.com/skypename.txt gives the txt status representation of a user. For example, if I am online and http://mystatus.skype.com/rickyepoderi.txt is set in a browser, online is returned in plain text (text/plain mime).
- http://mystatus.skype.com/balloon/skypename returns a image with a balloon that says the user status (image/png mime). Using my skype user when online it returns the image at the right. So the easiest way to integrate skype presence service is adding a img link in a final html page as follows:
<img alt="Skype Status" src="http://mystatus.skype.com/balloon/skypename"/>
Browser interaction to VoIP client
The whitepages portlet needs to interact with the VoIP userspace client application. Operations directly clicked from the browser have to be available in any portal solution: start a chat, a call, request authorization, etc. This way, when a work mate was found and displayed in the whitepages portlet we can, first, know his status (presence), and second, start a conversation or request/add him as our contact.
Skype uses for this purpose its own uri protocol. The complete detail for this little protocol is again in Skype developer site but its basics are very very simple:
- skype:skypename?chat: Start a chat to this contact.
- skype:skypename?call: Start a call to this contact.
- skype:skypename?add: Add skypename to contact list; show authorization dialog.
- Add skype debian repository to your /etc/apt/sources.list adding the line:
deb http://download.skype.com/linux/repos/debian/ stable non-free
- Install skype and some python/skype functionality packages:
$ sudo apt-get install skype python-skype skysentials
- Download the python script that handles skype uris for your browser action_handler_1.0.py from philipp's page.
- Make firefox (iceweasel) to handle skype protocol using the script downloaded in the previous step. Although there are a lot pages that explain this point (Skype blogs, mozilla wiki and third party pages) no one worked for me and I modified mimeTypes.rdf file directly (this file is located under firefox profile directory, in iceweasel something like ~/.mozilla/firefox/XXXXXXX.default/mimeTypes.rdf). A diff between backup and modified file shows the following differences:
$ diff mimeTypes.rdf mimeTypes.rdf.bck
18d17
< <RDF:li RDF:resource="urn:scheme:skype"/>
60,62d58
< <RDF:Description RDF:about="urn:scheme:externalApplication:skype"
< NC:prettyName="skype"
< NC:path="/home/ricky/apps/action_handler_1.0.py" />
152,155d147
< <RDF:Description RDF:about="urn:scheme:skype"
< NC:value="skype">
< <NC:handlerProp RDF:resource="urn:scheme:handler:skype"/>
< </RDF:Description>
162,165d153
< <RDF:Description RDF:about="urn:scheme:handler:skype"
< NC:alwaysAsk="false">
< <NC:externalApplication RDF:resource="urn:scheme:externalApplication:skype"/>
< </RDF:Description>
Finally a little whitepages portlet is presented. It was deployed on a liferay 5.2 java portal running on tomcat 6 application server. The portlet accesses mystatus skype site using HTTP from the server side (web service like solution) and depending user status the rest of the options (chat, call,... ) are shown or hidden. The following video shows how I search myself in the portlet and start a call, from my brother skype account of course.
Long Live Rock 'n' Roll!
PS: A second entry about this topic is on schedule. An open source based VoIP solution will be used behind my little whitepages portlet.
« previous page
(Page 2 of 2, totaling 6 entries)
Comments