I have Problems understanding best practice around OPC UA.
OPC UA is often called Protocol of future IOT and other positive stuff.
In my understanding, if you want to Provide Information over OPC UA as a Service you Implement SOAP Web services. As far as my Knowledge goes, RESTful services are just better in most Use cases.
I know SOAP REST comparisons that call Rest the better choice and then there are some Industrial Adverts calling OPC UA better then REST …
Pro Rest:
https://spf13.com/post/soap-vs-rest/
Pro OPC UA:
https://www.maintworld.com/Partner-Articles/Why-use-OPC-UA-instead-of-a-RESTful-interface
In my Conclusion, unless there are other Implementations of OPC UA then SOAP. REST seems without hesitation better.
Am I wrong in the Understanding that SOAP is the common Implementation of OPC UA?
Are not most Features of this “Amazing” Protocol behind RESTful standards?
How Comes most Production Related Software Products focus on OPC UA instead of REST?
Thanks for any Advice or Source of Information!
In my understanding, if you want to Provide Information over OPC UA as a Service you Implement SOAP Web services.
Not even close.
Am I wrong in the Understanding that SOAP is the common Implementation of OPC UA?
Yes, very.
The term “SOAP” literally isn’t used in the OPC UA article you linked to. I think you need to go back to step zero and start reading some introductory OPC UA material.
Here’s an overview article that even touches on the fact that there used to be an optional SOAP/HTTP transport defined by the spec, which may be the source of some of your confusion: https://www.rtautomation.com/technologies/opcua/
Newer versions of the spec have deprecated this transport because almost nobody used it. The UA TCP binary transport remains the only transport required to be implemented and the overwhelmingly most commonly used.
Related
I am exploring micorservices architecture through books, blogs etc.
What I have seen is that mostly people implement microservices using REST. Isn't it contradictory?
Microservices are supposed to decouple services to achieve scalability, but REST communication protocol is synchronous.
So how can these two go together?
The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.
-- Roy Fielding, 2000
"REST communication protocol is synchronous."
That's not quite right, on a couple of levels.
First, there is no "REST communication protocol"; REST is an architectural style.
Hypertext Transport Protocol, aka HTTP, is a an application protocol for for hypertext information systems. REST is an architectural style, the web is the reference implementation.
Second, HTTP isn't actually synchronous. Because there are no generic correlation identifiers in the metadata of the request, the client needs to keep track of the order in which requests were sent along a given connection. See RFC 7230, Section 5.6. It's "just" messaging.
Apache's HttpCore Tutorial includes a discussion of non-blocking HTTP connections.
I'm assuming you are looking at the linking of multiple HTTP Restful services.
If you are designing the messaging architecture for a Restful set of microservices. You need to take into account the risk and benefits of each communication technology. Remember you don't have to use one, you can use the best tool for each job.
The most common seemingly are HTTP and AMQP (Advanced Message Queuing Protocol). They both serve different purposes.
If you are providing the back end to a website as micro services. Then chaining calls together in a synchronous fashion might be required, if the user requires a response from the website. Also it's likely your inbound requests will be HTTP at this point.
Alternatively if no response is required, you might want to consider fire and forget messaging queues. These would allow messages to be passed to other micro-services asynchronously.
There is a great e-book that covers this topic in great detail.
https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/ [.NET Microservices. Architecture for Containerized .NET Applications]
This page covers the exact topic you are discussing.
https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/communication-in-microservice-architecture [Communication in a microservice architecture]
Hi I am studying IoT with PLC.
I was looking for a way to poll data from PLC modules, and found OPC Protocol that seems to be the standard.
If I adopt this protocol and make a server that polls data via OPC and mediate that protocol, will I be able to connect to any kinds of PLC?
I saw some solutions and they highlight specific vendor-drivers.
Does this mean OPC is not a standard and I need to see each vendor's protocols?
I need some grasp on this, so please advice on how I should communicate with PLCs with JAVA Server
OPC has multiple different versions.
The major ones you might consider are:
OPC DA ("Data Access"), which is based on Microsoft OLE, COM and uses DCOM as a wire protocol.
OPC UA ("Unified Architecture"), which has a more complex data model and has a distinct protocol specification. There are multiple wire protocols, including an XML based protocol and a compact binary encoded protocol. There are different types of security choices; interoperability means matching everything up.
For PLC access it may be that you are using a gateway between a wire protocol (for example Modbus or a vendor protocol) and an OPC programming environment. In this case you do not need to be aware of the protocol implementation; the driver/gateway is responsible for the conversion into the OPC programming environment.
In a Java environment you could find an OPC UA supplier that provides a Java API and has driver support for the devices you need to use.
Right, so only relatively recently did PLCs start to communicate via OPC-UA natively. Typically, each vendor has their own sometimes open, sometimes proprietary protocol that you need to use to talk to the PLC.
The traditional role of a OPC servers has been to let the vendor of the server worry about all the protocol details for each kind of device while clients just need to know OPC-DA or OPC-UA, which is an open standard.
My question is more conceptual than technical. I'm trying to understand connectors in REST, and in my mind they seem analogous to paths or connections in a network. So is a connector in REST just a channel of communication, or does it also include interfaces on the endpoints?
When in doubt, read the documentation, I guess:
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
On 5.2.2 of Fielding's paper, he defines and explains the connectors. The answer to my question is, "Yes, connectors include interfaces." In fact, they seem to be little more than interfaces.
A connector is more likely to be just one endpoint, but the definition for connectors is intentionally loose to include any part of a RESTful system that facilitates communication between the components. So a client component will delegate communication to a client connector which in turn communicates with a server connector that handles communication for its respective server component. A tunnel connector, on the other hand might include both of its endpoints.
Another point I found useful while reading Fielding's paper is that connectors benefit just as much from the uniform interface as any component. Since server/client/resolver/etc. connectors are all working on URIs, matters are greatly simplified.
I have been looking at the OPC UA Specification parts, however they do not give you a list of classes and function and tell you how they work. Is there something like that?
Also the server, the 1st thing it does is creates an Object right?
one of Server ?
what are the steps from the Server point of view ?
You should strongly consider using one of the available SDKs if you're looking to build an OPC-UA server.
That being said, UA Part 6 describes the encoding of the built-in datatypes. A schema describing many of the other structured types is available here: http://opcfoundation.org/UA/schemas/1.02/Opc.Ua.Types.xsd, along with some other useful XML files.
As you can read into the Part 1 : Overview and Concepts of the OPC UA Specification :
OPC UA defines a common infrastructure model to facilitate
this information exchange OPC UA specifies the following:
The information model to represent structure, behaviour and semantics.
The message model to interact between applications.
The communication model to transfer the data between end-points.
The conformance model to guarantee interoperability between systems.
You could get the OPC UA Stack from the OPC Foundation if you are member of it, but this is only the communication part of a Server/Client application.
Then you have to implement your own Server/Client (AddressSpace manager, Session Manager, Subscription Manager, Certificate manager,...) or buy a SDK that already contains all the required features of an OPC UA Server or Client and will allow you to launch a Server/Client with few code lines.
What are the disadvantages of using SOAP services?
Quotes from this wikipedia article: SOAP
Because of the verbose XML format, SOAP can be considerably slower than competing middleware technologies such as CORBA. This may not be an issue when only small messages are sent.[7] To improve performance for the special case of XML with embedded binary objects, the Message Transmission Optimization Mechanism was introduced.
When relying on HTTP as a transport protocol and not using WS-Addressing or an ESB, the roles of the interacting parties are fixed. Only one party (the client) can use the services of the other. Developers must use polling instead of notification in these common cases.