I've seen some recent examples where old-school point to point integrations are called SOA because they're built with web services, or architectures built with a scheduled FTP-Get called service oriented because it uses an
integration middle ware software component.
At the risk of sounding too much like a purist, I think it would be helpful to review the four simple rules that define SOA:
1) Boundaries are Explicit
Because each cross-boundary communication is potentially costly, service-orientation is based on a model of explicit message
passing rather than implicit method invocation.
2) Services are Autonomous
Services are entities that are independently deployed, assigned versions, and managed. This means that they should not be dependent on whatever is consuming them.
3) Services share schema and contract, not class
Services interact based solely on schemas for structures and contracts for behaviors.
4) Service compatibility is determined based on policy
Consumers must be able to determine the capabilities of a provider via a publicly accessible, standard policy.
I know that some people feel more comfortable with Batch/MFT or ETL patterns than with SOI because they've seen them work well in the past. However, I would argue that built properly, there is nothing about service oriented integrations that is less reliable than any other properly implemented pattern.
integration middle ware software component.
At the risk of sounding too much like a purist, I think it would be helpful to review the four simple rules that define SOA:
1) Boundaries are Explicit
Because each cross-boundary communication is potentially costly, service-orientation is based on a model of explicit message
passing rather than implicit method invocation.
2) Services are Autonomous
Services are entities that are independently deployed, assigned versions, and managed. This means that they should not be dependent on whatever is consuming them.
3) Services share schema and contract, not class
Services interact based solely on schemas for structures and contracts for behaviors.
4) Service compatibility is determined based on policy
Consumers must be able to determine the capabilities of a provider via a publicly accessible, standard policy.
I know that some people feel more comfortable with Batch/MFT or ETL patterns than with SOI because they've seen them work well in the past. However, I would argue that built properly, there is nothing about service oriented integrations that is less reliable than any other properly implemented pattern.
In order to achieve an event driven architecture and get the flexibility benefits that derive from this type of pattern, SOA is a prerequisite.
Posts
preach it brother! I've seen a lot of that jabows (just a bunch of web services) stuff lately too, and people keep calling it "SOA". Don't even get me started on the batch stuff. It's so mid-90's
ReplyDelete