James - Please forgive the length of this response! I want to provide you with as much information as possible to have you help me determine a sound architectural approach.
James Falkner:
On your other topic around integration.. I would caution you against using WSRP right out of the gate. It has several issues with it that would make me not want to use it for any integrations - it is very resource intensive (eats bandwidth and memory), and requires a separate identity propogration, authentication and authorization infrastructure as these topics were not addressed in the spec. These are usually handled by other enterprise WS-* setups. The only time I'd use WSRP is if the product I was integrating was based on it and provided 80%-90% of the work needed to complete the integration, or your portal was heavily based on it (e.g. Oracle WebCenter).
Unfortunately, I've come to the same conclusion... I was reading the following thread, which members of the Liferay staff had responded: http://www.theserverside.com/news/thread.tss?thread_id=45109
This approach, at a glance, really appeared to be the direction that made the most sense, based on what I believe our requirements to be. I'm disappointed that it appears to be so problematic.
James Falkner:
Depending on the nature of the apps you wish to integrate, there are many other techniques for integration (e.g. IFrames, custom portlets, web proxies). If you can give me more information on the nature of the products you are integrating I could give you some additional guidance. I just completed a whitepaper on this topic in fact and would probably be a good read for you.
I am very interested in reading this whitepaper! Can you provide me a link or email it to me?
Our architecture basically consists of individually written and owned applications, which happen to be presented to our clients as a single portal. This is our own home-grown portal, which is using the term "portal" very loosely!
Our portal is basically an elaborate menuing system, with integration techniques to make it appear as though these individual applications are a part of the portal. All of the user administration is managed at the portal level, and access to the applications are granted at the portal level as well.
For instance... We have:
- A reporting application, which accesses it's own database
- A document viewing application, which accesses it's own and separate database
- A job management application, which also accesses it's own and separate database
These three applications have been developed using some integration techniques, which enable them to be presented in our common portal interface as follows:
- Each application calls a Portal JavaScript method to include a common header/footer/CSS
- Each application calls a Portal Web Service to ensure a user is authenticated
- Each application implements a method to keep a portal session alive
As users are added to the Portal, they are granted access to one or more of the applications described above. When the user logs in, they are presented with a menu of applications and cabilities they are allowed to access (assume this is through https://mycompanyportal.com). As the select applications/capabilities, the users browser is redirected (via HTTP POST) to the application they have selected (assume http://applicationA.com). The Portal passes some information to the application that it will in turn use to validate the user and authorize to it's own application functions. The first thing the application does is call a Portal Web Service to ensure that the user is a valid user and in fact has an active Portal session. The application also calls some Portal Javascript methods to:
- Get a Header and Footer
- Include it's own header menu items
- Include some navigational breadcrumbs
- Keep the Portal session alive
To the end-user, it appears as though they are in a single application, although the URL would suggest differently. Header menu items, such as "Home" would navigate you back and forth between the Portal and the application, seamlessly.
Hopefully, this give you a good idea of our current state? Our target state is to implement an overall Portal strategy that implements standards such as JSR-168 and JSR-286, and enables much more flexibility to the end-user as far as the presentation goes.
Rather than having each application write to our proprietary portal framework, we would rather have them write to a Portlet specification, and be able to be included in one or more portals as appropriate. The key is that these applications will not be "physically installed" on the Portal server where the portlet is to be presented, as there may be one-to-many Portals choosing to allow access to the portlet, and this would be a maintenance nightmare. Instead, we would rather access the portlets remotely, allowing the team that owns that portlet to be responsible for hosting and maintaining it. Essentially, it is web services for portlets (or WSRP... LOL)
How, as an enterprise, would we go about architecting a Portal strategy that would enable application development teams to develop, implement and support their own portlets, to be used in Portals supported by entirely different organizations? I want to recommend the strategy and standards for doing so, yet am stuck with the limitations and feasibility of the technologies that would appear to get me there.
I'm happy to continue posting here, for the benefit of others, but feel free to email or call me, if you need more details. Meesa has my contact information, as do you, I believe.
Thanks and best regards,
Todd
Be kell jelentkezni ahhoz, hogy ez helytelenként legyen megjelölve.
