tag:blogger.com,1999:blog-142551222024-03-07T13:32:48.840+05:30Vikramark's BlogDiscussing Solution Design, DevSecOps, Cloud and Software Architecture, Infrastructure, Frontend and Backend Frameworks.Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.comBlogger48125tag:blogger.com,1999:blog-14255122.post-21955877098022832952021-09-01T01:56:00.012+05:302021-09-04T10:50:13.311+05:30Testing in Continuous Delivery<p style="text-align: left;">In this blog I want to discuss my take on testing strategy in continuous delivery (CD) process. I want to remove all the buzz words and just connect the dots as how we used to develop and deliver software before and how we want to do it now using CD. We will discuss a brief overview of benefits CD provides. </p><p style="text-align: left;">In this post I want to focus on testing because I feel it is the backbone for achieving the continuous delivery. Even if we build pipelines on any infrastructure, public or private clouds and in any language, without a good testing strategy we can never achieve CD. I will discuss a few testing tips that helped me implement continuous delivery in my recent project. </p><h3 style="text-align: left;">Traditional approach</h3><p>Let me start by giving a super high-level view of how we use to develop and deliver software. I am calling it a traditional approach in this context. Below diagram shows a typical traditional SDLC.</p><p> </p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTl2nJjDbA-ilIP76SvCyfOoLYI22xGwfOqg3uEVRPJp65hj6_8_bYwQrsaSKWFIanPQgMHC2y7txzoPfbi44cNKA0_Uk23NNSgP3ye3024IHGSVKUqN2Z3epJQryeaFrQ92fb/s730/SDLC-Traditional.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="730" data-original-width="729" height="598" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgTl2nJjDbA-ilIP76SvCyfOoLYI22xGwfOqg3uEVRPJp65hj6_8_bYwQrsaSKWFIanPQgMHC2y7txzoPfbi44cNKA0_Uk23NNSgP3ye3024IHGSVKUqN2Z3epJQryeaFrQ92fb/w598-h598/SDLC-Traditional.jpg" width="598" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><div class="separator" style="clear: both; text-align: left;">Everything starts with a business need. The requirements needs to be broken down into features and then scoped out. Then the development team start designing and coding the feature. Once the feature is complete, it goes to QA Team and may be an automation team. Once QA certifies the build it goes to Release Management Team to schedule it for a prod deployment. A date gets decided most likely mid night of some weekend. Some folks from Dev and QA team are selected to be present. Eventually sometime during the time window the build finally gets to prod. Hopefully everything is looking good, and people can go back to what is remaining of their weekends. </div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">I think mostly everyone who have been in software industry for a few years has experienced the above scenario in some form. If you have not experienced it, well what can I say, you are the lucky one! Go out and celebrate it. </div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">Let’s analyze this process and see if we can find areas of improvements. Here are a few issues I can think of:</div><div class="separator" style="clear: both; text-align: left;"><br /></div><div class="separator" style="clear: both; text-align: left;">1.<span style="white-space: pre;"> </span>The QA Team testing is mostly a manual process. Even a small change requires it to go through a full regression cycle and that would take weeks.</div><div class="separator" style="clear: both; text-align: left;">2.<span style="white-space: pre;"> </span>Most likely we have an awesome Dev Team, and they will churn out features like a flash flood. (Not to mention Dev most likely have more resources in the team too) With all the features lining up, the QA gets easily overwhelmed. Thus, these features are just waiting (wasting time) to be verified. </div><div class="separator" style="clear: both; text-align: left;">3.<span style="white-space: pre;"> </span>If QA team find an issue an inner bug fix cycle starts. It goes to Dev, gets fixed, then wait for its turn to be pushed to next cycle of QA testing. </div><div class="separator" style="clear: both; text-align: left;">4.<span style="white-space: pre;"> </span>Suppose we also have an awesome QA Team, who worked extra hard to get everything validated. But now this verified build cannot go to production just yet. It now needs to be scheduled by a Release Management Team. Thus overall, further delaying the feature to reach to production. </div><div class="separator" style="clear: both; text-align: left;">5.<span style="white-space: pre;"> </span>One interesting thing in all this is no one really paid any attention to our Automation Team. They were never considered part of the flow. </div><div style="text-align: left;"><br /></div></div><h4 style="text-align: left;">Testing in a traditional approach (anti-pattern):</h4><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTxnnJMujcZSaua6qpzHF99D62_WmLuyZiPX9FPnX7cCye21pIyzrdyuQQt_TnocE0Bo5_d2hp1K6hf4Ar2Rck4XClWK45PYu08VWBUEy_cf-unuUadC69vpl8UCj8EmNIjVup/s718/invertedPyramid.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="436" data-original-width="718" height="236" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTxnnJMujcZSaua6qpzHF99D62_WmLuyZiPX9FPnX7cCye21pIyzrdyuQQt_TnocE0Bo5_d2hp1K6hf4Ar2Rck4XClWK45PYu08VWBUEy_cf-unuUadC69vpl8UCj8EmNIjVup/w390-h236/invertedPyramid.png" width="390" /></a></div><p></p><p>Now that we understand how the SDLC use to be in traditional approach, let’s turn our focus on testing. I am showing an inverted pyramid, which now, is an anti-pattern. But it used to be common a few years back. We had a lot more Manual Tests followed by Functional/Acceptance Tests and then at the bottom were Unit Tests. You may ask “why unit test is at the bottom, shouldn’t we have more Unit Tests than the functional tests?”. The reason was the common notion that unit test only checks for a class or method thus does not provide value. But because Functional Tests test a complete feature, it provides more value.</p><p>I can think of a few drawbacks of this approach: </p><p>1.<span style="white-space: pre;"> </span>Too much time spent in repetitive manual work </p><p>2.<span style="white-space: pre;"> </span>QA Team might be shared by multiple teams causing more delays</p><p>3.<span style="white-space: pre;"> </span>Not one team is accountable but multiple teams are involved and hence more friction</p><p>4.<span style="white-space: pre;"> </span>Less focus on automation testing </p><p>5.<span style="white-space: pre;"> </span>Unit testing was ignored</p><p>Overall, the testing strategy was not geared towards faster delivery. It was also more error prone and delayed feedback.</p><h3 style="text-align: left;">Continuous delivery approach</h3><p>The SDLC in case of continuous deployment model looks very different. If you look at the image below, this approach removes the wait time that are struck off. The Dev Team would now have the responsibility to automate the tests for the features they are working on. This also include coming up with scenarios where they might think their feature would fail. This seems like an additional work on Dev Team, and it is, and it should be accounted in their user stories. The Dev Team are now more concerned about how the feature would be tested and would most likely keep that in mind when designing it. Plus, Dev Team can write much better automation tests as they know the system and inner workings of the application. </p><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYinlHGYprsiptx5djDWyvdKS2jSg7Cy1CvjE8He2X3ydzuRHS-AeFq8sN0Y1sCcnzXQu698jdP7r8Mkbstr8B4lNFIMP2Sla4ZqqF2wBe0RT0mxx5Lp5QT6L3ElwbyuR2f0L4/s888/SDLC_CD.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="792" data-original-width="888" height="475" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYinlHGYprsiptx5djDWyvdKS2jSg7Cy1CvjE8He2X3ydzuRHS-AeFq8sN0Y1sCcnzXQu698jdP7r8Mkbstr8B4lNFIMP2Sla4ZqqF2wBe0RT0mxx5Lp5QT6L3ElwbyuR2f0L4/w534-h475/SDLC_CD.jpg" width="534" /></a></div><br /><p>All the things that I have struck off in the above image, gets replaced by an automated pipeline: </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXGjJW52a-sHlsF5JEQVdvKr7rO206YseEVuGhStoZgjQOLPYqNaeMPU-VoTR1WsUkdbhek5ngit9fDQvmZCriAZ4uM8fNl-OGLc03DjUbcO7aUuJeAqsQKGrdlVqCPTda2Qyc/s1061/DeploymentPipeline.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="61" data-original-width="1061" height="35" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXGjJW52a-sHlsF5JEQVdvKr7rO206YseEVuGhStoZgjQOLPYqNaeMPU-VoTR1WsUkdbhek5ngit9fDQvmZCriAZ4uM8fNl-OGLc03DjUbcO7aUuJeAqsQKGrdlVqCPTda2Qyc/w628-h35/DeploymentPipeline.jpg" width="628" /></a></div><br /><h3 style="text-align: left;">Testing in a continuous delivery approach</h3><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDpJxYNggJaknBnE4pwYlG98r90LM1cBeILc6o4FUUulcUOHzTBYxL-UwC5MClNpwDwCz80zMK9MNGwZCdAyxJU0de6BoFApf_Uux2fQRNO53ve5B88BtrVq_G0DzeMGe9IqNW/s2048/Testing+Pyramid.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1117" data-original-width="2048" height="250" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDpJxYNggJaknBnE4pwYlG98r90LM1cBeILc6o4FUUulcUOHzTBYxL-UwC5MClNpwDwCz80zMK9MNGwZCdAyxJU0de6BoFApf_Uux2fQRNO53ve5B88BtrVq_G0DzeMGe9IqNW/w458-h250/Testing+Pyramid.png" width="458" /></a></div><div><br /></div><div><br /></div><div>The testing strategy for a continuous delivery needs to be thorough and fast. As we don’t have manual verifications it’s very important that our automated tests are reliable and has excellent coverage. Each piece of our code work together to form bigger components and applications. Multiple applications (e.g. microservices) working together would implement the feature. Hence all these layers need to be tested thoroughly. The testing pyramid strategy is the best practice to follow. It's built on a large number of unit tests, followed by functional tests and then a few end to end tests. </div><div><p><b>Unit Tests: </b></p><p>1.<span style="white-space: pre;"> </span>Testing one method and class at a time</p><p>2.<span style="white-space: pre;"> </span>Fastest feedback to developers </p><p>3.<span style="white-space: pre;"> </span>Consider it like Lego pieces, where each piece is validated and is foundation of the overall system</p><p>4. Unit tests runs with every commit and there should be some code coverage requirement as well. I generally use 85% as a minimum code coverage. </p><p><b>Functional Tests:</b></p><p>1.<span style="white-space: pre;"> </span>Testing a feature flow. It could cover the entire feature or impact of the feature on a domain if the application is developed using Domain Driven Design</p><p>2.<span style="white-space: pre;"> </span>Backbone of continuous deployment</p><p>3.<span style="white-space: pre;"> </span>Regression tests than can run on every commit</p><p>4. Make it part of pipeline and it should break the pipeline if it fails. </p><p><br /></p><p><b>E2E Tests</b></p><p>1. The E2E tests should be very few. </p><p>2. These tests should run across all domains. These tests the very critical functionality only. Because they touch across domains with very less or no mocking, these tends to require higher maintenance costs. </p><p><b>Challenges of Functional Tests:</b></p><p>The functional tests also have some challenges. Here are a few that I have encountered the most:</p><p>1.<span style="white-space: pre;"> </span>Slow and Fragile</p><p>2.<span style="white-space: pre;"> Simulating or Mocking D</span>ata</p><p>3.<span style="white-space: pre;"> </span>Separate Teams especially if you are keeping automation testing not part of development team</p><p><br /></p><p><b>Overcoming functional testing challenges:</b></p><p>I used below tips to overcome some of the challenges and these helped me immensely in my projects. </p><p>1.<span style="white-space: pre;"> </span><b>Keep the data and tests together</b>. We divided the system into smaller domains. Each domain was treated as a complete unit. The full feature was tested across this domain, mocking any external domains rest endpoints. We used wiremock, which provides an admin api. The tests were in cucumber. The tests were written in a way to set the mock responses at the start of the test and tear it down at the end. </p><p>2.<span style="white-space: pre;"> </span><b>Keep the tests independent.</b> The data should be set and cleaned up in a way so the tests can run independently of each other. </p><p>3.<span style="white-space: pre;"> </span> <b>Make the tests run in parallel</b></p><p>4.<span style="white-space: pre;"> <b>Run only the tests</b></span><b> </b>that might be related with the current commit. It is especially important in case of micro-services. If the modified service has no role to play in a feature (for example it belongs to a different domain), we can skip those tests. In addition to this, I <b>generally run critical, or core feature tests irrespective of</b> the commit impact zone. </p><p>5.<span style="white-space: pre;"> </span><b>The same development team</b> should be responsible for writing the automated tests as well. This is very important, as Dev Team knows the most about the application, and also, they can design the app in a way that it is more testable. </p><p>6. Never use functional tests as a replacement of unit tests. Code coverage is not the goal here and it cannot cover all permutations. The goal should be test the feature functionality. </p><p><br /></p><p><br /></p></div>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-6746093775115858032011-12-04T12:35:00.003+05:302012-09-02T00:32:13.879+05:30JVM CodeCache<div dir="ltr" style="text-align: left;" trbidi="on">
The main parts of memory of JVM are Heap, Perm Space and Code Cache. On one hand Heap and Perm sizes are well known as we need to set these sizes quite often, but on the other hand the Code Cache remains not so well known.<br />
<br />
With the introduction of JIT (Just in time compiler) I believe in JDK 1.2 version, not all code was compiled to machine code from the byte code at a time. This compilation is completely different from javac compilation we have to convert Java source files to byte codes. The JVM, maintains a certain number that a method should be called (executed), before it decides to compile the code and cache it. By default its 1500 executions but can be overridden using -XX:CompileThreshold=10000. The initial calls to methods when not cached are just executed in interpreted fashion.<br />
<br />
So where does code cache fits in all this? Well code cache is part of memory where all the compiled code is cached. There are options (-XX:ReservedCodeCacheSize=32m) to set the size of this cache memory. This memory stays outside of heap memory. So if you decide to make your system reach to peak performance early, by using some extra amount of memory, you should look at these options. Reducing the CompileThreshold and increasing the CodeCache Size, might help you to make your application the peak performance stage faster.<br />
<br />
More details on various option configurations:<br />
<a href="http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html%20">http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html</a></div>
Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-41182974948658525332009-07-28T21:43:00.007+05:302009-08-09T04:22:46.461+05:30Apache CXF Proxy Setting for Client with httpConduitMany times its required to run the webservice clients from within the company firewall. This require to go through a proxy, in Apache CXF webservice framework you can specify the Proxy setting for client code in cxf.xml file. You will need to place this file in the class path of your client application. Here is the setting one will require put<br /><br /><div sytle='padding:5px'><br /><div style="background-color:silver;font:'arial';padding:20px;font-size:12px;font-color:black" ><br /><beans xmlns="http://www.springframework.org/schema/beans"<br />xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<br />xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"<br />xmlns:conf-sec="http://cxf.apache.org/configuration/security"<br />xsi:schemaLocation="<br />http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd<br />http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd"><br /><div style='background-color:white'><br /><http-conf:conduit name="*.http-conduit"><br /> <http-conf:client ProxyServer="http://www-url-to-my-proxy.com" ProxyServerPort="80" /><br /> <http-conf:proxyAuthorization><br /> <conf-sec:UserName>username</conf-sec:UserName><br /> <conf-sec:Password>password</conf-sec:Password> <br /> </http-conf:proxyAuthorization><br /> </http-conf:conduit><br /></div><br /></beans><br /></div><br /></div>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com2tag:blogger.com,1999:blog-14255122.post-10973614191143761562009-07-18T07:32:00.001+05:302009-07-18T07:59:38.304+05:30Why do we need GUICE ?I was looking at one of the tech videos on GUICE framework. As I am not very familiar with this framework and I had some time on hand , I decided to go ahead and see this presentation. <br /><br />Here are the important features discussed for Guice in this presentation <br /><br />1. Dependency Injection <br />2. Modularize Code<br />3. Guice Servlet dispatcher <br />4. AOP – for transactions<br />5. Introspection for various Modules to see if dependency is broken<br /><br />We can achieve all this features using Spring Framework and Maven. I guess maven is excellent tool to develop code in Modular fashion. You can divide your application in modules and these can be used across any other applications (if well defined). Plus Spring Framework provides the pretty good dependency injection and AOP.<br /><br />So overall I am not sure as “Why GUICE ?”, when we can get the better things done through already well established framework. May be I will need to do some hands on to be able to find a better answer to this question<br /><br /><br /><object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/hBVJbzAagfs&color1=0xb1b1b1&color2=0xcfcfcf&hl=en&feature=player_embedded&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowScriptAccess" value="always"></param><embed src="http://www.youtube.com/v/hBVJbzAagfs&color1=0xb1b1b1&color2=0xcfcfcf&hl=en&feature=player_embedded&fs=1" type="application/x-shockwave-flash" allowfullscreen="true" allowScriptAccess="always" width="425" height="344"></embed></object>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com2tag:blogger.com,1999:blog-14255122.post-29039475833706806042009-07-16T06:06:00.003+05:302009-07-16T06:15:53.310+05:30ScalaThe scripting languages are gaining grounds at much more rapid pace. The scripting languages such as Groovy, and more recently Scala has added advantage as they give a mix of static language, dynamic language and functional language. I have worked on Groovy before during my with Grails framework, (which i believe is pretty good framework) but recently i have come across the Scala language. Currently my understanding of this language is kind of limited. But initial impression of this language seems to be very promising to me. Here is one of the interesting blog post i found, it gives comparision between Scala features and Groovy features. It also discusses other important features of Scala. <br /><br /><a href='http://www.khelll.com/blog/scala/scala-is-my-next-choice/'>http://www.khelll.com/blog/scala/scala-is-my-next-choice</a>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-72148711468664131242009-07-16T05:59:00.003+05:302009-08-09T09:28:26.029+05:30Ora 911 invalid characters in sql statementIf you get this error please make sure that the sql statement does not have any special characters in it. One of the most common issue is of adding <div style='background-color:white;'>a semi colon ; at the end of sql statement.</div>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-72380373165792387782008-03-06T07:03:00.001+05:302009-07-09T05:26:08.864+05:30JBoss Portal Release container 2Read more:<br /><a href="http://blog.jboss-portal.org/2008/03/jboss-portlet-container-20-candidate.html">Jboss Portal Blog</a>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-5479010040249252132007-05-04T21:39:00.000+05:302009-07-09T05:26:08.865+05:30New Entry: GWT with PortletI have shifted my blog to a new location. Here is the link to the lastest post<br /><br /><br /><a href="http://portaltalk.blogspot.com/2007/05/gwt-with-portlets.html">GWT with portlets</a><br /><br /><br /><br />tags: portal,GWT, portlet, JSR 168Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-15581986890390847652007-03-07T02:54:00.001+05:302009-07-09T05:26:08.865+05:30IPC in JSR286I was looking for an idea of what new features are added to jsr 286 for IPC. I found a few good articles on that topic.<br /><br /><a href="'http://blogs.sun.com/nav/entry/understanding_portlet_2_0_jsr'"><br />http://blogs.sun.com/nav/entry/understanding_portlet_2_0_jsr</a>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-1169969479845351912007-01-28T12:52:00.000+05:302009-07-09T05:28:14.040+05:30SideWalk: Grails Framework Java's answer to Ruby on RailsWith Ruby on Rails, the web-application development had become really fast especially for mid and small sized applications. A lot of credit goes to the Rails Framework. But still Ruby lack what Java has, including innumerable number of utilities, packages, resources, Industry investment and acceptability. <br /><br />Well, i guess after working on Grails i think we have got the right combination. Grails is built on Groovy and Hibernate. I liked GRAILS more then Stripes Framework also. We were able to develop web-application(small sized) at much quicker pace. It is more closer to Ruby on Rails framework. Provide Scaffolding and auto generating many of the code and functionality. It uses convention over configuration to the maximum. It has very easy to use and intuitive tags for Ajax implementation. <br /><br />Here is the link if want to know more http://grails.codehaus.org/Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com5tag:blogger.com,1999:blog-14255122.post-1167620391959610262007-01-01T08:19:00.000+05:302009-07-09T05:26:08.865+05:30WebOS in PortalsThe webOS is newer concept in web application domain. The concept is pretty simple of making browsers more capable, taking a step forward from Web 2.0. WebOS is a virtual operating system that runs in your web browser. Here is one of the article I found giving a comparison of latest WebOS present in market. <br /><br /><a href='http://franticindustries.com/blog/2006/12/21/big-webos-roundup-10-online-operating-systems-reviewed/'>Big webOS roundup</a><br /><br />I am not going to discuss further about webOS in this article. There has been a hype in market about Google Browser, Google coming out with similar GoogleOS. We have to wait and see when that happens. <br /><br />In this article, I want to bring in light how useful webOS can be for Portals. Portal already provides the features such as SSO, Authentication, Personalization, Customization and so on. With the help of WebOS the portal can act like a virtual desktop for a person. A person can access it from anywhere from any machine on any OS. He will get all the functionality right in one browser. <br /><br /><a href='http://www.exoplatform.com'>eXo Portal</a>, one of the leading open source portal, have come up with webOS implementation on Portals. eXo WebOS is coming out with desktop theme of Mac OS, Vista Theme.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/x/blogger/5111/1284/1600/457521/webOS%20eXo.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;" src="http://photos1.blogger.com/x/blogger/5111/1284/320/464973/webOS%20eXo.jpg" border="0" alt="" /></a> <br /><br />There is also a demo link.<br /><a href='http://demo.exoplatform.org:9090/ecmportal/public/exo:/'>DEMO</a><br /><br />Username: exoadmin<br />Password: exo<br /><br /><br><br /><br />Here more info on webOS eXo portal <a href='http://rexduffdixon.com/?p=1152'>Interview</a>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-1163546561045485022006-11-15T04:47:00.000+05:302009-07-09T05:26:08.865+05:30Protocol to access Portlet repositoriesI recently come across this new project Portlet Repository Protocol(PRP). The project is about able to establish a standard way in which various Portal Administrators can search, download and deploy the portlets from Portlet Repository. This furthur stresses the need of a vendor indpendent Repository Source, where one can find many readily available portlets on various Portals. Here is the link if you want to know more about <a href="https://prp.dev.java.net/">PRP</a>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-1163351608824526022006-11-12T22:40:00.000+05:302009-07-09T05:26:08.865+05:30Is portal going to keep Java a float ?There is a discussion going on <a href="http://www.theserverside.com/news/thread.tss?thread_id=43020">TSS</a>, about a comment made by <a href="http://blog.thinkphp.de/archives/170-Keynote-of-Tim-Bray-some-interesting-comparison-between-PHP,-Rails-and-Java.html">Tim Bray</a> about how Php, RoR is more scalable then Java.<br /><br />Even before RoR(Ruby on Rails), the simple websites were build over Php then on Java. This is because trying to build a small dynamic website on Java is more complex and time consuming, not to mention that to host Jsp website is more expensive then PHP. Thus its right, when we try to compare PHP and RoR and Java with respect to small websites and say, Php and RoR are better choices then Java/JSP. <br /><br />But still when it comes to bigger applications, where authentication, Security, better architecture, is required Java is still way ahead of both RoR and Php. Now with Portal applications coming up in Java, I guess Java web-application development for bigger applications have taken a big lead. Portal provides the authentication, integration, security, personalization, customization facilities to the web-application with not a big effort. RoR success is because it automate many things and time to develop websites is greatly reduced. Portal also does similar thing for bigger web-applications. It provides SSO, Authentication…etc which are heart of any big application with lesser efforts.<br /><br />But yes in near future we are about to see much development in RoR for small dynamic websites. So isn’t portal is the edge, that can keep Java a step ahead of all others. :)Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-1157470347205935052006-09-05T20:40:00.000+05:302009-07-09T05:26:08.865+05:30Can Mashups be exploited more with Portals?There have been quite a number of posts on Mashups now. Recently, Sun have released a sample <a href="http://developers.sun.com/prodtech/portalserver/reference/techart/mashups.html">implementation</a> of Mashups with Portals. The sample code is good and it uses the Yahoo Map Api to develop the mashup. The Personalization features provided by portal can furthur enhance what mashups can do. They provide the RSS feed that one can add, to be displayed on yahoo maps.<br /><br />This just shows a glimpse of how Portal can exploit power of Web2.0 and mashups. The end user can select his own mashups and personalize it to his own use. Though in this example the Ajax based api was used, it would be even more beneficial if Rest Protocol is used through Java. Take for example if we have Portlets for Google Calendar. We can have various such portlets which works on Rest Protocol and also uses the Power of Portals to personalize the things. There could be a way to single sign on, by storing important information in user preference data.<br /><br />The above approach is to use Web2.0 content inside portals. The other examples in this regard would be use of wiki forums blogs with portals.<br /><br />But the other approach is exporting the Portal data in form of Web2.0. I guess <a href="http://www.bea.com/framework.jsp?CNT=pr01597.htm&FP=/content/news_events/press_releases/2005">BEA Project Runner</a> is based on such a concept. Its still under developement and we have to see what the end result will be. But this will allow the normal web-applications to be able to work with Portals applications. <br /><br />Plus, we might wanna see the feature of allowing the portal to adapt itself according to the user interaction with the portal. Something like Tags etc. <br /><br />Overall, i believe that Portal is truely the first step towards SOA, with Soap or with REST. <br /><br />Your comments are appreciated.Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-1157079028331165502006-09-01T08:05:00.000+05:302009-07-09T05:26:08.865+05:30Sample Implementation of Mashup Portlet on SUN PortalJust a few days back i had posted an interesting article <a href="http://portlets-jsr168.blogspot.com/2006/08/portal-perspective-mashups.html">Portal Prospective:Mashups</a> . I had talked about how the Mashups are different from Portal and how portals need to adapt to Web 2.0 technologies. Here is one of the sample implemetation of <a href="http://developers.sun.com/prodtech/portalserver/reference/techart/mashups.html">Mashup Portlet</a> I found on Sun portal.Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-1157076688979284122006-09-01T07:35:00.000+05:302009-07-09T05:26:08.866+05:30One more OS Portal with Ajax Framework -- Light PortalThere is yet another Open source portal, "Light Portal". Light Portal is under Apache License. Here is the short description <br /><br />"Light is an Ajax and Java based Open Source Portal framework which can be seamlessly plugged in to any Java Web Application or as an independent Portal application. One of its unique features is that it can be turned on when users need to access their personalized portal and turned off when users want to do regular business processes."<br /><br /><br />Resources:<br />Website Link= <a href="https://light.dev.java.net/">Light Portal</a>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com1tag:blogger.com,1999:blog-14255122.post-1156944556544559812006-08-30T18:57:00.000+05:302009-07-09T05:26:08.866+05:30Jboss Portal 2.4 ReleasedJboss released its Jboss Portal 2.4. It has included features for better WSRP implementation. Here is the link to article <a href="http://jboss.org/jbossBlog/blog/rrusso/2006/08/29/JBoss_Portal_2_4GA_Released.txt">JBOSS Portal 2.4GA Released</a>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-1156825709493910532006-08-29T09:56:00.000+05:302009-07-09T05:26:08.866+05:30The Seven Secrets of SOA SuccessHere is one of the interesting article on SOA implementation <a href="http://webservices.sys-con.com/read/250498.htm">The Seven Secrets of SOA Success</a>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-1156734193859579582006-08-28T08:21:00.000+05:302009-07-09T05:26:08.866+05:30BEA Acquires SOA Repository FlashlineIn a trend to capture the SOA market, bigger firms are in spree of buying several SOA domain players. One more such aquisition happened last week. BEA acquired SOA Repository Flashline.<br /><br />The new acquisition will boost BEA AquaLogic(TM) Service Registry and will provide a complete metadata management solution. <br /><br />Here is the <a href="http://opensource.sys-con.com/read/263910.htm">Link</a>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-1156689257597568562006-08-27T19:56:00.000+05:302006-08-27T20:07:29.023+05:30BEA Releases BEA Weblogic 9.2Bea has released its version of weblogic 9.2. The central points are :<br /><ul><li>It does not include the Plumtree Portal Server.</li><li>The Emphasis is on Service oriented architecture</li><li>Better support for Ajax and WSRP</li><li>Standards-based portlet federation, based upon the WSRP standard, with support for syndication of portal books and pages, personalized delivery, performance optimization and service lifecycle governance.</li><li>A new community framework, as part of portal business services that is designed to simplify portal membership, management, and end user production of community portals.</li><li>Portal lifecycle management capabilities including the new release of BEA Workshop for WebLogic which provides an Eclipse-based development environment for Java, portal, Web, and service-oriented applications. Also, portal propagation is included to help simplify the IT management for moving portals through staging from development to production.</li></ul><br /><br />For more information visit <a href='http://www.bea.com/framework.jsp?CNT=pr01683.htm&FP=/content/news_events/press_releases/2006'>Weblogic press release</a>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-1156663465093273782006-08-27T12:39:00.000+05:302006-08-27T12:57:33.743+05:30Oracle's Whitepaper on Portal & SOAJust a few days back i had blogged about BEA Survey result as how Portal market is going to get a boost by SOA. Here is another whitepaper sponsered by Oracle this time. It explains as how SOA and Portal gel together. It gives an overview of SOA and its benefits and how it can readily be used with Portal. It quotes a Gartner Paper "A Portal May Be Your First Step to Leverage SOA," September 22, 2005 and supports its finding.<br /><br />One can have a look on this paper at <a href="http://www.line56.com/getinfo/oracle_0606.asp?src=feat_wp">Portals: The Face of<br />Service-Oriented Architectures</a>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-1155959249578170022006-08-19T09:13:00.000+05:302006-08-19T09:17:29.586+05:30Peoplesoft DesignerHi, got a chance to work with Peoplesoft CRM. Found it great. I liked the Designer Module, one can sketch the skeleton of the whole process. I am not sure if it uses BPEL at backend?????? I guess not though.Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0tag:blogger.com,1999:blog-14255122.post-1155190795837369552006-08-10T11:47:00.000+05:302006-08-10T11:49:55.846+05:30Portal Perspective: mashupsThere are new trends coming up as Web 2.0 is becoming more popular. The newer among them is of providing the customized web solutions(composite applications) through combining two or more Lightweight Services. These are seen in implementations of “Mashups”.<br /><br />The definition of “Mashups” as on <a href=”http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)”>Wikipedia</a> is “A mashup is a website or Web 2.0 application that uses content from more than one source to create a completely new service. This is akin to transclusion.”<br />Content used in mashups is typically sourced from a third party via a public interface or API. Other methods of sourcing content for mashups include Web feeds (e.g. RSS or Atom) and JavaScript.<br /><br />One can see many examples of using Mashups on Google Map Apis. There are also many websites which maintain a list of mashups and also API’s. Thus these are faster to develop and information can be extracted and displayed in an innovative way.<br />Sometime back a few friends came to me and ask me if Mashups can provide Page level integration, why do we need Portal? They were exited seeing on some website serveral Windows on the same page using Ajax and other API’s. <br /><br />The mashup provides lighweight composite applications. Portal also does gives a Presentation Level Integration of applications, but it does much more then just that. There are other features like SSO, Personalization, Authentication, and so on that are part of portal. For implementing Web Serivices Portal uses WSRP its based on SOAP.But on the other hand Portal require some infrastructure to begin with. But Mashups can be built easily. <br /><br />The Portal Vendor’s have realized some of the important features of Web 2.0 that should be incorporated in Portal too. The Ajax functionality will be part of <a href="http://jcp.org/en/jsr/detail?id=286">JSR 268</a> specification. The ajax can be beneficial in various ways for Portal. I did made Blog entry on that quite some time back <a href=”http://portlets-jsr168.blogspot.com/2005/11/ajax-in-portlets.html”>Ajax in Portlets</a>. Wikipedia, Blogs are already implemented by some portal vendors.<br /><br />Now the Portal vendors are working on providing the Mashups functionality. Liferay is a leading OS Portal vendor and its already working on implementation of Mashups. BEA is working on Project “Runner” for mashups. More portal vendors would also doing a similar implementations.Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com1tag:blogger.com,1999:blog-14255122.post-1154650573376135662006-08-04T05:45:00.000+05:302006-08-04T05:46:13.386+05:30When to use Customization & Personalization in Portals?I recently came across the question of whether to use the Personalization or customization feature. I realize many people who are new to portal, face similar dilemma. So here is the question “if we have some users (roles) who want to see different content when logged in to the portal? Which technique to use, the Personalization approach or Customization approach?”<br /><br />The solution can be that we develop a portlet for each role. Lets say there are 3 roles, dealer, retailer, and customer. So we develop a separate portlet for each such role. Now we can “customize” the view of each user by placing appropriate portlet on appropriate pages and showing the user a particular portlet or page on log in.<br /><br />The other approach is having just one portlet. Now based on the logged in user role, a different JSP file or content rendered. That is we have personalized the data depending on the logged in information.<br /><br />In my view the former approach of having 3 different portlet is better at most of the times.<br /><br /> <br />One should always try to develop the application seeing the future needs and flexibility to change the application easily. Suppose we do change the Re-direct JSP to another JSP depending on the user role, this will work in this scenario. Tomorrow the Role Name might change or some new roles might be added. The new role may want to have the combination of view what we have for our current roles. We will then require to change the code to fit to changed scenario. This kind of technique is what we use in normal J2EE applications. This technique I guess is not fully exploiting the potential of portal. <br /> <br />Now let us look at the second approach. Have 3 portlets for 3 roles. The administrator who will deploy portlet application to the Portal server will need to create Page Views depending on the Login of each Role. He will just need to add the corresponding Portlet on those pages. If suppose the ROLE name changes or new Role is created, then there is no need to change the code. Just what portlets should be displayed to this role, will be added to the page by administrator. <br /> <br />The central idea is to create as many small independent information blocks as one can in form of portlets. And then combine them together to have final Content to be displayed to the end user.<br /><br />The personalization features should be used when user himself is given the right to modify it or change it according to his own needs. Like changing of color and changing the number of records to be displayed are classic examples.Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com2tag:blogger.com,1999:blog-14255122.post-1154133191556336872006-07-29T06:01:00.000+05:302006-07-29T06:03:11.570+05:30Portals getting boost by BPM and SOA marketThe portal market will see a new boost as BPM and SOA market picks up. The SOA and BPM are complimentary technologies and the Portal provides presentation integration, security and other features on it. The above are the findings of a survey done by BEA. Here is the link to read more <a href='http://www.portalsmag.com/articles/default.asp?TopicID=7&ArticleID=7737'>LINK</a>Vikhttp://www.blogger.com/profile/11248886599080370379noreply@blogger.com0