Is there a convention for structuring the source code when there are multiple versions of the same web service in the same source code trunk or branch?
Here's our situation.
We version our web services by including the version number in the wsdl URL like this:
url/project/1.0/WebServiceA?wsdl
I'm going to deploy version 1.1 of WebServiceA along with version 1.0 so users of 1.0 don't have to change anything. Version 1.0 and 1.1 of WebServiceA will have their own seperate Java classes.
I want to deploy both versions in the same .war file. (We could adopt a policy of only one version of a web service in the .war and deploy other versions in their own .war. This would result in an increased number of.wars to deploy when we get several versions of several web services. I would prefer to deploy only one .war.)
I'm thinking we should just use a seperate package structure for the various versions:
com.company.dept.ws.WebServiceA (version 1.0)
com.company.dept.ws.v11.WebServiceA (version 1.1)
com.company.dept.ws.WebServiceB (version 1.0)
com.company.dept.ws.v11.WebServiceB (version 1.1)
com.company.dept.ws.v12.WebServiceB (version 1.2)
The Java classes under ws., ws.v11., and ws.v12. would be seperate Java classes.
Can you see any problems down the road with this convention?
If there is a tried-and-true convention for structuring the source code for multiple versions of web service code I'd like to hear about it before I make up my own.
Thanks.
Dean
Since you say you want these versions to all be "in the same source code trunk or branch" I think part of the answer depends on the source control system you're using, and whether or not you ever plan on fixing bugs in older versions.
If you ever want to fix bugs in older versions you'll want the ability to integrate changes forward or backwards between the different versions. For example, suppose you discover a critical security problem that exists in versions 1.0, 1.1 and 1.2. You aren't going to want to fix it 3 times. Most source control systems will let you do that sort of integration between related branches. Some (like Perforce, and I believe also git, and probably a few others) will let you integrate changes between files even within a branch. (in fact, Perforce's concept of a "branch" is just a convenience for recording inter-file integrates)
So you need to think about whether you'll need to make these sorts of multi-version fixes, and if so, can your sorce control system handle intra-branch integrations. If not, then you might be better off using a separate branch for each version.
Related
I have found myself trying to upgrade Apache Superset from version 0.35 to 0.37 or soon 0.38 as is about to get released.
Our version of superset was heavily modified, from code added to the default superset files to creating new one. We are talking about hundreds of files changed with 1 to 1000+ added lines Given this fact the upgrade fails with a lot of conflicts, something that was expected.
I would like to find a way to make the upgrade to the newest version and keep our modifications as well as making the process easier for future upgrades.
So far (until 0.35) we manage to upgrade to the newest version and solve the conflicts but it became more and more difficult.
The modification were from the front-end jsx files to css to python files.
What I tried and failed:
make a patch file using
diff <0.35 files> <our modified 0.35>
and apply the patch to 0.37 but this did not work as the files are very different between versions and the line numbers changed drastically as well as the folder structure is different in the newer versions.
Is there any way to keep our modification separated and make the process easier for future upgrades?
The more you fork and has the main branch evolves, the harder it gets to upgrade, that is simply to be expected when forking software. Given current high velocity and general pace of change in the Superset code base, and the pre-1.0 status of the software, you can pretty safely assume that any work you do in a fork is likely to be fully revisited every time there's a major upgrade.
The way you prevent that is:
extending only the things that were designed to be extended (plugins, extensions, configuration hooks)
contributing your changes back into the main branch
Many of us have learned that the hard way in our careers. The typical realization is that overtime, the progress in the main branch offer much more value than your customization, and upgrading and applying your customization becomes hard or simply impossible. The usual solution is to look into your customization and identify the really important ones, and try to contribute them back so that they can evolve with the software.
My goal is to write a client for onvif ptz cameras such that I can view data (pan/tilt/camera/lens values), send control commands, and view the video. I was somewhat successful using C++/gsoap with an Axis camera. Then I tried it with a camera from a different company and it didn't work. I believe the problem is because that other camera uses a different version of "something" - I'm not sure if it is a different schema, different profile version, a different version of ONVIF, or a different version of soap.
I want to make a client that supports any ONVIF camera, or at least the vast majority of them. I don't want to have to say "Sorry, your camera is 1 year old and that protocol is no longer supported".
I was using onvifcpplib, which seems to have been abandoned for a bit and now its gitbhub project forwards to rapidonvif which looks completely different.
For almost two days now I have been researching ONVIF and trying to make heads or tails of what this will take. If I go here: https://www.onvif.org/profiles/specifications/specification-history/ I see no less than 18 different spec versions!
This version seems to affect wsdl file verions, so for example I can see there is a version 1.0 for the media wsdl here: http://www.onvif.org/ver10/media/wsdl/media.wsdl ... but there is also a version 2.0 of the same file here: http://www.onvif.org/ver20/media/wsdl/media.wsdl .
And I don't think they are backward compatible. But I cannot find one for 2.6 - so:
http://www.onvif.org/ver26/media/wsdl/media.wsdl does not exist.
And this is just one of 15 wsdl files that I need to use gsoap with.
I'm really confused on what to do. Is there an ONVIF expert out there that can help me with some of these questions?
Question 1) Is there a master list or something that tells me as a client writer which wsdl versions I must support and which ones are not backward compatible?? Trying every possible permutation of all 18 versions with all 15 wsdl files would take forever! Some of them might be backward compatible and others not - how do I know which are which?
Question 2) On top of the network interface specifications, there are different profile versions. Are some of these not backwards compatible as well?
Question 3) On top of the network interfaces specifications AND profile versions, there are multiple versions of SOAP - 1.1 and 1.2. Do I need to worry about some cameras using 1.1, or does ONVIF always use 1.2?
Question 4) How am I supposed to compile with multiple versions using gsoap? If I use wsdl2h followed by soapcpp2 for version 1.0 and 2.0 of the ptz wsdl for example, and then try to include both into the same project there will be conflicts. I don't want to say to users... sorry, but you will have to research and find out if your camera uses ONVIF version such-and-such so you have to use this other executable or plugin.
Question 5) Even if I was able to get multiple versions to compile within the same app, how will I know which version to use when connecting to a particular camera? Do I query the camera and say "Which version are you? OK, you're using this particular version and profile, so I'll use this set of commands"?
Question 6) With so many variations and versions, how on earth can one be expected to write an ONVIF client that supports most cameras without spending months to years on development? Is there any third party library or sdk that abstracts all this versioning voodoo?
Thanks for any help you can provide!
1+2) A client can support whichever set of wsdl documents it chooses to, because only additions are made and no changes to types and operations are made. If I remember correctly, this is specified in the Core document.
3) Only SOAP 1.2 is used as far as I am aware.
4) I don't have a good answer, I wrote my own C++ code generator which dealt with these problems.
5) GetServices will return the version of the service the device provides.
6) It's not that bad... I think most features can be determined one way or another. There is definitely a lot of confusion prior to version 2.0. The main issues I have found are with implementations of the devices not following the specification.
My question is not about best practices for REST API URI design.
I've decided for myself, that i'm going to use the following approach:
https://theserver.com/api/v1/whatsoever
I'm much more curious about how to design the actual sourcecode in advance to easily extend the API with more versions.
Let's assume we've used a classic MVC-Framework for your favorite programming language. Our API works fine but we want to add & change functionality that is not backwards compatible. We did think about a nice URI design, but didn't think how our code should look in order to work nicely with different API versions. Crap.. What now?
Question: How should the source code for a versionable REST API look like?
Nice to have:
Not mixing up the different versions
Still best use of DRY
Don't reinvent the wheel over again
will be extended
Possible answers i can think of:
Same project - different Namespaces & Subfolders
Namespace: namespace App\Http\Controllers\v1\Users;
Folder: {root_folder}\app\Http\Controllers\v1\Users\UserLoginController.php
Different projects
Point https://theserver.com/api/v1/whatsoever to project 1
and https://theserver.com/api/v2/whatsoever to project 2
Here is my logic: - First of all we need to answer to the question "Why we need versioning?"
- If we can extend our API in way it is backward compatible, in that case we don't need versioning (All applications and services are going to use the same API and no changes are needed).
- If we can not can not provide backward compatible API in that case we need to introduce next version of our API. This will allow all applications and services to migrate smoothly to new version while to old one is working. After a time period (one year), first version can be obsoleted and stopped.
So based on the answer above I would keep API versions in separate branches in my repository. One codebase, multiple branches for each version. First branch corresponds to v1 which is stable and receives only fixes. No active development here. Second branch corresponds to v2 which has all new features.
I am cleaning up a build system for a product that uses Jetty. Currently the project has
javax.servlet.jsp:jsp-api:2.1
as a dependency. Given that I am using Jetty for my project I suspect using
org.mortbay.jetty:jsp-api-2.1:6.1.5
would be the better option. Am I right/wrong? Can they be used interchangeably? Does jsp-api-2.1 leverage a different implementation? Or is it simply a repackage if jsp-api to assert compatibility with Jetty?
I've been trying to find information about this on the web, so far nothing has come up.
Update: Seems like org.mortbay.jetty:servlet-api-2.5:6.1.5 and javax.servlet.jsp:servlet-api:2.1 have the same relationship.
Jetty has a long and colorful history with jsp, having no jsp implementation of our own we have leveraged other implementations often, judging by the version numbers your looking at those are very old versions where we were maintaining patches on top of the glassfish jsp implementation. I think it was a patch for supporting logging in jetty and then a bug fix or three.
Now a days we have been using the jsp artifacts from the java.net project which was spun out from glassfish a while back. However that doesn't seem to be tracking bug fixes very regularly either so we are kicking around trying the jasper implementation in tomcat.
Back on your question, the jsp-api artifacts are typically just repackaged artifacts since the api doesn't change frequently. We historically rebundled them to keep them paired with the patched implementation.
Now, you are obviously using a jetty-6 setup since your still using org.mortbay packaging but jetty6 and jetty7 are both servlet-api 2.5 so you might be able to get away with using the jetty7 jsp setup, we have a handy pom that declares these artifacts here:
http://central.maven.org/maven2/org/eclipse/jetty/jetty-jsp/7.6.5.v20120716/jetty-jsp-7.6.5.v20120716.pom
These are glassfish bundles as well, repackaged and made into osgi bundles in the process so they can be used with jetty in osgi environments....they ought to work normally though, we package them in our jetty7 distributions.
I'm working on a project that needs a simple, lightweight event server (i.e. a server that passes events between different client applications implemented in Javascript). At first Node.js and Socket.io seemed like the perfect solution but the amount of dependencies and config involved took some of the shine off (see below for details on the project and why configuration is an issue). Is there some tested and reliable way to package all those dependencies into a single executable that can be run with no additional configuration? If not are there any good C/C++ Websockets libraries that could be combined with something like Mongoose to create a standalone executable?
Project Details
Basic use case:
A moderator turns on the server on their OSX machine.
A group of 10-20 users point their mobile devices to a site hosted on the moderator's machine
Communication ensues for the duration of the session (about an hour)
Basic requirements:
Simple setup: The moderator will not be a developer and may have little to no technical expertise. Anything that requires the terminal or fiddling with configuration files or package managers is a non-starter.
Unreliable Configuration: The moderator's machine will be used in a lot of different contexts and by a lot of different users. Therefore the system shouldn't rely on very specific or pristine settings (i.e. would like to avoid something with lots of dependencies that requires special environment variables to be set)
Performance and security are not a concern: The server will run locally with small number of trusted users for a short time so security and high performance aren't important.
Interesting question.
I know there are some C and/or C++ WebSocket libraries under development in the WebSocket community (mentioned on the IETF discussion list) if you want to go in that direction.
It might interest you to know that some parts of Node.js are actually written in javascript and compiled during the build process as built-in modules, but I don't know of any way to accomplish that for your own code short of hacking up the build.
Since this is OSX you could package Node alongside your own code and any modules, built against a static v8 library, in your .app. This would be a fairly tight coupling though not quite what you are asking for.
It's also possible to build your extension (or part of it) as a C++ module loaded by Node and v8.