3 ms·

POSIX doesn't define a service API for (HTTP, local, or otherwise exposed) services, but if adherence to an existing API spec from the height of SOA is importan

POSIX doesn't define a service API for (HTTP, local, or otherwise exposed) services, but if adherence to an existing API spec from the height of SOA is important, there is Service Component Architecture (SCA) which has bindings to C (or other native PL), Java/JVM, and other relevant calling conventions. There used to be multiple implementations of SCA for C++ (Apache Tuscany, Trentino/Siemens, and others) but C++ name mangling is of course a PITA for binary forward compatibility.

tw061023 3y ago
I apologize, but how is this relevant? 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.
Zirias 3y ago
A "service" certainly doesn't mean SOA (using SOAP), it doesn't even mean any specific form of communication (there might be cases not needing any communication), it basically just means some hosted piece of software. 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.

tw061023 3y ago

I apologize, but how is this relevant? 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.

Zirias 3y ago

A "service" certainly doesn't mean SOA (using SOAP), it doesn't even mean any specific form of communication (there might be cases not needing any communication), it basically just means some hosted piece of software. 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.