What are the characteristics of a Scalable, Secure and Easy to Use Web Services?

Question

Our application currently exposes web services built with WSDL 1.1 and SOAP 1.1 following the w3c standards below:

http://schemas.xmlsoap.org/soap/http is the WSDL 1.1 binding for the SOAP 1.1 HTTP binding.

We want to revamp our web services to be Scallable, Secure and Easy to Use

Easy to use refer to the fact that at this moment web services do not incorporate any of the business logic on that layer. Basically, our current web service could be seen as a import/export service for external/3rd party developers.

This effort brings me to the question:

What do I have to expect of a revamp of our web services that are scallable, secure and easy to use?

---

Current issues with our Web Services

• You have to login (1st transaction) to receive a token (keeps session in memory) in order to use them.
• Is not scalable because any developer could open 20K sessions and crash the web service server.
• Is not secure because the same users from the admin of the site, could use the web services.
• It is not easy to use, because the web service do not incorporate any of the business logic.

The reasons our clients like our web service interface is because, any data element they add in the web application it will be exposed in the web service (wsdl) definition immediately.

---

One more bit of information:

I was hoping to confirm my theory that all the points mentioned above as issues could be solved if we implemented our web services in a RESTful way. Since each transaction will not cause memory buildup and each transaction will incorporate a security settings with public key or similar.

Either way, JRO, is right maybe if I slice the question in a series I will get better result. I will keep this question here until the end of day, if I get nothing better I will take JRO advice.

Answer 1

What are the characteristics of a Scallable, Secure and Easy to Use Web Services?

Scalability, security, and ease of use. Beyond that, it's going to depend a lot on what you're trying to do. You've provided very little information on what your web service does, what the issues are, and what you'd like it to do.

Answer 2

You're asking three different questions that might be interrelated but are so large that the aggregate answer of "it depends" is the only one you'll get. If this is the scope of your project, then break it down further, i.e. more granularity. Try solving this one issue at a time.

Let's approach this from your identified web service issues (the concepts around your question are too big for this space):

• You have to login (1st transaction) to receive a token: not certain why this is viewed as a "problem" without some context. Is generating/checking the token a problem? Is the implementation for the user a problem? You need to clarify why this is an issue.

• Is not scalable because any developer could open 20K sessions and crash the web service server. HTTP connection matters are best handled by web servers and load balancers, not programmatic management. If you need to limit a single endpoint's connection, start at the hardware layer.

• Is not secure because the same users from the admin of the site, could use the web services. This implies the security implementation for the service, and how the logic around credentials are handled internally. Not sure what to say other than fix this -- it's your logic, you're in control of what to do once you have credentials in-hand. If the problem is the security control model, that's a different topic. Identify what the real crux of the issue is, and don't confuse your implementation with tried-and-true models.

• It is not easy to use, because the web service do not incorporate any of the business logic. Without details of what this means, it means very little; not enough context. However, this type of question leans toward web service method/function design. To that end, coarse granularity in your methods is preferred -- make them more inclusive, rather than less.

My suggestion: bite off a single piece, such as the security implementation, and work with that first. Attempting to take on the other pieces simultaneously will only make things more confusing more you.

Answer 3

Regarding security, I can suggest you to download a free copy of Microsoft's Web Service Security Guide.

This guide will help you quickly make the most appropriate security decisions in the context of your Web service's requirements while providing the rationale and education for each option. A scenario-driven approach is provided to demonstrate situations where different security patterns are successful. The guide also combines a series of decision matrices to assist you in applying your own criteria to use the Web service security patterns to meet the requirements of your environment

It's very usefull in any development environment.
Have a good reading!