SOAP Webservices with Meteor


Hi all,

I have to use some javascript libraries to program a webservice, which must be implemented with SOAP.

My apologizes for the newbie question, I am new with Meteor, but I would like to know which is the best approach to implement the SOAP Webservice with Meteor. Does Meteor offer packages or tools to do it?

Any suggestion or comment is welcomed :slight_smile:



There is a package which has had a good few installs:

I have not tested it, but there are no open issues and it seems reasonably active.


Hi robfallows,

thanks a lot for your answer, it helps me :smile:

I am currently focused in the SOAP Webservices, not really in the creation of webpages to use the javascript functionality.

Do you think that Meteor is the best approach for me? I don’t know which other development environments than Meteor could be integrated with javascript.



You seem to be saying that you want to use Meteor to write SOAP endpoints, rather than consumers (e.g. web apps) of SOAP endpoints - have I got that right?

The short answer is that you can use Meteor for this, although whether it’s your best option depends on what you are providing SOAP endpoints onto. For example, if you’re interfacing with MongoDB, then Meteor offers you a very easy way into this. If not, then Meteor may not be the right choice. However, it’s been a l-o-n-g time since I looked at SOAP (other than in the bathroom :wink:), and I don’t know where else you might look.


I really need to use javascript libraries, and Meteor integrates javascript very well, right?

I don’t need to interact with MongoDB, but I need a development environment where I can do quick a prototipe and a productive version of the SOAP Webserver. And you are right, I want to program the SOAP endpoints, not the consumers.


Well, there are lots of JS frameworks out there. I love Meteor, so I’m not the right person for an objective response!

@serkandurusoy - you seem to have more of a background in this sort of use case - can you jump in, please? :smile:


@robfallows haha this is insane, I was just composing my answer when you mentioned me :slight_smile:

@skydog I’m using zardak:soap as a consumer in a project right now and it is working well.

It is actually a thin wrapper around which is an npm package for the node ecosystem. It is not intended specifically for Meteor, in fact it has nothing to do with Meteor except that zardak was kind enough to create the wrapper and publish it on atmosphere.

This package, with or without meteor, can also be used as a service endpoint.


Meteor is all about isomorphic, reactive applications which focus heavily on real time aspecs of an application.

Soap on the other hand is a technology from a different era and is designed to be a request/response method of interfacing with an application.

If you are developing your soap service to interface with an existing application or database, I think you should be doing that with plain node, using the soap package from npm. This is assuming the existing applicaton does not provide its own integration libraries you can consume on a different platform, which would be far easier to do.

If you are developing a new application that only has a soap interface and that application is going to use mongodb as a database backend, and that you are not very familiar with javascript and callback style programming, you might find it much easier to get a headstart with meteor and zardak:soap since javascript programming in meteor is easier to grasp than javascript programming elsewhere because it provides transparent and natural apis that hide away all that complexity.

So, if you want to discuss this further, I’d ask you to share a bit more about what you want to achieve so that we could talk specifics.


Hi @serkandurusoy, thanks a lot for the information :smile:

I need to implement a reliable interface, therefore SOAP comes into place (maybe REST in the future).

This is the setup environment (client/server):
1.- The server has to offer a webservice which MUST use some specific javascript libraries internally.
2.- The client application supports SOAP as webservice technology. REST functionality can be added in the future, but that’s out of scope at the moment.
3.- Currently I don’t need to access the webserver from an app or webpage.
4.- The potential number of users is low.

Yes, SOAP is a technology from a different era, but that’s what I have to use because of the technology restriction on the client side (SOAP).

Somehow I have to program the Webservice with a powerful tool which allows quick prototype and is robust, taking into consideration that I MUST use javascript libraries on the server side, therefore I though that Meteor would be good for this task.

Maybe the biggest problem is that I am restricted to the use of the javascript libraries and I don’t know which other technologies or development environment would fit better for me.


Why would you think soap is a more reliable interface? Especially the web has already become a huge bundle of rest api’s and json becoming the defacto standard of sharing data. So I hope the client app gets improved and this soon becomes your app scope :smile:

And building rest interfaces is very easy with meteor especially with packages like nimble:restivus, simple:rest, cfs:http-methods and even routing packages like iron:router and meteorhacks:picker

Of yourse you have better targeted nodejs frameworks for api development or rails ones, and even better yet java and scala frameworks that would be very reliable in any circumstance. That’s of course if you can break out of or work around the javascript library dependencies you mention.

Anyway, continuing on the soap discussion,

  • If there are existing javascript server side libraries you have to use, it means they are targeted at the node environment.
  • While meteor is itself built on top of node, getting in other libraries to work with meteor’s fiber-dependent environement might become hard for a beginner.

If you are familiar with JVM based languages, you might want to give vert/x a try which is polyglot, meaning you can mix and match languages like java, javascript, ruby and groovy! So that you can consume the existing javascript libraries, but write the rest of the app in ruby for example.

Don’t get me wrong, Meteor is really great and fun, but if you are new to javascript and developing a soap service, it may not be the best choice.