Since all versions of Learning Tools Interoperability previous to 1.3 are deprecated, I am trying to find a way to (as a tool provider) support re-launches of the tool analogue to the ab-initio in Scorm. In other words, I want the learner to start my activity as if it were the first time they did so.
I am looking for a supported way to do this in LTI 1.3
In LTI 1.0 there was the lis_result_sourcedid on which I have seen implementations of above functionality. According to the migration guide this is deprecated for 1.3
Second possibility, to use the optional resource_link_id property which the consumer would set for a requested from scratch launch, I am told, suffers the same fate.
My question now is: is there a better route to implement an ab-initio resource launch (as a tool provider)?
I am doing a project about the topic desinging and implementing an M2M Application using OM2M. When I found some documentation in the internet, I know that the OM2M is defined based on the ETSI-M2M and OneM2M Standard. These two standards make me a bit confused about the similarity. Can anyone tell me what is the difference between these two standards, the ETSI-M2M standard and OneM2M standard?
Thank you so much!
I will try to help from the standard prospective, not in terms of the implementation
ETSI M2M was developed starting form 2009, and two releases were completed. In the meantime was identified the need to globalize the solution, so ETSI and its members approched other companies and other Standard Organizations to build a common project, and this is today oneM2M.
It is worth to remember that oneM2M is not a new Standard Organization, it is simply shared Partnership Project among existing organizations to merge the efforts and the expertize to provide better specifications.
Technically speaking, the principles are the same, the key Resources are still Applications, Containers and Access Rights (ACP in oneM2M). And the principle of separation of the semantic treatment from the platform is still the same.
So de facto Release 1 of oneM2M is a sort of "Release 3" of ETSI M2M. But be careful, they are not backward compatible.
Being practical, I would suggest you to look directly at Release 1 and 2 of oneM2M. A lot of improvement has been added by the different partners making it more easily usable.
In particular Release 2 finalizes the semantic interworking framework to be build around the platform, providing inter technology interworking and data sharing.
I hope I was usefull.
Enrico Scarrone,
Telecom Italia - TIM
ETSI SmartM2M Chairman,
oneM2M Steering Comittee Vice Chair
We have found the limitations of Saxon-HE (see table) at the point of using Extensibility using reflexion and EXSLT extension function.
We are evaluating to purchase few licenses for the servers and development team members and we are short of time to evaluate every tool, considering that purchasing and distributing the license will also consume our time.
Apparently there is a previous version of Saxon called Saxon-B that saxonica is not longer maintaining but it claims to support Extensibility using reflexion and according to this Q&A supports EXSLT too.
My question is, could we stick with Saxon-B (an open-source solution) for those features mentioned or should we purchase those licenses?
Finally I am replying myself.
We have given a try to Saxon-B during last few days and it works perfectly for the needs we have (mentioned in the question). We have not found any minor/major bug so far.
Thanks Saxonica team for keeping available as open-source the Saxon-B version.
Edit: Saxon-B is no longer compatible with Java 8 and above.
I'm figuring that CORBA is considered a legacy technology that just refuses to die. That being said, I'm curious if there are any known standards out there that are preferred (and are also as platform independent.)
Thoughts? TIA!
Many organization are moving to WebServices and the open standards relating to them (HTTP, WS-*) as alternatives to Corba.
This article provides a comparison of the two technologies and offers some recommendations on when to use which.
If you really care about platform independence and protocol standardization - then the WS-* standards are something to look into.
There is now a state of the art modern CORBA implementation using C++11, TAOX11. This uses the new IDL to C++11 language mapping. For TAOX11 see the TAOX11 website. TAOX11 is supported on a wide range of platforms and compilers.
I have recently tried Google Protocol buffers, they seem rather similar to CORBA by design (some kind of IDL with compiler, binary compact messages, etc). It is probably one of the many possible successors.
Web services are good for the right tasks but creating and parsing messages needs more time and text based messages are more bulky than binary ones. REST API with JSON looks like a good solution where binary protocols do not fit well.
ICE from ZeroC aims to be a "better CORBA".
Unfortunately their licensing terms are crap (at least last time I checked with them), as they do not sell developer licenses but only (roughly) per-installation terms.
It is offered via GPL license too, if you can live with this.
What are the advantages of using Apache CXF over Apache Axis and vice versa?
Keep in mind, I'm completely biased (PMC Chair of CXF), but my thoughts:
From a strictly "can the project do what I need it to do" perspective, both are pretty equivalent. There some "edge case" things that CXF can do that Axis 2 cannot and vice versa. But for 90% of the use cases, either will work fine.
Thus, it comes down to a bunch of other things other than "check box features".
API - CXF pushes "standards based" API's (JAX-WS compliant) whereas Axis2 general goes toward proprietary things. That said, even CXF may require uses of proprietary API's to configure/control various things outside the JAX-WS spec. For REST, CXF also uses standard API's (JAX-RS compliant) instead of proprietary things. (Yes, I'm aware of the JAX-WS runtime in Axis2, but the tooling and docs and everything doesn't target it)
Community aspects and supportability - CXF prides itself on responding to issues and making "fixpacks" available to users. CXF did 12 fixpacks for 2.0.x (released two years ago, so about every 2 months), 6 fixpacks to 2.1.x, and now 3 for 2.2.x. Axis2 doesn't really "support" older versions. Unless a "critical" issue is hit, you may need to wait till the next big release (they average about every 9-10 months or so) to get fixes. (although, with either, you can grab the source code and patch/fix yourself. Gotta love open source.)
Integration - CXF has much better Spring integration if you use Spring. All the configuration and such is done through Spring. Also, people tend to consider CXF as more "embeddable" (I've never looked at Axis2 from this perspective) into other applications. Not sure if things like that matter to you.
Performance - they both perform very well. I think Axis2's proprietary ADB databinding is a bit faster than CXF, but if you use JAXB (standards based API's again), CXF is a bit faster. When using more complex scenarios like WS-Security, the underlying security "engine" (WSS4J) is the same for both so the performance is completely comparable.
Not sure if that answers the question at all. Hope it at least provides some information.
:-)
Dan
Axis2: More ubiquitous on the marketplace, supports more bindings, supports other languages like C/C++.
CXF: Much easier to use, more Spring friendly, faster got support for some WS-* extensions.
One more thing is the activity of the community. Compare the mailing list traffic for axis and cxf (2013).
Axis user 50-100 mails per month
CXF user 400-500 mails per month
So if this is any indicator of usage then axis is by far less used than cxf.
Compare CXF and Axis statistics at ohloh. CXF has very high activity while Axis has low activity overall.
This is the chart for the number of commits over time for CXF (red) and Axis1 (green) Axis2 (blue).
The advantages of CXF:
CXF supports for WS-Addressing, WS-Policy, WS-RM, WS-Security and WS-I BasicProfile.
CXF implements JAX-WS API (according by JAX-WS 2.0 TCK).
CXF has better integration with Spring and other frameworks.
CXF has high extensibility in terms of their interceptor strategy.
CXF has more configurable feature via the API instead of cumbersome XML files.
CXF has Bindings：SOAP,REST/HTTP, and its Data Bindings support JAXB 2.0,Aegis, by default it use JAXB 2.0 and more close Java standard specification.
CXF has abundant toolkits, e.g. Java to WSDL, WSDL to Java, XSD to WSDL, WSDL to XML, WSDL to SOAP, WSDL to Service.
The advantages of Axis2:
Axis2 also supports WS-RM, WS-Security, and WS-I BasicProfile except for WS-Policy, I expect it will be supported in an upcoming version.
Axis has more options for data bindings for your choose
Axis2 supports multiple languages—including C/C++ version and Java version.
Axis2 supports a wider range of data bindings, including XMLBeans, JiBX, JaxMe and JaxBRI as well as its own native data binding, ADB.
longer history than CXF.
In Summary: From above advantage items, it brings us to a good thoughts to compare Axis2 and CXF on their own merits. they all have different well-developed areas in a certain field, CXF is very configurable, integratable and has rich tool kits supported and close to Java community, Axis2 has taken an approach that makes it in many ways resemble an application server in miniature. it is across multiple programming languages. because its Independence, Axis2 lends itself towards web services that stand alone, independent of other applications, and offers a wide variety of functionality.
As a developer, we need to accord our perspective to choose the right one, whichever framework you choose, you’ll have the benefit of an active and stable open source community. In terms of performance, I did a test based the same functionality and configed in the same web container, the result shows that CXF performed little bit better than Axis2, the single case may not exactly reflect their capabilities and performance.
In some research articles, it reveals that Axis2′s proprietary ADB databinding is a bit faster than CXF since it don’t have additional feature(WS-Security).
Apache AXIS2 is relatively most used framework but Apache CXF scores over other Web Services Framework comparatively considering ease of development, current industry trend, performance, overall scorecard and other features (unless there is Web Services Orchestration support is explicitly needed, which is not required here)
As per my experience CXF is good in terms of configuring it into Spring environment. Also the generated classes are simple to understand. And as it is more active, we get better support in comparison to AXIS or AXIS2.
Another advantage of CXF: it connects to web servers using NTLMV2 authentication out of the box. (used by Windows 2008 & up)
Before using CXF, I hacked Axis2 to use HTTPClient V4 + JCIFS to make this possible.