I heard many time that people have problems when refreshing a web page. Well, I really do not understand it and I would like that someone points me to a concrete example.
I agree totally that a stateless application has problems when doing a page refresh but then I would not call it an application but a service or something like that. My opinion is that an application needs some state representation and according to that state you can access stateless services. Thus, when doing a refresh you just show the same things that the user was seeing before the refresh.
Ok ok, what if you have 10000000 .... users ? What if an atomic bomb .... ? :) I have read a nice post about user data management sometimes ago but I forgot where I saw it. I will post the link as soon as I find it.
Actually, the article was stating that with 256 megs you can have a loooot of users, on which I agree totally. Of course, you can have a lot of data in the user session but what about load balancing, caches and ...
So, is memory the real problem for saving the state on the server side?
I think that on a technical level using AOP, Spring AOP / interceptors can be considered and used to solve the refresh problem.
Tuesday, December 11, 2007
Saturday, October 13, 2007
Rich Internet Application (RIA)
A non-expert talking about user interfaces should not be taken seriously, but here is some thoughts that came to my mind.
Well, a RIA is in fact a Web Application that has the features like a desktop application.
A classical web application (let's call it Web1.0 application) has something that we call web flows, presentations flows or whatever how else somebody use to call it. Those flows are page based flows and they dictate the way a user is browsing from one page to another and so on.
I would even say that the page flow is dictated by end user requirements for the usability of the application (i.e a real state application, bank application ... ).
A RIA (or Web2.0 apps) should not limit users to a predefined flow. I think there should be no flow at all, because the user should be able to do whatever he/she wants at any moment and in any way. For example, one should be able to lookup a contact information while writing an email.
Actually, MVC (model view controller) pattern helps in separating the user interface from the business logic. But, MVC has not much to do within this article so I will not discuss about it more.
In my mind a RIA should be totally decoupled from the server presentation flow, and there should be no presentation flow, as I said already.
What about loading the whole user interface at the startup time and let the user navigate through the application just the way he would do it in a desktop application? Well, there should be a possibility to enable some components to be loaded later for example the less used components. The communication with the server should be done using AJAX of course, but the presentation layer is entirely managed by the client side.
I agree that there are a lot of applications written following this principle already, but I guess there is some place to think about this and maybe add enhancements to this way of programming.
Well, a RIA is in fact a Web Application that has the features like a desktop application.
A classical web application (let's call it Web1.0 application) has something that we call web flows, presentations flows or whatever how else somebody use to call it. Those flows are page based flows and they dictate the way a user is browsing from one page to another and so on.
I would even say that the page flow is dictated by end user requirements for the usability of the application (i.e a real state application, bank application ... ).
A RIA (or Web2.0 apps) should not limit users to a predefined flow. I think there should be no flow at all, because the user should be able to do whatever he/she wants at any moment and in any way. For example, one should be able to lookup a contact information while writing an email.
Actually, MVC (model view controller) pattern helps in separating the user interface from the business logic. But, MVC has not much to do within this article so I will not discuss about it more.
In my mind a RIA should be totally decoupled from the server presentation flow, and there should be no presentation flow, as I said already.
What about loading the whole user interface at the startup time and let the user navigate through the application just the way he would do it in a desktop application? Well, there should be a possibility to enable some components to be loaded later for example the less used components. The communication with the server should be done using AJAX of course, but the presentation layer is entirely managed by the client side.
I agree that there are a lot of applications written following this principle already, but I guess there is some place to think about this and maybe add enhancements to this way of programming.
Friday, September 14, 2007
Svarog - call center
Svarog (http://sourceforge.net/projects/svarog/) is an open source web based call contact center. It is a "real time" application that shows informations happening on a PBX. The only implementation till now is done for Asterix PBX using asterisk-java library (http://asterisk-java.org/). Actually it receives all the informations from the PBX and can send actions to it such as making a call, hangup or transfer. Telephony is not the only way of communication used in Svarog, email and chat should be supported. Emails are queued and so, they are delivered in a FIFO way to different agents in the call center. There is a possibility to give different events (emails, telephony ... ) a higher priority so, if there is an email coming from a VIP client it should be possible to make it come directly to the first place.
As I said it is a web based application which shows everything in real time in your browser, meaning there is no need to install any software on your desktop. It is an AJAX application using DWR (http://getahead.org/dwr) for the javascript and server side java communication, coupled to the Springframework (http://www.springframework.org/) it offers solid bases for an application.
Well, Svarog is in fact developed as EDA (event driven architecture/application) but without using special frameworks for that, just java 5 queues to make the application asynchronous. These days I was looking if that could be improve with an embedded ESB as Mule but I am still not sure if this is a good idea to do that.
In this blog http://gradecak.blogspot.com/2007/09/jain-slee-or-esbjbisca.html I wrote my thoughts about SLEE and as I said SLEE is something like ESB + JBI + JCA for me. So, probably that I will give it a try very soon.
Svarog uses DOJO for javascript widgets, DWR for AJAX and Spring on the server side. And all deployed inside the Liferay portal. There is several portlets that are in fact not really independent portlets but each portlet is more like a "widget". I also think that portlets will become something like widget containers in the future. As the first portlet specification does not help in portlet communication I am using dojo topics, which does it pretty well. There is also a possibility to use DWR reverse ajax capabilities but I did not have the time to implement that, but probably that it will be done in the next months. Right now the browser polls each seconds for informations and show it in real time.
At the beginning I used MyFaces JSF components but as it lacks (and I think is still lacking) of ajax components I decided to go with DOJO (as I am not a javascript guru... nor Java) I chose DOJO for its simplicity.
Sometimes after Svarog was working within Liferay portal I decided to make it a separate webapp, just to see if that could be easily done and yes it can be done pretty fast because all those technologies are not tight to portals and may work very well as pure webapps or within portals. With probably a little of refactoring a fat client could be wrote for Svarog presentation layer this is something that I will keep in mind.
I just decided to blog about Svarog because maybe there would be some people that are interested in it, so the can see the possibilities. There is the mobicents project (www.mobicents.org/) which is an open source SLEE implementation, and I would like make Svarog something ala SLEE LIKE ... I will follow may blog about SLEE and ESB and I hope that it will become a nice product soon.
At the end, Svarog helped me to work with a lot of technologies and I will share my founds like inter portlet communication and other things some other day.
As I said it is a web based application which shows everything in real time in your browser, meaning there is no need to install any software on your desktop. It is an AJAX application using DWR (http://getahead.org/dwr) for the javascript and server side java communication, coupled to the Springframework (http://www.springframework.org/) it offers solid bases for an application.
Well, Svarog is in fact developed as EDA (event driven architecture/application) but without using special frameworks for that, just java 5 queues to make the application asynchronous. These days I was looking if that could be improve with an embedded ESB as Mule but I am still not sure if this is a good idea to do that.
In this blog http://gradecak.blogspot.com/2007/09/jain-slee-or-esbjbisca.html I wrote my thoughts about SLEE and as I said SLEE is something like ESB + JBI + JCA for me. So, probably that I will give it a try very soon.
Svarog uses DOJO for javascript widgets, DWR for AJAX and Spring on the server side. And all deployed inside the Liferay portal. There is several portlets that are in fact not really independent portlets but each portlet is more like a "widget". I also think that portlets will become something like widget containers in the future. As the first portlet specification does not help in portlet communication I am using dojo topics, which does it pretty well. There is also a possibility to use DWR reverse ajax capabilities but I did not have the time to implement that, but probably that it will be done in the next months. Right now the browser polls each seconds for informations and show it in real time.
At the beginning I used MyFaces JSF components but as it lacks (and I think is still lacking) of ajax components I decided to go with DOJO (as I am not a javascript guru... nor Java) I chose DOJO for its simplicity.
Sometimes after Svarog was working within Liferay portal I decided to make it a separate webapp, just to see if that could be easily done and yes it can be done pretty fast because all those technologies are not tight to portals and may work very well as pure webapps or within portals. With probably a little of refactoring a fat client could be wrote for Svarog presentation layer this is something that I will keep in mind.
I just decided to blog about Svarog because maybe there would be some people that are interested in it, so the can see the possibilities. There is the mobicents project (www.mobicents.org/) which is an open source SLEE implementation, and I would like make Svarog something ala SLEE LIKE ... I will follow may blog about SLEE and ESB and I hope that it will become a nice product soon.
At the end, Svarog helped me to work with a lot of technologies and I will share my founds like inter portlet communication and other things some other day.
Sunday, September 2, 2007
JAIN SLEE or ESB + JBI + JCA ?
I was looking what SLEE (Service Logic Execution Environment) or in the java world JAIN SLEE could offer in a telephony world. I am working on an open source telephony application called Svarog (http://sourceforge.net/projects/svarog/) based on Asterisk PBX (http://www.asterisk.org/) and I wanted to see how I could improve it in a next step.
Well, there is the SLEE specification and a java open source implementation sponsored by RedHat and JBoss called Mobicents (http://www.mobicents.org-a.googlepages.com/index.html). I am not an expert in telephony nor in SLEE specification, but what I understood is that this is something to do with EDA (Event Driven Architecture). We also have a reference implementation of SLEE, which is done by OpenCloud (http://www.opencloud.com/ ). And SLEE is often considered to be in telephony what EJB is in JEE.
SLEE is also "service" oriented where it has its own SBB (Service Building Blocks) which are resource adaptors. It does not seem to be specified for the telephony world only and it should be possible to inlcude any kind of services into the SLEE environment. It is specific because it offers a scalable, robust, reliable and transacted environment for "real time" applications. Probably that is why it is tight to the telephony world.
If this is not wrong, what I said till there, I see no reason why this kind of environment could not be setup using some open source projects such as ESB (Enterprise Service Bus), JMS (Java Messaging Service), rule engines and workflow engines. What I do think is that SLEE is maybe more complicated than setting up all those different projects. There is JBI (Java Business Integration) which already has several implementations in the open source community and IBM has its own standard SCA (Service Component Architecture) which seems to be adapted as well and which should not be an opponent to the JBI specification. I think that the Springframework could offer a base for writing something "ala" SLEE and to get a good support for Java Transactions and other services needed to write a scalable, robust, reliable and transacted environment. I mentioned JMS but I know it is not event based, but could be used and I think is used in some EDA. I forget to say that there is also JCA (JEE Connector Architecture) which is here in purpose to be used for resource adapters.
Well, the point is that it seems Mobicents cannot be used without the JBoss Application Server, and I think SLEE specifies that the implementation should not be tight to JEE.
We do not have specifications for ESB but we do have for JBI, which are also used in ESB such as Mule or ServiceMix. Both of them offers integrations with workflow and rule engines and are based on events ... so, how is SLEE different in it? In my opinion, SLEE could be a standard way to do ESB.
To conclude, an ESB coupled with JCA with a good support for transactions is really a god environment for a real time event based driven architecture, could be the thing that is needed for a telecom service platform.
Well, there is the SLEE specification and a java open source implementation sponsored by RedHat and JBoss called Mobicents (http://www.mobicents.org-a.googlepages.com/index.html). I am not an expert in telephony nor in SLEE specification, but what I understood is that this is something to do with EDA (Event Driven Architecture). We also have a reference implementation of SLEE, which is done by OpenCloud (http://www.opencloud.com/ ). And SLEE is often considered to be in telephony what EJB is in JEE.
SLEE is also "service" oriented where it has its own SBB (Service Building Blocks) which are resource adaptors. It does not seem to be specified for the telephony world only and it should be possible to inlcude any kind of services into the SLEE environment. It is specific because it offers a scalable, robust, reliable and transacted environment for "real time" applications. Probably that is why it is tight to the telephony world.
If this is not wrong, what I said till there, I see no reason why this kind of environment could not be setup using some open source projects such as ESB (Enterprise Service Bus), JMS (Java Messaging Service), rule engines and workflow engines. What I do think is that SLEE is maybe more complicated than setting up all those different projects. There is JBI (Java Business Integration) which already has several implementations in the open source community and IBM has its own standard SCA (Service Component Architecture) which seems to be adapted as well and which should not be an opponent to the JBI specification. I think that the Springframework could offer a base for writing something "ala" SLEE and to get a good support for Java Transactions and other services needed to write a scalable, robust, reliable and transacted environment. I mentioned JMS but I know it is not event based, but could be used and I think is used in some EDA. I forget to say that there is also JCA (JEE Connector Architecture) which is here in purpose to be used for resource adapters.
Well, the point is that it seems Mobicents cannot be used without the JBoss Application Server, and I think SLEE specifies that the implementation should not be tight to JEE.
We do not have specifications for ESB but we do have for JBI, which are also used in ESB such as Mule or ServiceMix. Both of them offers integrations with workflow and rule engines and are based on events ... so, how is SLEE different in it? In my opinion, SLEE could be a standard way to do ESB.
To conclude, an ESB coupled with JCA with a good support for transactions is really a god environment for a real time event based driven architecture, could be the thing that is needed for a telecom service platform.
Subscribe to:
Posts (Atom)
Posts
