Migrating to SOA - Best practices of interface design
Well, a long time since my last blog. Blame a really great holiday along the Great Ocean Road for the delay. It was just too hard to think about work when having such a great time…
It's time I started working on my "Migrating your Enterprise to SOA" talk. I've put together the high-level agenda of the talk:
- My Enterprise today
- What is a SOA?
- A look at data
- Crawl…
- Exposing existing business processes as web services
- Useful messaging patterns that apply (Hub, Gateway, Message Bus)
- Applicable standards (XSD, WSDL, UDDI, WS-I)
- Best practices (Interface design, schema design, WS management)
- Walk…
- Building new processes by orchestrating existing processes
- Useful patterns that apply (Service Integration, Process Integration)
- Applicable standards (WS-I, BPEL, BPML)
- Best practices (using a process manager...)
- Run…
- Business activity monitoring, publication of activity, use of business rules, business intelligence
The fictional enterprise I present is a bank (mainly because that is the example we used in the Integration Patterns book). This bank is changing, as it tries to provide more customer services than the classic retail bank model. The bank is doing this by acquiring complementary financial service providers, and integrating their services with the standard services provided by the bank. One example of the kinds of applications added is bill payment. Naturally these applications run on disparate platforms, and have no unified integration mechanism.
I then present a simple definition for services and SOA, and talk about why this is useful to the bank. The service definition specifies that boundaries are explicit, services are autonomous, services share schema and contract but not class, and service compatibility is based on policy). SOA is described as a journey (not a destination), as we strive to make our IT investment responsive to the (rapidly) changing needs of our enterprise, by making use of the idea of services.
Next, I look at data, from the perspective of how it exists in the enterprise, how it exists inside applications, and how it exists flowing between applications (along the lines of Pat Helland's data talk (which you can look at here if you want). The main reason for this section is so that later in the talk, when I talk about service design, I can explain why some interface / schema designs are a good/bad idea.
The bit I'm working on now is the Crawl… part. Here I discuss exposing the various applications within the bank as web services. I touch on how to break apart applications into services that can be exposed, messaging patterns that might apply, and the key standards that should be adhered to. Then I talk about best practices related to interface design etc
So, how do you design a "good" interface? What are some of the characteristics of a good interface? I have some ideas from colleagues at Microsoft already (based on recent discussions), but if anyone has any specific views around this, I'm all ears.
What I have so far is…
Easy To Consume Regardless of Platform
Interfaces that are easy to consume are as simple as possible, but no simpler
- Few but meaningful parameters
- Parameters with one and only one meaning (not ParamA means X unless ParamB is “foo” then ParamA means Y)
- Document centric rather than method centric
- Conforms to WS-I base profile
Right Granularity
Interfaces that are of the right granularity are
- Able to accomplish a business unit of work in a single call
- Reusable across many different contexts (not just the first app that it was built for)
- Models business processes rather than lower level functionality
Easy To Version
Interfaces that are easy to version are
- Easily extended with the addition of new parameters
- Don’t break clients when a new interface is defined
Promote Loose Coupling or Autonomy
Interfaces that promote loose coupling
- Insulate the service consumer from changes in the service implementation
- Don’t require anything other than the schema and contract to know how to invoke them (what about security?)
- Don’t leak internal abstractions outside the service boundary
- Don’t require “out of band” services like 2PC to function correctly
(Thanks to Ron Jacobs for this list)
Of course the difficult question is how you ensure your design meets these requirements…
