The contracts between services are the most important thing there is in either SOA or EDA IMHO. You get this right and your future is bright, get it wrong and it is dim. Pretty much that simple.
I came to SOA/EDA from CORBA, J2EE, and DCOM projects. I thought that IDL was the only way to fly. When WSDL came out, I treated it like any other IDL. I was one of the people who endured significant pain with WSDL when it first came out because I was such a believer in "contract first" design/development.
The first time I started muttering "what is the contract?" when discussing OO design, service design, anything software related really was when I was mimicking one of my mentors (Dave Read when we worked at eXcelon). Just because I knew he was wicked smart and he said that a lot, I made sure I knew what he was talking about and added it to my repertoire.
So I am still a huge fan of contract first development, but it isn't always practical - especially with EDA. For one thing if you wanted to use WSDL today with EDA, you really couldn't as WS-* doesn't support pub/sub yet and WS-Notification & WS-Eventing are being merged into WS-EventNotification. I tend to think they will be too rigid when they are updated, but we'll just have to wait and see. Anyway, just because you don't have an IDL, doesn't mean you shouldn't think about contracts.
Service contracts in EDA aren't usually request/reply like they typically are in SOA. It is easier to get your hands around contracts with request/reply. With event streams, you have N services listening to an event and possibly publishing N events to N destinations. A service may listen to many destinations or a pattern. A service may receive XML documents conforming to different schemas. So you pretty much have to let the whole IDL thing go ... unless you just allow "any" or whatever it is in XSD (which is pointless).
This isn't very concise, but for me, contracts in EDA are:
- Event input payload(s)
- Service input destinations (set/patterns)
- Event output payload(s)
- Service output destinations (set)
Here are some more details on my opinions on service contracts and event stream design and EDA:
- Devote appropriate time to service contract/event stream design
- Have several sets of experienced eyes review
- Review a number of times - allow for "soak time" as my friend Sarge would say
- The goal is low coupling and high cohesion
- Anticipate event stream flow changes
- Consider persistence when thinking about contracts
- Get the granularity right (narrow vs. coarse) - the truth is somewhere in the middle
- UML sequence diagrams with embellishments (persistence, state change, etc.) and annotations works very well for technical design and review
- Great website/book - Enterprise Integration Patterns