The community of developers using odata for their REST implementations seem to be the least of all the REST implementations that I usually come across.
Any reasons?
There is virtually no contract. A service consumer has no idea how to use the service (for example, what are valid Command arguments, encoding expectations, and so on).
The interface errs on the side of being too liberal in what it will accept.
The contract does not provide enough information to consumers on how to use the service. If a consumer must read something other than the service’s signature to understand how to use the service, the factoring of the service should be reviewed.
Consumers are expected to be familiar with the database and table structures prior to consuming the Web service. This results in a tight coupling between service providers and consumers.
Performance will suffer due to dependencies on late binding and encoding/decoding between boundaries within the same service.
Source: https://docs.servicestack.net/why-not-odata
OData is a great standard to expose datasets with good tool support (Excel, Tableau, PowerBI...).
As far as I'm concerned it saved me a lot of time and effort, projecting/sorting/filtering... being available out of the box without having to code anything (especially with .net). It's my go to option for RESTful APIs on table like structures.
I had an interesting conversation with a contractor from one of the major outsourcing companies the other day. He has built restful APIs for many customers and when I asked if he used OData sometimes, he replied 'we don't do OData, we prefer Json' (sigh...).
So I guess one of the possible answers to your question is ignorance, many simply don't know OData or understand it...
This is a somewhat general question but I'm hoping someone will have specific info or recommendations.
I have an application suite that includes a service application that acts as a communications interface and data historian for industrial pollution-control hardware. The service contains a singleton COM server to allow the rest of the suite to have access to the hardware and data via the service.
I've read the stuff about how SvCom is required to make COM servers work in Delphi service apps. I have and use SvCom - it does what it claims. But I'm not all that comfortable with it, the product and my coding styles and expectations don't match, and it makes debugging somewhat more of a headache.
But my real problem is with the idea that the lengths SvCom goes to to make a COM server work in a service app is absolutely required. Their documentation, and some of the stuff that comes up in searches on the subject, makes it sound like their toolbox is absolutely required for any COM-server-in-service scenario. But I have a couple of different 3rd-party libraries for implementing OPC servers, Prosys Sentrol and the older Production Robots library (if you're not familiar with OPC, it's a pretty-much ubiquitous data-interchange standard built on COM) and both support the OPC COM server being put in standard TService-based apps without special handling beyond doing in the AfterInstall and BeforeUninstall events what would normally be done in a stand-alone EXE when run with the /regserver or /unregserver command-line switches, and of course using DelayInitialize := True. So at least SOME COM servers can be done as typical TService-based apps without the extraneous steps SvCom goes through.
So my question is: Is the line between "what sorts of COM servers work in a TService-based app" and "what causes the need for the extra stuff SvCom does" clearly known? If so, what is it and/or where is it documented? If not, I'm kind of surprised - seems like implementing COM servers in service apps would be a fairly common need, but I've does several deep searches and, based on the dearth of info I've found on the subject, maybe it's not.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
Is there any decent alternative to OPC-UA as a solution for accessing process data of a system composed of various PLCs? Something that is platform independent and can "speak" with products of different brands ?
I've heard of MQTT but it seems to be much more like a transport protocol, and only that. It does not have all the higher level stuff like the information modeling, etc.
Thanks for your help!
OPC is the only standard way for communicating with PLCs. OPC DA is the old alternative. OPC UA is the new one and recommended, nowadays. Before OPC there was just proprietary protocols and shared protocols like Modbus, but they are just lower level transport protocols as you've mentioned.
OPC UA is pretty unique with the Information Modeling, especially. With that feature it is enabling new communication possibilities for higher level systems and applications as well, in addition to plain PLC communication.
Note that some PLCs can also talk OPC UA natively, which makes it a standard in that way.
And OPC UA is really standardised as IEC 62541, ensuring that it's independent.
Update 17/07/19: OPC UA is now defined also as the Industry 4.0 Communication as I wrote in my recent article.
Update 20/05/05: OPC UA version 1.04 defines Pub/Sub alternatives, using UDP for secure data multicast in local networks and AMQP/MQTT for secure broker based data & event delivery to cloud systems. Version 1.04 also defines a WebSocket/JSON protocol alternative, which enable easier usage in web applications. None of these are broadly available, yet, but hopefully will become popular in 2020-21 time frame.
OPC-UA has some very interesting parts, especially concerning information modelling, interoperability and the publish/subscribe pattern.
However, even though it's a standard in the strictest of senses, I've found that to use it in a webapp you need to code a gateway server. Because it uses raw sockets and a binary (although fast) serialization protocol.
This is why we created an alternative protocol called Woopsa at my university. We decided to base it on HTTP + JSON. We tried to make a protocol that's similar to OPC-UA: it has Information Modelling, publish/subscribe, and even multi-requests. It's all completely open-source.
We've just released version 1.0 here: http://www.woopsa.org/
You can get the source code directly on our GitHub: https://github.com/woopsa-protocol/Woopsa
Basically, our protocol is just a standardized RESTful API using HTTP+JSON. For example, you can read a value by making a GET /woopsa/read/Temperature and it will reply you in JSON:
{"Value":24.2,"Type":"Real"}
You can also get the object tree by using the meta word, for example: GET /woopsa/meta/ which will give you something like that:
{
"Name":"WeatherStation",
"Properties": [
{"Name":"Temperature","Type":"Real"},
...
],
"Methods": { ... }
"Items": [
"Thermostat",
...
]
}
In a practical industrial application, MQTT is not an alternative to OPC-UA. The original goal of OPC, back in the '90s, was to provide a standard communication mechanism and data model that would provide interoperability among clients and servers that implemented the specification. OPC-UA expands and generalizes the data model and the communication without giving up on that core goal. In order to do this, the standard must specify things like the format of a time stamp, the encoding of data types, historical values, alarms, etc.
MQTT is a message transport layer that does not provide interoperability by design. It does not stipulate the format of the payload, does not specify how one transmits a particular data type, timestamp, value, hierarchy, or anything else that would allow an application to understand the data being transmitted. You can create a valid MQTT server that emits XML, JSON, or custom formatted data that is plain-text, encrypted, base-64 encoded, or anything else you like. The only way a client application can interact with your server is by knowing in advance what data format the server will produce and accept.
OPC-UA has recently introduced a publish/subscribe mechanism to improve bandwidth utilization, reducing a communication bandwidth advantage that MQTT currently offers. At the same time, the MQTT specification will need to grow to specify data formats in order to promote interoperability. Expect to see a convergence of functionality between MQTT and OPC-UA, mostly MQTT growing to meet OPC-UA.
MQTT is a much simpler implementation at the moment, which holds advantages for embedded and resource-constrained systems. The addition of a data modeling specification would act to reduce this advantage.
The bottom line is that OPC-UA is for interoperability and MQTT is for simple custom communication. MQTT needs to grow before it can be an alternative to OPC-UA.
MQTT is growing in popularity as the protocol of choice for I.o.T. It does have its short comings - however its simplicity is often seen as a strength whereas OPCUA carries the overhead of design by committee.
If you need to combine the two, you may like to consider trying our simple gateway mqtt2opcua
Unserver is a product designed to solve the exact problem described in this question.
It is capable of talking to different field devices and provide a unified HTTP API on
top of them.
It integrates with devices via Modbus RTU, but other common protocols will be added in the future.
In short, first you configure a data 'tag' like this:
{
"name": "tank1",
"device": "plc1",
"properties": [
{
"name": "level",
"address": "HR0",
"type": "numeric",
"raw": "int16"
}
]
}
Then you can work with the tag using an API endpoint created automatically:
GET http://localhost:9000/tags/tank1
{
data:{
level: 1
}
}
Check out the documentation for more info.
The product is free for evaluation and non-commercial use.
Disclaimer: I'm part of the team. Hope this is useful.
I just released another approach to this challenge. The project is called ELTRA IoT.
It's cloud service as mediator and end-user components that act as device representation or operator interface (https://www.eltra.ch/)
Primarily, it was created to simplify integration of CANopen devices with smartphone applications, but I quickly realized, that it can be used for any IoT project.
This project is inspired mainly by CANopen and FDT architecture.
The first idea was to deliver the solution, that allows bringing your device into internet using web standards like REST/JSON (avoid binary protocols, gateways, firewall, proxies issues and all this staff, that makes this whole process more complicated) within short time.
Web standard like HTTP/REST/JSON/WebSocket plays well with all operating systems and architectures and allows also easy end-user app integration in any modern language.
Main features:
Same API both sides (device and operator)
CANopen CiA-311 data model representation
Nodes, object dictionary, index, subindex, strong data typing, ranges etc. You know CANopen = you are at home
History data
RPC support - custom commands execution
Simple cloud service API https://eltra.ch/docs
Standard authentication scheme
SSL encryption
Cross-platform solution for Windows, Linux, Android, IPhone, Raspberry PI
SDK is available as open source on Github:
https://github.com/eltra-ch/eltra-sdk
At the moment, the library is implemented in .NET Standard and tested with Windows, Linux (x64 and ARM32), Android, IPhone.
Nuget package is available under:
https://www.nuget.org/packages/Eltra.Connector/
If the complexity of OPC UA is an overkill and Woopsa doesn't fit your design, then ELTRA could be an alternative.
disclaimer: This project is part of my masterthesis and eltra.ch service is my privately held website
I need to make a recommendation on approaches for allowing web service (WCF) documentation (wsdl, schemas, locations etc.) to be stored and found. Being able to monitor the services would be a definite bonus.
This needs to be considered in the wider context of moving to an SOA built, where possible, with Microsoft technologies that should be accessible by clients from other frameworks. The aim is to develop a system in which clients do not need to change if a service is moved or new versions are brought online - it should be possible to write the client 'knowing' just one address / location which is capable of directing them appropriately.
Having a central location for the service documentation is important too; our Business Analysts should be able to find all they need to about the services we provide from a central place. We would also want (potentially) to expose that repository of service information to partners as well. I know we could generate wsdls and manually manage them (create a folder somewhere and zip them up before sending them out) but that seems very labour intensive and prone to error (on my part).
As I see it at the moment there are two broad approaches;
Write something bespoke that uses WS-Discoverability and a dynamic routing service which can respond to the client requests.
Get an off the shelf solution.
I have to say that an off the shelf solution is the most likely approach that will be accepted but I have to at least consider the alternatives. For the off the shelf solutions I have identified
BizTalk
WSO2 ESB and WSO2 Governance Registry
as possibly providing the features.
What I need to know
Am I right with my understanding of the broad approaches?
Are there any other approaches I should consider evaluating?
Specifically I also need to know pros and cons of any approach I consider and have an idea of how it could be implemented.
To start with I would definitely not go with Biztalk or any WS-Whatever SOAP based protocol.
Go simpler and you'll be an happy man in the end.
For the middleware I would go Mass Transit
or if you prefer, NServiceBus, which I'm not a big fan off, but which provides another level of enterprise support. If you choose to go with Event SOA you'd get async operations as a bonus.
With the middleware layer defined it is time to define the API Layer. I would not expose my services to the outside world, and if the middleware is event based, the services within it they can only respond to events placed in the bus, so I would use ASP.NET Web API with a REST interface to get the requests to the outside, and based on the request type create the related message (command) and place it on the bus.
Way to high level but I hope it helps.
I need to take a huge Delphi XE application (backed by proprietary SQL server NexusDB) and begin providing my clients the ability to access the system in new ways:
Thinner Windows client for slow/VPN connections
Mobile/Tablet
Web
DataSnap appropriate for this or is introducing a middle tier the wrong way about providing remote/mobile access? Other solutions/ideas welcome.
(I have XE2 Enterprise but am stuck on XE Enterprise for awhile.)
DataSnap is being aggressively positioned by Embarcadero as a Multi-platform connectivity solution, where servers are written in Delphi, and mobile connectors are available (in XE2 and later) for a variety of mobile device platforms. So the quick answer is yes, it is suitable in general.
Is it suitable for you? You haven't said much that would help me answer that question; You are willing to buy Enterprise or Architect SKUs of Delphi, so I would guess yes.
If it was me, I'd look for a solution that implements a pure simple REST architecture that is available to every system out there, mobile or otherwise, no matter what language or platform, but I haven't got a suggested alternative because it seems to me that SOAP is nearly dead and that there is no universal replacement technology out there that does everything that soap client/server systems do. I'd be tempted to consider "roll your own REST+json" or evaluate Remobject's product offerings too, and select a path that makes sense for you, from a business and technical point of view.
Datasnap is fine, but it's not the only option. It's probably the simplest and most easy to roll out option currently available, and the only one "out of box" ready to go in XE2 if you want apple, android, and a few others, right away.
That depends on your security needs, and the way you're providing data to clients. As I often pointed out, dbExpress-Datasnap has big security flaws (while the DCOM version is not well suited outside a LAN, and does not offer out of the box mobile devices support).
A web application would have less issues because the datasnap-web server connection would be probaby internal, it would be up to the web application to ensure data protection.