Related
Just looking at Haskell and web frameworks and wondering if it would make sense to use Haskell's great threading/event functionality to power a platform for writing HTML5 and REST apps that expose an HTTP API for data and a WebSocket (with maybe SockJS support for appropriate fallback) API for events? It doesn't seem like the "big" web frameworks support WebSockets as a first-class citizen, though they seem to have a lot of other things going for them.
My concern is making use of available cores, which Haskell can do well, but also providing easy user integration on the server side for validation and server-side logic (maybe by embedding Lua or similar?). If one wrote this on the JVM, one could make use of multiple server-side language support and lots of libraries for this sort of thing.
I'm sure people are doing things like this in a one-off solution for their own applications but I'm thinking along the lines of a PaaS-type approach where one can write HTML5 apps with data (including proper synchronization for offline use) and eventing "for free" as a fundamental part of the platform. Most logic would reside in the browser but some could be run on the server with the appropriate hooks and a reasonable embeddability (JavaScript seems out of the question and not sure about embedding interpreters in Haskell as I'm only dangerously familiar with Haskell in general).
Part of the problem I've had with Haskell so far is that I'm not a Math guy. I didn't study CS in college and I'm a creative-type thinker. So a lot of the tutorials and documentation get me pretty lost, especially when dealing with the mathematical stuff.
Has anyone trod this path already? Am I late to the party? :)
Gregory Collins gave a tutorial at CUFP last year about using Snap to build an interactive chat website using long polling (not websockets). The source code is here.
In the websockets department, Jasper Van der Jeugt wrote a Haskell websockets library. It is available on hackage and comes with websockets-snap, which provides Snap framework support. There's also wai-websockets which provides integration with Warp.
I believe all of the major frameworks have some level of websockets support, so they should all be a fair choice based on your requirements. For Yesod, there's an example of creating a chat system (using eventsource, not websockets) available in the book:
http://www.yesodweb.com/book/wiki-chat-example
I am currently working on a design for a collection of subsystems, and I would like to be able to offer the API's exposed by a given subsystem for use by other subsystems.
In the past, I have used SWIG to expose C api's to a variety of other languages. This has worked well for me, but ultimately the API is defined in C. So basically one side of the API is language agnostic, and the other isn't.
What I would really like is to have something similar to SWIG that could generate the interface between 2 arbitrary languages based on some description of the API.
I don't want to use web services.
For example, I would like to call a 'function' from java, and implement the 'function' in Python. I'd like to be able to generate the language interop using a code generator.
Is there anything that exists which can do this today? At least for simple 'function' calls - ignoring the more complex cases like callbacks and situations where you need to maintain references outside of the 'function' call itself.
I found this after following gooli's link to Protocol Buffers .
This looks so compelling I'm going to propose it as an answer to my own question.
http://incubator.apache.org/thrift/
Thrift is a software framework for scalable cross-language services development. It combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml.
From the whitepaper:
...we were presented with the challenge of building a transparent,
high-performance bridge across many
programming languages. We found that
most available solutions were either
too limited, did not offer sufficient
datatype freedom, or suffered from
subpar performance
Also from the whitepaper:
A. Similar Systems The following are software systems similar to Thrift.
Each is (very!) briefly described:
SOAP. XML-based. Designed for web services via HTTP, excessive XML
parsing overhead.
CORBA. Relatively comprehensive, debatably overdesigned and
heavyweight. Comparably cumbersome
software installation.
COM. Embraced mainly in Windows client softare. Not an entirely open
solution.
Pillar. Lightweight and high-performance, but missing
versioning and abstraction.
Protocol Buffers. Closed-source, owned by Google. Described in Sawzall
paper.
The last part about Protocol Buffer's is out-of-date - its been open sourced
COM (and to a lesser extent Firefox's XPCOM) might be what you are looking for. In COM, you define the API using a language called IDL which can then be compiled into different languages. When using the same language the calls usually degenerate into efficient function calls.
However, COM is a very complex and dying piece of technology that I would never use for a new project.
I am the lead instructor of web & internet related courses on a private post high-school institution. My current classes include introductions to HTTP, TCP/IP, (X)HTML/CSS/JavaScript and generic SQL. Next year we will deal mostly with PHP / Java. What, in your opinion, are the most important aspects of web development in contrast and relation to traditional development and what should be the main focus of my lectures?
Of course there is a curriculum I will follow but I would really like to enhance it with everything there is time for, from hypes and semantics to oldschool hardcore scripting.
Keep in mind that I am fortunate enough to deal with highly talented and moderately motivated individuals.
Most important aspects of web development:
Where is this code running? (Client vs Server programming - as many have said)
Who is going to use this? (Know your audience - why are they on your site/app)
How to play nice (copyright, standards, borrowing ideas vs stealing stuff)
How to be resourceful (code libraries, google search and stackoverflow)
Main Focus of lectures
I am a strong believer in contextual learning. Let them choose a project with boundaries and guidelines that will employ the concepts you want to get across. One can spend all day learning syntax and concepts, but real learning is done when you are trying to solve a problem. They will also have more fun.
Summary
Lecture on the How (XHTML,CSS, JS, etc) but only in the context of Who, What and Why.
In my opinion, the most important thing is to teach the difference between server and client programming, and when you would use one over the other. I am so surprised at the number of new graduates that don't understand the difference.
IMHO, the most difficult concept in Web development is that of state and how to maintain it.
If I were designing a Web programming course I think I would get the students to design a simple application framework that attempted to address transparent state maintenance. Dividing them into groups, you could have them take different approaches (server-side, client-side, database supported etc.) approaches to this. And at the end of it I believe that they would have learned a lot more about Web architectures than if you had focussed on producing an actual application.
For front-end web development ((X)HTML/CSS/JavaScript), try the Opera Web Standards Curriculum which:
takes students from complete beginner
to having a solid grounding in
standards-based Web design, including
HTML, CSS, and JavaScript development.
I believe a lot in inspiration. As a new web developer I found it really difficult to make my websites usable, appealing, and well coded. I found inspiration in outside resources such as Nettuts and Smashing Magazine. These websites really opened my mind to all of the features I really could learn and use in my designs/coding.
Well if you are asking for opinion....
Please teach them:
self documenting code.
the difference between client and server
data checking
security
If they have a good understanding of the programming language (which it sounds like they will get with your curriculum) the things that I have listed will be a great improvement.
I also believe that web development can only be taught after first learning a little bit about software engineering. I think agile processes is the best route for teaching students software engineering. It's lightweight and not quite as document driven.
After that I would teach them the basics of client server programming, the http protocol and some basic web programming (PHP and javascript would be sufficient). If there is enough time I would show them the basics of Java EE programming and the differences between that and PHP.
Also cover some of the more advanced materials such as MVC for the web (using JSF) and javascript libraries (JQuery). I would also teach them data access objects and persistent objects.
For my senior research this year I came up with some materials for an upper level college course that requires web programming, web design, and software engineering background. You may look at the basic materials here to get a basic idea of what I thought of a course for an advanced web application development course. I know this may be out of your scope, but it might be a start.
Keep in mind that web programming is a mess and it is your job to provide not just light at the end of the tunnel, but the tunnel itself. I would expand on AaronS's answer:
The difference between client and server.
Web applications run over a network, with all that implies.
There is more than one way to do it. Squared.
In the end you will have to choose what not to teach to actually get somewhere.
If you have a group of motivated people then I will suggest to focus on creating a full web application from scratch, I mean, from requirements elicitation itself.
You could start with a brainstorming session where you get some of your students to take the role of the clients from different perspectives (you will need to came up with the base problem itself) and then another group of students who try to get the "clients" group to express their needs and propose solutions to those problems using via a web application. This will help them to learn one of the biggest problems of development in general which is the interaction with clients and how to get the most information out of them overcoming the usual communication problems. Actually if you can get other non-technical people to act as the clients it will be even better.
Then you can introduce then to a methodology like extreme programming or any other you like. I would suggest an agile one because it will provide faster results and won't get boring that fast, besides, the market appears to be shifting in favor of them.
Now, regarding web development itself, it is really important to get people to understand the need for web standards and how wrong things can go when they are not followed (IE6)
After all this is clear, it will be time for them to realize that in web development most of the time you just have to deal with the differences in platforms in which their applications will be displayed and teach them actual techniques to do so like unobtrusive javascript and progressive enhancement.
Regarding the server side of the equation, I believe it is important to enforce the use of patterns (MVC is a must), code re-use, and all the usual development practices. And be sure they understand that HTTP itself is a stateless protocol and how it is important to handle cookies and sessions in a responsible fashion, here it is important to make sure they understand the differences between the server and the client side.
Also, covering the OWASP top 10 (at least) is a must, the last version is available at: http://www.owasp.org/index.php/Top_10_2007
Some links:
http://www.quirksmode.org/blog/archives/2005/06/three_javascrip_1.html
http://dowebsitesneedtolookexactlythesameineverybrowser.com/
http://forabeautifulweb.com/blog
http://www.alistapart.com/
http://www.owasp.org/index.php/Top_10_2007
Teaching web development (like GUI builder in the old age) has the risk of focusing too much on the front-end and not enough on the back-end. It is too easy to fall into the trap of getting the students to think too much about superficial visual issues (e.g., how to align these two things) rather than core things (how to we effectively compute, calculate, store, etc.).
In addition, many web-development languages are not hallmarks of good programming practices since they tend to be on the dirtier scripting side.
These two factors together, to me, are why languages like PHP often get a bad rep.
If you were teaching people who were actually going to be practicing developers, I would focus separately on the model and on the view, and show how to tie them. But in a high school environment, it's possible that the parents just want their kids to demonstrate some publicly visible stuff for their college applications.
If they are truly talented and motivated, teach them real programming with some web manifestations (e.g., use Java servlets), and leave all the scripting for them to learn in their spare time. A good teacher is invaluable for building good engineering skills, so use your time where it matters.
I honestly do not believe you can do well with web development without having a good background with general software development. If one doesn't pay attention to that he/she will end as a mundane scripter or something.
Would be a good idea if you told us what kind of people with what background you get.
If you got some financial academy graduates, it is not clear what kind of motivation will they have towards any kind of development. If these are engineers or some creative field like design, decorations etc. it will be a different story.
Try to gather a little bit of best-practices from various aspects of development. A little from testing and quality control, a bit from project management, a few things about dealing with customers, security for publicly-exposed software, legal aspects. Not too much, just to paint a big picture.
I would start with introduction to web standards carriculum by Opera.
I think it would give a good understanding of some of the basic concepts in web development
For the programming portion, I would suggest you start with the lowest level / most basic concept you can come up with. The first thing that jumps to my mind is HTML. You could make sure the students understand HTML (and markup in general) and its basic syntax. I think that starting with hand-coded HTML will also give them a greater appreciation for some of the great tools out there that help you generate HTML or other code.
After that, you can get into some tools and technologies surrounding HTML like CSS, JavaScript, and AJAX.
Once the client-side is covered and those concepts are concrete in their minds, you can move onto server side scripting / programming. Most of the languages on the server side simply emit HTML, CSS, JavaScript, etc. to the browser, so understanding those things first is essential.
Finally, start talking about using their new found knowledge to create apps that talk to other systems (databases, web services, etc.). Once all of those basics are in place, you'll probably be done with the class, but then they'll be ready for the 200 level, right?
I like the answer about the difference between client side and server side programming. Since you teach talented/motivated students, I think that some theoretical discussion of the MVC (Model View Controller) architecture might be in order. How it was originally devised for desktop applications, and in that case it was necessary to implement a system that listened for events, so as to be able to keep all facets of the view synchronized with the state of the model as it was modified. But that, under the web paradigm, the listener code is given to you for free in the form of the web server, and the request is the event. And therefore MVC for the web, at least as regards interaction between client and server, should be less complex, with the controller merely mediating between the client and server.
That is, of course, until the advent of Ajax. When now it is appropriate to implement listener code on the client side with Javascript, so as to be able to keep widgets in synch.
I am an MVC junkie so take whats useful from this. Your mileage may vary, but I do think material on MVC is certainly warranted.
Good luck
Since you're getting into the server-side stuff, I would highly recommend going over some basic application security. From keeping applications (Wordpress, PHPBB, etc) up to date and patched, to actual attacks like SQL Injection and Cross-site scripting.
Since it sounds like you're teaching them from the ground up, you have a great opportunity to impress upon them the importance of input filtering and output escaping, legitimate user authentication, and other best practices.
This is very front-end focused as well... but I thought it was a great post.
http://veerle.duoh.com/blog/comments/teach_the_web_right/
[Edit]
She mentions the Opera Web Standards Curriculum as has been mentioned in previous posts, but she also mentions WaSP InterAct Curriculum. That seems like it's still very much in progress, but already has some great resources and links.
Focusing on "Next year we will deal mostly with PHP / Java". I'll focus on Java, since I don't know much about PHP.
Get the model right. Design a model, use the ORM, get this to work sensibly. This is highly reusable stuff. It's the backbone of the application. If this isn't right, the rest will rapidly become a mess.
Get the template presentation right. JSP's shouldn't do too much (they can, but shouldn't). This should have any fancy processing -- that's either a model problem or an action class problem.
Knit these together with Struts action classes and Java Beans that make sense in the domain you're building a solution for.
Add CSS/JavaScript and what-not after it all -- essentially -- works. No amount of JavaScript can fix a fundamentally flawed model.
Core Technology issues (XML, HTML, SQL, etc.) are important, but not central. It's hard to skip around, but you have to skip around.
SQL, ORM, Java first.
HTML, JSP, more Java next.
Struts, Action Classes, etc. and more Java next.
I think that much of the core skills issues need to be covered in a Just-in-Time manner. If you spend too much time on fundamentals of HTML, CSS and SQL, no one's building anything useful.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I need some resources that talk about how to design your software to be extensible, i.e. so that other people can write add-ons/plug-ins that adds functionality to it.
What do you recommend? Any books out there that discuss the subject?
I would prefer something that's short and to the point; a bit of theory and a bunch of concrete examples.
I'm not targeting a specific language, I want to be able to understand the core idea so that I can implement it in any language.
And for the same reason, I prefer not to do it using a framework that someone else built (unless the framework is not very high-level, i.e. doesn't hide too much), at the moment I only want to educate myself on the subject and experiment with various ways to implement it. Plus, a framework usually assumes user's knowledge about the subject.
UPDATE
I'm not asking about OOP or allowing my classes to be inherited. I'm talking about designing an application that will be deployed on a system, such that it can be extended by third-party add-ons AFTER its been deployed.
For example, Notepad++ has a plug-in architecture where you can place a .dll file in the plugins folder, and it adds functionality to the application that wasn't there, such as color-picking, or snippet insertion, or many other things (a wide range of functionality).
IF we're talking .NET, try Scripting .NET applications with VBScript over on CodeProject. Lots of concrete examples there.
Below are sites implementing various application extension techniques
ClearScript - Makes V8, VBScript and JScript available to .NET apps
CS-Script - The C# Script Engine
Plugin Architecture using C#
Opinio plugin architecture
Notes on the Eclipse Plug-in Architecture
Plug-in Architecture Framework for Beginners
Gecko plugin architecture
Fungimol plugin architecture
OSGI is a good practical example of a technical framework allowing to do what you are after.
The theory is here.
The (free!) book is there.
Extensibility and the ability to write plugin must deal with service lifecycle
adding / removing service/plugin on the spot
managing dependencies between services
managing states of services (declared, installed, started, stopped,...)
What is OSGI for ?
One of the main functions of a module is as a unit of deployment… something that we can either build or download and install to extend the functionality of our application.
You will find a good introduction here, on the central notion of service (which is related to your question, and which explain some problems around services, key component for extensibility).
Extract:
Why are services then so important if so many applications can be built without them? Well, services are the best known way to decouple software components from each other.
One of the most important aspects of services is that they significantly minimize class loading problems because they work with instances of objects, not with class names. Instances that are created by the provider, not the consumer. The reduction of the complexity is quite surprising
Not only do services minimize configuration, they also significantly reduce the number of shared packages.
Implement SOLID principles in your application.
1. Single responsibility principle: A class should have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class
2.Open/closed principle: Software entities … should be open for extension, but closed for modification
3. Liskov substitution principle: Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program
4. Interface segregation principle: Many client-specific interfaces are better than one general-purpose interface
5. Dependency inversion principle: One should Depend upon Abstractions. Do not depend upon concretions
Stackoverflow questions:
Example of Single Responsibility Principle
Is the Open/Closed Principle a good idea?
What is the Liskov Substitution Principle?
Interface Segregation Principle- Program to an interface
What is the Dependency Inversion Principle and why is it important?
You try to reach two competing goals:
The components of your software must expose a lot of themselves, so they can be reused
The components of your software must expose very little of themselves, so they can be reused
Explanation: To encourage code reuse, you should be able to extend existing classes and call their methods. This isn't possible when the methods are declared "private" and the classes are "final" (and can't be extended). So to meet this goal, everything should be public and accessible. No private data or methods.
When you release the second version of your software, you will find that many of the ideas of version 1 were plain wrong. You need to change many interfaces or your code, method names, delete methods, break the API. If you do this, many people will turn away. So in order to be able to evolve your software, the components must not expose anything that is not absolutely necessary - at the cost of code reuse.
Example: I wanted to observe the position of the cursor (caret) in an SWT StyledText. The caret is not meant to be extended. If you do it, you'll find that the code contains checks like "is this class in the package org.eclipse.swt" and a lot of methods are private and final and whatnot. I had to copy about 28 classes out of SWT into my project just to implement this feature because everything is locked down.
SWT is a nice framework to use and hell to extend.
Of course there is the famous Open Closed Principle - http://en.wikipedia.org/wiki/Open/closed_principle
Well it depends on the language.
In C/C++ I'm pretty sure there is a loadlibrary function that allows you to open a library at runtime and invoke it's exported functions. This is typically how it's done in C/C++.
In .NET, there is Reflection, which is offers similar (but more broad) to loadlibrary. There is also entire libraries built on Reflection like Managed Extension Framework, or Mono.Addins that does most of the heavy lifting for you already.
In Java, there is also Reflection. And there is the JPF (Java Plugin Framework) which is used in stuff like Eclipse IIRC.
Depending on what language you use I could recommend some tutorial/books. I hope this was helpful.
Plugin architecture is becoming very popular for its extensibility and thus flexibility.
For c++, Apache httpd server is actually plugin based, but a concept of module is used instead. Most of apache features are implemented as modules, like cache, rewrite, load balancing, and even threading model. It is a very modular software I ever saw.
And for java, Eclipse is definitely plugin based. The core of Eclipse is an OSGI module system which manage bundles, another concept for plugin. Bundle can provide extension points on which we can build modules with less efforts. The most intricate thing in OSGI is its dynamic characteristic, which means bundles can be installed or uninstalled at runtime. No stop-the-world syndrome any more!
Since I dont have enough rep points to leave a comment, I am posting this as an answer. SharpDevelop is an IDE for developing applications in C#/VB.NET/Boo. It has a pretty impressive architecture that allows itself to be extended in a number of ways - right from new menu items to development support for whole new languages.
It uses a bit of XML configuration to act as a glue layer between a core of the IDE and the plugin implementation. It handles locating, loading and versioning of plugins out of the box. Deploying new plugins is matter of simply copying in the new xml configuration file and the required assemblies (DLLs) and restarting the application. You can read more on this in the book "Dissecting a csharp application" by the original author(s) - Christian Holm, Mike Krüger, Bernhard Spuida of the application from here. The book doesnt seem to be available on that site, but i found a copy that might still be around here
Also found a related question here
Checkout "CAB" - Microsoft's Composition Application Building blocks Framework. I think they've got a "web version" of that too...
I have just started to develop a smart client application. These are two options I am considering.
Using Microsoft's System.AddIn namespace. Looks very promising, however it may be a little complex for our end solution.
Or the Smart Client - Composite UI Application Block from Microsoft
Recently, i have looked at taking components both the Composite UI Application Block and the System.AddIn namespace to build my own. Since source code is available for the CAB it is easy to extend. I think our end solution will be a light weight version of the CAB, definatly using the Unity Application Block
If you work with .Net, our research yielded two approaches: scripting and composition.
Scripting
You extend the functionality of what your classes can do by orchestrating them using scripts. That means exposing what is compiled in your favorite .Net language in a dynamic language.
Some options we found worth exploring:
IronPython
IronRuby
JavaScript: Jint, Jurassic and JavaScript .Net are good starting points.
Script.Net -> this one was the first one to call our attention.
Composition
If you start a project with .Net 4 or above, you must take a good look at the Managed Extensibility Framework (MEF). It allows you to extend the functionality of your apps in a plugin way.
The Managed Extensibility Framework (MEF) is a composition layer for
.NET that improves the flexibility, maintainability and testability of
large applications. MEF can be used for third-party plugin
extensibility, or it can bring the benefits of a loosely-coupled
plugin-like architecture to regular applications.
Managed Add-in Framework is also a good read.
MSDN: http://msdn.microsoft.com/en-us/library/dd460648.aspx
Codeplex: http://mef.codeplex.com/
Rather than re-inventing the wheel, use the frameworks in hand. Eclipse and Netbeans both support plugin based extensions. You have to work in Java though.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
In evaluating different systems integration strategies, I've come across some words of encouragement, but also some words of frustration over BizTalk Server.
What are some pros and cons to using BizTalk Server (both from a developer standpoint and a business user), and should companies also consider open source alternatives? What viable alternatives are out there?
EDIT: Jitterbit seems like an interesting choice. Open Source and seems to be nicely engineered. Anyone on here have any experience working with it?
BizTalk Server's key benefit is that it provides a lot of 'plumbing' around deployment, management, performance, and scalability. Through Visual Studio, it also provides a comprehensive framework for developing solutions, often with relatively little code.
The frustration and steep learning curve that others mention often comes from using BizTalk for the wrong purpose and from a misunderstanding about how to work with BizTalk and message-oriented systems in general. The learning curve is not as steep as most people suggest - the essential part of the underlying learning actually focuses on changing thinking from a procedural approach to a stateless message-based approach.
A drawback people often cite is cost. The sticker price can seem to be quite high; however, this is cheap in comparison to the amount you'd spend on developing and supporting features on your own.
Before you consider alternatives, or even consider BizTalk server, you should consider your organization's approach to integration and it's long term goals. BizTalk Server is great in cases where you want to integrate systems using a hub and spoke model where BizTalk orchestrates the activities of many applications.
There are other integration models too - one of the more popular ones is a distributed bus (don't confuse this with the term "Enterprise Service Bus" or ESB). You can also get BizTalk to work as a distributed bus and there are alternative solutions that provide more direct support. One of the alternate solutions is an open source solution called nServiceBus.
When considering whether to use a commercial product like BizTalk, verses something else (open source or developed in house), also consider maintenance and enhancements and the availability of the necessary skill-set in the marketplace.
I wrote some articles that go into more detail about the points I discussed here - here are the links:
Why BizTalk?
Top 10 BizTalk Mistakes
Extensibility Features in BizTalk Server
Open Source Integration with nServiceBus
My experience with BizTalk was basically a frustrating waste of time.
There are so many edge cases and weird little business logic tweaks you have to make when you are doing B2B data integration (which is probably the hardest part of any enterprise application) that you just need to roll your own solution.
How hard is it to parse data files and convert them to a different format? Not that hard. Unless you're trying to inject a bloated middleware system like Biztalk into the middle of it.
As a BizTalk consultant I have to agree at least partly with Eric Z Beard, there are a lot of edge cases that take up alot of time. But quite a few scenarios are handled extremly smooth as well, so it all depends IMO. But when you (Eric) call BizTalk bloated I have to disagree! We've found that the performance and reliability is excellent, it's flexible and comes with a lot of good adapters out of the box.
BizTalk needs to be used correctly,
I am a BizTalk developer and my experience with BizTalk is quite good.
Its reliable, performant, scalable, contains a lot of built in architectural patterns and build in components to make integration easy and fast, you get security, retries, secondary transports, validation, transformation etc... and what ever you dont have build in with BizTalk you can easily customized with .NET code, its basically a hard earned integration system and you get all this in one box.
BUT you need to know how to implement BizTalk correctly, not once I came across solutions that where implemented and often also architected incorrectly.
but the real benefit of BizTalk is that you can implement small solutions and scale up whilst most other integration systems from big vendors will only sell a whole integration pack which can cost much more.
BizTalk is considered the most complicated server from the house of Microsoft.
So any body saying BizTalk is not good dosent know BizTalk period.
We evaluated BizTalk at our company and were really disappointed.
We are using IBM WebSphere Transformation Extender (which has lots of (other) problems, too) and the mapping tool of BizTalk is a joke in comparison to WTX.
The graphical tool is not really usable for complex mappings (we have schemas with a few hundred fields in repeating groups) and if you do more than the usual "concat first name and last name to name" mappings, you will be tired of the graphical approach (for example the arguments of the functoids in the graphical mapper are not labeled and the order in which you connect fields to these arguments is important).
The XSLT-Mapper was usable but not really convincing, and even the microsoft rep told us to use a tool like XMLSpy for XSLT and load the resulting XSL file into BizTalk.
A third approach to mapping is to use C#-Code for the mapping, which was not acceptable for us as a general approach (we don't want to teach everyone C#).
In addition to the mapping tool we did not like the deployment in BizTalk. In order to deploy your process, you need to make lots of settings in different tools and places. We had hoped to find a mechanism like a WAR file for Java Web Applications in BizTalk, so that you can give one archive for your whole process solution to your administrator and he can deploy it.
We've been using BizTalk since version 2004, and now have a mix of versions 2006 R2 and 2004 running. I found that the learning curve was quite severe, and development time for solutions is not always quick. Those are definitely shortcomings. Where BizTalk really excels is in its fault tolerance, gauranteed delivery, and performance. You can rest assured that data will not get lost. Retry functionality and fault tolerance robustness is baked in so generally speaking if systems are down BizTalk will handle that and successful delivery will occur once systems come back on line. All these issues such as downtime, etc that are important in an integration scenario are handled by BizTalk.
Further, generally speaking when developing solutions BizTalk abstracts the communication protocols and data formats of the native systems by dealing with everything as xml, so when developing solutions, you typically don't have to wrote code specific to those systems, you use the BizTalk xml framework.
In the last year, we've implemented a java open source engine called Mirth for our HL7 routing. I found that for HL7 purposes, the HL7 adaptor for BizTalk is a challange to work with. Management dicated that we use Mirth for HL7 routing. Where BizTalk falls down in terms of learning curve, Mirth makes up. It is far easier to develop a solution. The problem with mirth is that it doesn't really have any gauranteed delivery. Most of the adaptors (except for hl7) have no retry functionality so if you wanted that you'd have to write your own. Second, Mirth can lose date if it goes down. I would call it very easy to use (although there is no documentation) but I'd be hard pressed to call it an enterprise solution. I'm going to check out jitterbit which was mentioned by someone else.
We used BizTalk for a couple of years, but gave it up for our own custom framework that allowed more flexibility.
There is always Sun's (now Oracle) OpenESB framework. Its generally speaking a smaller, lighter version of Biztalk but with roughly all the same features.
You do get to write more code with it, though.
Its Open Source as well.
In the OSS space (though I've never used them as a BizTalk replacement personally - this is anecdotal) you can use one of the Java/J2EE Messaging engines such as OpenMQ (which is the Sun enterprise one rebadged and without support). If you need Orchestration / Choreography (i.e. SOA/ESB pieces) on top of this, you could look into something like Apache Mule
My experience with BizTalk and doing B2B integrations is that most organizations do not truly do schema first design or fully understand xml standards for that matter. Most tend to weave objects and hope they materialize into meaninful schemas. In an enterprise environment, this is backwards.
BizTalk does have a learning curve, but once you get it you are rewarded with durability, performance, true scalability, and extensibility. Like most have said though, it best to make sure it meets your needs and contort your needs to BizTalk.
In the past I have worked with BizTalk 2004 through 2009, and another product called webMethods.
I have no direct experience with JitterBit, but I have heard very good things from coworkers.
I came across Apatar (unable to post url, but Google finds it) while looking for a solution cheaper than BizTalk. I have yet to try this out.
My last company had many problems with BizTalk being too complex and ridged, but I can’t help but think this was mainly down to the implementation the consultant did.