← Back to team overview

ladon-dev-team team mailing list archive

Re: Accumulative service catalog descriptions

 

Yes but do you want to make a collection-level WSDL file with all services
and methods embedded or make generic enumerator methods? What is the
use-case for all this. I would like that we support all interfaces on all
levels, not just WSDL.

2012/11/1 Mykhailo Stadnyk <mikhus@xxxxxxxxx>

> I really can't understand your arguments.
>
> I propose to have 2 levels of WSDL descriptions. Currently you have only
> one level. I DO NOT propose to change this. I just propose TO ADD on a
> collection level another one WSDL which describes WHOLE collection. And it
> means that the user still possible to do everything you've mentioned with
> every single service, but for whose, who need - there whould be a
> possibility to request whole collection description with one HTTP request.
>
> Best regards,
> Mike
>
>
> 2012/10/31 Jakob Simon-Gaarde <jakobsg@xxxxxxxxx>
>
>> I might add, that delivering such collection level service with standard
>> methods for listing services would also make it easier for the end-user to
>> enumerate the collections capabilities.
>>
>>
>> 2012/10/31 Jakob Simon-Gaarde <jakobsg@xxxxxxxxx>
>>
>>> Oh wait - now I see what you meen. I thought you just ment there was an
>>> error in the wsdl generation.
>>>
>>> I really don't think it's a good idea to make wsdl files or
>>> jsonwsp/description files (which btw do not support this as we speak) that
>>> describe the whole collection. I think Ladon should keep the descriptions
>>> per service and try to uphold a hierarchical approach to the
>>> Collection/Service access.
>>>
>>> I would definately prefer that we make a standard collection level
>>> webservice that can list services, and maybe even service methods with
>>> arguments and types.
>>>
>>> /Jakob
>>>
>>>
>>> 2012/10/31 Jakob Simon-Gaarde <jakobsg@xxxxxxxxx>
>>>
>>>> Please - go ahead and fix it, no problem.
>>>>
>>>>
>>>> 2012/10/31 Mykhailo Stadnyk <mikhus@xxxxxxxxx>
>>>>
>>>>> Jacob, I reviewed WSDL specification and see that you are not true.
>>>>>
>>>>> http://www.w3.org/TR/wsdl#_document-s
>>>>>
>>>>> service element defined as:
>>>>>
>>>>> <wsdl:service name="nmtoken">* **
>>>>>
>>>>> Asterisk means the following from the same specification:
>>>>>
>>>>> "Characters are appended to elements and attributes as follows: "?" (0
>>>>> or 1), *"*" (0 or more)*, "+" (1 or more)."
>>>>>
>>>>> So, it means that standard directly points to the fact that you can
>>>>> describe as many services as you want in one WSDL
>>>>>
>>>>> Best regards,
>>>>> Mike
>>>>>
>>>>>
>>>>> 2012/10/19 Jakob Simon-Gaarde <jakobsg@xxxxxxxxx>
>>>>>
>>>>>> Hi Mike.
>>>>>>
>>>>>> Simplest and least complex solution is almost always the best
>>>>>> solution, that's almost a rule in my experience :-)
>>>>>> WSDL Does not support multiple services in one description file, so
>>>>>> when you speak about imploding several services into one WSDL file I can
>>>>>> almost guess that it involves a "MetaService" that picks up all methods
>>>>>> defined in all services of a collection and wrap them into one meta
>>>>>> service. I see plenty of problems in that approach right away that tells me
>>>>>> this is not a simple nor uncomplex solution. For instance, which service
>>>>>> class has precedence if the same service method is defined in two different
>>>>>> service classes. Already here we would have to take non-intuitive choices.
>>>>>>
>>>>>> I still like the idea that it is possible to enumerate all service
>>>>>> classes and methods of a service collection programmatically, but I think
>>>>>> it should be through the approach I talked about, because it does not break
>>>>>> standards and it does not have to take undefined choices.
>>>>>>
>>>>>> Also this approach will let us keep the Ladon's URL style but now in
>>>>>> levels:
>>>>>>
>>>>>> Service-level descriptions:
>>>>>> GET http://my.domain.org/<ServiceName>/<protocol>/description
>>>>>> Service-level method calls:
>>>>>> POST http://my.domain.org/<ServiceName>/<protocol>
>>>>>>
>>>>>> Collection-level description (only one and always the same with
>>>>>> methods like "collectionInfo()", "listServices()" )
>>>>>> GET http://my.domain.org/<protocol>/description
>>>>>> Service-level method calls:
>>>>>> POST http://my.domain.org/<protocol>
>>>>>>
>>>>>>
>>>>>> / Jakob
>>>>>>
>>>>>>
>>>>>> 2012/10/19 Mykhailo Stadnyk <mikhus@xxxxxxxxx>
>>>>>>
>>>>>>> Need to check that in spec but we tried to implode several services
>>>>>>> into one WSDL and it does work!
>>>>>>>
>>>>>>>
>>>>>>> 2012/10/19 Jakob Simon-Gaarde <jakobsg@xxxxxxxxx>
>>>>>>>
>>>>>>>> I like the idea that the collection can describe itself. But as far
>>>>>>>> as I know there is no WSDL specification for service collections that allow
>>>>>>>> this.
>>>>>>>>
>>>>>>>> But there is nothing to stop us from exposing a single method
>>>>>>>> service at collection level which can list all services in a collection.
>>>>>>>>
>>>>>>>> / Jakob
>>>>>>>>
>>>>>>>> 2012/10/19 Mykhailo Stadnyk <mikhus@xxxxxxxxx>
>>>>>>>>
>>>>>>>>>  Hi Jacob.
>>>>>>>>>
>>>>>>>>> Another one idea I think IS REALLY required in ladon is to have
>>>>>>>>> WSDL/JSONWSP/etc.. descriptions for service catalogs. I mean if there is
>>>>>>>>> published subset of service objects it's good to have only one URL which
>>>>>>>>> describes all the services available.
>>>>>>>>>
>>>>>>>>> Than just in client:
>>>>>>>>>
>>>>>>>>> import suds
>>>>>>>>> service = suds.client.Client('
>>>>>>>>> http://localhost/soap/description').service
>>>>>>>>> service['Test'].echo()
>>>>>>>>>
>>>>>>>>> Because currently if I want to work with several service objects I
>>>>>>>>> need to do 1 more HTTP request to parse description for each service I use
>>>>>>>>> and it's not very good.
>>>>>>>>>
>>>>>>>>> I guess it's not hard to implement. Currently I'm working on REST
>>>>>>>>> implementation proposal and after I guess I can work on this feature.
>>>>>>>>> What is your opinion?
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Mike
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Mailing list: https://launchpad.net/~ladon-dev-team
>>>>>>>>> Post to     : ladon-dev-team@xxxxxxxxxxxxxxxxxxx
>>>>>>>>> Unsubscribe : https://launchpad.net/~ladon-dev-team
>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Med venlig hilsen / Best regards
>>>>>>>> Jakob Simon-Gaarde
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mailing list: https://launchpad.net/~ladon-dev-team
>>>>>>>> Post to     : ladon-dev-team@xxxxxxxxxxxxxxxxxxx
>>>>>>>> Unsubscribe : https://launchpad.net/~ladon-dev-team
>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Med venlig hilsen / Best regards
>>>>>> Jakob Simon-Gaarde
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Med venlig hilsen / Best regards
>>>> Jakob Simon-Gaarde
>>>>
>>>
>>>
>>>
>>> --
>>> Med venlig hilsen / Best regards
>>> Jakob Simon-Gaarde
>>>
>>
>>
>>
>> --
>> Med venlig hilsen / Best regards
>> Jakob Simon-Gaarde
>>
>> --
>> Mailing list: https://launchpad.net/~ladon-dev-team
>> Post to     : ladon-dev-team@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ladon-dev-team
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>


-- 
Med venlig hilsen / Best regards
Jakob Simon-Gaarde

Follow ups

References