MHonArc v2.5.2 -->
wsia message
[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