← Back to team overview

ladon-dev-team team mailing list archive

Re: Accumulative service catalog descriptions

 

OK Mike.

jsonwsp/description does not support this yet, so you will have to add some
kind of _supports_multi_service_description() method to the
ladon.interfaces.BaseInterface class, so we know which service protocols to
list on collection level.

Try it :-)


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

> I imagine it will include all service which has all methods which has all
> user defined types. Equivalent is to grab all WSDLs (JSONWSP) descriptions
> of all services in a collection and pack them into single file.
>
> Than it gives an ability to do the following:
>
>  import suds
>  service = suds.client.Client('http://localhost/soap/description').service
>  service['ServiceOne'].echo()
>  service['ServiceTwo'].some_method()
>  service['ServiceTrhee'].s3method()
>  ...
>  service['ServiceN'].sNmethod()
>
> Where ServiceOne ... ServiceN is a different services in catalog. Each of
> them has their own description file, so if you need to access only one of
> these services you still able to do it like today:
>
>  import suds
>  serviceOne = suds.client.Client('http://localhost/<http://localhost/soap/description').service>
> ServiceOne/ <http://localhost/soap/description').service>
> soap/description').service <http://localhost/soap/description').service>
>  serviceOne.echo()
>
>  serviceTwo = suds.client.Client('http://localhost/<http://localhost/soap/description').service>
> ServiceTwo/ <http://localhost/soap/description').service>
> soap/description').service <http://localhost/soap/description').service>
>  serviceTwo.some_method()
>
> From this example I feel it is possible to feel the difference. If you're
> going to use a number of services from the catalog, it's useful to grab all
> the descriptions with one request, and as opposite for today - for each
> service I want to use I need to do a separate request to grab its
> description.
>
> Regards,
> Mike
>
>
> 2012/11/1 Jakob Simon-Gaarde <jakobsg@xxxxxxxxx>
>
>> 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
>>
>> --
>> 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

References