I've just been chatting with a Microsoft MVP, and he told me that MSMQ is obsolete. Is this true? What's the infrastructure for SOA then???
Well, they released a new version (4.0) with Vista, and it's an explicitly available channel in WCF, out of the box, so I'd say no.
I've built new services based on it in the last six months, and there's no official MS documentation I'm aware of that says it's going away.
If you need reliable messaging, there aren't many good options. If you're already deep in database land, Service Broker may make sense, but otherwise... MSMQ
I don't think it's obsolete at all. Do a google search for MSMQ and WCF - you'll get lots of results.
Here is a good article:
http://www.codeproject.com/KB/WCF/WCF_MSMQ_Integration.aspx
Related
Is it possible to scale Axon Framework without Axon Server Enterprise? I'm interested in creating a prototype CQRS app with Axon, but the final, deployable system has to be be free from licensing fees. If Axon Framework can't be scaled to half a dozen nodes using free software, then I should probably look elsewhere.
If Axon Framework turn out not to be a good choice for the system, what would you recommend? Would building something around Apache Pulsar be a sensible alternative?
I think I have good news for you then.
You can utilize Axon Framework perfectly fine without Axon Server Enterprise.
Firstly, you can use the Axon Server Standard edition, which is completely free and you can check out the code too if you want.
If you prefer to get infrastructure back in your own hands, you can also select different approaches to distributing the CommandBus and the EventBus/EventStore.
For the CommandBus the framework provides the DistributedCommandBus for which two implementation are in place, being:
JGroups
Spring Cloud
I'd argue option 2 is the most ideal for distributing your commands, as it gives you the freedom to choose whichever Spring Cloud Discovery Service implementation you desire. That should give you the handles to work "free of licenses" in that area.
For distributing your Events, you can broadly look at two approaches:
Share the database, aka your EventStore, among all instances
Use a event message bus to distribute your event messages
If you want instances of your nodes to be able to Event Source the Command Model, you are inclined to use option 1. This is required as Axon Framework requires a dedicated EventStore to be able to source the Command Models from history.
When you just want to connect other applications to your Event Stream, option 2 would be a good fit. Again, the framework has two options in this area:
AMQP
Kafka
The only thing I'd like to point out on this part additionally is that the Kafka extension is still in a release candidate state. It is being worked on actively at the moment though.
All these extensions and their options should be clearly stated in the Reference Guide, so I'd definitely check this documentation out if you are gonna start an application.
There is a sole thing you cannot distribute though, which is the QueryBus.
There is an outstanding issue to resolve this, for which someone put the effort in to provide a PR.
After seeing how Axon Server Standard edition does it though, he intentionally closed the PR (with the following comment) as it didn't seem feasible to him to maintain such a tool at this stage.
So, can you use Axon Framework without Axon Server Enterprise?
Well, I think you can. :-)
Mind you though, although you'd be winning on not having a license fee if you don't use Axon Server Enterprise, it doesn't mean your production is gonna be free.
You'd be introducing back quite some infrastructure set up and production time to get this going.
Hope this gives you plenty of feedback #ahoffer!
My situation is that the Microsoft IIS app server and code in C# already exists.
The Web Services and contracts have been done in the .NET framework. My question is what open source Enterprise Service Bus is available to register the endpoint for sending messages to/from the services on the IIS app server? Can I have a Java-based ESB when my endpoint is written in a different language, C#?
I'm looking for an open-source ESB where I can deploy existing WSDL to register the Microsoft server endpoint and wondering if a Java-based ESB will work? What kind of issues would creep up? Is it better to match endpoint vendor type with esb vendor type?
Warewolf ESB is a GPL Licensed Open Source ESB based on the Microsoft Stack. You can download an installer from http://warewolf.io, or the source code from Github at https://github.com/Warewolf-ESB/Warewolf-ESB
Its very easy to work with, and is highly extensible. The development team are also very friendly and are quick to respond to the communities queries.
Since nobody else has chimed in, I guess I'll give it a go.
You'll see that most of the open-source service buses in .NET (NServiceBus, MassTransit, etc) stay pretty far away from WSDL - instead preferring to take a more message-centric approach.
Full disclosure, I'm deeply involved with NServiceBus.
Java-based ESBs tend to be more open to integrating more web-service-centric approaches.
The tradeoffs associated with introducing non-Microsoft technology in your production environment center around your operations team's familiarity with them. There's also the development side of things, but in my experience, that tends to be more minor in comparison.
Hope that helps in some small way.
Are there any essential differences between CouchDB and Couchbase?
I think there are some essential differences between CouchDB and Couchbase Server that need to be pointed out.
I will not write about the advantages of switching from CouchDB to the Couchbase Server because those are described pretty much everywhere (see The Future of CouchDB by Damien Katz or
Couchbase vs. Apache CouchDB
by Couchbase). Instead, I will try to enumerate features of CouchDB that you will not find in the Couchbase Server.
All of the names relating to CouchDB and Couchbase can be really confusing, so I've updated this answer, to begin with a brief explanation of the most important ones.
Names and confusion
There is CouchDB, CouchIO, CouchOne, Couchbase, Couchbase Server, Couchbase Mobile, Couchbase Lite, CouchApps, BigCouch, Touchbase, Membase, Memcached, MemcacheDB... all different and yet related in a way not at all obvious from the names alone.
First, there was CouchDB, a database created by Damien Katz, a former IBM developer. Its official name was changed to Apache CouchDB after it became an Apache project.
A company named CouchIO was founded to work on Apache CouchDB and later changed its name to CouchOne (by "its name" I mean the company name - not the database name).
CouchOne (formerly CouchIO) merged with Membase (formerly NorthScale) to form a new company called Couchbase. Membase (the company) developed Membase (a product of the same name). Membase was created by several leaders of the Memcached project and it used the Memcached protocol. After the merger of CouchOne and Membase, Couchbase continued the development of the Membase software and later changed its name to Couchbase Server.
Today I think most people believe that Couchbase Server is a new version of CouchDB but it is, in fact, a new version of Membase. It still uses the Memcached protocol and not the RESTful API of CouchDB. Meanwhile, CouchDB is still CouchDB, actively maintained and enhanced as an Apache project.
Now to the relevant differences:
Licensing
The Couchbase Server is not entirely open-source/free software. There are two versions: Community Edition (free but no latest bug fixes) and Enterprise Edition (there are restrictions on usage, confidentiality provisions, audits by Couchbase Inc. that "will be conducted during regular business hours at Licensee's facilities" and other terms typical to proprietary software that many people may find unacceptable).
CouchDB is an open-source/free software (no strings attached) project of The Apache Software Foundation and is released under the Apache License, Version 2.0 (DFSG-compatible, FSF-approved, OSI-approved, GPL-compatible, non-copyleft, commercial-friendly).
Philosophy
I have never seen it directly pointed out but this may be actually the most important difference between those two databases because it is deeply about the underlying philosophy of distributed computing models and not only about certain features, APIs or licensing. CouchDB and the Couchbase Server completely differ in their philosophy of building distributed systems and databases.
According to the CAP theorem it is impossible for a distributed database to simultaneously provide consistency, availability and partition tolerance.
CouchDB is an AP type system (provides Availability and Partition tolerance).
Couchbase Server is EITHER a CP type system (according to Wikipedia) OR a CA type system (according to Couchbase technical update) - WHICH OF THESE IS CORRECT? PLEASE COMMENT.
Features
This is what I found to be a list of CouchDB features that are not supported by the Couchbase Server:
no RESTful API (only for views, not for CRUD operations)
no _changes feed
no peer-to-peer replication
no CouchApps
no Futon (there is a different administration interface available)
no document IDs
no notion of databases (there are only buckets)
no replication between a CouchDB database and Couchbase Server
no explicit attachments (you have to store additional files as new key/value pairs)
no HTTP API for everything (you need to use the Couchbase Server SDKs or one of the Experimental Client Libraries at Couchbase Develop so no experiments with curl and wget)
no CouchDB API (it uses the Memcached API instead)
you can't do everything from the browser (you have to write a server-side application)
no two-tier architecture for Web apps is possible (you have to write a server-side application to sit between the browser and the database, like with relational databases)
no eventual consistency
not entirely open-source/free software
not a drop-in replacement for CouchDB (seems like a drop-in replacement for Memcached instead)
Those features of CouchDB may or may not be important to you so whether the lack of them is a disadvantage or not is strictly subjective, but I think that the decision whether to switch from CouchDB to Couchbase Server or not should be based on those differences and your dependence on those feature in your current CouchDB deployments.
For example if you've got interested in CouchDB after watching The CouchDB changes feed NodeCamp talk by Mikeal Rogers or one of the great CouchApp tutorials by J. Chris Anderson then you have to realize that if you want to switch to the Couchbase Server then you will have to forget about pretty much everything they were talking about.
Because of that, I would say that Couchbase Server looks like an evolution of Memcached and Membase (not an evolution of CouchDB) and as such it looks like a great product if you are currently using Memchached or Membase. If you are using CouchDB in the most basic way then you may consider using the Couchbase Server for the same things and it may or may not perform better (if you don't mind the license restrictions). But if you are actually using any of the features that are unique in CouchDB (like the changes feed, CouchApps, two-tier architecture, peer-to-peer replication etc.) then you can either forget about those features or stay with CouchDB.
In any case, make sure to read and understand the Migration to Couchbase for CouchDB Users tutorial before you think about switching.
People often get the wrong impression (maybe after reading things like "What's the future of CouchDB? It's Couchbase.") that CouchDB is somehow obsoleted by the Couchbase Server, or that it is an old, legacy version of Couchbase. Meanwhile CouchDB is an actively maintained open-source project, Couchbase server is a completely separate project (it is a newer project but it is not a newer version of CouchDB - they are not even compatible) and since even new tools for creating CouchApps still keep being developed (eg. see the Kanso project) then CouchDB is not going anywhere soon.
I hope it clarifies the confusion. Please correct me if I'm wrong on anything here.
Update:
Couchbase Server is actually a new name for the Membase Server (the Membase Server was renamed to Couchbase Server somewhere around version 1.8). See Couchbase 2011 Year in Review:
Unfortunately, we confused the heck out of many of our potential users. In addition to Membase Server and our new mobile products we also offered Couchbase Single Server which was a packaged “distribution” of Apache CouchDB. On top of that we began releasing developer previews of Couchbase Server 2.0, which incorporated CouchDB technology into Membase Server – but this product was not compatible with Couchbase Single Server (or CouchDB). [...] Membase Server will be renamed Couchbase Server 1.8 on its next release in January – a tiny step that simply alleviates “name” confusion. As has been planned from the beginning, the Couchbase Server 2.0 release (currently at Developer Preview 3) will add index and query functionality. While Couchbase Server 2.0 will incorporate substantial technology from the CouchDB project, it will not be upward compatible with CouchDB and it shouldn’t be viewed as a “version of CouchDB.” [emphasis added]
See also:
Comments to "The Future of CouchDB" by Damien Katz (removed in 2012 - available in the Web Archive)
Comments to "Why Couchbase?" by Damien Katz (removed in 2012 - available in the Web Archive)
Couchbase 2011 Year in Review
Membase Server is Now Couchbase Server
Couchbase technical update
Difference between Cloudant and CouchOne
They are different yet similar pieces of software. I've remixed the content from the top answer into a picture that might help clarify the "difference" as well as the common things:
A comment from Matt Ingenthron adds to this:
To add some context/corrections: NorthScale founders are Steve Yen and Dustin Sallings. I joined them shortly after founding. Also, Damien didn't later join Couchbase, he was part of CouchIO/Couch One prior to the merger. Citing a fun, historical source: https://youtube.com/watch?v=aZ_JOnU8tkI
I think CouchBase seem to be perceived as CouchDB's 'enterprise' alternative. Which in a way seem to be true.
Apart from lack of ability to attach files to records ( documents) and 'out-of-box' REST endpoints compared to CouchDB, CouchBase has sql like language i.e. N1QL (sometimes pronounced a Nickel, UPDATE renamed to SQL++ in Couchbase 7.0).
This is one of the reason why I don't really like / recommend using the term 'NoSQL'. I personally like term 'Non-relational'.
I've been looking at these too, both seem to provide fully functional XMPP servers in Java. I know Tigase is designed in a very modular way, not looked at Openfire in as much detail yet.
My intended use would be to create a custom IM-based app, using XMPP for convenience rather than to open my server up to talk to other XMPP servers.
I'm trying to evaluate my needs based on the following, roughly in order of importance:
Documentation coverage & community
How easy to plug in own functionality
Licensing/cost - I don't plan to release my code
Maturity and stability
Do not use Openfire if you expect to scale beyond a couple of thousand concurrent connections.
Tigase is amazing at handling hundreds of thousands concurrent connections and is wonderfully architected for largely distributed platforms where XMPP is simply the external interface. It comes with a price of rather poor documentation. You often need to go and read the source code to understand what's going on.
Openfire is perfect for small setups and its API is simple and very well documented. Unfortunately, it's not architected to scale even nearly close to what tigase is capable of.
Tigase is GPL(even version 3) licensed opposed to OpenFire being under Apache license ... for closed source application is OpenFire the go.
It is embaddable and proven to be reliable - 1000s of concurrent users. It even has gateways to communicate with legacy networks - like ICQ.
Only drawback I can se here is that it can handle only one domain per instance(port), however from your description that should not be a problem.
I totally agree with #Yuriy in that Tigase is great for high scalability whereas Openfire is more suitable for small, novice IT running chat for a SMB. I have gone into more detail on this in my blog on Tigase vs Openfire.
And Openfire 3.7.0.beta is out since some days now.
Lots of bug fixes, now also support Solaris as host system.
Concerning openfire ... it seems to be more or less abandoned and certainly not because of lack bugs to fix ;)
It seems that SaaS and Cloud computing are old concepts with new names, and I am curious if I am wrong.
For cloud computing you can look at: Difference between cloud computing and distributed computing?
Basically, it seems that when we have been hosting that that is cloud computing, it is just that now some companies have put in much great resources to ensure better uptime than my local ISP. But, it seems that there is nothing really new here.
For REST, it seems that it is what we have been doing with cgis for 15 years.
Here is a question on REST: What am I not understanding about REST?
It appears that REST is an old concept, and I am curious how it is different than has been done since the early days of the web, and, to a large extent, the early days of using telnet (which http is on top of).
Am I mistaken in my simplification of these? I try to see how what is new is like what I know so I can see what more has to be learned in that topic, but for cloud computing and REST it seems that very little needs to be learned.
You are both right and wrong. You are right in the sense that new ideas are normally similar to old ideas, and indeed cloud computing is based significantly on distributed computing.
What is new in cloud computing is
virtualization
self-service
With virtualization, you can run multiple operating systems on a single hardware. While that, in itself, isn't new, either, it was never considered in distributed systems as a relevant piece of the architecture. Using virtualization allows self-service: users can create their own clusters of nodes without the administrator of the hardware taking any action. This allows a significant acceleration of deployment, and a significant reduction of cost.
For ReST, what you are missing is the client API. It is true that on the server side, a ReST service can be implemented with CGI. What is new here is that it is not an end user which retrieves the URL, but a program.
Saying that HTTP is on top of telnet ignores realities; this is like saying that we made no progress since the introduction of copper wires for communication. Strictly speaking, HTTP is not in top of telnet, but on top of TCP (which telnet is also on top of, these days).
Considering Roy's dissertation coined the term REST back in 2000, you can definitely argue that there is nothing new about REST. Additionally, the REST architectural style was synthesized from successful existing practices, so REST implementations pre-date the definition. Having said that, there is nothing simple about designing REST interfaces. Ever since Netscape first abused cookies to allow servers to maintain session state people have been swimming upstream against the web.
REST's recent resurrection has come mainly from people becoming disillusioned with SOAP based Web Services. SOAP tried to hide HTTP instead of embracing it and I think people are starting to realize how effective HTTP can be as an distributed application protocol that can do more than just deliver HTML to web browsers.
RESTful web applications don't use session state, so one could argue that by that virtue alone it is different than most web applications in existence at the moment.
As for Cloud Computing, I find myself agreeing with Larry Ellison for once in my life.
I'm in agreement on what you've posted. You might consider making this community wiki since it's likely to garner many answers based on opinion. Cloud computing seems to have taken off as a buzzword, and this is largely due to a decrease in cost for mass quantities of hardware. And then there is REST which is really just a formal name and definition for something that has been in place for a long time. Some people like to encapsulate ideas with buzzwords and acronyms. Sometimes it's useful to put a name to an idea though.
Not only this, the concept of things being old concepts with new names is old. It's hard to be original these days :P
You are right about REST -- its mostly old concepts with a lot of added pedantry and not much added substance.
Cloud computing has a small but fundamental difference from distributed computing. In distributed computing you had servers dedicated to particular functions, and usually some sort of directory service to locate the correct server. In cloud computing any server is capable of any task and usually the servers queue up for work which is distributed from a central point.