[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]createEntity/createTemplate/createPortlet
Eilon - 1. A syntax like http://foo.com/wsrp?s=weather would at least be more promising like the former approach. However this relies on the ability to access request parameters from within a SOAP handler. Unless you override the SOAP handler this will not be possible as normally your SOAP environment directly maps the incoming request to a method call in your prefered programming language. For the method, the calling context is totally transparent. In SOAP4J and AXIS you could write yourself a hack for this problem, but in my opinion we should not build our interface and protocol specification on such assumptions. Furthermore I don't know an easy way in .NET to do the same thing. 2. We should try to design our data structures, method signatures and WSDL files such that today's standard tools are able to generate automatic proxies and stubs (e.g. WSAD and Visual Studio .NET). This will not be easy and maybe in the end there will be the need of some custom mappings. But I think that we should not enforce users to hack themselves into their product's SOAP stack to implement WSRP services. If a portal vendor does this for efficiency reasons, that's ok, but it should not be required. 3. The approach to put some parameters together in one data entity sounds good. I would even go a step further and try to make as much information implicit as possible: - e.g. the portlet instance implies the portal ID because it has already been created in a registration context - the same is true for instance and type There is another reason why explicitly addessing portlets in the portal service might be preferable to using the URL to address them and that is batch processing. For tasks like staging or deserialization of portals you can assume that a large number of remote portlet thingies might need to be generated "simulaneously" from the same consumer on the same producer. Instead of requiring N request for this we could allow vectors of information to be passed to the different WSRP methods and such significantly reduce roundtrips. We should at least do this for the deletion of handles but why not for their creation as well. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+-----------------------------> | | "Eilon Reshef" | | | <eilon.reshef@webc| | | ollage.com> | | | | | | 05/28/2002 06:04 | | | AM | | | Please respond to | | | "Eilon Reshef" | | | | |---------+-----------------------------> >---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Carsten Leue/Germany/IBM@IBMDE | | cc: "'Alan Kropp'" <akropp@epicentric.com>, "'Gil Tayar'" <Gil.Tayar@webcollage.com>, "'Michael Freedman'" | | <Michael.Freedman@oracle.com>, <wsia@lists.oasis-open.org>, <wsrp@lists.oasis-open.org> | | Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]crea teEntity/createTemplate/createPortlet | | | | | >---------------------------------------------------------------------------------------------------------------------------------------------| We are on the same page with the approach. Three questions I might have: 1. Would URL parameters (e.g., http://foo.com/wsrp?s=weather) be more natural to those environments? (Still no need for an explicit parameter) 2. The problem we are trying to solve is a single service serving multiple portlet types (otherwise, there's no issue with either approach). Do we expect such services to use .NET out of the box or would it be reasonable to expect such service to implement custom SOAP-to-object mapping? 3. Would it make sense to assume that the function createTransientThingy (...) accepts a persistentThingyID as an argument, i.e., createTransientThingy (persistentThingyID) and that persistentThingyID can be assumed to include <portlet type, portlet instance, [portal id]> and leave the question whether we want to separate those components into explicit variables to a WSRP-specific discussion? Eilon -----Original Message----- From: Carsten Leue [mailto:cleue@de.ibm.com] Sent: Monday, May 27, 2002 6:36 AM To: Eilon Reshef Cc: 'Alan Kropp'; 'Gil Tayar'; 'Michael Freedman'; wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]crea teEntity/createTemplate/createPortlet Eilon - I would discourage the URL path approach because it seems as if this worked only in a servlet world. The SOAP servlet intercepts the request, interprets the remaining portion of the URL and addresses the internal service according to this URL. E.g. a request to http://foo.com/wsrp/weather would be intercepted by the "htttp://foo.com/wsrp" servlet with the service identifier "weather". Do I understand this approach correctly? The problem is that this won't work in AXIS or in .NET. That's why I would prefer to have a single service and do the dispatching using a class identifier that is passed as an explicit parameter. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+-----------------------------> | | "Eilon Reshef" | | | <eilon.reshef@webc| | | ollage.com> | | | | | | 05/24/2002 07:33 | | | PM | | | Please respond to | | | "Eilon Reshef" | | | | |---------+-----------------------------> > ---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Carsten Leue/Germany/IBM@IBMDE, "'Alan Kropp'" <akropp@epicentric.com> | | cc: "'Gil Tayar'" <Gil.Tayar@webcollage.com>, "'Michael Freedman'" <Michael.Freedman@oracle.com>, <wsia@lists.oasis-open.org>, | | <wsrp@lists.oasis-open.org> | | Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]crea teEntity/createTemplate/createPortlet | | | | | > ---------------------------------------------------------------------------------------------------------------------------------------------| Carsten, Clearly there's a need for a single servlet to handle multiple portlet types. Why do you feel there's a need for a single service (in the WSDL sense) to handle multiple portlet types? Why not map multiple services, each representing a different portlet type, into a single servlet using WSDL techniques, such as URL paths, etc.? Eilon -----Original Message----- From: Carsten Leue [mailto:cleue@de.ibm.com] Sent: Friday, May 24, 2002 10:48 AM To: Alan Kropp Cc: 'Eilon Reshef'; 'Gil Tayar'; 'Michael Freedman'; wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]crea teEntity/createTemplate/createPortlet Alan - from my point of view there are a couple of advantages introducing the concept of a service container (at least for WSRP): - for WSRP all services are of the same type, so handling them (life cycle, invokation framework on the server, addressing) will be the same. In that case it is much easier to handle the request centrally at one single access point. - a portal might expose a large number of portlets. If there was no container the service would need an entry point (e.g. soap servlet) for each of the portlets. This is not only difficult to setup but may also consume a lot of resources (depending on your app server) - conceptually a portlet is something that runs inside a portlet (that manages access, lifetime etc) . So it makes sense to adpot this model to the remote case by introducing a service container. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 |---------+----------------------------> | | Alan Kropp | | | <akropp@epicentri| | | c.com> | | | | | | 05/24/2002 01:32 | | | AM | | | Please respond to| | | Alan Kropp | | | | |---------+----------------------------> > ---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: "'Eilon Reshef'" <eilon.reshef@webcollage.com>, "'Michael Freedman'" <Michael.Freedman@oracle.com>, "'Gil Tayar'" | | <Gil.Tayar@webcollage.com> | | cc: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org | | Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]crea teEntity/createTemplate/createPortlet | | | | | > ---------------------------------------------------------------------------------------------------------------------------------------------| Mike, Along the lines of Eilon's question, I'd like to have a better understanding as to what the WSRP Producer Container is for. I confess to not being well-informed on the motivation for introducing this concept in the early interfaces/protocols discussions. My hope has been that it is entirely a WSRP-specific construct, and therefore not something that needs to be accounted for in the joint interface. But I'm not convinced one way or the other, yet. In the interests of furthering this discussion, if you could run down the main points behind the container, for both groups, I think it would be beneficial. I think Mike's outline of the lifecycle interfaces from a "pure" WSRP perspective, in relation to Gil's and Rich's latest rev of the joint interface specification, represents the clearest illustration yet of the "gap" we need to close. This is good progress. Alan -----Original Message----- From: Eilon Reshef [mailto:eilon.reshef@webcollage.com] Sent: Thursday, May 23, 2002 3:36 PM To: 'Michael Freedman'; 'Gil Tayar' Cc: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]createEntity/createTemplate/createPortlet Mike, Per the tension you mentioned, and your previous e-mail with the "Container" interfaces (C1-C4). This is a question that Rich referred to as "Heterogeneous versus Homogeneous" services. The question is whether the "container" behavior should be an explicit part of the interface (as you suggested in C1-C4 = "heterogeneous") or can be implicit in the interface by providing different "services" (in the WSDL sense), each representing a separate portlet type (= "homogeneous"). Why do you feel that WSRP needs the heterogeneous service? Couldn't a single container/server provide different services for different portlet types, and use WSDL techniques (mainly, URL paths) to differentiate between the different portlets? Eilon -----Original Message----- From: Michael Freedman [ mailto:Michael.Freedman@oracle.com] Sent: Thursday, May 23, 2002 5:51 PM To: Gil Tayar Cc: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org Subject: Re: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]createEntity/createTemplate/createPortlet I don't think we want to give up so quickly on this. As I think all calls (after createEntity) need to be passed the entity handle -- and would find each to be unnatural if we defined they took an optional "bind" key. Also, I don't think entities are WSRP exclusive things. Rather I think the tension is WSRP needs (generic) container model while many components will be happy running as standalone services. Personally, I wonder if we will end up with two APIs -- one for service simple and one for service container -- much like I depict in the e-mail sent earlier describing different component types needing to be modeled. Though containing by and large the same API the difference is the need for createEntity and passing the return handle in all subsequent operations -- i.e. getFragment, etc. -Mike- Gil Tayar wrote: In the interest of sanity and progress, I have broken up Rich's, Michael's, Monica's and Eilon's emails into four subjects - "Shared Transient Information", "Persistent Information Scope", "createEntity/createTemplate/createPortlet", "session and entity handles", and "Property lists". This email will deal with createEntity/createTemplate/createPortlet, and the relevant quotes from the emails and my reply to them: Rich wrote:> Presuming the 2nd case to get dropped relative to the previous set of > emails, I would propose this section call out how we will refer to these > things throughout the remainder of the document/API. In particular, I would > suggest: > Session Information - This is carried opaquely in the interface as a > "sessionID". > => goes away > Persistent Information - This is carried opaquely in the interface as > a "handle".> > Rather than "Manifestation", I would propose using "Entity" to describe the > thing from which markup may be requested. I think it has the right level of > opacity (Consumer has no idea what kind of entity it is) while carrying > appropriate semantics (a thing that may be interacted with). Using these > terms, there was also an open question at the end of our last call related > to whether there were both persistent and transient entities ... > > If we are going to support explicit lifecycle for both of these, I would > propose: > handle createEntity(handle, propertyValues) > sessionID createSession(handle, propertyValues) Michael wrote:> 1) createEntity (aka createTemplate). In WSRP we have discussed requiring > consumers register with a producer to "activate" it. Registration returns an > 'activation' handle used in subsequent calls to identify the consumer. How can > we account for this with the createEntity (and other) APIs? I really, really, > really, don't want this to be an property value. Also what is the actual > intent of these property lists? Gil implies they are persistence presets. If > so should we have a separate list parameter that allow the consumer to further > qualify the Entity being created? I.e. in WSRP portlets aren't the direct > producer -- they are managed/contained by the producer. We will want to use > the createEntity call to create/be tied to these subtypes -- hence need someway > to qualify it in the call. Finally, are we assuming the service never wants to > programmatically authorize this operation? If not, don't we need to pass User > identity and roles as well?> > 2) destroyEntity (aka destroyTemplate). Since we seem to want to support > creating new entities from existing one's do we want to support cascading > delete? If not we likely should support bulk deletes. [Note: should we > consider bulk create as well for import/export/publish purposes?] As with > create entity the consumer ID should be passed.Eilon wrote (and I condense...):[...]> Would you find the following, radically simplified, suggestion for an operation> name intrusive:> createPortlet> Along those lines, a portal would call the operation createPortlet, would get back a > (persistent) portletID and then (optionally) call createSession with the portletID. [...]> 2. The ability to create a persistent key seems to be only under the scope of > WSRP and not under WSIA. WSIA supports a persistent key to create sessions and > to subsequent operations, but wouldn't probably deal with how they are created> and management (with all the associated issues that are well described in Mike's> latest summary). Hence, the motivation to use a portal-specific name.So now Gil writes:It seems that Michael, Eilon, and myself believe that the createEntity/Template/Portlet operation is particular to WSRP (Rich, I even remember adding the "templateKey" thingie as a shot in the dark to where WSRP is going - it seems the shot missed!).I suggest then, dropping this from the joint interface subcommitee, and leaving it in the hands of the WSRP. Having said that, we must be able to support some type of connection between the template/entity/portlet and the "session handle", so what I propose is that the createSession/Instance operation (outlined above) will accept an unspecified "bindingKey", i.e.:sessionHandle/ID = createSession/Instance(bindingKey).The "bindingKey" will be an opaque string to be defined either by the WSIA service, or defined by specs above WSIA (i.e. WSRP). One can argue that this is similar to JDBC's "connection URL" (in getConnection) which is an opaque string specified when "connecting". WSRP could also use it to specify the "sub-service/portlet" of the container, if WSRP decides to go the heterogenous.My suggestion is to drop the createEntity/Template/Portlet, and leave:sessionHandle = createSession(bindingKey) [bindingKey is an opaqueString, which will be used in the future by WSRP binding specifications]getMarkup/performAction....(sessionHandle, ...) [i.e. all operations within the session will receive the sessionHandle]destroySession(sessionHandle)And, as Michael suggested, resolve timeout and implict session creation and deletion issues ASAP.(I specifically dropped the "propertyList" arguments as they are not the issue here, but that doesn't mean that I don't support them). Gil TayarWebCollage ---------------------------------------------------------------- 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