[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][markup] First conference call (Summary)
From my point of view one very important point for using SOAP is its interoparability with other platforms, notably between J2EE and .NET. SOAP is widely supported by development environments what makes it easy to develop applications right from a WSDL interface and - more important - to develop such applications. Notably the debugging effort would increase significantly if we chose to either develop a new protocol on top of HTTP or just reuse HTTP. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+----------------------------> | | Thomas Schaeck | | | | | | 04/26/2002 01:20 | | | AM | | | | |---------+----------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Carsten Leue/Germany/IBM@IBMDE | | cc: | | From: Thomas Schaeck/Germany/IBM@IBMDE | | Subject: RE: [wsrp][markup] First conference call (Summary)(Document link: Carsten Leue) | | | | | | | | | | | >--------------------------------------------------------------------------------------------------------------------------------------------| Alan Kropp <akropp@epicentric.com> 'PAVLIK,GREGORY (HP-NewJersey,ex2)'" <gregory_pavlik@hp.com>, "'Sasha Aickin'" <AlexanderA@plumtree.com>, Eilon Reshef <eilon.reshef@webcollage.com>, Takao Mohri <mohri.takao@jp.fujitsu.com>, "WSRP Mailing List (E-mail)" <wsrp@lists.oasis-open.org> This is a very interesting discussion - I think one thing to keep in mind in this context is that we are not aiming at building an equivalent of simple HTTP client - web application interaction on top of SOAP instead of HTTP - we are aiming at defining a server-to-server protocol for web services that plug into portals and are aware of portal context, also including management/life-cycle functions. In WSRP, the processAction / getMarkup part that is somewhat similar to the interaction between an HTTP client and server is only a small part of the whole. Apart from that, there also will need to be SOAP operations in the protocol for creating instances, potentially templates, for raising events, etc. SOAP allows us to define a protocol based on well-structured XML messages, in which user profile info, data objects, billing information, metadata, ... can be embedded, encoded in a standard way, formally described in a WSDL interface definition exactly specifying all the datatypes. The SOAP stacks available on J2EE and .NET provide all the function for convenient and fast composition, parsing and validation of such XML messages according to the formal WSDL definitions. The alternatives to SOAP would be either to write code similar to the SOAP stack for encoding/decoding everything in HTTP headers or to send XML Documents via HTTP in the body - which probably would mean reinventing SOAP... This of course would strictly limit WSRP to the HTTP protocol forever - it would never be possible to use any other unterlying transport mechanism. Also interesting to consider in this context are possible optimizations we have discussed - e.g. that a portal might send a SOAP request for multiple portlet instances to a WSRP service if it detects they all have the same URL - the service could then send back the markups for all those portlet instances in a single SOAP response, encoded as different sections in an XML document or different SOAP atachements contained in the response. This is just an example, basically the point I want to make here that by using SOAP to exchange XML messages, combining different pieces of information and markup is much simpler and less error prone than coding everything in HTTP headers and potentially multi-part messages. I think HTTP caching would not be very appropriate for use with WSRP services since it has the limitation of only being able to cache entire HTTP responses. However, WSRP services might return different pieces of information and markup (some of which may be and some of which may not be cachable or may have different expiry settings) in the same response to limit roundtrips across the Internet. Since we discussed for WSRP 2 to allow WSRP services to raise events for other WSRP services mediated by the aggregating portal, in many cases the response might carry the markup result and one or more raised events. The markup may be cachable, but you'd not want to raise the same events multiple times. While using SOAP vs plain HTTP impacts the providers of the platforms running WSRP services, it does not impact the portlet service developers - as Alan and Greg pointed out, for example Portlets written to the Java Portlet API may be exposed as WSRP services by their containers. Whether SOAP or HTTP is used is transparent to service developers, this is a platform implementation detail below the API abstractions. Best regards, Thomas Alan Kropp <akropp@epicentric.com> on 04/25/2002 02:45:04 AM Please respond to Alan Kropp <akropp@epicentric.com> To: "'PAVLIK,GREGORY (HP-NewJersey,ex2)'" <gregory_pavlik@hp.com>, "'Sasha Aickin'" <AlexanderA@plumtree.com>, Thomas Schaeck/Germany/IBM@IBMDE cc: Eilon Reshef <eilon.reshef@webcollage.com>, Takao Mohri <mohri.takao@jp.fujitsu.com>, "WSRP Mailing List (E-mail)" <wsrp@lists.oasis-open.org> Subject: RE: [wsrp][markup] First conference call (Summary) I'll chime in in support of Greg here. Sasha makes a valid observation regarding the potential difficulty in getting today's web app developers to adopt a new paradigm to create WSRP portlets, and migrage existing web apps to portlets. However, I think this may be mitigated to the extent that JSR 168 and WSRP (not to mention WSIA, which could be seen as addressing the more generic web application case) mature in a synchronized fashion, and ultimately comprise well-coordinated layers in a new stack which addresses the full spectrum of web app development, implemented on top of SOAP and HTTP/WAP/Other wire protocols. I see risk in the failure of these multiple efforts to achieve the necessary synergy, thereby sending a confused message. In this event, we certainly could expect resistance and slow adoption. Alan -----Original Message----- From: PAVLIK,GREGORY (HP-NewJersey,ex2) [mailto:gregory_pavlik@hp.com] Sent: Wednesday, April 24, 2002 2:05 PM To: 'Sasha Aickin'; PAVLIK,GREGORY (HP-NewJersey,ex2); Thomas Schaeck Cc: Eilon Reshef; Takao Mohri; WSRP Mailing List (E-mail) Subject: RE: [wsrp][markup] First conference call (Summary) Sorry, I meant to say that the portlet container would be doing what the servlet container now does, ensuring that the user is shielded from managing sessions for portlets. I agree with you in that I think it's clear that both WSRP and WSIA are working toward a new paradigm for web applications. The degree to which these specifications will succeed is going to be predicated on developer's willingness to rethink how they build web apps, which is a substantial goal. Greg -----Original Message----- From: Sasha Aickin [mailto:AlexanderA@plumtree.com] Sent: Wednesday, April 24, 2002 4:49 PM To: PAVLIK,GREGORY (HP-NewJersey,ex2); Thomas Schaeck Cc: Eilon Reshef; Takao Mohri; WSRP Mailing List (E-mail) Subject: RE: [wsrp][markup] First conference call (Summary) Greg, I totally agree with you in your first paragraph here. Folks earlier on this thread were suggesting that implementing a web service portlet using standard web app tools would not be hard, and I was trying to point out that it would be quite hard to leverage web app features like caching and session management without a lot of work. I think you hit the nail on the head when you say that "it's not clear how a SOAP message should be reconstituted in a normal and repeatable way into something that the servlets treat as an HTTP request without a standardized definition". Thanks for being clearer and much more concise than I was. If this hypothesis is true, and portlet development will not work like web app development, then I think we need to be honest about the fact that we are discarding a lot of developer knowledge, training, and experience by using a SOAP based approach. We are also creating a large barrier to entry for the large existing codebase of web apps out there. I don't mean to imply that we would be able to create a spec that will support all existing web apps if we use HTTP/HTML, but the smaller the barrier, the better. To answer your question, Plumtree's current architecture does use HTTP/HTML, and we do use standard proxy caches in between the portal and portlet. Since we didn't define a new caching scheme, portlet developers can use standard HTTP caching directives in JSP, ASP, and Perl, and they have a good strong specification (RFC 2616) as to what effect those caching directives will have. I understand your point about action handling, although I would argue again that this is discarding the standard notions that developers have about (X)HTML links. Also, I feel like relative links might be a little tricky, but I haven't honestly thought that completely through. As for your point about session management, I'm not quite sure I understand the sentence "Session could be eliminated as a problem in Java if the portlet container is in fact a container rather than a web application." Can you expand on this point? Thanks, Sasha. -----Original Message----- From: PAVLIK,GREGORY (HP-NewJersey,ex2) [mailto:gregory_pavlik@hp.com] Sent: Wednesday, April 24, 2002 4:49 AM To: Sasha Aickin; Thomas Schaeck Cc: Eilon Reshef; PAVLIK,GREGORY (HP-NewJersey,ex2); Takao Mohri; WSRP Mailing List (E-mail) Subject: RE: [wsrp][markup] First conference call (Summary) It's not necessarily an easy problem to call from SOAP to servlets. Axis may do what Thomas states, but that's no guarantee that it's a ubiquitous capability of all SOAP servers. In addition, even if we assume the SOAP request is sent over HTTP and the server gives the programmer access to the RequestDispatcher, it's not clear how a SOAP message should be reconstituted in a normal and repeatable way into something that the servlets treat as an HTTP request without a standardized definition, certainly not without jeopardizing both server-side implementation portability and alot of repetitive coding. This kind of implementation can be done, but it's not a good mechanism for implementing portlets. To make it simple and transparent, there really needs to be a portlet container unless portlets are just web applications as Sasha seems to be suggesting. Sasha, what you are describing is essentially the way Plumtree's portal architecture is built? Do people use, for example, HTTP proxy caching agents between portlets and portals routinely? I don't really see a problem if the portal framework has different or new cache management rules for WSRP as this is an implementation detail of the framework. With respect to action handling, this should be the responsibility of a portlet container, which in Java is already being defined. Again, I don't see a huge problem: hand the action URL from the SOAP handler to the container and return the result. It's only becomes a problem if you take the position that WSRP servlets should be implemented as regular web apps based on servlets. I agree that session is a problem, since we want it to be replicated or fault tolerant in the same way we expect servlet sessions to be (though persistent state strikes me as being no different). Session could be eliminated as a problem in Java if the portlet container is in fact a container rather than a web application. Greg -----Original Message----- From: Sasha Aickin [mailto:AlexanderA@plumtree.com] Sent: Tuesday, April 23, 2002 11:36 PM To: Thomas Schaeck Cc: Eilon Reshef; PAVLIK,GREGORY (HP-NewJersey,ex2); Takao Mohri; WSRP Mailing List (E-mail) Subject: RE: [wsrp][markup] First conference call (Summary) Thomas, I realize that it is possible to implement WSRP services on Java application servers in the way that you suggest, but it seems to me that a lot of web application programming paradigms will be so different in that scenario that developers will not be able to leverage their web app development experience, tools, and knowledge. One example is state and session management. Currently, servlets depend on the app server's native session support, which is usually implemented with cookies (or URL rewriting). Several people on our TC have suggested using a token in the WSRP API as a way to manage states and sessions instead of cookies. When we use the paradigm you suggest (SOAP code dispatching out to a servlet), which notion of state/session management would we expose to the servlet? If we use the app server's native cookie-based session management, then the servlet needs to have knowledge about how to extract the WSRP state/session token. If, instead, we expose the WSRP session management to the servlet, then we will have changed the semantics of the way the servlet works, and someone may have to write a whole new session mechanism which uses WSRP tokens as their key. Caching is another thing that we are in danger of rewriting. Standard HTTP/HTML web apps have fairly well developed ideas of how caching should be done, and those mechanisms have proved remarkably successful in scaling up the web. However, HTTP caching is not generally used in SOAP calls for many reasons, chief among them being that it is not clear when two SOAP requests correspond to the same call into a Web Service (whereas HTTP can specify this with the Vary header). This suggests to me that either WSRP will not support HTTP-type caching capabilities (the kind of features exposed by the Expires, Last-Mod, Etag, and Vary headers) and will therefore be less feature rich, or we will spend quite a while spec'ing out caching rules in our protocol. If we do spec out caching rules in our protocol, we would then need to build infrastructure so that web apps written in servlets could easily exploit those caching mechanisms. We would also have to implement caches that understood our new type of SOAP based cache rules (and potentially even try to convince proxy server makers to do the same). This is a tremendous amount of work to just get to the level of functionality we already have with HTTP/HTML web apps. Action handling is yet another problem that we are looking to rewrite. With an HTTP/HTML web app, user actions are generally handled by links and forms. However, since a web service will generally always be at the same URL, links in the markup will need to be transformed according to some scheme to become arguments to the web service. I could see your SOAP to servlet scheme taking in an URL argument to the web service and dispatching to a servlet which corresponds to the URL, but this would be both cumbersome to implement and difficult to make work with relative URLs. We are looking at adding several levels of transformation and indirection to standard HTML/HTTP links, and I don't see that action handling in web services gains any interesting functionality above and beyond links in HTML/HTTP. My basic point is that, by using SOAP (and decoupling markup from HTTP), we are losing many solutions to common problems that are standard in the HTTP/HTML application world, and I am not clear that we are gaining that much in terms of functionality. By porting concepts like session management, caching, and action handling to web services, we will need to build and test new development tools, provide documentation for development best practices, and train developers in our new solutions to these problems. This seems to me like a major problem for our spec, and one which will potentially be a large barrier to entry for developers. What do people think about this? Cheers, Sasha. -----Original Message----- From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com] Sent: Saturday, April 13, 2002 12:53 PM To: Sasha Aickin Cc: Eilon Reshef; PAVLIK,GREGORY (HP-NewJersey,ex2); Takao Mohri; WSRP Mailing List (E-mail) Subject: RE: [wsrp][markup] First conference call (Summary) Just as a comment - it will be quite easy to implement WSRP services as servlets running on a normal application server, all one has to do is to call from the SOAP code (e.g. SOAP4J or AXIS) into the servlet container using the request dispatcher that can be obtained within a provider for the SOAP code. Similar things are probably possible on .NET. So when starting from scratch, developing WSRP services will be about as simple or hard as developing web apps. But of course it is true that existing web apps need to be changed to run as WSRP services... Best regards, Thomas Sasha Aickin <AlexanderA@plumtree.com> on 04/12/2002 05:48:27 AM Please respond to Sasha Aickin <AlexanderA@plumtree.com> To: Eilon Reshef <eilon.reshef@webcollage.com>, "PAVLIK,GREGORY (HP-NewJersey,ex2)" <gregory_pavlik@hp.com>, Thomas Schaeck/Germany/IBM@IBMDE, Takao Mohri <mohri.takao@jp.fujitsu.com> cc: "WSRP Mailing List (E-mail)" <wsrp@lists.oasis-open.org> Subject: RE: [wsrp][markup] First conference call (Summary) Eilon, While this is true (and I'm generally a big fan of integrating with existing systems), supporting HTML doesn't seem like the big barrier to supporting JSP and Perl scripts. The big problem with that, it seems, is that we've committed ourselves to the SOAP web services world. Rewriting a web app to be a web service is decidely non-trivial; you can lose out on a lot of things that J2EE server and IIS give you for free (session management being a huge one), and fitting in with the web service programming paradigms is very different than writing a web app page. As a sidenote, I have to admit that sometimes I get frustrated that we are trying to solve a lot of problems that have already been solved with standard web app development tools. Session management, authentication, privacy, efficient caching, and other issues are all fairly well understood using the basic HTML/HTTP solution, and I feel like we're rewriting a lot of that. Not only is it a lot of work, it will be hard for us to document and for developers to learn. Does anyone else sometimes feel this way, or am I the only one? That all being said, I think that we have to support HTML if only for the huge amount of developer knowledge of HTML (vs. XHTML). Cheers, Sasha. -----Original Message----- From: Eilon Reshef [mailto:eilon.reshef@webcollage.com] Sent: Wednesday, April 10, 2002 8:58 AM To: 'PAVLIK,GREGORY (HP-NewJersey,ex2)'; 'Thomas Schaeck'; 'Takao Mohri' Cc: 'WSRP Mailing List (E-mail)' Subject: RE: [wsrp][markup] First conference call (Summary) I do believe we have to offer a migration path for people that have or even prefer plain old HTML - expecting everybody to go back to their Perl scripts and JSP templates and rework them might provide a barrier to entry that we can avoid by simply supporting HTML. -----Original Message----- From: PAVLIK,GREGORY (HP-NewJersey,ex2) [mailto:gregory_pavlik@hp.com] Sent: Wednesday, April 10, 2002 11:48 AM To: 'Thomas Schaeck'; Takao Mohri Cc: PAVLIK,GREGORY (HP-NewJersey,ex2); WSRP Mailing List (E-mail) Subject: RE: [wsrp][markup] First conference call (Summary) Is there a general statement on whether the markup subcommittee intends to treat HTML and XHTML interchangeably? My initial thought was that WSRP would do better to standardize on XHTML, which would have a number of advantages including the ability of the consumer to treat the fragment as an XML fragment. It's not terribly difficult to tidy up a piece of HTML and repurpose it as well-formed/valid XHTML when dealing with legacy content. An early focus on XHTML might position us better for dealing with devices in the long run, as it appears that WML and cHTML are going to be secondary targets for the TC. Greg -----Original Message----- From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com] Sent: Tuesday, April 09, 2002 5:43 PM To: Takao Mohri Cc: PAVLIK,GREGORY (HP-NewJersey,ex2); WSRP Mailing List (E-mail) Subject: Re: [wsrp][markup] First conference call (Summary) There is not something like "the markup language of WSRP", the WSRP protocol needs not to be tied to any particular markup language, the protocol and the markup exchanged can be viewed as orthogonal. However, WSRP will need to define rules for valid markup fragments and common styles with the priorities 1. (X)HTML 2. WML, cHTML, VoiceXML... It would be interesting to see the rules that would define valid XHTML Basic fragments. Takao, could you post an XHTML Basic example document to the mailing list and an outline of fragment rules for XHTML Basic ? Which tags would be allowed in aggregatable XHTML Basic fragments and which tags would not be allowed to use in fragments ? Best regards, Thomas Takao Mohri <mohri.takao@jp.fujitsu.com> on 04/09/2002 01:26:58 PM Please respond to Takao Mohri <mohri.takao@jp.fujitsu.com> To: "PAVLIK,GREGORY (HP-NewJersey,ex2)" <gregory_pavlik@hp.com> cc: "WSRP Mailing List (E-mail)" <wsrp@lists.oasis-open.org> Subject: Re: [wsrp][markup] First conference call (Summary) Greg, Yes, as you mentioned, XHTML Basic is becoming a standard for cellular phones. In WAP 2.0, XHTML Mobile Profile (an extention of XHTML Basic) is a standard markup language. In Japan, cellular phones that support WAP 2.0 are already on sale by KDDI. NTT Docomo also has announced support of WAP 2.0. In the near future, WAP 2.0, i.e, XTHML Basic will be used by many mobile devices. If the markup language of WSRP is based on XHTML Basic, it makes support of mobile devices much easier. Regards, Takao "PAVLIK,GREGORY (HP-NewJersey,ex2)" wrote: > > Gino, > > Could you clarify if your intent is to consider XHMTL/XHTML Basic as a part > of the HTML focus? This wasn't clear from the notes. There appears to be a > broad convergence in the mobile space, both with respect to WML and NTT > Docomo, to standardizing on XHTML Basic + CSS. XHTML is going to be here on > the device very soon, perhaps quicker than on the desktop, making this a > relatively high priority item. Fujitsu may have some comments on this as > well. > > Greg > > -----Original Message----- > From: Gino Filicetti [mailto:gfilicetti@bowstreet.com] > Sent: Friday, April 05, 2002 3:22 PM > To: WSRP Mailing List (E-mail) > Subject: [wsrp][markup] First conference call (Summary) > > Team, > > Attached are the meeting notes from today's Markup Subcommittee meeting. > Comments and suggestions are welcome. > > One thing I did notice was that there were quite a few participants today > that aren't on the actual list of official members for this team. Since this > team is quite small, I think it'd be great if we could get some of you to > officially join and help out with the effort. Unfortunately, I wasn't able > to capture the names of ALL the attendees this time around (I'll be sure to > record the con-call next time), but please send me an email so we can add > your name to official list and flesh out the team a little more. > > Currently, the official list is: > > Gino Filicetti > David Taieb > Khurram Mahmood > Susan Levine > Michael Hillerman > > Thanks, > > . . . . . . . . . . . . . . . . . . . . . . . . > Gino Filicetti | Software Engineer > One Harbour Place, Portsmouth, NH 03801 > T 603.559.1692 | gfilicetti@bowstreet.com > w w w . b o w s t r e e t . c o m > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> // Takao MOHRI (mohri.takao@jp.fujitsu.com) // FUJITSU LABORATORIES LTD. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC