Monday, March 30, 2009
Bug in Twitter API
Twitter API is broken. Request direct messages since some ID does not work - it returns all messages! So, for example, our bot t411 is starting to resend old replies again ...
Thursday, March 26, 2009
Cache in Java
Interesting articles about cache in Java applications. Author targets the following Open Source frameworks: OSCache,Ehcache,JCS and Cache4J.
From our side we would like to point also your attention to the following cache related components: Cache taglib and Cache filter. They are very easy to use add-ons for your web applications.
From our side we would like to point also your attention to the following cache related components: Cache taglib and Cache filter. They are very easy to use add-ons for your web applications.
Wednesday, March 25, 2009
PDF in Java
A good practical article - how to create PDF in Java. Based on the Open Source library iText. Interesting, the latest version of iText supports barcodes.
P.S. And for the web applications you can check out the following component from Coldtags suite: Acroform. It is also iText - based component, lets you proceed so called Acroform (actually - templates in pdf) right in JSP.
P.S. And for the web applications you can check out the following component from Coldtags suite: Acroform. It is also iText - based component, lets you proceed so called Acroform (actually - templates in pdf) right in JSP.
Tuesday, March 24, 2009
JSOS 6.25
Coldbeans Software announced the next milestone in JSOS (servlets office suite) development. JSOS reaches the version 6.25. This largest collection of Java servlets and filters provides 130+ "out of the box" components ready for building web-pages.
Check out more here: http://www.servletsuite.com
Check out more here: http://www.servletsuite.com
Saturday, March 21, 2009
Friday, March 20, 2009
Visual traceroute
GeoTrace mashup has been updated. This web tool lets you visualize the results for traceroute. Do traceroute from your own computer, copy results into mashup window and click Show button. You will see the intermediate nodes right on Google Maps.
Technically is is a practical example for our GeoIP component as well as for Ajax taglibs from Coldtags suite
Technically is is a practical example for our GeoIP component as well as for Ajax taglibs from Coldtags suite
Wednesday, March 18, 2009
Money on the map
Googlebar control lets you show your Adsense in the local search on the Google Maps.
You can see it on the practice in Big map mashup.
You can see it on the practice in Big map mashup.
Sunday, March 15, 2009
Friday, March 13, 2009
Access restriction filter
Yet another solution for access restriction: This host filter. Lets you restrict access to some resources (as per filter's mapping in web.xml file) to the particular host (hosts) only. Hosts should be described by their IP's (comma separated list). By default the localhost (127.0.0.1) only is allowed.
P.S. and for access restriction via setting mandatory referer you can see Force referer filter.
P.S. and for access restriction via setting mandatory referer you can see Force referer filter.
Thursday, March 12, 2009
Queue in the cloud
Interesting service - online Message Queue. OnlineMQ provides simple queuing messaging services such as IBM Websphere MQ and Microsoft MQ, but data are online. They promise to keep the service free.
Wednesday, March 11, 2009
Tuesday, March 10, 2009
Struts 2
The following files must be in Struts 2 Hello World application. Sometimes I really think that something is very very deep wrong with so called Java "frameworks" ...
Monday, March 09, 2009
Schedulers in web applications
What if your web application requires some periodical process? It is good when your hosting provides some kind of cron tab scheduler, lets you invoke your own application, but it is not so widely used option. One trick we've used for example in Twitter 411 mashup (periodical polling with Twitter API) simply "borrows" requests from site visitors. You can add to your site a hidden (invisible) iframe where src attribute points to the "scheduler". And your "scheduler" will perform the requests to your periodical tasks (implemented as JSP pages or servlets). This trick described here. But it is applied level timer support.
Another option (system level) is Lifecycle modules. Lifecycle listener modules provide a means of running short or long duration Java-based tasks within the application server environment, such as instantiation of singletons or RMI servers. These modules are automatically initiated at server startup and are notified at various phases of the server life cycle.
The lifecycle module classes are called synchronously from the main server thread and Lifecycle modules can create threads if appropriate.
And the third option is writing custom MBeans. See for example Timer MBean
Another option (system level) is Lifecycle modules. Lifecycle listener modules provide a means of running short or long duration Java-based tasks within the application server environment, such as instantiation of singletons or RMI servers. These modules are automatically initiated at server startup and are notified at various phases of the server life cycle.
The lifecycle module classes are called synchronously from the main server thread and Lifecycle modules can create threads if appropriate.
And the third option is writing custom MBeans. See for example Timer MBean
Sunday, March 08, 2009
Thursday, March 05, 2009
Bookmarklets
Our bookmarklets mentioned in this blog collected on the separate web page: Abava bookmarklets
Wednesday, March 04, 2009
Twitter: map on demands
One new service for Twitter - map on demands. Based on our Twitter 411 mashup (see more articles about Twitter 411 here).
It is a bot lets you obtain a map for some address. How does it work:
1. Follow to t411
2. Send to t411 a direct message in the following format:
map some_address
For example:
map Palo Alto
you will get the response in Twitter (as a direct message too) with the map for the given address. The map will be delivered in the form of the static picture - so you can see it on any mobile phone for example. We are using here the same idea as in our Mobile Maps mashup - Google static maps.
Your comments and suggestions are welcome.
And here you can read the technical details - how to create the similar new bot for Twitter by your own.
It is a bot lets you obtain a map for some address. How does it work:
1. Follow to t411
2. Send to t411 a direct message in the following format:
map some_address
For example:
map Palo Alto
you will get the response in Twitter (as a direct message too) with the map for the given address. The map will be delivered in the form of the static picture - so you can see it on any mobile phone for example. We are using here the same idea as in our Mobile Maps mashup - Google static maps.
Your comments and suggestions are welcome.
And here you can read the technical details - how to create the similar new bot for Twitter by your own.
Tuesday, March 03, 2009
Smart Card web server programming
This post summarizes a presentation of Web Gate project (Dmitry Namiot, Simagine 2009 Innovation Award).
Web gate for SCWS
Introduction
Web gate project presents a bridge for the mobile Internet and Smart Cards Web Server (SCWS). This bridge provides a "standard" (practically defined and implemented) way for the mobile internet developers (web developers) to deploy smart cards based features in the own projects. All in all, Web gate is a development tool targets web developers and provides for them a smooth access to smart cards features.
Project description
The main idea behind this project is how to mix SCWS and mobile Internet. No doubt, that the mobile internet word is much bigger, than the potential SCWS-alone based projects. So the aim of this project is to bring SCWS-based capabilities to the mobile internet developers. Let them deploy smart cards based projects via the familiar (well known) for them web tools.
As per above-declared goals we have to implement at least the following things:
- propose a set of the components (widgets), provided access to the smart cards features
- propose a smooth integration for the selected components into modern web development tools
As a result web developers will get a tool (it is a key point – we are providing project for SCWS, but our target is actually web development crowd), let them access to smart cards features without knowing any technical details about smart card programming. And even more – this access will be tied to the web development exclusively, so there is no need in the new development skills for the web developers at all.
From our understanding the ability to win developers is a key issue for any new computer platform, including smart cards. Such a win can provide a stream of the new applications from the development community and so make the platform successful. And on this way the web development is becoming the mainstream. At the first hand it is so due to its simplicity and the huge army of the developers. So we are expecting here, that adding for web developers some forms of the convenient access to the smart cards data will be more than simply requested feature. This feature will smoothly enhance the existing development tools without adding a new complexity for the developers. It is the main idea behind our Web gate project.
Main features
Web gate offers a set of web controls (widgets) for the mobile web pages. We’ve decided to provide these controls in the form of custom tag. It is a standard approach for the extending markup languages (e.g. HTML), supported nowadays in all the development frameworks (e.g. JSP, ASP, ASP.NET etc.) These tags, being rendered by the application server (servlets container like Tomcat) provides at the end some piece of HTML code. So the initial page could be loaded as usually into browser on the mobile phone.
HTML code, generated by the components contains links to the SCWS. So the user could activate these links and get access to the appropriate servlets on SCWS. And these servlets (also part of Web gate package) provide access to the smart card features (to the features available via smart cards). So for the user this smart card access is just a click away from the original (loaded) page.
There are two types of code chunks created by the Web gate components. The first type is just a "direct" access to card’s features. For example: make a call, send SMS etc. HTML code chunk created by the component is just a "normal" hyperlink pointing to some SCWS servlet, where the relevant attributes (e.g. phone number to call) could be provided as servlet’s parameters
The second type of the components lets developers personalize forms with the data stored on (provided by) the smart card. It is HTML form that should be submitted to some CGI server (as per mobile web page business processes) where some fields could be filled by the data from the smart card. E.g. read some data file from the smart card and use its data within the form or request a cell id and use it as a value for some hidden form’s field etc. So this chunk of HTML code is a form again but instead of the real CGI it could be passed to the SCWS servlet. This servlet will request data from the smart card and return back the initialized form pointed to the real CGI script again. The drawback here is an extra click (submit the form to the localhost). But the positive elements are prevailing in our opinion: high level of customization (substitute data from the smart card), improved usability (no manual typing), safety (do not memorize keys and id’s – they will be extracted from the smart card), high level of the personalization (telecom operators will be able to provide cards with own data for use them in mobile web). And all of this just for the price of one extra click.
High level architecture
Here is what we did (proposed) from the practical point of view. As per life cycle of the typical web application:
1. Web developers prepare a mobile site (page)
2. Web page may include components (controls) pointed to the smart cards. The word "pointed" here describes either the ability request some functionality from the card (via the card) or the ability to get some data, saved on the card and reuse them (data) across the page (within the web application)
3. Page is requested by the web-browser (as usually) from the mobile terminal. As it is stated above the loaded page may include SCWS related stuff. Due to nature of HTML we have the well defined abilities to present the potential actions. It either a hyperlink or a form. So in our case we could present either some hyperlink, pointed to SCWS resource or some form, where the action attribute pointed to SCWS resource (servlet).
4. User may activate SCWS related things (controls) right from the browser. As per the above-mentioned nature of the components it either simply click on the hyperlink or submitting the form.
5. The hyperlinks will be used for the direct actions: place a new call, send a new SMS.
6. The forms will be used for the access to the data, saved on the smart cards. The typical use case is the following. The original mobile web page contains HTML form, where some of the fields should be filled by the data saved on the smart card.
Smart card is a trusted source. So the operator raised the card could save, for example, some own data on the card. It could be for example client’s id (ids), some preferences, marketing related data (sex, age group etc.) And later, when the card owner surfs the Net with the own mobile, the above-mentioned data could be used within the web applications.
What does it mean "used" here? All the existing web applications at the end of the day do absolutely the same things regardless of their business area – perform HTTP requests. E.g. customer fills out some form and submits it to the server. And here the smart cards data goes to the scene. We can add the data from the card to the form. So, technically the target web application will get via HTTP request some parameters, filled (initialized) from the smart card.
How can we do that? We can do it through the followings steps:
- replace action attribute of the original form with our SCWS servlet
- submit the original form to our SWSC application first
- fill the parameters and return back a new page (with the original form again!) where action attribute will be pointed to the its original destination. And some the fields within the returned form could be filled (initialized) by card’s data
So it is an extra click from the user’s point of view (submit form to SCWS servlet first), but for such minimal usability discrimination we can get a huge advantages. This process let us automatically pickup within our form any data right from the smart card. You can see this process as an analogue of form auto-filling, where data comes right from smart card. So it is a practical way for the personalization in the mobile internet.
And by the way, by the same principles we can save some data right on the card for the future usage.
Also we can mark here, that the described approach is similar by the some manner to the well known approach in the web development called ‘url rewriting’. As you can see above, we also "rewrite urls", but do actually a much more than simply session id adding.
Usage scenario
Now let us see how to incorporate our "smart controls" into mobile web pages. In order to make the easy transition to new components for the web developers we are providing the components as custom tags. Tags are familiar for the web development crowd. And all the modern IDE support custom tags.
So in this project we propose components as custom JSP taglibs. They will work "as is" in JSP and/or Coldfusion projects. The similar approach could be moved practically "as is" to ASP.NET world for example.
As we stated above there are two types of components (controls) pointed (referred) to the SCWS:
1. Hyperlinks, actually requested some actions from Smart Cards. The typical use cases are: place a call, send a new SMS.
2. Forms. Actually will be used for the requesting the stored data right from the cards.
For the actions the JSP inclusion looks so (sc here is a prefix, assigned for the taglib):
<!-- make a call -->
<sc:MakeCall phone="1800976"/>
<!-- send a SMS -->
<sc:SendSMS phone="1800976">how are you</sc:SendSMS>
web developers places a links (of course, the attributes could be generated dynamically) and the actual action (place a call, send a SMS) is just an ordinary link activation.
Let us see how the new (smart) forms looks like.
the original form on the web page looks so:
<form action="your_real_action" method="post">
<input type="hidden" name="id"/>
Name: <input type="text">
<input type="submit" value="Submit" />
</form>
our goal is to obtain a value for ID field (hidden field in the form) from user’s smart card. So we offer to the user submit the form to SCWS, our servlet will calculate ID (e.g. read its value from some file, preloaded by the telecom operator) and returns back the same form with the initialized fields. This “smart” form could be presented so:
<!-- submit form to SCWS servlet at the first hand -->
<sc:Form scws="your_scws_servlet" action="your_real_action" method="post">
<input type="hidden" name="id"/>
Name: <input type="text">
<input type="submit" value="Submit"/>
</sc:Form>
this example illustrates the idea with the forms (see above about the components). Code generated by this tag is just a form too, but its action will be described by the attribute scws. So the form could be submitted to our servlet. Servlet will calculate "smart" data and return back the original (here is the trick!) form with the pre-filled data:
<form action="your_real_action" method="post">
<input type="hidden" name="value_from_smart_card"/>
Name: <input type="text">
<input type="submit" value="Submit"/>
</form>
The technical implementation
For the actions (MakeCall, SendSMS) taglib simply generates a link to the appropriate SCWS servlet (the real link to http://127.0.0.1:3516/...)
For the forms taglib creates a form again, changes the action attribute (now it must be our SCWS servlet) and passes the whole original form (tag’s body) as a parameter. Servlet can read this parameter (the original form), replace (substitute) some data within it and return it back.
Conclusion
No doubt, that mobile web area is huge. Smart Card Web Server as per spec is somewhat isolated from the web. The proposed tools fill the gap, combining the best things from the both words: wide adoption of mobile web will meet the high level of personalization. And two tings are especially important here: the personalization comes from the trusted source (smart card) and uses the instruments the web developers are familiar with already.
And what is especially important, that the proposed add-on follows actually to the development model web programmers are already familiar with.
Web gate project suggests the practical approach for the mobile web developers – how to incorporate smart cards features into web projects. The biggest advantage of the suggested method is its smooth (natural) incorporation into the current web development practice. The gate does not introduce a new paradigm for the web developers and leverages their existing skills.
Another big advantage is the openness of the project (the ability to extend it). It is very easy to suggest (add) new components, where new stuff could be added any time without changing the already implemented things.
Web gate for SCWS
Introduction
Web gate project presents a bridge for the mobile Internet and Smart Cards Web Server (SCWS). This bridge provides a "standard" (practically defined and implemented) way for the mobile internet developers (web developers) to deploy smart cards based features in the own projects. All in all, Web gate is a development tool targets web developers and provides for them a smooth access to smart cards features.
Project description
The main idea behind this project is how to mix SCWS and mobile Internet. No doubt, that the mobile internet word is much bigger, than the potential SCWS-alone based projects. So the aim of this project is to bring SCWS-based capabilities to the mobile internet developers. Let them deploy smart cards based projects via the familiar (well known) for them web tools.
As per above-declared goals we have to implement at least the following things:
- propose a set of the components (widgets), provided access to the smart cards features
- propose a smooth integration for the selected components into modern web development tools
As a result web developers will get a tool (it is a key point – we are providing project for SCWS, but our target is actually web development crowd), let them access to smart cards features without knowing any technical details about smart card programming. And even more – this access will be tied to the web development exclusively, so there is no need in the new development skills for the web developers at all.
From our understanding the ability to win developers is a key issue for any new computer platform, including smart cards. Such a win can provide a stream of the new applications from the development community and so make the platform successful. And on this way the web development is becoming the mainstream. At the first hand it is so due to its simplicity and the huge army of the developers. So we are expecting here, that adding for web developers some forms of the convenient access to the smart cards data will be more than simply requested feature. This feature will smoothly enhance the existing development tools without adding a new complexity for the developers. It is the main idea behind our Web gate project.
Main features
Web gate offers a set of web controls (widgets) for the mobile web pages. We’ve decided to provide these controls in the form of custom tag. It is a standard approach for the extending markup languages (e.g. HTML), supported nowadays in all the development frameworks (e.g. JSP, ASP, ASP.NET etc.) These tags, being rendered by the application server (servlets container like Tomcat) provides at the end some piece of HTML code. So the initial page could be loaded as usually into browser on the mobile phone.
HTML code, generated by the components contains links to the SCWS. So the user could activate these links and get access to the appropriate servlets on SCWS. And these servlets (also part of Web gate package) provide access to the smart card features (to the features available via smart cards). So for the user this smart card access is just a click away from the original (loaded) page.
There are two types of code chunks created by the Web gate components. The first type is just a "direct" access to card’s features. For example: make a call, send SMS etc. HTML code chunk created by the component is just a "normal" hyperlink pointing to some SCWS servlet, where the relevant attributes (e.g. phone number to call) could be provided as servlet’s parameters
The second type of the components lets developers personalize forms with the data stored on (provided by) the smart card. It is HTML form that should be submitted to some CGI server (as per mobile web page business processes) where some fields could be filled by the data from the smart card. E.g. read some data file from the smart card and use its data within the form or request a cell id and use it as a value for some hidden form’s field etc. So this chunk of HTML code is a form again but instead of the real CGI it could be passed to the SCWS servlet. This servlet will request data from the smart card and return back the initialized form pointed to the real CGI script again. The drawback here is an extra click (submit the form to the localhost). But the positive elements are prevailing in our opinion: high level of customization (substitute data from the smart card), improved usability (no manual typing), safety (do not memorize keys and id’s – they will be extracted from the smart card), high level of the personalization (telecom operators will be able to provide cards with own data for use them in mobile web). And all of this just for the price of one extra click.
High level architecture
Here is what we did (proposed) from the practical point of view. As per life cycle of the typical web application:
1. Web developers prepare a mobile site (page)
2. Web page may include components (controls) pointed to the smart cards. The word "pointed" here describes either the ability request some functionality from the card (via the card) or the ability to get some data, saved on the card and reuse them (data) across the page (within the web application)
3. Page is requested by the web-browser (as usually) from the mobile terminal. As it is stated above the loaded page may include SCWS related stuff. Due to nature of HTML we have the well defined abilities to present the potential actions. It either a hyperlink or a form. So in our case we could present either some hyperlink, pointed to SCWS resource or some form, where the action attribute pointed to SCWS resource (servlet).
4. User may activate SCWS related things (controls) right from the browser. As per the above-mentioned nature of the components it either simply click on the hyperlink or submitting the form.
5. The hyperlinks will be used for the direct actions: place a new call, send a new SMS.
6. The forms will be used for the access to the data, saved on the smart cards. The typical use case is the following. The original mobile web page contains HTML form, where some of the fields should be filled by the data saved on the smart card.
Smart card is a trusted source. So the operator raised the card could save, for example, some own data on the card. It could be for example client’s id (ids), some preferences, marketing related data (sex, age group etc.) And later, when the card owner surfs the Net with the own mobile, the above-mentioned data could be used within the web applications.
What does it mean "used" here? All the existing web applications at the end of the day do absolutely the same things regardless of their business area – perform HTTP requests. E.g. customer fills out some form and submits it to the server. And here the smart cards data goes to the scene. We can add the data from the card to the form. So, technically the target web application will get via HTTP request some parameters, filled (initialized) from the smart card.
How can we do that? We can do it through the followings steps:
- replace action attribute of the original form with our SCWS servlet
- submit the original form to our SWSC application first
- fill the parameters and return back a new page (with the original form again!) where action attribute will be pointed to the its original destination. And some the fields within the returned form could be filled (initialized) by card’s data
So it is an extra click from the user’s point of view (submit form to SCWS servlet first), but for such minimal usability discrimination we can get a huge advantages. This process let us automatically pickup within our form any data right from the smart card. You can see this process as an analogue of form auto-filling, where data comes right from smart card. So it is a practical way for the personalization in the mobile internet.
And by the way, by the same principles we can save some data right on the card for the future usage.
Also we can mark here, that the described approach is similar by the some manner to the well known approach in the web development called ‘url rewriting’. As you can see above, we also "rewrite urls", but do actually a much more than simply session id adding.
Usage scenario
Now let us see how to incorporate our "smart controls" into mobile web pages. In order to make the easy transition to new components for the web developers we are providing the components as custom tags. Tags are familiar for the web development crowd. And all the modern IDE support custom tags.
So in this project we propose components as custom JSP taglibs. They will work "as is" in JSP and/or Coldfusion projects. The similar approach could be moved practically "as is" to ASP.NET world for example.
As we stated above there are two types of components (controls) pointed (referred) to the SCWS:
1. Hyperlinks, actually requested some actions from Smart Cards. The typical use cases are: place a call, send a new SMS.
2. Forms. Actually will be used for the requesting the stored data right from the cards.
For the actions the JSP inclusion looks so (sc here is a prefix, assigned for the taglib):
<!-- make a call -->
<sc:MakeCall phone="1800976"/>
<!-- send a SMS -->
<sc:SendSMS phone="1800976">how are you</sc:SendSMS>
web developers places a links (of course, the attributes could be generated dynamically) and the actual action (place a call, send a SMS) is just an ordinary link activation.
Let us see how the new (smart) forms looks like.
the original form on the web page looks so:
<form action="your_real_action" method="post">
<input type="hidden" name="id"/>
Name: <input type="text">
<input type="submit" value="Submit" />
</form>
our goal is to obtain a value for ID field (hidden field in the form) from user’s smart card. So we offer to the user submit the form to SCWS, our servlet will calculate ID (e.g. read its value from some file, preloaded by the telecom operator) and returns back the same form with the initialized fields. This “smart” form could be presented so:
<!-- submit form to SCWS servlet at the first hand -->
<sc:Form scws="your_scws_servlet" action="your_real_action" method="post">
<input type="hidden" name="id"/>
Name: <input type="text">
<input type="submit" value="Submit"/>
</sc:Form>
this example illustrates the idea with the forms (see above about the components). Code generated by this tag is just a form too, but its action will be described by the attribute scws. So the form could be submitted to our servlet. Servlet will calculate "smart" data and return back the original (here is the trick!) form with the pre-filled data:
<form action="your_real_action" method="post">
<input type="hidden" name="value_from_smart_card"/>
Name: <input type="text">
<input type="submit" value="Submit"/>
</form>
The technical implementation
For the actions (MakeCall, SendSMS) taglib simply generates a link to the appropriate SCWS servlet (the real link to http://127.0.0.1:3516/...)
For the forms taglib creates a form again, changes the action attribute (now it must be our SCWS servlet) and passes the whole original form (tag’s body) as a parameter. Servlet can read this parameter (the original form), replace (substitute) some data within it and return it back.
Conclusion
No doubt, that mobile web area is huge. Smart Card Web Server as per spec is somewhat isolated from the web. The proposed tools fill the gap, combining the best things from the both words: wide adoption of mobile web will meet the high level of personalization. And two tings are especially important here: the personalization comes from the trusted source (smart card) and uses the instruments the web developers are familiar with already.
And what is especially important, that the proposed add-on follows actually to the development model web programmers are already familiar with.
Web gate project suggests the practical approach for the mobile web developers – how to incorporate smart cards features into web projects. The biggest advantage of the suggested method is its smooth (natural) incorporation into the current web development practice. The gate does not introduce a new paradigm for the web developers and leverages their existing skills.
Another big advantage is the openness of the project (the ability to extend it). It is very easy to suggest (add) new components, where new stuff could be added any time without changing the already implemented things.
Monday, March 02, 2009
Mobile video
Mobile video site - Jokes: http://tinyurl.com/dxz5yt. Created with Mobile video mashup
You can copy the above mentioned link right to your phone with the help of QR-code.
Sunday, March 01, 2009
Twitter SMS
Free SMS provider for Twitter: Twe2. So you can still get direct messages as well as replies via SMS. And by the way it means that with the help of Twitter 411 service you can create a free information service for the mobile (it is a key!) users. So Twitter will play a role of a mobile development platform.
You can find a more about Twitter 411 - bot creator in this blog.
You can find a more about Twitter 411 - bot creator in this blog.
Subscribe to:
Posts (Atom)