My company is trying to figure out how to turn our current camera line into ONVIF compliant cameras.
What I've found is the specification documents and a bunch of WSDL files. But everything I've seen so far appears to set up "the client side" of things.
I'm trying to create a middleware service so that our existing cameras can become ONVIF supported.
Are the WSDL files used for both a client and a device?
How do companies program ONVIF compliant cameras? Our's are PTZs, would the PTZ WSDL be what I'm looking for?
How does one start the service device side. Although the specification covers everything it isn't written well for new developers of the standard.
Please help me figure out how I would turn my embedded linux camera in c++ into an ONVIF compliant camera. Do developers use the WSDLs to achieve this?
Thank you!
well one of the most common ways to implement ONVIF is via the gSoap library, it has a very vast guide regarding both client and server use cases. You should go through the server side documentation to get a glimpse of how it works. From a very generalized point of view - it has a wsdl2h tool that takes a set of WSDL files and generates stub code (mostly parsing and I/O code that takes care of creating structure representations of the request data) for you, then using another gSoap tool called soapcpp2 you can generate C/C++ client/server objects (I've worked only with client side, so I guess the guide mentioned above is the best way to understand how to build a server using the generated objects). Then you can host a service and interact with the requests from the camera through this C/C++ object abstraction, which should be quite easy. All the request xmls are deserialized to object instances, and you can just look at the needed fields, create an instance of the needed response object and send it back. At least I've been using gSoap so far for client requests to ONVIF cameras and I'm quite satisfied. Here is a small tutorial from the maintainers of gSoap on how to deploy a simple service.
That being said, I've seen cameras that don't use gSoap or any other high level framework and just parse the request content with any common xml parser and have response string templates that are formatted with the needed values and sent back - if your camera is not very complex this might work, but it depends on your needs. Feel free to ask any follow up questions, at least for me ONVIF was quite a spiders web when I started.
Related
I've been assigned a small project and directed to use Mirth Connect as part of the solution. We currently do not use Mirth but because we have an upcoming project that will require an interface engine, I was asked to use it for this project so I can gain experience with it. However, I think it's a poor suggestion for this project; I also know my boss would not want me to implement something that adds unnecessary complexity just for the sake of learning.
With that said, I want to make sure I have valid reasons for suggesting that Mirth Connect should not be used for this project. Neither of us know much about it, but I think he's been convinced it is the end all solution for all things interface/webservice related. I appreciate any input I can get from those of you who have more experience with the product than I have.
This is a very simple project in that we have a client needing to make a handful of requests into our system from there's in order to retrieve and update data. For example, they will make a request to get patient demographics, to add an admission for a patient, a request to get a list of possible care settings from our application, etc. For this project we will not use HL7 but a set of predefined XML messages.
Both the client's application and our application reside on the client's network.
They do not want to build any services of their own, so the services we build need to handle all of the work. The results returned in response to their calls to the services will be returned as XML.
There are no plans to integrate any other applications with theirs or ours in the foreseeable future.
It seems to me the best option would be for us to build a standalone web service that would take their request and send back an XML response. I just don't see any reason to include Mirth Connect in the picture (other than for learning but that can be gained in other ways).
What are your thoughts? Is it true that the interface engine is not a good choice if the client wants to receive data from our system without having a receiving mechanism on their end? In other words, they want to make a web service call such as GetCareSettings and to get a response back with an XML representation of all the possible care settings in our system. It seems to me they would need a web service on their end for Mirth to use as a destination to send the results. All Mirth is going to send back is an ACK message, correct? (Unless of course it wrote the data to another webservice on the client end, which they have said they do not want to do.)
Thanks for taking the time to read this. I hope my lack of knowledge and understanding of Mirth Connect and the use of interface engines hasn't made this question difficult to answer.
From what I understand, Your client appears to be either a Lab or a third party service vendor, who will take inputs from your application like patient demographic charts, appointments, provider details etc. Basically he wants to query your application.
A) HL7: It has the capacity to handle query request and response with demographics. I am assuming that you have done you might be knowing about QRY messages.
B) XML/webservices/SOAP:still provides a viable solution, a little more concrete and can be expanded to Handle custom request like GetCallSettings, or may be any other. The vendor is not just interested in fetching patient related data but also other inputs for which HL7 might not be enough.
If we talk about approach, then its a professional advice to use an interface engine. It is not limited to just using mirth connect, you can also use Iguana if you want. A good reason which comes instantly to my mind is that an engine gives you an advantage while troubleshooting, support and maintenance activity.
Your Webservice responses can be handled easily by HTTP sender connector type and through RESTful webservices.
The engine is also capable of handling large volumes of request and responses at the same time, which in case is not required right now, but I think will be the condition later on. Your source in the channel shall change to an Webservice Listener.
Another good approach is to do away with XML and use JSON for handling request and responses, a much more light weighted than XML, to save your overhead with the network. We are doing some similar work, but we are sending request to a webservice through JSON.
Overall, Mirth is there to make your life more easier.
Good Luck!
I am looking for a clean way to add service oriented access to an existing GWT application (client + RemoteService based server). The thing is that all the services are already in place, described by the #RemoteServiceRelativePath notation. It would be nice to be able to actually add the #WebService notation and have access to them both with RPC and XML/JSON/..
The real problem is that extending a current application to support other clients than the existing GWT one is a bit hard because of the GWT obfuscation. This also leads to an unneeded coupling between client and server since they both need to be deployed at the same time, because of the .gwt.rpc generated files.
I would like to reuse the existing RemoteService interfaces to define web services and connect to them with new clients via a plain-text protocol. Additionally, I would like to port the existing GWT client to the same protocol.
Is it possible to do this while using the same interfaces and implementation just by annotation?
What would be the best way to port the existing client to use a plain text protocol, RequestBuilder? Or just inject a new serialization implementation that does xml / json?
I don't even know where to start with this, this is why I'm asking. Maybe it is better to rewrite all the services and port everything at once but it will break everything until this is finished.
We've had a different approach since GWT the coupling of GWT between server and client side is not all bad but gives you a nice integration and you don't have to think too much about communication issues etc.
For that, our application had a frontend tier which consisted of the full gwt stack (client + server-coupling) and on the server-side, we connected via spring and RPC to the service layer.
On that way you can use on the benefits of spring and you don't loose the comfort of GWT.
But I Would like to hear if somebody already has gone other ways ;)
This is rather late and GWT is not the wonderchild it once was. However, for the sake of tying loose ends here's the solution I went for:
create a Java generator that parses all model (shared client/server classes) files through reflection and generates a Java file that reads/writes SOAP objects
bootstrap the above into a generic Java handler that handles native objects + array, sets, maps
write the service that can deal with the generated XML from the files above
It sounds a bit terse and a bit complicated but it 'only' took ~1 month to write the code to reliably convert >200 objects to their XML representation, automatically. The added benefit is that it allows mocking and cross-platform clients/servers.
As a summary, the generated code creates new methods 'fromXML' and 'toXML' that feed the fields that are public members (get/set) in the given class. So, given MyClass it would generate the MyClassSerializer and MyClassDeserializer Java classes that implement those SOAP-specific methods and also publish themselves to a 'dispatcher'. So whenever that dispatcher sees 'MyClass' it would know where to get the ser/deser functions from.
(Sorry for my english)
First: I have an application created using C++ (this is for performance needs), this application uses an image to make some processing and returns a simple answer (1 or 0 ).
Now I need to expose this application from a webservice.
I think to create a webservice using Rails, but I don't know if it's possible using rails to call the C++ process..
The idea is to use the webservice to get an image sent by a client, pass this image to the C++ application and return (using the webservice) a message to the client, based on the result of C++ application.
Is this possible?
Any example or guideline?
Thanks in advance
EDIT: Solved using Thrift thrift.apache.org
I read something about Thrift .. but i think maybe i can't use to solve this problem (maybe) ..
The idea is use a mobile application (iOS and/or Android) where the user can upload an image to the service. The service take the image and make some image processing, this part (the processing) was written with C++ as standalone application that receive an image and return a message, so when the processing is done, the service receive the result (a message) from the processing app and return this to the mobile application.
So.. is this possible with Thrift (if so, i need to read more)? o i need to use something else?
Thanks in advance
I have never done that before, but I think you should take a look at Thrift which was initially developed by Facebook and allows you to make multiple languages work together via RPC calls.
Thrift allows you to define data types
and service interfaces in a simple
definition file. Taking that file as
input, the compiler generates code to
be used to easily build RPC clients
and servers that communicate
seamlessly across programming
languages.
I encourage you to search on Google with the following keywords : thrift C++ rails webservice etc.
I have existing video streaming application which is based client server technlogy.
Existing system is as follows There is data center, client application and gateway. camera is connected with gateway and gateway is connected with data center.client request video to data center and datacenter get it from gateway.
Now we want to use p2p technology here and want to have direct communication between gateway and client.we want to use RTMFP .for client we can use flex, but the existing gtateway code and business logic is written on c++.
Is there any way around to call c++ code from flex.
Thanks
Hey,
Yes this is pretty much possible with flex 4,(ie. only if you are using a desktop application).From a web based swf, running in a browser you cannot start running a C++ code.
I am assuming that you are developing a desktop app.To call a c++ code , you would need to do the things mentioned in the following example link.It is pretty straightforward.
http://www.adobe.com/devnet/air/flex/quickstart/articles/interacting_with_native_process.html
Or, incase you have access to the C++ code, then you can use a few already built classes which allow C++/Flex interaction.
http://anirudhs.chaosnet.org/blog/2008.03.13.html
My company is planning on implementing a remote programming tool to configure embedded devices in the field. I assumed that these devices would have an HTTP client on them, and planned to implement some REST services for them to access. Unfortunately, I found out that they have a TCP stack but no HTTP client. One of my co-workers suggested that we try to send “soap packets” over port 80 without an HTTP client. The devices also don’t have any SOAP client. Is this possible? Would there be implications if there was a web server running on the network the devices are connected to? I’d appreciate any advice or best practices on how to implement something like this.
If your servers are serving simple files, the embedded devices really only need to send an HTTP GET request (possibly with a little extra data identifying the device, so the server can know which firmware version to send).
From there, it's pretty much a simple matter of reading the raw data coming in on the embedded device's socket -- you might need to only disregard the HTTP header on the response, or you could possibly configure your server to not send it for those requests.
you don't really need an HTTP client per-se. HTTP is a very simple text-based protocol that you can implement yourself if you need to.
That said, you probably won't need to implement it yourself. If they have a TCP stack and a standard sockets library, you can probably find a simple C library (such as this one) that wraps up HTTP or SOAP functionality for you. You could then just build that library into your application.
Basic HTTP is not a particularly difficult protocol to implement by hand. It's a text and line based protocol, save for the payload, and the servers work quite well with "primitive, ham fisted" clients, which is all a simple client needs to be.
If you can use just a subset, likely, then simply write it and be done.
You can implement a trivial http client over sockets (here is an example of how to do it in ruby: http://www.tutorialspoint.com/ruby/ruby_socket_programming.htm )
It probably depends what technology you have available on your embedded devices - if you can easily consume JSON or XML then a webservice approach using the above may work for you.