This post by Jean-Jacques over at ebpml.org suggests that SSDL couples a contract with Web Service endpoints. We’ve thought about this issue and this is the reason we’ve decided to make endpoints optional. A contract is still a contract even if there are no endpoints. The endpoints may be discovered out-of-band.
I also think that we are using the term ‘contract’ correctly. An SSDL contract describes a set of message interactions. For any two or more parties to meaningfully engage in conversations through message exchanges, they have to agree on the same contract. Whether the document is static and is forced upon others or it’s negotiated and used dynamically, it still needs to have a structure; that structure is what the SSDL specification defines.
SSDL in the news:
I am probably missing others.
I do hope that people will start commenting and giving us feedback; I know that it’s a lot of information to digest and people are busy. Let the discussions start. And remember… there is a dedicated mailing list too.
I am currently busy working on releasing the SSDL tool. I just finished the setup project (it was very easy with VS.NET 2005 🙂 but I need to do some work on how the plugins get discovered and receive command line arguments.
There’s a unique energy that comes with starting something new — a blend of excitement,…
As I continued work on BrainExpanded and its MCP service, I came to realize that…
Just over a month ago, I published "Playing with graphs and Neo4j". Back then, it…
After my initial implementation of some BrainExpanded-related ideas on top of dgraph using its GraphQL…
Say hello to the Graph Model Domain Specific Language (GMDSL), created with the help of…
As I wrote in previous posts, the manual recording of memories for BrainExpanded is just…