The idea of the "core" part of "poser" (the only one implemented so far) is to provide a framework (and toolkit) to easily implement your service targeted at hosting on POSIX platforms. Among other things, it does offer abstractions for socket communication of the STREAM type, as this is what many services will use for communication. At this low level, it is completely protocol agnostic. All that's offered is some convenience API to tell the connection what's expected to be received next: binary data (optionally of a specific size) or strings/text with any strategy to find the end of the message (offering an implementation finding typical "line endings" as this is what many text-based protocols use).
I might add more libraries to "poser" in the future, e.g. to offer HTTP functionality.
SOAP is one thing that certainly won't be added though. SOA is dead. IMHO, rightfully, it's just an over-complex mess. When you offer HTTP-based services nowadays, you typically use REST semantics (using the verbs offered by HTTP for the actions, working on resources identified by the URI). For the documents exchanged in a REST API, JSON is a popular format choice. I don't know whether I will implement anything supporting communications using HTTP/REST, but that might be an option one day.
Just looking at the Wikipedia page for this standard makes it really clear why it has never seen widespread adoption (and I, for one, am really happy it didn't).
The project OP is referring to instead adheres to a very small, very clear spec, and not in the sense of implementing it. Instead, the project seeks to provide a set of tools using this limited spec.
I have my own set of criticisms for the OP, but this just doesn't make any sense.