More often then not, technical people look to solve problems with some sort of tool or product rather then try and change internal processes or the way they manage themselves or the organization. Many times we will look at a product and insist that it is not the way that we do it. Often there has to be a combination of changes for things to work effectively. Custom tooling and/or configuration, or modifying the way a product works out of the box takes time and the results are not often what you expect. The best of all worlds is finding a product or tool that fits nicely with your organization, approach, and requirements, rather then having to spend a bunch of money to do custom modifications or making your organization change their process to conform to a stricter set of rules. But we can’t always have it both ways. Take a look at Maven as an example. Maven expects you conform to its prescribed way of defining and performing a build, and if you accept this, then things work reasonably well. If you have different ideas and want to do it your own way, then you are on your own to get things working correctly. Or you can take a different route and build your own custom scripts using Ant, which provides a much more flexible approach, but requires more work on your part to define and build the build components. It's all about choices and flexibility IMHO.
Portal can be a little like that to. There are lots of extension points in WebSphere Portal where the software can be adapted to your organization, but not in every case. Making the software flexible enough to different requirements, and still keeping it robust is a difficult task. I'll have to admit some learning goes into the process as well, understanding where the pain points are for customers if often an evolving task that changes from release to release as new functionality and flexibility is provided.
I encourage customers to be flexible and open minded about the way WebSphere Portal approaches things. Approaches to handling security, performance, and emerging standards have been proven through thousands of customers of WAS, WP, and other products in the WebSphere brand. But in some cases there is a sound business or technical reason for adaptation and flexibility and there are many customization points within the portal. In these cases I am usually in favor of taking the hard road to create the right solution, rather then trying to kludge together some work around to avoid getting our hands dirty. It does take a good understand of the effort needed to perform customization, and it may not also provide the best results without some time to evolve your solution. This is the same way that parts of the portal have evolved and improved with each new release. Don't expect extensive modifications to work exactly the way you need right away, especially if you are new to the technology. It often gets worse before it gets better. But the reward can be there in these situations with a simplified architecture that fits nicely within your environment.
Sometimes folks make extensive architectural modifications and then ask if I will come in and validate their work. This is very difficult unless I have been involved with the effort from the initial design, or even done the coding myself. Some static analysis is possible, but signing off on complete compatibility is often not in the cards. Mostly this isn't a big deal, because the stuff works and you went into the situation with the understanding that custom modifications, the same as custom application code, would be supported by your development teams.
just some food for thought![Read More]
Portal in Action
More often then not, people look to solve problems with some sort of tool. But often there has to be a combination of the two. Custom tooling and/or configuration takes time, and the best approach is a tool that fits your approach, rather then you having to conform to a stricter set of rules. But we can’t always have it both ways. Take a look at Maven as an example. Maven expects you conform to its prescribed way of defining and performing a build, and if you accept this, then things work reasonably well. If you have different ideas and want to do it your own way, then you are on your own to get things working correctly. Or you can take a different route and build your own custom scripts using Ant, which provides a much more flexible approach, but requires more work on your part to define and build the build components.
Currently, in my spare time, I am working on some ideas around using Rational Build Forge with Portal. I think these two products could be a great match and I am hoping to build some examples to prove it. Starting with a set of sample scripts to illustrate how Build Forge can be used to build and deploy portal artifacts. This is something that has been lacking in the portal space, a good build and configuration management tool that can be easily implemented by customers. Rumors do suggest that improved site management for portal is right over the horizon, which will hopefully start to solve some of common issues, but I don't think it will fill some of more visible configuration management issues; at least not initially.
In the past, my recommendations for builds have mostly been to look at using open source products. For those of you who have seen my presentations at conferences, I'm always showing demos of how to use Anthill, or CruiseControl to build and deploy portal components. In fact the first version of our book, "Portlet Programming", has an appendix on how to setup your environment for using just such a build tool. Deployment has been slight more difficult, but is possible with some moderately complex Ant scripting to get some of these tools to perform the initial deployment to a dev or integration server.
To me, the key is allowing developers the ability to deploy and update code on their schedule, but to still maintain good control of what they are actually able to do. By having a tool with a simple interface where they can kick off a process which will build a portlet and deploy it to a test server, right after checking in their code, is a win-win situation. No more having developers waiting until the end of the day for someone to be available to deploy their code, or worse, when it doesn't work, having to do several deploys in a row to get the right files installed and configured in a timely manner.
Without this type of streamlining in place, the process breaks down. Developers can't wait, and so the infrastructure folks give them administration access to deploy. But now there is no control over who is doing what in the environment, and more then likely things are getting built and deployed from developer’s workstations, rather then from version control where it's supposed to be coming from. This also allows administrators to control better who has access to their machines, as well as ensuring that all code goes through source control and gets versioned.
In don't think these ideas are very unique, but it takes someone who understands the problems and concerns of both the development teams, and the administration teams to see how to accomplish the joint goal.
OK, I wandered off point again, but it's all so interesting. I'm actually going to stop here and continue this in a separate entry in a few days. Some of the feedback I get from time to time is that my entries are too long, and people don't have time to read them unless they really are interested in the topics or need some specific data. I'm not the type of blogger that posts the latest fixpack or industry news. I figure you can get that on your own. So I'll continue this story in a few days - like a mini-series, for geeks!
I have probably said this before, but I will talk about it again because of recent discussions I have had. When talking with customers and project teams I always caution about expecting too much from Out Of the Box (OOB) portlets. The issue is this, if the portlet doesn't do exactly what you want, or if the customer would like one tiny change, you have to do custom development to meet the new requirements, and if you have not counted that into your project plan you might have some trouble.
This is also true of portlets available on the WebSphere Portal Catalog. Care should be taken to ensure that the portlets you need are actually available, and that they are available for the portal version that you are going to be using. Many of the portlets available on the catalog are provided by 3rd party vendors and new versions of the portlets are not always readily available with new portal server releases. Additionally, all OOB portlets have some limitations that may be problematic in your environment. One good example is the new google gadgets portlet. This is a great new set of functionality that does not, with the current release, support the use of a proxy server. OK, that might not be a problem... until you need it. And unless you can get an exception from your security and operations teams you might be out of luck, until the next version is released. I'm picking on this portlet because it is so popular, but I could have chosen any one of a handful to point out potential limitiations.
One of my favorite portlets the Portal Log Viewer has not been updated for WebSphere Portal version 6, with no plans in sight for an update. I was able to track down the original developer, who has since moved on to a new job and is not working on this portlet anymore. : (
The catalog does have a rating and comment system, so it is important that you read any comments offered by those that have come before you. Additionally I think it is up to customers to put the pressure on vendors to update their portlets and make them available. There is obvious value in being able to access information through a portlet or set of portlets, but the visibility needs to be raised [to vendors] that there is actually a demand for this capability from you the customer. With JSR 168 as a standard there should be no excuses around compatability and it should be one size fits all for the leading portal servers. One place where the catalog can help is in validating new portlets that become available from 3rd parties.
Custom development is of course always an option, and in many cases, not as bad as you would think. WebSphere Portal offers a number of development options such as JavaServer Faces, the Portlet Factory, and more recently Lotus Component Designer. Someone with a little experience can code up a simple portlet in a few hours using one of these approaches. Other products, such as Lotus Workforce Management are filling the gap by providing connection capability to commonly used back end systems.
I think that overall the situation is getting better, but you should proceed with caution if you are basing the core of your portal strategy on OOB capability.[Read More]
I finally got a chance to read Sandy Carter's new book on SOA and Web 2.0 during some recent travel. Like most people in my business I usually have a stack of books and magazines sitting by my desk waiting for my next trip. As a techie who likes to be a little more in the weeds I tend to shy away from business oriented books, but with SOA it is different. HOW to build services is pretty well defined and documented, what eludes me more are the WHYs and WHATs of a Service Oriented Architecture. I think much of SOA can be difficult to understand for many people (myself included), and I was looking for this book to
The book was able to deliver on both counts. I particularly like the chapter on Governance. As some of you know I am always preaching governance and process within projects and IT organizations. I was discussing it most recently in my articleIs your portal project robust or fragile?. But there is a perception that 'governance = slow' which is an issue for many companies and especially for techies like myself who don't like process to get in the way of getting something done. I was impressed with how Sandy was able to tie governance and flexibility together within the SOA context. This tie in happens throughout the book actually as maximum 'business' flexibility is illustrated through examples and case studies. In addition, Sandy says, "Governance is the policy, clarity, and measurements that drive the alignment of business and IT." This ties in exactly with points I have made in early blogs about the business driving IT and adding value to the business rather then IT. Several years ago I started down this path with an entry on Development Requirements and Business Value. It is good for me to read a more formalized approach that can add direct value to any business.
If you are interested SOA I would check it out. Also, check out the reviews on Amazon if you need a second opinion.
I need to phrase this posting as more of a question then a solution. The question asked to me was the following. Given several pages or tabs on the entire portal, how do I get a specific portlet on the page to refresh back to its original state, when the user navigates to a different page and then back again to this original page which contains the portlet. Also, even if a user just clicks on the page (or page tab) I want that to act as a refresh to set the portlet to its original state also.
Customers are always coming up with different requirements like this; often we have to come up with some weird hack to make it work. A friend of mine, Chris Vishwanathan authored an article last year with a different scenario. This one where the customer wanted to save any data entered into a portlet form when ever the user navigated away and then back to the page. Similar scenario, just a different requirement on the portlet. Check out Persisting portlet forms data in WebSphere Portal V5.1 for more info on that one.
It have been awhile since I have had to figure something like this out, so I thought I might spend a little brain power to think about a solution. In this case the results I was seeking were small enough that I could spend a little time on researching the problem. Obviously my day job prevents me from activitvely solving every question I receive. : ) My first step was to see what happens in the portal today that we could leverage. I cooked up a couple of test portlets to see what happens. I got the following scenarios.
I thought we could use this relationship to try and reset portlets when necessary. One caveat here is that I was told there would only be one portlet on the page. With multiple portlets, depending upon what function they performed some of this may need to be reconsidered. The key here for me would be that any action within the portlet needs to go through the processAction() method and a parameter could be set to let the doView() know that things were ok. If the parameter was not set that it would trigger the doView() to know that this was an actual refresh, or that the user was working somewhere else within the portal.
The resetting of the page itself has to be portlet specific. In this case I don't know whether this is a form, or some type of in portlet navigation that the user is performing, but I think those specific can be worked out once a design approach is designed upon.
Anyway, these are just some thoughts, I would love to her how others have approached similar problems or if these thoughts are useful to others. I'm better other projects have similar requirements that are just slight different from what I outlined here. What tricks did you come up with in solving these challanges?
I was able to spend a little time over the last few weekends reviewing the WSRR-Portal Tech Preview. Pretty sad isn't it, this is what I do with my free time? This is an area of integration that we nagging at me, and I really want to try and stay ahead of the curve on the latest portal advances with SOA integration.
I was disappointed in some areas and excited with others. First I guess I'll talk about my disappointment. Really this is not the fault of any of the tools or development efforts, but rather my own bias toward improving portal management and governance. What I really think we need is some type of tool that allows us to provide meta-data around portlets themselves in some sort of catalog fashion. Some of this meta-data would include the purpose and owner of the portlet as well as any input or output parameters that the portlet may use with messaging. This would allow new composite applications to be created more easily by allowing administrators and business owners to look up portlets and see how they might communicate with one another. It would also help enforce some sort of standard approach to messaging allowing developers to adhere to published formal or informal standards. In other words, a developer can look at what parameters other portlets are using and attempt to build their portlet in a complimentary fashion. Up to now, I think the best way to accomplish this type of catalog may be a wiki that will allow cross domain teams to collaborate and maintain the information on different components. Our goal should be to help define a set of meta elements or development standards that can be used as a template to accomplish this goal. I'll try and come up with a template for a sample portlet catalog entry on Portal Patterns.org.
As for the exciting news, the WSRR tech preview really is impressive in terms of the integration with WSRR for portlet that utilize or provide services. There are two main parts to the integration.
With WSRP producers, after a portal is registered as a producer, other portals can then look up available producers and search for WSRP services any given producer offers. This is directly inline with most of the WSRP producer patterns that have been put forward. This includes either standalone producers or producers that also provide a standard interface to end users. I'll have to enumerate some of the common WSRP patterns that are available in a different posting. WSRP has been a little slow in being full adopted, but the vision has been constant, and the standard is continuously being improved upon. It is only a matter of time before it becomes better adopted within portal environments.
The second integration point is the ability to register portlets which consume services that are defined within WSRR. This provides a nice catalog of portlets which are really the front end for services available within the enterprise. Additionally, the capability to modify the service that the portlet uses is provided with some replacement of some of the administration capability within WebSphere Portal. This is an interesting capability that allows portlets to consume updated services that may become available over time.
From a portal perspective I think WSRR is still a challenge and I would not recommend embracing this approach, unless you already were embarking upon an SOA strategy within your organization. If this is the case then WSRR is probably going to be a player within your infrastructure and you are building the skills within your enterprise to manager this type of environment. For the average portal administrator (including myself) there is still a bit of a curve to climb to become truly proficient with and taking best advantage of WSRR within your SOA environment.
This integration is still a tech preview, so there were a few bumps in getting everything to work correctly, however the initial results were pretty impressive and I expect these things to become much cleaner as it becomes a fully integrated part of the product set.
JoeyBernal 1200007EAE 756 Views
Some interesting activities have been going on in my project with WPF over the past couple of weeks. We were still working with the Portlet Factory and actually starting to code, when our project basically got canceled. This was sad, if only in the fact that we were starting to make progress on getting the factory to work our way. One pain point was the ability to build factory war files directly from the SCM without having eclipse installed. Using RAD or eclipse bugs me when used in this way. There is a build pattern called the "Golden or Magical Workstation" that allows for this approach. I have even used this on occasion, but for big projects the build should be abstracted from developers completely.
Since everyone works in the same war in WPF, then everyone works on the same project in the SCM. This is troublesome, but not enough to throw us off too far. From my discussions with other WPF experts, there are some teams that have worked out how to code in separate projects in WPF, but this issue didn't bother me enough to consider going down that path. I was more concerned with how we were going to handle code check-in/check-out in the same project.
The best practice recommendation is to only check on those models, profiles, java classes that are being used by the developers. Since a lot of the files in the project are system dependent this would prevent folks from getting their systems overridden with someone else’s properties files. Unfortunately, I knew this would not work on the build side, so my goal was to get the entire project checked into the SCM so that it could be checked out and built by our build scripts. A few days of wrangling and we eventually ended up with setting ignores everyone within the checked in project so that only files that were necessary were being synchronized. Unfortunately because of our project status, we were only getting the bugs worked out before we stopped our efforts in this area. The goal here though is to get this streamlined so that new developers coming on line can sync up and get the right files with little effort.
On the build side of the project, there was also some progress that we made if only as proof points. It did make for an interesting set of discussions around whether we should conform to the factory, or make it conform to us. Our build manager was doing the research and came up with a combination of Ant scripts and Cruise Control as the primary approach. Checking out the files from the SCM was no problem, but it took some hunting to determine which build scripts to use for actually creating the portlet war file. If you search into the WEB-INF\bin\deployment\jsr168 there are a number of scripts that provide the right information. After setting up Ant I was able to build a war direct from the command line, but more importantly our build manager was able to do the same on the build machine without eclipse installed.
I’m not going to offer any guarantees on any of this discussion, as we were just scratching the surface.
Also from the comments, it looks like William was interested in Portlet Factory Training. There are a number of course offered throughIBM Training. For example there is a course Portlet Factory: Developer Fundamentals, as well as several other advanced courses. Most of the folks on our team had gone through the training and picked things up pretty quickly. All of them had previous development experience with WebSphere Portal which I think makes a difference. Our factory consultants tell us that with the right training and guidance people are very productive using this tool. Honestly, I have seen our experts build things very quickly.
Anyway, until I get another chance at this I'll move on to something new. Specifically back to looking at the WebSphere Portal WSRR Integration Technical Preview.
OK, not really, but I figured this would grab your attention. Actually for for the current project I am working on we are using WebSphere Portlet Factory (WPF) as the main development tool. This is a first for me, mostly because my background is more traditional J2EE architect and development I have been engaged with customers and projects using the Portlet or IBM API, Struts, or more recently JSF. I have been through WPF training and on a few projects I have been on teams which were split, with some developers using WPF and others coding in Java, but even on these projects I had not really seen first hand the coding effort involved for building a non-trivial WPF portlet.
As part of my role within Software Services for Lotus, I have taken on the daunting task of trying to help customers understand when to use a particular approach or tool for portal development, so this current effort is really important in helping me to understand the power and limitations of the factory in building a large application. Usman Memon, my good friend, and crazy WPF advocate has been trying to convince me for years about the power of WPF. Many of the claims around the tool I have always taken with a grain of salt, but this time we were able to make the discussion more tangible by focusing on real world deliverables.
I had started some discussions around this topic recently with my blog entry Too Many Development Tools?, but I think I am only scratching the surface. Folks that read this blog or know me understand that these efforts are a journey. Since I flirt between infrastructure, development, architecture, or whatever depending upon who I'm working with at the current time, it may end up taking months or years to sort this all out. This is especially true when you think about customers who want to use Flex2, SpringMVC, or anything else you can imagine. Yes, I have actually talked to customers who want to use these frameworks, and in most cases they are quite valid approaches, but from a delivery side it is difficult to understand them all and make recommendations.
So, back on point, this particular project happens to include some SAP integration. Usman was leading some of the developers (including me) in how this integration could be built with WPF. The results were truly impressive, being able to connect and build out a simple call within a few hours of coding and design discussions. At one point we had to drop into creating a java class to help parse the data into a format that was easier for the factory to deal with and display. Originally I thought this was a limitation of WPF, but thinking more reasonably it is just a fact of the tool. You might actually consider it a feature the way the factory lets you extend the tooling with custom java classes and libraries. One point to consider here is that some Java skills may be necessary for anything beyond a trivial application.
So far, I do have a few additional issues not related to coding. They have to do with items like separation of projects, source control, automatic builds of the factory war, but members of our team are sorting those items out. It may be a case of me having to adjust my views on how things are supposed to be done. Imagine that? My goal is to continue to build out a few more portlets and measure the learning curve, and the value, against other technologies. We'll see how things end up... maybe I have been converted after all?[Read More]
The title of this entry makes it think like I'm just catching on; but actually I have just been struggling for quite awhile around how to define the term. I think that finally I have some of the idea sorted out. Of course I might just be slower then everyone else, because it seems like everyone has an idea for what composite applications are all about. In an earlier blog I talked about little about the multiple tools that IBM has for developing portal applications, and I think this has led a little to the confusion as the marketing message for each tool or component seems to scream "composite applications" at everyone. I think I have the tools message sorted out, which is important enough to warrant its own entry at a later time.
We all know how marketers like to throw on the buzz words, thinking it helps to make a sell, but for me it makes things more confusing sometimes, and then makes the term meaningless. Another thing that added to my confusion is that sometimes I view things myopically from a strictly portal view, so naturally when thinking about composite applications I think of portlets, when in reality I should think more about SOA big picture. So, from my (portal) perspective a composite application is:
So, doesn't this list seem to include really any portlet? We'll almost; the driving factor here is the idea of the portlet being driven or interacting with a service. But there are also other examples where several portlets could be wired together, and not all be back ended with a service, but rather a database query or by a notes database. Really this is the only way that I can rationalize all of this with all the messages that come at us every day. This set of rules would obviously include mashups and other presentation level efforts, as well as deeper level integration with existing services. If you look at the definitions below from Wikipedia you will see what I mean.
Wikipedia seems to back up my thinking, and begins its definition of composite applications by saying it, "Composite Applications express a perspective of software engineering that defines an application built by combining multiple services." It also goes on to say that composite applications, "consist of functionality drawn from several different sources within a service oriented architecture (SOA)", and the definition seems to imply that web services are necessary to constitute it being called a composite application, but I think it could be extended to include other types of services as technology allows.
There is another blog on developerWorks that focuses almost solely on composite applications. Reading through it there is some good perspective on types of composite applications in portal.
One aspect that bothers me, and has probably led to my confusion, is the idea that all of these portlets are going to be magically wired together as new applications are composed. One thing missing here is the standards required to ensure that a portlet created today can someday interact with another portlet created by a different developer 6 months from now. This requires not only coding and messaging standards and naming conventions, but also a catalog of portlet metadata to ensure that we can lookup how things can be composed at a later date.
Fortunately, Stefan Hepper figured out a way to try and manage the messaging standards that are required not only with internal development, but by external vendors who are supplying portlets with this functionality. Stefan figured out that a wiki page would be a great place to allow the development community to collaborate on messaging standards and messages for each portlet. This first step will allow an organization to maintain a listing or catalog of what is available and let developer build upon the work of others. I see this starting to take hold a little as internal developers start to document the input and output messages of their portlets. This information needs to start being published publicly so that customers and vendors can build solutions which interact with these portlets. Luckily, Stefan gave me permission to recreate this idea on portalpatterns.org for others to share and improve upon. I'm published some initial samples so take a look at this page and let me know if you think this approach will work?
The other thing that organizations will need is an extension to this information so that users can find all the available portlets. This would be something similar to the portlet catalog as an extension of the concept that WSRR provides in terms of creating a repository of services within the organization. I think that WSRR is probably a good fit for maintaining WSRP services, but not sure that is can work for general portlets.
There are different schools of thought by the way (or maybe it is just me) around the idea of end users and business users creating new composite applications and making changes within a production portal environment. Of course different portals have different requirements, but governance is important in maintaning a healty system. Changing the user patterns, or making changes without moving and testing these changes throught the deployment chain could be trouble.
An architect I once worked with asked me why I sometimes struggled with the high level patterns he would discuss during our conversations. I told him it was because I was the one who actually had to make things work! I think it is a little of the same with the idea of composite applications. Conceptually we have some solid patterns, and even available tooling for wiring or "composing" applications, and workflow to orchestrate new solutions. But to really make the vision a reality within an organization another level of detail is required that I'm not sure everyone understands.[Read More]
JoeyBernal 1200007EAE 911 Views
One of my areas of focus is on different development tools and approaches that are available within the portal space. Picking even one tool or API and trying to keep up with all the latest features and functions is hard enough. Trying to understand variations between different tools is just crazy. Of course, since I get involved in different areas of interest, infrastructure, development, deployment, configuration, etc., I tend to circle around on topics as questions arise.
Last summer I spent some time exploring where we were in the JSF space and trying to determine if JSF was ready for prime time, and to what degree. I concluded that it was about there for many efforts, and with some caution, folks could proceed with using JSF as their primary development platform for portlets. In conjunction with this effort, I spent some time exploring the pros and cons of WebSphere Portal Factory and how and why an organization might make some decisions around choosing a primary framework for their environment. A lot of the decision points came down to existing skills within the organization, tactical vs. strategic efforts, future directions, and organizational standards.
As someone who focuses on providing services around the IBM products, one of my goals is to help customers make the right decision around product choices, and then once decided, to use those products effectively. I think I have mentioned before that with some customers this can be difficult becuase of IT rules or legacy issues, and products have to be twisted to make the right fit. In other situations, customers just want a recommendation on what approach or product to use, which in some ways can be even harder, becuase you don't want to steer folks in the wrong direction. Once you are used to customers saying, "we don't do it that way", it is sometimes a shock when someone says, "we'll do it whichever way you suggest". : )
More and more I am using the term, "One size does not fit all", to describe our product and tooling offerings. This is really the only way I can think of to explain why many of our products have overlapping features and function. And really in this posting I am just thinking about the development tooling space. Don't even get me started on our primary server line of products and offerings.
Recently, Lotus announced a new development tool, Lotus Component Designer. My goal is to take a hard look and talk to the development team to see how this fits in to our overall strategy and when customers might choose this tool over, or combined with other tools in our development lineup. From a surface view it appears that Lotus Component Designer would fit nicely with traditional RAD development using the Java Portlet API or JSF. But some discussions with the product manager to understand the product view better will help shape my position on when this should be recommended to a customer. I'd like to see where this fits into the concept of building useful portlets and even composite applications.
Ooh. I almost got started on a rant about composite applications, but I'll hold off till another posting for that one.
When people ask this question, I am usually very happy. That means they are thinking about design and development standards for their team or organization. Inexperienced teams never ask this question, they just put the files where ever is convenient for each team member and go about their business. Only when deployment time comes do some of these decisions come back to haunt them. I tend to repeat myself on different topics and this is one of them. There is no right answer to this question. This is something that experienced folks struggle with also. We'll maybe not struggle as much as think about options and make some organizational decisions. Even if your choice does not cover 100 percent of all cases, there is always room for exception cases.
Benedict Fernandes and Keys Botzum have provided an article on developerWorks on Using URL resources to manage property files. For many teams this may be the right solution.
A colleague and I had a conversation about this recently as he was getting ready to lead another team through some portal development. For me it often depends upon how I am involved in a project as to where I put the file. What is really troublesome however is large projects with many portlets and many developers who are stepping all over each other in their property usage. Sometimes this happens when several portlets are using the same properties, such as a database or LDAP connection.
1. Without proper communication each will probably end up setting up their own property, and when the application gets deployed, someone has to set the same property value several times.
2. Other conflicts can occur when someone tries to use a common properties file, but assumes a different meaning for a specific property. This can cause a conflict when two different components want different values for the same property.
Item 1 most people can live with, although deployment has to be better documented to ensure that the property is changed in all the right places. Item 2 is more difficult and can require a rework of the code.
During our conversation I suggested we build up a properties service that would deliver properties to the calling components and could be searched by other developers to see if a property they were considering already existed. After stumbling around a little bit I saw that J2SE 1.5 now allows you to load properties via an XML files as well as using the standard name=value pairs approach. Using XML was interesting to me because it would allow me to add meta-data right to the property itself. Only problem here WebSphere Portal has not moved up to 1.5 yet. No problem, I'll just build my own XML based property service.
I came up with a very simple format that seemed to achieve what I wanted.
and then the service was built as a very simple singleton around this central file.
The portlet is pretty generic. No real searching or formatting, it just lists things out one after another. I suppose the extra effort could be taken into account during other project work so this approach could build upon itself. The portlet does allow you to reload the properties file without restarting the server, which is handy.
Once a developer knows what property they want need they can access it using something like
I've posted this sample code on my personal site Bernal.net for you to take a look at and reuse if interested. The whole thing probably took 2-3 hours, including the portlet and my stumbling at first. But the potential savings could be huge with a little more work to polish things up a bit. Of course I've posted more info at PortalPatterns.org.
As always I would love to hear your comments on how you approach properties within your organization or if you have some of the problems I have mentioned above?
For those of you that care: Hey, no rewrite rules needed![Read More]
I was at a meeting recently with some high level executive's of a large corporation to discuss the results of an analysis I had recently performed on one of their portal applications. There was an interesting theme that keep repeating itself during the meeting. As we discussed different issues, often around some process, or perhaps a coding issue that was found during the static analysis of the application, was the point that this was not really a portal specific problem. My response to this comment/question was usually no, many of these issues are common in any development environment.
The discussion got me to thinking, that often when customers have problems, they look to portal as a source of their problems. In the most simple terms, building applications for a portal environment isn't in itself a problem, but in many cases I think the portal environment can exacerbate the problem, simply because your components have to live in a shared environment. I think it is pretty obvious the benefits that a portal framework can provide, especially on an enterprise scale, so I won't go into that discussion here, however we really do want our applications and components to share a common environment and infrastructure, and be able to collaborate and be composed into larger applications, not to mention the fact that we can apply security, navigation, and other aspects to our applications without recoding or redeploying applications.
I watch the J2EE space very closely, as new technologies and approaches arise that could help my customers build better solutions. When I take a look at other technologies or approaches that other types of developers are taking, I then try and apply them to the portal space and see how they can be used to help improve our portal applications. Things like Hibernate, Ibatis, and Spring, which can be leveraged to build a local service layer into many applications and provide the right level of abstraction. At this level, there is very little, if anything, that is specific to portal, but much that portal developers need to be concerned with for their application design. Of course while new technologies can make our applications better, more scalable and robust, there is also a lot more that the developer needs to know, so unfortunately there is never time for resting on your laurels.
Now that portlets are really first class java components (pretty close if not actually there) and are using a standardized API, more emphasis can be placed on J2EE dev skills, rather then trying to build up folks who don't know Java into portlet developers. Knowledge of the Portlet API can be added to the list, along with Servlet, and EJB skills as organizations staff portal projects. You can see how portlet developers need to be concerned with everything that is going on in the J2EE space and not just portal specific issues. In many cases, portal experts need to be J2EE experts! Of course we still need to understand all the portal specific functionality as well. : )
In my next entry, I'll give you a specific example of how the portal space can complicate issues with properties files.[Read More]
I spent some time last weekend and the early part of this week getting WSRR installed. WSRR stands for WebSphere Services Registry and Repository. You can read about it in some articles published here on developerWorks at Intro to WSRR
One of my jobs in Lotus Services is to keep ahead of the Portal and SOA space and make sure we can fully address challenges integrating with portal, as IBM continues to drive new products in the SOA space. I have to admit I am in interested what WSRR has to offer. Although I don't think there is anything portal specific to using it, there may be some opportunities to build some portlets or samples that allow easier use with WebSphere Portal. Working with companies that are starting to build web services, not a lot of organizations have moved to the point where they are implementing strong governance or management of there services (from my experience). But I think that everyone understands that this is going to be necessary, and having worked with UDDI a little in the past, I see WSRR as a big improvement in its capability.
Of course I was not as excited with the installation of the product. I was actually a little disappointed that it failed to install easily on both Windows 2000 and Red Hat Enterprise 4. I have finally built up a decent library of blank virtual machine images that I can copy over and try things on different platforms. After several tries on both platforms I switched to Windows XP and the product installed without a hitch. I can't really say if it installed because of the platform, or because of the things I learned from previous failures. Once it had it up and running, I have to admit the interface was a bit daunting, so the next challenge is to actual try using it and build some samples. We'll see how that goes and what benefits this can bring us in the portal space.
On another note more portal related, I was able to put some more words to page on the Portal Patterns. With the help of some colleagues I was able to flush out some guidelines for the number of portlets to put on a page. Also, some more work in the portal development standards section on portlet packaging.[Read More]