> Hi, > > > > 1. JSR 168 portlets can co-operate in they are within the same > WAR. If it is WSRP then there is no concept of WAR. Right ? It is > remote. So the normal co-operation that the JSR 168 spec. defines will > not apply. > Yes, the WSRP environment could be written in Java, .Net, or PERL. But you who uses that remote service have no access to the 'inner implementation' -- i.e. a war file.
> 2. Actually I was trying to find out if SAML is used now in > conjunction with WSRP widely. I think that SAML is used for federated > identity management ? > > 3. WSRP security means normal SSL or something else. Right ? > Doesn't SOAP define security ? > > 4. "WSRP will not properly handle cookie information from your > portlet all the way back to the client." Why is that ? > For every cookie that gets sent back to a client, there is a domain associated with them. The browser will only use cookies that come from the original domain. From the client's perspective, all the portlets reside on the portal -- which is (likely) a different domain than the domain of the service. In effect, the domain of the cookies would need to be rewritten as well -- which could cause a collision with other cookies having the same "name" attribute from other cookies in other services. To answer your question in a simple sentence, the WSRP spec is defined to be stateless -- like the good old days of HTML when cookies were not available. > 5. "Unfortunately, the information between the a tag (i.e. <a > href="...">URL will be rewritten</a> ) will get rewritten as well. This > could lead to problems if NOT careful." Can you point me to some > examples ? I must confess, I'm writing this after working with the WSRP spec nearly 2 years ago. I don't have any real examples to show since I'm not seeing WSRP services everywhere I look on the web at this time. I have done work with Portals and portlets that used technology that pre-dated WSRP and found that there were occasional issues with the global search and replace technique that's currently implemented for WSRP4J. I looked at the source code of WSRP for Java and saw that this could be an issue if the HTML data (vs HTML markup) did coincidently have the same values. To do this 'right', contextually searching and replacing the atributes of tags such as the <a> and the <img> will give a result that can be expected. Since WSRP is ultimately an XML file getting passed back to the client, images or even PDF files could be rendered from a WSRP response -- where the likelihood of a collision increases. > > 6. AJAX in WSRP.... and JSON > Good luck! Remember, you have no idea what service will be next to yours in some browser. You also have no clue as to whether your service is rendered in a (I)Frame based portlet or a <table> based portlet. If the portal uses tables (and most of them do), some other service could have the same method or variable name in that portlet as you have in yours -- thus causing a namespace collision. Although I don't remember the spec defining a portal page requiring table based portlets, most of the portals use the table tag because of issues that Frames or IFrames have with setting the Cascading Style Sheet (CSS). It's easier to layout all your portlets in a table and get a consistant look and feel than insert the respective CSS of the portal into each of the portlets (I)Frames and expect a consistant look and feel throughout the portlets. Take care! James Moliere > > > So many things that are possible with portlets seem to break in WSRP. > > > > > > Thanks, > > Mohan > > ________________________________ > > From: Tali Garsiel [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 11, 2006 7:53 PM > To: [email protected] > Subject: RE: Limitations of WSRP > > > > Hi, > > > > I think a big limitation is that's almost impossible to use AJAX calls > in WSRP portlets. > > > > Tali > > > > ________________________________ > > From: James Moliere [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 11, 2006 5:01 PM > To: [email protected] > Subject: RE: Limitations of WSRP > > > > Mohan, > > > > 1 - Yes. Think of WSRP and JSR168 as a standard where WSRP is the > remote portlet and JSR168 is the local portlet. They are similar > technologies that avoid stepping on each others toes. > > 2 -- ? > > 3 -- ? > > 4 - In WSRP, any type of HTML may lead to problems - i.e. the base tag ( > <BASE SRC="">) for HTML may become a problem for you if the URL doesn't > get rewritten. In the case of javascript, remember that the portlet you > are developing will likely go into a container that serves the HTML in a > table. The problem with this is that other portlets that have > Javascript may collide with your functions (names space collisions). In > essence, avoid Javascript. Another problem is Cookies - avoid cookies > as well. WSRP will not properly handle cookie information from your > portlet all the way back to the client. Even if it tried, the spec for > cookies is, 20 cookies from one domain will get sent back from the > client to the server. If a user just happened to have 21 portlets > (where rewrite is turned-on on all of them) on 1 page all requiring 1 > cookie - one of the cookies will not get sent back to its respective > remote service. > > > > 5 -- To rewrite the URLs in WSRP, the algorithm is a simple search and > replace throughout the whole document and replace the URL. The problem > with this is that the standard should have been written to contextually > search and replace a document. For example, the following HTML tags <a > href="...">, <img src="">, could be searched and replaced as expected. > Unfortunately, the information between the a tag (i.e. <a href="...">URL > will be rewritten</a> ) will get rewritten as well. This could lead to > problems if NOT careful. > > > > I'm really looking forward to an update to the spec - WSRP 2.0. > > > > I hope this was helpful > > > > James Moliere > > > > ________________________________ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 11, 2006 3:41 AM > To: [email protected] > Subject: Limitations of WSRP > > > > Hi, > > We have been trying to list the limitations of WSRP 1.0. I have a > few questions. Appreciate if somebody can answer or point at the > mistakes. > > > > 1. What impact does WSRP have on co-operating JSR168 portlets ? Can > they still co-operate if they are served by the producer ? > 2. Is there any integration API available for WSRP and SAML ? > 3. What are the security mechanisms available to secure WSRP > communication? > 4. Can I assume that any type of HTML/DHTML markup and Javascript > can be served by the WSRP impl. ? > > 5. What other limitation does WSRP impose ? > > > > Thanks, > > Mohan > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you have > received it in error, please notify the sender immediately and delete > the original. Any other use of the email by you is prohibited. > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you have > received it in error, please notify the sender immediately and delete the > original. Any other use of the email by you is prohibited. >
