We are using Adobe LCDS 2.1 and thinking of Upgrading it to a higher version.. can someone tell me a brief Comparison of the LCDS versions available (3.1 , 4.1....) ????
The last version is 3.1 You need to read the documents from this url in order to understand what are the new features (the release is good but is not enough), and after that it would be good to try building a prototype (if you plan to use the data modeling for example) to see how they will fit into your current architecture.
I wouldn't do any upgrade unless there is a business reason (bugs, poor performance, luck of productivity) - for any product.
I don't know why you'd need a comparison for 'all versions' if you can only purchase the latest one. I suggest you look at the latest version's whitepaper so that you can see what's been added. The biggest thing IMO is better integration for all clients, different messaging protocols and well as much needed bug fixes (I remember 2.1 had some fairly obvious bugs).
Looks like the choice is "should we upgrade or not?"
I'd say it may also be worth considering what you're doing with LCDS -- if you're only using it for things like Flash Remoting, is it possible that you could go the other route and 'downgrade' the the open source BlazeDS? It has a lot fewer features, but might do what you need, and be a lot cheaper.
Here's a comparison of BlazeDS to LCDS ES2: http://www.adobe.com/products/livecycle/dataservices/compare.html
I'm not familiar with prior releases of LCDS, so I can't offer any better advice about comparing versions than the previous respondents. Basically: Check the release notes =)
Related
I've been looking at options for persistence when using RxSwift and Realm was looking attractive due to it's relative simplicity and the availability of some extensions in the community repo.
Unfortunately although I can get Realm and RxSwift working nicely in Xcode 8b6, things of seriously wrong as soon as you try to connect them together as RxRealm does not currently compile (there seems to be more going wrong with it than the Grand Renaming as far as I can tell).
Is there a workaround that is reliable? I can't believe for a moment that there isn't, I just can't find a resource at present. I was thinking of converting the Result object into an Set or Array and making this Observable but. I'm not sure if the contents (Realm Objects) are going to be handled correctly. Knowing my luck, I suspect not!
There's a Pull Request towards the RxRealm project adding Swift 3 support: https://github.com/RxSwiftCommunity/RxRealm/pull/26
I suggest you try using that.
More generally, targeting an Xcode beta will by definition give you a less stable software ecosystem, since no one is submitting apps with that and it's a moving target (often with weekly breaking changes). So if you want stable software, use stable tools. Realm and RxRealm both support Swift 2.2 quite well, so using that will give you the best experience.
(Possible alternatives being Adobe's CF, Bluedragon, Railo, etc.)
What would you use for Coldfusion middleware if you had the following requirements and major considerations:
Flex front end (w/remoting via AMF)
Free (or low cost enough for a non-profit side project)
Large enough community and resources online to find assistance when needed
Maturity (and confidence that a particular version of CF isn't going to turn legacy any time soon)
MySql database
I think Adobe CF would tick all your boxes except your 'free' requirement. We use BlazeDS and Flex with it, it's mature, well supported and has a large friendly community. In short it works great.
However, in terms of the licence cost there is an argument that CF has a lower cost of ownership but if paying anything is a big no-no, then I'd look at Railo - it's pretty much up to CF 9 standard, it's got paid support if you get really stuck and it has some active forums.
Hope that helps.
PHP is an another alternate for a back-end. It talks to MySQL and can do remoting with Flex. It does require a bit of configuration to get remoting work, but it does work.
Has anyone done a thorough comparison of AppFabric and NCache or AppFabric and ScaleOut? We are currently looking to implement either AppFabric, NCache or ScaleOut for distributed caching in geographically distant locations and I would like to know anyone's thoughts who has compared them side by side. I appreciate that many people use one or the other and tell me why their chosen solution is great but I am really looking for a comparison of the two products. Such things as what does AppFabric not do or not do well (if anything), partially from a features point of view but also from developer's point of view. Is working with one compared to the other nicer, easier, more flexible, more powerful, etc.
There are plenty of lists of features which I can compare but am really looking for a comparison from someone who has perhaps been in a similar position to us and has performed the evaluation that we are about to launch into which will give us some food for thought whilst we do so.
Thanks in advance.
Here is a good comparison between the features of NCache and Appfabric
As a more mature product, NCache has a number of more advanced caching features that Velocity/AppFabric doesn't have -- check out their website for some "marketing" comparisons.
However, we have had a number of issues troubleshooting NCache and obtaining more visibility from their support/engineering team into certain behaviors of their application. Given that, plus the cost compared to AppFabric, I'm not sure I would recommend NCache at this point -- at least, we're in the process of re-evaluating our caching provider.
My frustration/complaint with Velocity/AppFabric is the the sluggishness in the release schedule. Seems like they were in CTP forever. Certainly Microsoft can crush NCache on price alone. There are now players like NorthScale (memcached) that are entering the fray which I think are also worth considering. A lot depends on what you want to use caching for in your application.
The most used one is Memcached. for sure.
we currently are starting using AppFabric as our dcache, as it easily integrates into our .net solutions, and has a good feature set, that we want to use.
if you just do basic dcaching, make a abstraction of caching itself (or use the .net 4 System.Runtime.Caching.ObjectCache) so you are safe if you want to do changes. or want to stress test more solutions.
Also, depending on your App architecture, think of using more entities/instances of your DCache, as different parts maybe favor different systems.
It is looking like we will need more advanced functionality than what Velocity provides so it will be either NCache or ScaleOut. There are good reasons for both, we just need to sort through these. We do not have Unix resources so memcached is out. I know there is a Windows port but colleagues who know memcached tell me that it is somewhat buggy and if you are going to bother going down the memcached path, you really should make the effort to go for the Unix version.
Some might argue that this is a biased comparison, but it's worth reviewing..
http://www.alachisoft.com/comparison/ncache-vs-appfabric.html
PDF has the full review.
http://www.alachisoft.com/downloads/comparison/ncache-vs-appfabric.pdf
I work in a shop that is mostly .NET based, and we're trying to pick out a content management system to use. This means we mostly likely won't be able to use any of the common open source CMS projects (Plone, phpNuke, anthing not based on .NET, etc.).
Since I'm a huge usability nerd (just finished reading The Design of Everyday Things by Norman), I've been looking at them from that point of view. Frankly, I haven't been too impressed. This quote sums it up:
Most open source content management software is useless. The only thing worse is every commercial CMS I’ve used. - Jeffrey Veen
Here's a short list of our requirements:
Has to be .NET based
Prefer open source or on the inexpensive side
Limited feature set (we don't need too many features and they make things harder to use)
Does need Active Directory integration and robust permissions
Should be focused on web standards and usability
I know it's probably an impossible feature list, but are there any content management systems that kinda sorta look like they might not suck more than a Dyson?
Edit:
Here's the current situation:
I'm going to push for N2. I've got Active Directory integration working well (I even wrote a custom role provider). The only thing missing is workflow functionality. Hopefully I can get something going with that since it's the last sticking point. The N2Contrib project might provide a starting point if I can figure it out.
I would still love to check out Stencil CMS if/when it gets off the ground.
One of my co-workers was trying to get Umbraco going but wasn't having much luck.
Thanks for the help!
Self-plug is lame, but what you're describing is pretty much exactly what I am getting ready to release for $79 a pop. If you're still looking in a few weeks, take a peek. If you'd like, shoot me an email (rex#stencilcms.com).
I've heard both positive and negative feedback about Umbraco. A lot of people like Graffiti, but it's more blog-oriented than a full-blown CMS.
Check out N2 (http://n2cms.com/). I think that it covers most, if not all, of your requirements (I don't think it has Active Directory capability at this time). We are using N2 and I have really enjoyed how flexible it has been.
My company just completed a review of several commercial .NET-based CMS/portal platforms and, while I can't reveal who was in them (thanks, NDAs!), I can tell you that IMO they all sucked very, very badly.
Good luck on your search. I'll keep an eye on this thread in the hopes that there's something we missed.
We had a similar set of requirements and chose Telerik Sitefinity. It's got it's faults but overall I've been happy with it so far.
Unfortunately Jeffery speaks the truth. Which is probably why I build a new custom cms from the ground up every few years. Basically, the motivation for "boxed" CMS packages is to have every feature on earth and be everything to everyone and therefore do nothing particularly well for anyone. With the feature bloat comes the usability nightmares. Unless you start customizing and then you usually end up forking the project and losing the advantage of community updates.
Kentico CMS according your list:
Has to be .NET based
It's .net based, .NET Framework 2.0 or later
Prefer open source or on the inexpensive side
Free edition which can be used for commercial purposes is available, paid license starts at $750, source code is an option
Limited feature set (we don't need too many features and they make things harder to use)
Many built-in modules/features, anyway they can be easily disabled to keep the UI simple to use
Does need Active Directory integration and robust permissions
AD, Forms and Live Id! Integration
Should be focused on web standards and usability
UTF-8 Support including RTL languages, WAI Compliant, XHTML Compliant, XML, XHTML, HTML, XSLT, CSS.
Instant on-line demo or download available at:
http://www.kentico.com/Download.aspx
My company (a large organization) is developing a "road-map" for evolving their rather old, tangled confederation of systems to an SOA model. A few people are pushing hard for using Websphere Integration Developer and Websphere Process Server as the defacto platform for developing future applications...because they feel IBM is a stable vendor, the tools are made for the enterprise, they drank the "business agility" BPEL kool-aid, etc.
Does anyone have positive or negative thoughts on this platform? Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
My experience with the IBM Java tool set is pure pain. Days to install lots of different versions of different components all incompatible with each other, discover a bug in component A get told to update to see if it fixes, updating component A breaks component B and C, get told to update these etc.
I find Eclipse with out the IBM extensions far more stable and quicker and provides more features (as its stable versions are a couple releases ahead of WID/RAD).
I would advise against going the IBM way for development tools. As for process server I have less experience but the people in my team using it seemed to enjoy it as much as I enjoyed WID. not a lot.
So far I havent been impressed by any tools with the "SOA" and/or "BPM" labels on them. My "roadmap" would be very very iterative to see some results with the archetecture as fast as possible while trying to grab some of the easy fruits. That way you gain your feel for what works for you and your people.
I would never let any vendor push me anywhere in the "scuplturing" of the architecture.
I agree with other users complaining about WID. The only reason we are using WID is that a decision was made a while back to use IBM products across the board by our sales department.
That's right, our sales department made the decision to use IBM products.
Development has been painful and frustrating. We have lots of stability problems with Process Server, sometimes it doesn't want to start or shutdown properly. Yeah you can easily draw processes in the IDE, but most any toolset provides that functionality these days. It is nothing special or unique to WID or IBM. IBM is a few iterations behind mainstream.
There are plenty of open source implementations out there that offer great support. Checkout JBoss or RedHat, they are pretty good. If that doesn't float your boat, you can always use Apache tools.
Walter
Developers don't choose WID, WMB, or WPS. Managers do, because IBM is a "stable vendor".
Look at JBoss, or K.I.S.S.
WID/WPS is actually pretty simple. The original intention was for analysts and business people to "compose" services (DO NOT LET THEM DO THIS!) so the UI is simple and easy.
Most of the work will be in defineing and implementing the back end services which depending on the platform will mostly involve wrapping existing code in SOA service.
The most important thing to bear in mind is that SOAP is technoligy and SOA is an architecture and a state of mind.
There is a zen to a succesful SOA implementation. Its all about "business services", if you have a service that you cannot describe to a business user in less than six words you have done it wrong! Ideally the service name alone should be enough to describe the functionality of the service.
If you end up with a service called "MyApp.GetContactData" described as "get name, addresses tel fax etc." then you are there. If You have a service called MyAppGetFaxNoFromOldSys" described as "Retrieve current-fax-nmbr from telephony table in legacy system" you are doomed!
Incidently most of the Websphere tooling for WS* is pretty nice. But I would recommend the very wonderful SAOPUI tool from http://www.eviware.com which is very good for compsing/reading WSDL based messages and also function as a useful test client or server.
Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
As a Developer, I find the tools at varying levels of being bug free. 6.0.1 was a pain, 6.2 is so much better. But once you develop with the tool, there is minimal effort to maintain it. I develop in hours what java developers take days to do. It is also easy to maintain as changes can be made very quickly. I cannot answer your question from the perspective of an architect or a Manager but i would agree with comments of some others here.