How do component-based and service-oriented architectures differ?
, you mention that a component may have multiple service interfaces to meet different clients' needs. But isn't SOA about standard interfaces? If I have multiple interfaces for a single component (all of which are published), will it not be confusing? For example, on the top, at the interface level, the two will seem to be different (due to different interfaces), but the bottom or the component or the implementation will be the same. Am I missing something?
Yes, SOA relies upon standard interfaces, but that's quite different from having a single interface. If service interfaces corresponded one-to-one with component APIs, then there wouldn't be that much of an advantage to the service interface. You might as well just use the API! However, because it's possible to dynamically discover service interfaces, a proper SOA has the luxury of being able to allow multiple service interfaces for a particular component (service provider).
The question of whether this will be confusing is really an architectural question. Sure, if you allow service interfaces to proliferate in an uncontrolled manner, you'll have a management headache on your hands. But if you provide multiple interfaces in a controlled, managed fashion to meet the specific needs of service consumers in order to promote the loose coupling between the service consumers and providers, then you will be on...
your way to realizing the benefits SOA has over traditional APIs.
Dig deeper on Service-oriented architecture (SOA) implementations
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.