← Back to team overview

ladon-dev-team team mailing list archive

Re: Accumulative service catalog descriptions

 

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

Follow ups

References