Hi I am investigating OPC UA for my organization. I am trying to work out an example for a presentation based on an information or data example.
I have one for a on demand read operation and one for a continuous monitor. What I don't quite understand since I am just learning and haven't picked a vendor yet (lean towards United Auto) is how is the data represented?
For example if I have a data struct or object called machineInfo with 13 attributes (data) how would I create that on the server side and show how its done?
How would it fit in the BaseNode, Variable hierarchy? Or am I way off?
I can show high level or just code.
Thanks
MachineInfo would be an Object node (NodeClass of Object), with HasComponent references to each of the 13 attributes, which themselves would be Variable nodes (NodeClass of Variable).
As far as type definitions go, you could start out with just using the BaseObjectType and BaseDataVariableTypes, but if you're going to be using a client capable of taking advantage of more complex types you could create a custom ObjectType for the object. The variable components could be further exposed as AnalogItemType or DiscreteItemType, if applicable...
What programming language/SDK are you leaning towards?
Related
I am building a OPC-UA server using eclipse milo. What are the different ways to provide multiple nodes for a subscription service? Can I define a custom data object having properties of basic data types, for this? How?
I want to have a service which serves data of different data types (Integer, Double, Boolean etc.) as it's output. Each of the values should be named different not single name like array output with single name for all of the values. For this purpose is there a way to define a custom data object class with attributes of different types? Is this possible in OPC to have a custom data object type as output of a service?
Conceptually, adding Nodes with each of the different DataTypes you're asking about is no different than creating a folder node and adding nodes to that.
The ExampleNamespace in the milo-examples project shows you how to do that.
If you truly want to use an instance of a custom ObjectType rather than an instance of FolderType then there's a bit of bookkeeping work you'll need to do.
Create an instance of ObjectTypeNode to describe your new type.
For each property/member it will have, create a new VariableNode with that configured with the DataType you want, then add a HasComponent or HasProperty reference from your ObjectTypeNode to this VariableNode. (These Nodes are what the spec calls InstanceDeclarations)
Add your ObjectTypeNode to the address space as a subtype of BaseObjectTypeNode.
Then, when you created your original ObjectNode, you'd specify the type definition as being your newly created ObjectTypeNode rather than, say, a FolderType.
You can get a better idea about how all this works in Part 3 and 5 of the spec or by using a client like UaExpert to inspect some of the pre-existing ObjectTypes in the server, such as ServerType.
Edit: There's now an example of how to do this here. If this seems a bit bulky... you're right. Typically ObjectTypes and VariableTypes are designed in a modelling tool and imported via a NodeSet XML file, but that's outside the scope of things right now...
My questions is about bringing a concept to reality through technical availability of EA.
I am looking for a way to connect instances at an object diagram through which I can transfer tagged values. Let me explain the background of the project.
Purpose is to first have Stereotypes for specific roles in the system, such as "Calculation", "Transmission", "Decision", "Qualification", "Abstraction" etc.
Each of these stereotypes have specific tagged values suitable for their purpose.
Then I am creating instances from these stereotypes, eg. "MotorTorque:Calculation" and "LimitedTorque:Abstraction"
Each of these instances have a common tagged value, "criticality", boolean and I want this tagged value to progress from "MotorTorque:Calculation" to "LimitedTorque:Abstraction" through an output port > some sort of flow > input port kind of way.
Questions are:
1- Is this approach technically achievable in EA? If so what would be the correct way to do it?
2- The purpose is to have this "connection" readable in XMI export of the diagram which I will be using as an input for another purpose.
I have created an MDG Technology for my project with stereotypes and tagged values, however, I am having difficulty achieving this "connection", this "flow" of values.
Thank you for your time.
What you are asking for is not directly achievable. However, many ways lead to Rome.
One way would be to <<trace>> connect those objects to a Status class (or what ever you like to name it) and have this carry the "shared TV".
Another way is (by far more complex) to use an add-in. You would anyway need ways to create groups which share the TV. From your current explanation I can't see what that might be. Maybe the instantiating class of those instances? If so, you make a script that propagates a TV setting from ist current to all other linked instances. I'm not sure if the add-in events fire when a TV is changes (I do have some doubts here). If needed I could look that up.
What you propose is partially feasible.
There is a tagged value inheritance chain in EA, in which tagged values are inherited down the generalization chain, and from a classifier to its instances. In the GUI, inherited tagged values are shown separately from the instance's own ones, and in the API they are accessed using the Element.TaggedValuesEx property. Inherited tagged values can also be overridden.
Since the correct way to create a port (or part/property) is to make it an instance of a component, a port will inherit any tagged values from that component. So if your Calculation stereotype applies to component, ports which are instances of Calculation components will inherit the MotorTorque tagged value.
However, there is no way to "flow" tagged values from one port to another. If you want such a function, you'll have to implement it yourself with an Add-In.
Regarding XMI, first you must understand that an XMI export is based on a package, not a diagram. The XMI format itself is extensible, which means that different tool vendors create their own extensions which are typically not publicly documented. Crucially, diagram layouts are part of these non-standardized extensions. In EA's case, the image data is some sort of UU-encoded bitmap which you won't be able to extract any useful information from.
Elements' tagged values are included in an XMI export, but again, the EA extensions are not publicly documented. In other words, you can import EA:s XMI format in another program, but you will need to reverse-engineer the format. Not impossible, but it's probably better to either write your own specialized export function, or export via CSV. Note, however, that CSV export cannot be automated -- there's no call for it in the API.
I have a question on whether or not a particular REST-service design is good or not.
The background is of having an inhouse monolithic system (will call this "the main system") dealing with e.g. customers. Then there are external components that have additional information on persons, which may or may not correspond 1-1 with a customer in the main system.
At present there is no definite specification of what kind of data is or may be associated with a person/customer in these external components.
The proposed design I have been presented with is a REST- service that exposes an API for the external system to call in order to feed the component with this arbitrary data associated with persons.
The idea is that by doing so the main system will have a single place to go to, to get the external data for customers/persons.
A proposed requirement of this REST service is that as new types of data is loaded into it by an external component, this data is automatically made accessible by the service, without it needing to be changed in any way, or redeployed. And "new data" generally means a new type of key value set. E.g. initially the service might provide data for customer identified by a customerId. Then an external component decides to post some kind of data associated to SSN. This should automatically entail that the service can be queried for this data by supplying SSN in the request.
In order to avoid the need to change/redeploy the service I’m assuming the solution will ahve to have a very generic scheme of reference, e.g.
http://url/generic-resource-name/?id=[customerId]&keyType=cusomterId
There is really nothing in the requirements that limits the data to be associated to a person, only that it’s key be made up of one value.
And example use case sequence could be:
So to the question:
Is it a good idea to implement such a general purpose service? And how does it rhyme with the principles of REST: the noun in question that the service will operate on will have to be very generic, really nothin short of “resource” or “data”, which in itself seems like a smell to me.
So to the question: Is it a good idea to implement such a general
purpose service?
I believe not. You are going straight into Inner platform effect antipattern. You must be very careful, or you might end like Vision.
Please also read a chapter "The allure of distributed objects" from Fowler's PoEAA book. Just to be careful.
Short version
I am considering to use BusObjects to implement hard interface control on a (large industrial) application using Simulink and I would like to store the BusObjects (hundrends of them) into a Matlab structure so that the entire application interface specification is well organized. However, it seems that BusObjects cant be contained into structures, nor they can reside on other workspaces other than Matlab Base. Any idea on how to handle this?
Long version
I would like the interfaces specification to be hierarchical and centralized in some way. I mean, I would like to specify the external interface of my application, then the internal interfaces, then the internal interfaces of the internal interfaces and so on. And I would like this information to be stored in one object that resembles the hierarchy. I was thinking in using an structure with BusObjects as elements.
Unfortunately, it seems that, for a bus object to work, it must be declared on the Matlab workspace as an independent variable of class BusObject. It cant be an element of an structure that is a BusObject, or an element of a cell whose elements are BusObjects or an element of a BusObject vector.
Any suggestion on how to handle this? take into account that if you have a model with dozens and dozens of blocks and more than 3 hierarchy levels, then you end up with hundreds of bus objects in the Matlab workspace without any particular structure... I think that is too messy to let it be...
Bus objects are always stored in the global workspace.
Send a request to Mathworks if you want to change this.
In my attempt to redesign an existing application using REST architectural style, I came across a problem which I would like to term as "Mediatype Explosion". However, I am not sure if this is really a problem or an inherent benefit of REST. To explain what I mean, take the following example
One tiny part of our application looks like:
collection-of-collections->collections-of-items->items
i.e the top level is a collection of collections and each of these collection is again a collection of items.
Also, each item has 8 attributes which can be read and written individually. Trying to expose the above hierarchy as RESTful resources leaves me with the following media types:
application/vnd.mycompany.collection-of-collections+xml
application/vnd.mycompany.collection-of-items+xml
application/vnd.mycompany.item+xml
Further more, since each item has 8 attributes which can be read and written to individually, it will result in another 8 media types. e.g. one such media type for "value" attribute of an item would be:
application/vnd.mycompany.item_value+xml
As I mentioned earlier, this is just a tiny part of our application and I expect several different collections and items that needs to be exposed in this way.
My questions are:
Am I doing something wrong by having these huge number of media types?
What is the alternative design method to avoid this explosion of media types?
I am also aware that the design above is highly granular, especially exposing individual attributes of the item and having separate media types for each them. However, making it coarse means I will end up transferring unnecessary data over the wire when in reality the client only needs to read or write a single attribute of an item. How would you approach such a design issue?
One approach that would reduce the number of media types required is to use a media type defined to hold lists of other media-types. This could be used for all of your collections. Generally lists tend to have a consistent set of behavior.
You could roll your own vnd.mycompany.resourcelist or you could reuse something like an Atom collection.
With regards to the specific resource representations like vnd.mycompany.item, what you can do depends a whole lot on the characteristics of your client. Is it in a browser? can you do code-download? Is your client a rich UI, or is it a data processing client?
If the client is going to do specific data processing then you pretty much need to stick with the precise media types and you may end up with a large number of them. But look on the bright side, you will have less media-types than you would have namespaces if you were using SOAP!
Remember, the media-type is your contract, if your application needs to define lots of contracts with the client, then so be it.
However, I would not go as far as defining contracts to exchange single attribute values. If you feel the need to do that, then you are doing something else wrong in your design. Distributed interface design needs to have chunky conversations, not chatty ones.
I think I finally got the clarification I sought for the above question from Ian Robinson's presentation and thought I should share it here.
Recently, I came across the statement "media type for helping tune the hypermedia engine, schema for structure" in a blog entry by Jim Webber. I then found this presentation by Ian Robinson of Thoughtworks. This presentation is one of the best that I have come across that provides a very clear understanding of the roles and responsibilities of media types and schema languages (the entire presentation is a treat and I highly recommend for all). Especially lookout for the slides titled "You've Chosen application/xml, you bstrd." and "Custom media types". Ian clearly explains the different roles of the schemas and the media types. In short, this is my take away from Ian's presentation:
A media type description includes the processing model that identifies hypermedia controls and defines what methods are applicable for the resources of that type. Identifying hypermedia controls means "How do we identify links?" in XHTML, links are identified based on tag and RDF has different semantics for the same. The next thing that media types help identify is what methods are applicable for resources of a given media type? A good example is ATOM (application/atom+xml) specification which gives a very rich description of hyper media controls; they tell us how the link element is defined? and what we can expect to be able to do when we dereference a URI so it actually tells something about the methods we can expect to be able to apply to the resource. The structural information of a resource represenation is NOT part of or NOT contained within the media type description but is provided as part of appropriate schema of the actual representation i.e the media type specification won’t necessarily dictate anything about the structure of the representation.
So what does this mean to us? simply that we dont need a separate media type for describing each resource as described above in my original question. We just need one media type for the entire application. This could be a totally new custom media type or a custom media type which reuses existing standard media types or better still, simply a standard media type that can be reused without change in our application.
Hope this helps.
In my opinion, this is the weak link of the REST concept. As an architectural and interface style, REST is outstanding and the work done by Roy F. and others has advanced the state of the art considerably. But there is an upper limit to what can be communicated (not just represented) by standard media types.
For people to understand and use your REST-ish API, they need to understand the meaning of the data. There are APIs where the media types tell most of the story; e.g. if you have a text-to-speech API, the input media type is text/plain and the output media type is audio / mp4, then someone familiar with the subject matter could probably make do. Text in, audio out, probably enough to go on in this case.
But many APIs can't communicate much of their meaning with just media type. Let's say you have an API that handles airline ticketing. The inputs and outputs will mostly be data. The media types on input and output of every API could be application/json or application/xml, so the media type doesn't transmit a lot of information. So then you would look at the individual fields in the inputs & outputs. Maybe there's a field called "price". Is that in dollars or pennies? USD or some other currency? I don't know how a user would answer those questions without either (a) very descriptive names, like "price_pennies_in_usd", or (b) documentation. Not to mention format conventions. Is an account number provided with or without dashes, must letters be all-caps and so on. There is no standard media type that defines these issues.
It's one thing when we're in situations where the client doesn't need a semantic understanding of the data. That works well. The fact that browsers can visually render any compliant document, and interact with any compliant resource, is really great. That's basically the "media" use case.
But it's entirely different when the client (or actually, the developer/user behind the client) needs to understand the semantics of the data. DATA IS NOT MEDIA. There is no way to explain data in all its real-world meaning and subtlety other than documenting it. This is the "data" use case.
The overly-academic definition of REST works in the media use case. It doesn't work, and needs to be supplemented with non-pure but useful things like documentation, for other use cases.
You're using the media type to convey details of your data that should be stored in the representation itself. So you could have just one media type, say "application/xml", and then your XML representations would look like:
<collection-of-collections>
<collection-of-items>
<item>
</item>
<item>
</item>
</collection-of-items>
<collection-of-items>
<item>
</item>
<item>
</item>
</collection-of-items>
</collection-of-collections>
If you're concerned about sending too much data, substitute JSON for XML. Another way to save on bytes written and read is to use gzip encoding, which cuts things down about 60-70%. Unless you have ultra-high performance needs, one of these approaches ought to work well for you. (For better performance, you could use very terse hand-crafted strings, or even drop down to a custom binary TCP/IP protocol.)
Edit One of your concerns is that:
making [the representation] coarse means I will end up transferring unnecessary data over the wire when in reality the client only needs to read or write a single attribute of an item
In any web service there is quite a lot of overhead in sending messages (each HTTP request might cost several hundred bytes for the start line and request headers and ditto for each HTTP response as in this example). So in general you want to have less granular representations. So you would write your client to ask for these bigger representations and then cache them in some convenient in-memory data structure where your program could read data from them many times (but be sure to honor the HTTP expiration date your server sets). When writing data to the server, you would normally combine a set of changes to your in-memory data structure, and then send the updates as a single HTTP PUT request to the server.
You should grab a copy of Richardson and Ruby's RESTful Web Services, which is a truly excellent book on how to design REST web services and explains things much more clearly than I could. If you're working in Java I highly recommend the RESTlet framework, which very faithfully models the REST concepts. Roy Fielding's USC dissertation defining the REST principles may also be helpful.
A media type should be seldomly created and time should be invested in making sure the format can survive change.
As you're relying on xml, there is no particular reason why you couldn't create one media type, provided that media type is described in one source.
Choosing ATOM over having one host media type that supports multiple root elements doesn't necessarily bring you anything: you'll still need to start reading the message within the context of a specific operation before deciding if enough information is present to process the request.
So i would suggest that you could happily have one media type, represented by one root element, and use a schema language to specify which of the elements can be contained.
In other words, a language like xsd can let you type your media type to support one of multiple root elements. There is nothing inherently wrong with application/vnd.acme.humanresources+xml describing an xml document that can take either or as a root element.
So to answer your question, create as few media types as you can possibly afford, by questioning if what you put in the documentation of the media type will be understandable and implementeable by a developer.
Unless you intend on registering these media types you should pick one of the existing mime types instead of trying to make up your own formats. As Jim mentions application/xml or text/xml or application/json works for most of what gets transmitted in a REST design.
In reply to Darrel here is Roy's full post. Aren't you trying to define typed resources by creating your own mime types?
Suresh, why isn't HTTP+POX Restful?