(Migrated) wsdl in services

(This message has been automatically imported from the retired mailing list)

I have a concern related to soap services and their wsdl file, In my
business I am generating generic services in OpenERP that are deployed in
Zato, the related wsdl is generated too. In the sales process I generate
channels to authorize to the generated Zato Basic Auth User to consume the
service with the proper authorization and decrease the amount of queries
that he can do over that channel. By the way I need the service deployed in
Zato when the sale is get confirmed since it’s what is going to be sold.
My concern is that the wsdl here is not service related, I think that would
be soap channel related since I don’t want to let the user what are all the
service actions that is attached to the service that can be used by others
users over others channels. The wsdl would be to that soap channel that has
the related service. On the other hand if I assume the situation rigth now
in Zato I end up with so many equal services to only specify the proper
wsdl to that service related to the channel and since the wsdl is only
related to soap channels there is no point to have it at the service level.
To resolve this I will create a service only to serve the wsdl files per
soap channel or to generate them based on a channel config.

I share this with a goal to have a different point of view.
Let me know what you think

On 01/15/2014 05:56 PM, Axel Mendoza Pupo wrote:

Hi Axel,

By the way I need the service deployed in
Zato when the sale is get confirmed since it’s what is going to be
sold.

For that, I think, the existing API is enough or you’d rather see it
expand in order to accommodate your needs?

https://zato.io/docs/public-api/intro.html

My concern is that the wsdl here is not service related, I think that would
be soap channel related since I don’t want to let the user what are all the
service actions that is attached to the service that can be used by others
users over others channels. The wsdl would be to that soap channel that has
the related service.

On the other hand if I assume the situation rigth now
in Zato I end up with so many equal services to only specify the proper
wsdl to that service related to the channel and since the wsdl is only
related to soap channels there is no point to have it at the service level.

To resolve this I will create a service only to serve the wsdl files per
soap channel or to generate them based on a channel config.

Right, I’m wondering if the upcoming features, partly implemented, are
not the answer to it.

1.2 will have, among other things, these ones:

  • Pass-through services (done)
  • More SIO data types (partly done)
  • WSDL generation out of SIO definition (not started)

Pass-through services

This is exactly as it sounds - services that don’t do anything
themselves, only proxy requests and responses.

Their usefulness lies in the fact that they can be exposed over channels
independently. In git master it’s already possible to do something like
this:

from zato.service import Service

class ChannelService1(Service):
passthrough_to = ‘my-actual-service’

class ChannelService2(Service):
passthrough_to = ‘my-actual-service’

class MyActualService(Service):
def handle(self):
pass

Here you have the actual implementation defined in MyActualService
whereas channels use different services.

More SIO data types

New SIO types slated for inclusion in 1.2 are

  • CSV
  • Dict
  • List
  • ListOfDicts
  • Nested

Out of these, Nested is a sort of a pass-through container that enables
one to embed arbitrary elements. Nested is also the only one that’s not
implemented fully yet.

When they are all done, they will allow for expressing quite complex
documents in declarative manner. Please see below, lines 69-153

https://github.com/zatosource/zato/blob/master/code/zato-server/src/zato/server/service/internal/checks/sio.py#L69

This uses JSON currently only but will support XML (hence SOAP) as well.

Plan is to work on it within the next 2 months, most likely.

WSDL generation out of SIO definition

This will fetch an SIO definition and output a corresponding WSDL. This
will mean that Java, C#, C++ or other clients will be able to generate
stubs for connecting to Zato services corresponding to what SIO will have.

Work on it will begin once the above is done, probably within 2-3 months.

Now, combining these all 3 together you will be able to create,
essentially, the same WSDL for each of your client applications.

Yet, because you’ll be using pass-through channels, each of the WSDLs
will be using different channel names, URLs, addresses and so on so from
the perspective of each of the client applications they just won’t know
that there is anything more - they will only see as much a pass-through
channel has access to.

Do you think this is it or you’d like to refine it further?

On 01/15/2014 05:56 PM, Axel Mendoza Pupo wrote:

Hi Axel,

By the way I need the service deployed in
Zato when the sale is get confirmed since it’s what is going to be
sold.

For that, I think, the existing API is enough or you’d rather see it
expand in order to accommodate your needs?

https://zato.io/docs/public-api/intro.html

My concern is that the wsdl here is not service related, I think that would
be soap channel related since I don’t want to let the user what are all the
service actions that is attached to the service that can be used by others
users over others channels. The wsdl would be to that soap channel that has
the related service.

On the other hand if I assume the situation rigth now
in Zato I end up with so many equal services to only specify the proper
wsdl to that service related to the channel and since the wsdl is only
related to soap channels there is no point to have it at the service level.

To resolve this I will create a service only to serve the wsdl files per
soap channel or to generate them based on a channel config.

Right, I’m wondering if the upcoming features, partly implemented, are
not the answer to it.

1.2 will have, among other things, these ones:

  • Pass-through services (done)
  • More SIO data types (partly done)
  • WSDL generation out of SIO definition (not started)

Pass-through services

This is exactly as it sounds - services that don’t do anything
themselves, only proxy requests and responses.

Their usefulness lies in the fact that they can be exposed over channels
independently. In git master it’s already possible to do something like
this:

from zato.service import Service

class ChannelService1(Service):
passthrough_to = ‘my-actual-service’

class ChannelService2(Service):
passthrough_to = ‘my-actual-service’

class MyActualService(Service):
def handle(self):
pass

Here you have the actual implementation defined in MyActualService
whereas channels use different services.

More SIO data types

New SIO types slated for inclusion in 1.2 are

  • CSV
  • Dict
  • List
  • ListOfDicts
  • Nested

Out of these, Nested is a sort of a pass-through container that enables
one to embed arbitrary elements. Nested is also the only one that’s not
implemented fully yet.

When they are all done, they will allow for expressing quite complex
documents in declarative manner. Please see below, lines 69-153

https://github.com/zatosource/zato/blob/master/code/zato-server/src/zato/server/service/internal/checks/sio.py#L69

This uses JSON currently only but will support XML (hence SOAP) as well.

Plan is to work on it within the next 2 months, most likely.

WSDL generation out of SIO definition

This will fetch an SIO definition and output a corresponding WSDL. This
will mean that Java, C#, C++ or other clients will be able to generate
stubs for connecting to Zato services corresponding to what SIO will have.

Work on it will begin once the above is done, probably within 2-3 months.

Now, combining these all 3 together you will be able to create,
essentially, the same WSDL for each of your client applications.

Yet, because you’ll be using pass-through channels, each of the WSDLs
will be using different channel names, URLs, addresses and so on so from
the perspective of each of the client applications they just won’t know
that there is anything more - they will only see as much a pass-through
channel has access to.

Do you think this is it or you’d like to refine it further?