Biztalk is something I've used quite a bit in both its 2006 and 2010 variants. It has its benefits and its drawbacks. So I thought I'd break down my understanding of its components as a reference.
A schema in Biztalk is an xml schema, that is an xsd. Schemas are fairly straightforward. Their job is to act as the template for xmls you receive and process in Biztalk.
There are receive and send ports in Biztalk. Their job is simply to transmit and receive xmls. Where ports get interesting are their types and the components you can connect to a port.
A port type determines its interaction with an outside system. You can have a file port, which consumes xml files or outputs them. You can have a web port, connected to a web service that processes requests. Then there's SQL ports which allow you to turn xml into an SQL query and run it on a server. You can have e-mail ports, FTP ports, even MSMQ ports.
The other neat feature of ports are components hanging off them. Ports can have maps, which we'll get to soon, connected to them directly which allow you to immediately transform xmls coming in or going out. Why is this great? Well if all you need is to turn one xml into another you can build a map, connect it to a port and call it a day. Ports also use pipelines which can do all sorts of crazy things. In fact let's jump to them next.
Pipelines are an area I haven't worked much. I know what they do, they transmute the incoming data and dissassemble it for reading by the other components. I also know you can build custom pipelines that will do other things on the incoming message or make calls to external libraries and log or change data. You could essentially build your entire application into a pipeline, though that might make it unreadable.
Maps are the meat of xml transformations. To set up a map you give it a source and destination xsd. Once deployed you feed it xmls of the source type and it outputs xmls of the destination type. So what? XSLTs do that and a map is, if you look in the code behind, just an XSLT. However what a map does is provide a visual layer that makes it easier to see what's going where. Maps also have functoids which are visual shorthand for script functions allowing you to do things like concatenate two fields into one, add today's date to a field or even do a database lookup for a value.
Orchestrations are the highest level of a Biztalk Application. An orchestration contains the logic that dictates what to do and where to send messages. Orchestrations generally receive messages from ports, transform them with maps and then send them out on ports. That's simple orchestration. Complex orchestrations can call other orchestrations, decide where to route messages or what transformations to apply, they can even perform send/receive requests where they contact external services to do something with the content of a message. Orchestrations are about bringing all the other components together and doing something interesting with them.
Next time I'll do some introductory blurbs on the components that can hang off a Biztalk Server like the Business Activity Monitor.