In order to plan and implement an effective web service, you must first understand the scope. But what questions should you ask to determine your service's scope? Vanick has the answers. Read on to learn more.
One of the benefits of SOA is the ability to consume information as an abstracted service. However, the main advantage is the reuse of the service.
It is very rare to see a web service created proactively for use outside of the project it is being written for. Often, these services are built for a specific application need with the recognition that there would be others who could use the information from this service. The services are typically developed as the consuming application is developed and are specifically scoped to serve their project. The result is a service that is limited and likely will only work for this consuming application without modifications for future consuming applications. And much like the demand development of the first version of the service, the future versions will modify the service to meet just the needs of their application.
Developing web services for specific application use is not SOA. SOA implies broad reuse. If you are going to build a web service for reuse then you need to ensure that you have a firm understanding of the scope of the service before you start writing it.
To understand the entire scope you need to answer the following questions:
- Who is the consuming audience for the service? Is it internal? Customers? Partners? Vendors?
- What data do I want to expose to this audience?
- Are there different views of the data that might require many methods?
- Do I need to create flags to include or exclude data for service efficiency?
- What service standards do I want to support? (ReST, SOAP, idoc, xml-rpc, json-rpc, etc.)
- Will you create a formal WSDL or Schema to validate the request against?
- What languages will this service support?
- What error conditions should be considered and what language should be used that is meaningful to my audience?
- Is this a synchronous or asynchronous service? Will there be live users waiting on an answer from the service? What is the response expectation?
- What is the largest possible payload expected to be sent or received? Is this practical?
Once you have the answers to these questions, you will be much more successful at creating a service that will work for the audience you scoped it for.
About the Author
Lou Powell's expertise lies in marketing, interactive media, and computer systems. He has conducted extensive research on click selection in interactive media and managed IT projects around the world. He has more than 17 years of IT and Marketing experience, including 10 years of experience in running a business.