In the SOA world, are 'services' interchangeable with 'applications'? In a new post, Dave Linthicum cautions that there is often confusion about what constitutes a 'service' versus a full-fledged SOA-enabled 'application.'
"Services are not applications. They are small parts of an application," Dave advises. He also cautions that services are not to be construed as "subsystems," but rather, as small parts of subsystems.
Thus, designing a 'service' calls for a different approach than application design. Dave says in the SOA projects he's seen, there has not been enough attention paid to "service design." He notes this is becoming essential as we increasingly move to the use of services to assemble and integrate software. SOA-based service design is a whole differnent animal.
There are five key considerations that go into SOA service design:
1) Define the purpose of the service. "What will the service do, and who is the intended user?"
2) Determine the information to be bound to the service, including both metadata and schemas. "This means you need to understand how information is leveraged by the service, and what functions require what data," Dave says.
3) Determine the functions (methods) encapsulated inside the service. This may consist of behaviors you would like to expose, such as "check inventory." Dave advises use of a traditional functional decomposition chart at this stage of the design process.
4) Define any interfaces into the service; both machine and human. "This means we need to determine how the service will interact with the calling applications, and through what mechanisms," Dave says. Rich client interfaces that invoke human interaction should also be considered.
5) Define how the service is to be tested. Testing is often "a very important but often neglected step," Dave points out.
Leave a comment