Some phone companies disable reception of SMS delivery reports, allegedly to cut costs. I'd like to know if eliminating such facility could be considered a violation of the SMS protocol, or if this is an optional feature.
I couldn't find an authoritative source about the protocol. RFC 5724 is about SMS URIs, but not the protocol itself, and I found something about 3GPP, but it seems more like an implementation guide than an actual specification. Besides, it's a Word document, which seems to me unlikely to contain the "official" specification.
Related
I am reading about microservices communication style, and there is a style here called "domain-specific protocol" which i don't understand.
Can anyone please describe it with simple words?
"domain-specific protocol" means a protocol that's purpose-built for the task at hand (for example SMTP is built for sending email, RTSP is built for streaming video).
The alternative would be a generic message-passing system (such as a message queue or a generic RPC system like gRPC, DCOM, ...) where only the messages themselves are domain-specific, but the protocol itself is built in a way to flexibly adapt to different purposes.
recently I've implemented MFN M15 message sender using HL7 (v2.x).
I see that HAPI FHIR is emerging as de-facto standard. Can someone point me out what would be MFN M15 message counterpart in https://hapifhir.io/?
NOTE:
I've already downloaded ca.uhn.hapi.fhir:org.hl7.fhir.dstu3:4.2.10-SNAPSHOT, and start investigation in org.hl7.fhir.dstu3.model but some directions would be more than gratefull.
Work on managing inventory using FHIR is still an area of exploration in FHIR (definitely a long way from 'de-facto standard' in this space, though FHIR is certainly becoming that for some areas of healthcare. In DSTU3, you may be able to cobble together part of a solution using Device and Medication. You might also look at this stream on chat.fhir.org: https://chat.fhir.org/#narrow/stream/179165-committers/topic/inventory.20tracking
So far I have seen non-Java client support only for open source message brokers like Apache ActiveMQ, JBoss HornetQ and Open Message Queue (OpenMQ).
Are there also closed-source products like WebSphere, WebLogic or Tibco which offer non-Java access to their MOM brokers, using a documented wire protocol (opposite to a closed-source binary client library) which allows to write clients in other languages?
This is getting more interesting as products (like WebLogic) are available in the (EC2) cloud so that developers can use the cloud instance to develop and test a client application without the need to purchase and install the full version.
I don't have a definitive answer because I specialize in WMQ exclusively. However, I believe the answer is "no" for the most part. (More on that in a minute.)
Regarding WMQ IBM makes available exit points to tailor the behavior of the channels, API calls and authorizations. Exits are very well documented and perform narrow functions within the scope of a particular action - i.e. receive a message, initiate a connection, etc. These are written in C and, more recently, Java. For the most part these are unused and customers I talk to generally cite complexity. They want something customizable through configuration and not through low-level code. I suspect other MOM vendors experience similar requirements from customers.
What does this have to do with your question? My take on this is that if customers are reluctant to code up exits with limited function, it seems far fetched that they would code up a full-featured and robust client that supports reliable message delivery, one- and two-phase commit, client-side exits, diagnostics, and all the other functionality that WMQ channels provide.
Assuming that this task was undertaken by an open-source team capable of that level of code, who would support it? the MOM vendors currently provide end-to-end support when using their proprietary clients. The notion of how a trouble ticket might be resolved when using a third-party client that is community-supported is a bit scary to many customer. For example, IBM supplies add-ons for WMQ called SupportPacs. Although there are SupportPacs that are fully supported and are considered product extensions, some of the SupportPacs are provided as-is. Many of my customers won't run as-is code even when it is supplied by the vendor.
Finally, there is the notion of the interface contract. WMQ supports a few verbs with a lot of options. The underlying channel protocol is MUCH more complex. When WMQ v7 came out, the channels had considerable new functionality and tuning. this was possible at this scale because the internals are not exposed to clients and so IBM was able to make massive changes without fear of negative impact to 3rd party clients. Exposing all of that would create dependencies on an order or two higher magnitude than exist with just the API's exposed.
So, according to my theory (I don't pretend to speak for the MQ development team here) the big MOM vendors have a vested interest in not exposing their channel protocols to independent developers. The new wrinkle here is AMQP which I alluded to above. It defines the wire protocol and allows each vendor to code a compliant product. Although this provides the opportunity you describe for open-source solutions, the ability of any one implementation to improve the product is limited by the fact that they don't own the protocol. For the time being though I don't expect you'll find any of the big MOM vendors exposing their wire protocols for 3rd party development. That said, this is just a guess and if I'm wrong, I'm sure someone here will jump in and provide the counter-example.
Can someone please tell me what are the pre-requisites for establishing an SMS Aggregation service (as a business), I am after the technology and implementation, a rough overview of what is involved (what components, ex. Gateway, carrier, etc) will be great help.
Regards
Find partner(s) with the right infrastructure that offer you connection to the mobile world. You will have difficulty dealing with carriers directly, but there are some "super-aggregators" that are connected to several carriers and offer you their services. This partner deals for you with the low level stuff (routing & delivery on SS7 layer). Get connected to the partner, probably via SMPP, the de facto standard protocol for SMS over IP.
Find many good customers. Offer them a broad range of interfaces like SMPP, HTTP, SOAP, ..., you name it.
...?
Profit!
If you keep it like that you have an IP only infrastructure and you won't have to deal with the nasty parts of the SMS world (at least not technically).
I have a client who wants a solution to allow delivery people to text (SMS messaging) in that they have completed a pick up at a particular location. What I'm looking for is Code to read an imbound SMS message or a SMS component if appropiate. This would allow me to create a windows service to read the message and update a SQL record accordingly.
Probably not quite what you're looking for but one approach is to use a gateway like iTagg which provides a number of interfaces for developers to send and receive SMS/MMS etc. Depending on your location, iTagg may be no use but I'm sure there'll be an equivalent for your region.
Sometime ago I implemented something similar using a GSM modem. I think most of the GSM modems offer AT commands that can be used for receiving and sending SMS messages. At the time, I used a library in Java that provided a easy to use API. The commands to read and send SMS are really easy but I bet there is something in .Net for that purpose that can make the task even easier.
I made a little search and I found this article with an example of using AT commands to interact with a GSM phone. I looked into the supplied source and it includes a library with operations related to SMS.
In my previous project I used a Siemens GSM modem with a RS232 interface. It wasn't very expensive and was able to manage all the messages sent by onboard units placed in vehicles. But if you have a unused phone it can work as well.
Thanks Luke, I am thinking more of a GSM modem which would be connected to the server. I think this would give more control rather than go through a third party, but I take your point and will investigate further.