Lan Jiang's Blog
Lan Jiang's Homepage
Lan Jiang is a principal consultant with the BEA professional service. He has architected and developed many J2EE/Portal/Integration applications on the WebLogic Platform for BEA customers. He is certified by BEA as both a WebLogic Server application developer and a WebLogic Portal solution developer. His interests include J2EE, object-oriented design, SOA.
Lan holds a M.S. degree from the University of Illinois at Chicago. Lan now resides in the Chicago area with his wife and newborn daughter.
ALSM is not just a performance monitoring tool
Posted by ljiang2 on March 19, 2008 at 9:50 PM | Permalink
| Comments (1)
One customer manager, whose company was in the process of adopting SOA, asked the question when we introduced ALSM to him: "We have purchased application performance monitoring product XYZ already. We are quite happy with it. Why do we still need ALSM?" It is a great question. The answer is that ALSM is a SOA run-time governance solution rather than a service/application performance monitoring solution, although it does offer service performance monitoring feature. Policy based runtime management, security management, SLA management and exception management are ALSM's forte. Besides, ALSM offers other unique features such as auto-discovery of services on the network, tracking messages traveling to and from services, etc. Not to mention that ALSM can be nicely integrated with ALSB and ALRR. ALSM can be proved to be extremely valuable to provide run-time governance of a disparate and distributed SOA system.
Wait to try Kapow's new RoboSuite release
Posted by ljiang2 on September 29, 2005 at 9:53 PM | Permalink
| Comments (1)
One of the many fun things to do in BEA World 2005 is to visit the partner booths in the exhibit hall. Sure one reason is to get all the free gifts, but more importantly I get to chat with our partners employees and learn how our partners are doing and what are the cool features they offer. It is nice to see how our partners’ products work seamlessly with BEA’s products and together provide a better enterprise solution to our customers.
I happened to stop by at Kapow’s booth and had an interesting chat with their employees. BTW, I got a nice black T-shirt from them too.
The flagship product from Kapow is its RoboSuite. For those who don’t know what it is, it is basically a web intelligent clipping tool. By using Kapow RoboSuite, you can integrate a legacy web application into WebLogic Portal easily, without rewriting the legacy web application into a pageflow portlet. For example, during one of my previous engagements, we integrated a customer’s old ASP site into WebLogic Portal without touching a single line of code at the ASP site.
But I have also experienced several major drawbacks in the previous Kapow release. One of the problems is that it did not handle frame, javascript well. So if you have a site that utilizes frame or javascript heavily, you are in trouble. Another problem is that it only supported scenario based clipping. Basically, you need to tell the RoboMaker how you want to clip the other site and walk through the scenarios you want. It did not have the capability to simply take a site URL and clip the whole site.
According to my chat at the Kapow booth, Kapow RoboSuite 6 solves all these problems! Wow. I got all excited. The person I talked to was not sure when the version 6 was going to be released, but after the conference, I went to their web site http://www.kapowtech.com and happily found out that it was released on Sep 27, 2005, the first day of BEA world. But to my surprise, after browsing through their site, I found out neither they provide the trial download for version 6 (only V5.5 download link is there), nor do they have any documentation on the latest release. I hope Kapow can make all these available soon so that I can try all these new cool features.
Blog Clients Review
Posted by ljiang2 on September 15, 2005 at 11:53 AM | Permalink
| Comments (0)
I have tried the w.bloggar client, but don’t like it very much. The problem is that it does not have a WYSIWYG editor, though it has syntax highlight feature for html tag. When I tried to blog some topics on xml, it treats all the xml tag as html and can not display correctly. I have to use < to replace all the “<” to make it display correctly. It is quite annoying.
Our editor uses ecto on OS X, I downloaded the ecto’s window version but found out that it has only text editor support too.
Eventually I tried BlogJet, which you can download from http://blogjet.com/. I am glad to see that it has a nice WYSIWYG editor. It is not free though ($40), but I will still considering buying it, just for the convenience sake.
Of course, if anyone knows how to get w.bloggar (which is free) to work with xml tag, or knows any other free blog client that has a WYSIWYG editor, I am all ears.
Here is a nice link to review some popular blog clients on the market: http://www.cmswire.com/cms/cms-reviews/blog-client-reviews-in-brief-000492.php
Oh, one thing I found out that the “post as draft” feature does not work in BlogJet. I tried to post as a draft, but it appears on the site as “published” status right away. Same thing happens to me when I used w.bloggar too. BlogJet has its own draft saving feature.
Portal Desktop Recreation Best Practice Part 2
Posted by ljiang2 on September 9, 2005 at 9:56 PM | Permalink
| Comments (0)
In my last blog, I recommended a new way to recreate desktop basing on .portal template file, without losing entitlement settings or customization settings.
In a nutshell, instead of deleting the old desktop and creating the desktop again, we should create an extra new desktop basing on the updated .portal template file. When WebLogic admin portal prompts you that there are conflicts between the resources in the template file and existing resources in the library, choose either option 2 (Replace conflicting Portal Resources with Template version) or option 3 (Replace markup with Template version) to overwrite. Option 3 is only available on WLP8.1sp4. The advantage of this approach is that it can keep entitlement settings if you choose option 2 and keep both entitlement and customization if you choose option 3. Hmm, should we use option 3 all the time? If you keep reading, you will see that option 3 can not deal with certain types of .portal changes in the .portal file and requires manual modifications after desktop is refreshed. Let's investigate different scenarios in more details.
1. Add a page/book
If you add a new page/book in the .portal template file, after redeploying the portal ear file, you have to recreate the desktop to allow end user to see the new page/book. Choose either option 2 or option 3 to make the new page/book visible. The only difference is that option 3 will keep both entitlement and customization, which option 2 only keeps entitlement settings.
2. Delete a page/book
If you delete a page/book in the .portal template file, after redeploying the portal ear file, end user will still see the page/book that is supposed to be gone. Now, if you follow the best practice to recreate the desktop, if you choose option 3 to overwrite, you will still see the book/page that you have already deleted in the template. You have to manually remove it in the admin portal. If you choose option 2, though you still lose the customization, the deleted book/page disappears without any manual step.
3. Change the page/book definition label
You can think of changing the page/book definition label the same as deleting the old book/page and creating a similar page/book with a different definition label. Guess what will happen? You will see duplicated books or pages if you choose option 3. You have to delete the extra page/book manually in the admin portal. If you choose option 2, portal will give you a desktop conforming to what is in the .portal template file.
4. Add a new portlet
If you create a new portlet and add it to a portal page in the .portal template, end user won't be able to see the new portlet even if you recreate desktop using option 3. You have to manually add the new portlet (already in the portal library though) to the desired page. If you choose option 2 to recreate desktop, the new portlet can be shown without any manual step involved.
5. Delete a portlet from page
After we redeploy the portal application or recreate desktop using option 3, the portlet still shows on the page. If we use option 2 to recreate desktop, the deleted portlet will disappear after the desktop is recreated.
6. Not only delete the portlet from portal page, but also delete the .portlet file from application
After we redeploy the portal application or recreate desktop using option 3, the portlet still shows on the page, but with the following message "This portlet is no longer available. Please remove.". That's because after the redeployment, the portlet does not exist in the portal resource library any more. If we use option 2 to recreate desktop, the portlet that has been deleted will disappear.
7. Change a portlet definition label
In this case, you don't even need to recreate desktop. If you simply redeploy the portal application, the definition label of such portlet will be automatically updated in your portal resource library and your existing desktop. The end user will still see the same portlet.
8. Change a portlet definition property in the .portlet file such as title or content url
It is the same as case 7. After redeployment, the new title and data from the new content url take effect in the existing desktop right away without we recreating the desktop
9. Change a portlet instance label in the .portal file
After you redeploy the portal application, there is no change to the portlet display. But the portlet in the desktop still has the old instance label. Recreating desktop using option 3 does not change anything. After you recreate desktop using option 2, the portlet in the desktop shows the new instance label.
10. Change the portlet instance property such as title
You can change the instance property of a portlet such as title in the .portal template file. It can be different from the definition property title we define in the .portlet file. After redeployment or desktop recreation using option 3, the portlet still does not show the new instance property. Only if you use option to recreate desktop, will the new instance property such as title shows before the end user.
In summary, if you don't use customization in your portal application, always choose option 2 (Replace conflicting Portal Resources with Template version), . If you use customization in your portal application, in some case you have to modify the existing desktop manually. These cases include deleting a page/book, changing page/book definition label, deleting portlet, etc.
On another note, as a best practice, you should come up with a good naming convention for all the definition label and instance label at the beginnig of your portal project. It does not matter what naming convention you use. The key is having one and sticking to it from the very beginning. This will avoid the hassle of changing the labels later. Here is the label naming convention that Quinton Wall recommends: http://dev2dev.bea.com/blog/quinton_wall/archive/2005/08/definition_labe_1.html
Portal Desktop Recreation Best Practice Part 1
Posted by ljiang2 on September 8, 2005 at 9:25 PM | Permalink
| Comments (5)
The most common way to create desktop in the admin portal is to base on a .portal template file. Please click here to see step by step instructions on how to create portal desktop from a portal template file. It is simple and easy. However, soon your .portal file will be changed during the development. How do you recreate the desktop in the administration portal? One way is to delete the old desktop and create the new desktop basing on the updated .portal. The drawback of this approach is that all the entitlement and customization you have done in the admin portal is gone. Configuring a portal desktop to setup all the entitlement rules is not a simple task. I have a client who got so frustrated when he had to go through all the books/pages/ portlets and set their entitlement every time he recreated the desktop.
Instead of deleting the old desktop and recreating a new desktop, you can also edit the existing desktop in the admin portal manually. Thus all the customization and entitlement you have done are intact. There are several drawbacks for this approaches too. First, you need to diff the previous .portal file with the new .portal file to understand what has been changed. It is a lengthy manual process and it is easy to miss some changes made in the .portal file and forget to apply them to the desktop in the admin portal. Second, if there are changes such as adding a new backing file to a portlet, there is no easy way to do it in the admin portal.
Here is a better way: leave the existing desktop intact and create a new desktop with a different desktop name by using the updated .portal template. Because the resources such as books and pages are already in the portal library (If you don't change the definition label), the admin portal will prompt you if you want to overwrite the resources with the new settings in the .portal file. You should choose "overwrite". Once the operation is done, you have two desktops. Please note that at this moment, though it seems that you have not made any changes to your old desktop, actually it has already been updated with the new settings in the new .portal file. In this case, the entitlement rules are still be intact.
What about customization then? You will still lose the customization if you use WLP8.1sp3 or older. Since sp4, there is a new option when the admin portal tells you there are conflicts with the resources in the library and what action you want to take. The new option allows you to only overwrite the markup of the resources in the library with the template version. If you choose this new option combined with my recommended desktop recreation strategy, the customization will be kept intact.
 |
