Friday 04 July, 2008 (BizTalk | Security | Tips)
There is a nice little SFTP adapter for BizTalk on CodePlex http://www.codeplex.com/SftpAdapter/. I have been trying this out for a couple of days and it works quite nicely. I have been using freeSSHd as SFTP server and WinScp as a client to see that the SFTP functionality works. WinScp comes with PuttyGen for generating key pairs for authentication and there are a couple of guides on the web which offer clues as to how this should all be configured but I still had to resort to trial and error to get the SFTP authentication working. So this is my super concise guide to getting it up and running for local testing (presuming you have installed all the software first).
Generate a keypair with PuTTYGen
Under WinScp in the start menu you have "Key Tools/PuTTYGen"
Click "Generate" and move the mouse about. When PuTTYGen has created your keypair enter a comment so that you key is easier to identify, you can use a passphrase for your master key if you like. Save your private key as a .ppk file somewhere safe this is your master file and you can open it in PuTTYGen later if you need to export it again. Export the key (under the Conversions menu) as an OpenSSH key, but remove the passphrase first since the SFTP adapter doesn't currently support passphrases for private keys, save this key somewhere where the SFTP adapter can access it. This key should also be kept safe since it is the equivalent of a password. Select the entire textbox with the public key and copy to the clipboard.
Configure freeSSHd for public key authentication
Open up the freeSSHd settings dialogue and go to Authentication. Enter a directory where the public keys for your users will be stored. Make sure that "Public Key Authentication" is not set to disabled and that "Password Authentication" isn't required.
You also need to set a directory under the SFTP tab for storing the files. Add users in the Users tab selecting "Public key (SSH only)" as the authorization method. Also make sure that the SFTP checkbox is selected.
Go to the directory that has been configured for freeSSHd keys. Create a text file named "username" ( the users login name and no extension) and paste the public key string from PuTTYGen into it making sure it is all on one line.
Test it with WinScp before trying it from BizTalk. Now you should be up and running with your SFTP adapter and an SFTP server.
Tuesday 01 July, 2008 (Architecture | EDA | SOA)
I have been reading a lot about Event Driven Architecture (EDA) in relation to SOA recently and while the ideas are very interesting and the benefits are alluring it adds an additional complexity and uncertainty to the overall behaviour. Two good articles on EDA are http://martinfowler.com/eaaDev/EventCollaboration.html and http://eaipatterns.com/docs/EDA.pdf
From my view the main problem is that when implementing a business process that spans several services (for example entity services) we do not generally want the entity services to react to events and then store or retrieve data based on the events because this means that the services need to have some kind of knowledge of the expected behaviour relating to the process - generally seen as a bad thing in SOA, as the northbound - southbound dependencies get reversed. We also want to have some stability from a callers perspective that the overall flow will be moved forward, traditionally done by issuing a command. If events get turned into commands then I believe we will have problems coordinating the different actors (presuming that the command event was only meant to be acted on once). Jack Hof has an interesting take on the relationship between SOA and EDA especially his extended pdf version has some interesting ideas about how to realise SOA and EDA together which contains a potential solution to the problem, basically by just combining EDA and SOA and knowing when to implement which principles.
A related problem is what should our messages contain - are command messages even required? Two slightly different takes on the problem are presented here and here. Thinking about events and messages has lead me to attempt to create (a very crude) classification system for events that are related to a solution that I am developing for a client.
- State-change events: no messages are published as long as the underlying values are not updated, the message is related to a specific instance of an entity or service. There is no expected behaviour for the recipient.
- Scheduled events: messages are published at a certain frequency whether the values are updated or not, all available data should be published simultaneously within a single message or as multiple messages. There is no expected behaviour for the recipient.
- Request or reservation events: these messages are requests for behaviour. A receiver may safely ignore the message, send a negative response if it cannot fulfil the request or a positive response if it can fulfil the request. The event needs to have a predefined response message which the event source can understand and the response needs to be able to be routed back to the source without the listener needing to have prior knowledge of all sources. This is basically an event which initiates a dialogue between two parties based on the reservation pattern. It is the requestors responsibility to coordinate the possible responses and outcomes. There is an expected behaviour for recipients who return a positive response but no prescribed behaviour for those who ignore the event or actively return a negative response.
- Command events: This must be an anti-pattern since a command denotes that the sender expects the recipient to perform some specific task and thus exhibit an expected behaviour, which is impossible in a loosely coupled, event-driven, service oriented world since the sender does not know who is listening.
The first two event types are just statements, the third (reservation) is really just a variation of a state-change event with additional semantics attached to it. Using EDA the expected behaviour that is needed for a specific business process must be realised with the help of some kind of process controller (notification server in Jack Hof's world) which follows the traditional Command and Control (call stack) approach for coordination but uses events to track what stage the overall process or task is at.