savas parastatidis

Endpoints in SSDL and SSDL in the news

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.

2 responses to “Endpoints in SSDL and SSDL in the news”

  1. Jean-Jacques Dubray
    Savas: thanks for the response, I don’t mean to overly criticize SSDL as both the spirit of a “community” standard and your approach to web service description are refreshing. I still think that componentisation is not enough and you must complitely separate interface definition from binding (many types of bindings can be created). It will also encourage people to reuse interface definition as they will be published as independent artifact. the second fix I would to WSDL is at the binding level. As you may be aware, there is a new WS-standard coming up (WS-CDL) which allow for description of peer-to-peer interactions. However, I am not completely sure (I have to look at it) that the bindings to WSDL (and within WSDL) support peer-to-peer interactions. Ultimately, WS MUST SUPPORT PEER-to-PEER interactions. Note that for me this is what is a contract (how two or more interfaces may interact together). I am not a vocabulary guy so if you call interface contract but you have a concept that make two contracts work together, I am fine, I just want to make sure that both are semantically different. The 3rd thing I would fix is provide the ability to provide more semantics to operations (or message exchange patterns). The type of semantics that come to mind are: a) Resources: does this message contains a representation of a resource (Order, Customer,…) b) behavior: what is the MEP allowed sequence c) message type: signal, event, … d) MEP type (see the lastest OASIS ebBP spec) …. I think your modular approach will support these semantics I would not mind contributing a bit more, if you are interested, hope that helps, JJ-
  2. Savas Parastatidis
    JJ, many thanks for your input. I believe that some of your suggestions can and should be built at a different level from what SSDL tries to achieve but your insight is valuable to us. Many thanks!