I did a day trip to XTECH 2005, where I was presenting on WS-CAF. A very long, but interesting day.
I wasn't presenting until later in the day, so Edd asked me to chair one of the earlier sessions of the day. The presentations I chaired were "Adoption of UBL in Denmark - business cases and experiences" and "Implementing Web Services for Healthcare - Lessons & Pitfalls", which were both very interesting for similar reasons. Firstly, they both talked about the use of ebXML in the public sector (ebXML is a big effort, so if you want to know which aspects of it they're using, I'd encourage you to read the papers), and secondly, the key to their success was pretty much the same: legislation! In one case, any Netherlands company wanting to send invoices to the government has to do it electronically and were given 8 weeks to implement the necessary support within their organisation. I forget the actual figures at the moment, but the government did a "time and motion" study of invoicing and reckoned they could say $100 million annually by doing this. And it all seems to be working!
They were both extremely interesting presentations and the audience asked some good questions that helped to pull more information from the presenters. Overall, I think this time I probably found the chairing experience more interesting than presenting!
Sunday, May 29, 2005
Monday, May 16, 2005
WWW2006 update
We're in the process of finalising the PC for the XML & Web Services track of WWW2006. It's shaping up to be a good PC and I hope the quality of papers we get is good too. So, get your thinking hats on and start to write. Although the CFP hasn't gone out yet, and we'll be accepting papers on a wide range of XML & Web Service related topics, this year I'd like to see some papers on fault tolerance and reliability. That topic tends to get overlooked a lot in the early days of any distributed architecture "wave", but I think we're reaching the crest of this wave and things need to change.
Friday, May 13, 2005
Asymmetrical WS-Addressing
I have to admit that I like symmetry for a number of reasons. Nature prefers symmetry in a wide range of areas and it shows up all around us. So, symmetry is good. I know it's not a hard-and-fast rule, but we've followed nature before and I reckon it still has a lot to teach us. And more pragmatically, symmetry just makes sense. To paraphrase Occam's Razor: the simplest solution is probably the right one. So, why make things more complex than they need to be?
So how does this relate to WS-Addressing? Well ever since I started to use it when the Web Services Coordination and Transaction specifications, I've been annoyed by the fact that not everything is a WS-Addr End Point Reference (EPR). Basically in WS-Addr, an EPR is a delivery address for your message and contains the URI of the service as well as other information needed to ultimately deliver that message.
When sending a message, you can define wsa:ReplyTo, wsa:FaultTo and wsa:From all as EPRs. But the actual destination address isn't an EPR! Or more accurately, it's a broken apart EPR: as a receiver, you may have got it in a wsa:ReplyTo, but if you then want to us it to send a response, you have to do some work with it first.
For example, here's a valid wsa header for an input message:
Now in a symmetrical world, I should simply be able to take the wsa:ReplyTo EPR and put it (renamed as wsa:To of course) into the SOAP header of the response message like so:
But no, I can't do that. I have to take everything out of the wsa:ReplyTo and essentially promote the contents to the root, like so:
And as you can see, it's not actually as simple as that - I've got to break apart the ReferenceParameters (which could be arbitrary in size). Why can't I just use the EPR I received as an EPR? It can't be because of deficiencies in the SOAP processing model and I don't see how it adds anything to the architecture/model (if anything it detracts from it).
In short: It does not make sense!
So how does this relate to WS-Addressing? Well ever since I started to use it when the Web Services Coordination and Transaction specifications, I've been annoyed by the fact that not everything is a WS-Addr End Point Reference (EPR). Basically in WS-Addr, an EPR is a delivery address for your message and contains the URI of the service as well as other information needed to ultimately deliver that message.
When sending a message, you can define wsa:ReplyTo, wsa:FaultTo and wsa:From all as EPRs. But the actual destination address isn't an EPR! Or more accurately, it's a broken apart EPR: as a receiver, you may have got it in a wsa:ReplyTo, but if you then want to us it to send a response, you have to do some work with it first.
For example, here's a valid wsa header for an input message:
<S:Header>
<wsa:MessageID>http://example.com/someuniquestring
</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://example.com/business/client1
</wsa:Address>
<wsa:ReferenceParameters>
<foo:dest objid=urn:1234:5678/>
</wsa:ReferenceParameters>
</wsa:ReplyTo>
<wsa:To S:mustUnderstand="1">
mailto:fabrikam@example.com</wsa:To>
<wsa:Action>http://example.com/fabrikam/mail/Delete
</wsa:Action>
</S:Header>
Now in a symmetrical world, I should simply be able to take the wsa:ReplyTo EPR and put it (renamed as wsa:To of course) into the SOAP header of the response message like so:
<S:Header>
<wsa:To>
<wsa:Address>http://example.com/business/client1
</wsa:Address>
<wsa:ReferenceParameters>
<foo:dest objid=urn:1234:5678/>
</wsa:ReferenceParameters>
</wsa:To>
</S:Header>
But no, I can't do that. I have to take everything out of the wsa:ReplyTo and essentially promote the contents to the root, like so:
<S:Header>
<wsa:To>
<wsa:Address>http://example.com/business/client1
</wsa:Address>
</wsa:To>
<foo:dest objid=urn:1234:5678/>
</S:Header>
And as you can see, it's not actually as simple as that - I've got to break apart the ReferenceParameters (which could be arbitrary in size). Why can't I just use the EPR I received as an EPR? It can't be because of deficiencies in the SOAP processing model and I don't see how it adds anything to the architecture/model (if anything it detracts from it).
In short: It does not make sense!
Saturday, May 07, 2005
java.net blog
I've had a blog on java.net for a while, but have found very little time to put something together for a first post. A conversation I had with Greg the other day around the importance of WS-RX and WS-Context got me thinking and I thought I'd write something about WS-Context for the readers of java.net.
Thursday, May 05, 2005
Some more history
Just a couple of links to some things of historial interest to other ex-HP/Bluestoners out there.
Sunday, May 01, 2005
Why transactions are often under used
Back here I mentioned that on many occasions I've come across companies and products that could/should be using transactions when they're not. Obviously the inverse is also the case: the use of transactions when they're simply not needed can leave people with a bad experience and hence averse to looking to transactions in the future, when perhaps they should. So, the reasons for people not using or considering transactions when they are in fact useful can be broken down into two broad categories:
(i) overhead: it's true that you can never get something for nothing. But as we showed here with regard to principles, and I mentioned here with regard to our specific implementation, it doesn't have to be the case that you have to pay dearly (in terms of overhead and cash) to get the guarantees transactions offer. There's always a trade-off to be considered in pretty much any additional functionality you may want to add to an application, whether it's transactions for reliability/consistency, replication for availability/performance, security etc. Rather than think about what negative impact this functionality is going to have on your system, you need to consider what the impact will be on not having it. Now with the likes of security and replication it's fairly evident what benefits they bring most of the time. With transactions it's always a little more difficult, because most of the time you don't see the benefit: it's typically only when a failure happens. Now it is true that failures are not common, but they do happen - network failures, disk failures, memory failures etc. But in that case you should think of transactions like an insurance policy: how often do you claim on your home, car or travel insurance? Probably not that often. But most people will still renew their policies year after year, even when some (e.g., holiday insurance) aren't mandatory. Why? Because you don't want to take the risk and in simple terms the cost of insurance is significantly less than the cost of whatever it is that you're insuring. I'd like to see a time when transactions are seen to be so cheap that they're just part of the infrastructure that people take for granted. I think with something like ArjunaCore and the transaction implementation in Indigo that's starting to look possible.
(ii) education: in some ways this follows on from the above discussion, where people (architects, engineers etc.) either have a bad previous experience of transactions or have heard rumours. However, there are at least a couple of other sides to this: first, people (biz-dev as well as engineers) simply not knowing that transactions exist (computer science is a large field, so it's not always the case that everyone knows about every one of its facets). More worrying though is the second aspect, which I've seen a few times - vendors of products that really could (and should) benefit from transactions not using them because they either don't understand the reasons why they need them (education again) or they don't want the perceived overhead in their products and are willing to take the risk (on behalf of all of their customers) that failures won't ever happen; and they may do it "silently". It's this last point that always annoys me and not simply because I've been working with transactions for a long time: if you go back to the insurance analogy, it's the equivalent of you buying insurance but the insurance company simply pockets the money and if/when you come to make a claim they feign ignorance, leaving you up the proverbial creek without a paddle. By the time you know there's a problem, it's already too late!
I think that there's a lot that we as a transaction industry can do to help this, through education, evangelising and improved product functionality/performance. But I also think there's a lot that the user can do, for instance by considering what the effects of failures might be in certain scenarios and, particularly in the case of 3rd party products/components where you might have been told failures "are handled", drill down into the "hows" and "whys" rather than just taking it for granted. You don't buy insurance from just anyone; you use trusted parties, such as banks, where trust is built up and the products assured and backed by the law. It's a shame we don't have something equivalent for software.
(i) overhead: it's true that you can never get something for nothing. But as we showed here with regard to principles, and I mentioned here with regard to our specific implementation, it doesn't have to be the case that you have to pay dearly (in terms of overhead and cash) to get the guarantees transactions offer. There's always a trade-off to be considered in pretty much any additional functionality you may want to add to an application, whether it's transactions for reliability/consistency, replication for availability/performance, security etc. Rather than think about what negative impact this functionality is going to have on your system, you need to consider what the impact will be on not having it. Now with the likes of security and replication it's fairly evident what benefits they bring most of the time. With transactions it's always a little more difficult, because most of the time you don't see the benefit: it's typically only when a failure happens. Now it is true that failures are not common, but they do happen - network failures, disk failures, memory failures etc. But in that case you should think of transactions like an insurance policy: how often do you claim on your home, car or travel insurance? Probably not that often. But most people will still renew their policies year after year, even when some (e.g., holiday insurance) aren't mandatory. Why? Because you don't want to take the risk and in simple terms the cost of insurance is significantly less than the cost of whatever it is that you're insuring. I'd like to see a time when transactions are seen to be so cheap that they're just part of the infrastructure that people take for granted. I think with something like ArjunaCore and the transaction implementation in Indigo that's starting to look possible.
(ii) education: in some ways this follows on from the above discussion, where people (architects, engineers etc.) either have a bad previous experience of transactions or have heard rumours. However, there are at least a couple of other sides to this: first, people (biz-dev as well as engineers) simply not knowing that transactions exist (computer science is a large field, so it's not always the case that everyone knows about every one of its facets). More worrying though is the second aspect, which I've seen a few times - vendors of products that really could (and should) benefit from transactions not using them because they either don't understand the reasons why they need them (education again) or they don't want the perceived overhead in their products and are willing to take the risk (on behalf of all of their customers) that failures won't ever happen; and they may do it "silently". It's this last point that always annoys me and not simply because I've been working with transactions for a long time: if you go back to the insurance analogy, it's the equivalent of you buying insurance but the insurance company simply pockets the money and if/when you come to make a claim they feign ignorance, leaving you up the proverbial creek without a paddle. By the time you know there's a problem, it's already too late!
I think that there's a lot that we as a transaction industry can do to help this, through education, evangelising and improved product functionality/performance. But I also think there's a lot that the user can do, for instance by considering what the effects of failures might be in certain scenarios and, particularly in the case of 3rd party products/components where you might have been told failures "are handled", drill down into the "hows" and "whys" rather than just taking it for granted. You don't buy insurance from just anyone; you use trusted parties, such as banks, where trust is built up and the products assured and backed by the law. It's a shame we don't have something equivalent for software.
A belated review for Eric's latest book
Web Services specification architecture book
Some of my friends/colleagues from IBM have finally gotten their book out. This gives a view of the Web Services architecture as IBM sees it, along with the specifications they see as fitting into it. Since most (all?) of the specifications are ones that IBM has been working on (in and predominately out of standards bodies), it may not be an objective view, but no one can argue that it's not important to the industry.
Now all I need do is write a review.
Now all I need do is write a review.
Saturday, April 30, 2005
WWW 2006
I'm the chair of the XML and Web Services track of WWW2006, which next year is being held in sunny Edinburgh. Santosh is my deputy (kind of makes a change after all these years) and we're in the process of drawing up the list of PC members. I'm not sure when the CFP will go out, but I suspect it'll be around August time, with reviews happening over December as they did for this year's conference. So, get those thinking hats on!
Thursday, April 28, 2005
Grid and Web Services work
The session concept for Web Services
Greg has posted about a paper we wrote at the end of last year. I won't repeat the whole story here, but I really hope the delays in publication are sorted out. Anyway, take a look at the paper. Greg is hopefully going to put up a pdf version shortly.
The utility of standards
Savas has definitely hit the nail on the head with regard to standards and what it means to talk about "compliance", "conformance" and interoperability. I've been working in the area of standards for more years than I care to remember and some of the standards I've come across have often been let down by their conformance statements, with a knock-on effect on interoperability. It is always difficult to get large companies with vested interests in their own products to agree to a standard that either obsoletes their product(s) or means they have to modify them; it does make sense to protect your investments. However, the benefits of standards only come when you pay more than lip-service to them and the "conforms to" label shouldn't be used as a badge of honour unless it really means something. Unfortunately there are many vendors, products and organisations that rely on the fact that their customers/users don't have the time or skills to see beyond the label and understand what it really means to them. I've often heard the complaint that customers get locked into a standard, when in fact what they really mean is that they've been locked into one vendor's interpretation of that standard.
WS-CAF in New Orleans
The WS-CAF committee has been meeting in New Orleans this week. Unfortunately due to previous commitments I couldn't make it in person, which meant I had to take part via teleconference. Not exactly the easiest to do: phone's were definitely not meant for day-long meeting; roll on the invention of some form of holographic avatar.
Anyway, despite the fact that several of us had to endure the telephone line frequency response of 300 Hz to 3400 Hz for two days, we made excellent progress. We've pretty much closed up all of the issues related to WS-Context (thanks to Kevin Conner for working on the schema and WSDL). With a little luck we'll be able to move that to another committee draft within the month. (Apparently the change in OASIS rules recently has had a knock-on effect on names such as "committee draft" and "committee standard" which I've yet to fully understand, but I know what I mean even if OASIS staff might argue.) I've said before that with hindsight, WS-Context is probably the most important and potentially influential specification of the entire WS-CAF stack. It was never intended to be, but as is often the case, the simplest things that get overlooked initially turn out to be the most important.
I'm not saying that coordination or transactions aren't important, but the applicability of context to Web Services (and any distributed architecture) is so much wider. As more Web Services specifications come along, it's easy to see how they are using a form of context without necessarily being explicit about it. Hopefully this is just an education thing and once WS-Context becomes a standard and we are able to evangelise about it more and more, there'll come a time when WS-Context is used as naturally as SOAP and WSDL. One of my next posts will be about a paper I helped write with Greg on this subject.
I'm also contributing to the OASIS SOA-RM technical committee on this and other aspects of WS-CAF, so that's another way of expanding the influence of context as a principle and WS-Context as a concrete example.
As far as the New Orleans work went though, we also made excellent progress with WS-CF (the coordination framework). I'm confident we're close to being able to finalise this and put it up for public review. The model is a little more focused now that it was when we first submitted the specifications. It's down to pure registration and groupings, with coordination as something that can be layered on top. As with WS-Context, I think this helps to increase its applicability and I suspect that Greg and I may be writing a paper on this eventually.
So that left transactions. I gave a presentation overview (again) of the models and we agreed that the first thing to do was separate our 3 models into individual specifications. This has a lot of merit, not least of which is the fact that it's easier to manage and easier for people to decide what aspects of transaction management they want to implement and still be able to say in a straightforward manner what they conform to. We've also decided that the first model we need to concentrate on is WS-ACID. This is primarily intended to interoperability of existing transaction processing systems, and I'm really looking forward to a future interoperability workshop where we can demonstrate transaction interoperability Arjuna-to-Oracle-to-IONA (for example).
Anyway, despite the fact that several of us had to endure the telephone line frequency response of 300 Hz to 3400 Hz for two days, we made excellent progress. We've pretty much closed up all of the issues related to WS-Context (thanks to Kevin Conner for working on the schema and WSDL). With a little luck we'll be able to move that to another committee draft within the month. (Apparently the change in OASIS rules recently has had a knock-on effect on names such as "committee draft" and "committee standard" which I've yet to fully understand, but I know what I mean even if OASIS staff might argue.) I've said before that with hindsight, WS-Context is probably the most important and potentially influential specification of the entire WS-CAF stack. It was never intended to be, but as is often the case, the simplest things that get overlooked initially turn out to be the most important.
I'm not saying that coordination or transactions aren't important, but the applicability of context to Web Services (and any distributed architecture) is so much wider. As more Web Services specifications come along, it's easy to see how they are using a form of context without necessarily being explicit about it. Hopefully this is just an education thing and once WS-Context becomes a standard and we are able to evangelise about it more and more, there'll come a time when WS-Context is used as naturally as SOAP and WSDL. One of my next posts will be about a paper I helped write with Greg on this subject.
I'm also contributing to the OASIS SOA-RM technical committee on this and other aspects of WS-CAF, so that's another way of expanding the influence of context as a principle and WS-Context as a concrete example.
As far as the New Orleans work went though, we also made excellent progress with WS-CF (the coordination framework). I'm confident we're close to being able to finalise this and put it up for public review. The model is a little more focused now that it was when we first submitted the specifications. It's down to pure registration and groupings, with coordination as something that can be layered on top. As with WS-Context, I think this helps to increase its applicability and I suspect that Greg and I may be writing a paper on this eventually.
So that left transactions. I gave a presentation overview (again) of the models and we agreed that the first thing to do was separate our 3 models into individual specifications. This has a lot of merit, not least of which is the fact that it's easier to manage and easier for people to decide what aspects of transaction management they want to implement and still be able to say in a straightforward manner what they conform to. We've also decided that the first model we need to concentrate on is WS-ACID. This is primarily intended to interoperability of existing transaction processing systems, and I'm really looking forward to a future interoperability workshop where we can demonstrate transaction interoperability Arjuna-to-Oracle-to-IONA (for example).
Friday, April 22, 2005
Monday, April 18, 2005
JavaOne 2005
Saturday, April 16, 2005
New Orleans and diving
I was hoping to go to the next face-to-face meeting of WS-CAF in New Orleans. As last year, we've made it coincident with the annual OASIS Symposium in New Orleans. Last year was my first time in the city and I loved it: great food, great music and a great atmosphere. Myself, Eric, Greg and other friends and colleagues managed to find time from the slog of standards work (none of that sniggering at the back please!) to check out some of the Jazz festival last year, so I was looking forward to going back. That and hopefully producing another Committee Draft of WS-Context, maybe the first Committee Draft of WS-CF and trying to start on WS-TXM (a lot for a 2 day meeting, I know).
Unfortunately I won't be able to go :-( For Christmas my wife enrolled me on a PADI open water diving course. I've been talking about learing to SCUBA dive for many years, going back at least to when we spent a week in the Carribbean as guests of Bluestone for being a Bluestone President's Club Aware Winner. Several friends have also qualified over the intervening years, including Jim who kept pushing me to go do it. However, as with most things that aren't work related, I always managed to find a reason to put it off. Until this year that is. I have to say that since starting the course I've had a lot of fun and wish I'd done it earlier. Unfortunately, there are exams connected with the course, both written and practical (in the ocean - we've been doing everything in the local swimming pool so far), and some of them are coincident with the New Orleans face-to-face. I tried to postpone them, but it ain't going to happen, so I'm not going to be at the meeting in person. Which leaves me looking forward to 2 days of attending the meeting via the phone!
Unfortunately I won't be able to go :-( For Christmas my wife enrolled me on a PADI open water diving course. I've been talking about learing to SCUBA dive for many years, going back at least to when we spent a week in the Carribbean as guests of Bluestone for being a Bluestone President's Club Aware Winner. Several friends have also qualified over the intervening years, including Jim who kept pushing me to go do it. However, as with most things that aren't work related, I always managed to find a reason to put it off. Until this year that is. I have to say that since starting the course I've had a lot of fun and wish I'd done it earlier. Unfortunately, there are exams connected with the course, both written and practical (in the ocean - we've been doing everything in the local swimming pool so far), and some of them are coincident with the New Orleans face-to-face. I tried to postpone them, but it ain't going to happen, so I'm not going to be at the meeting in person. Which leaves me looking forward to 2 days of attending the meeting via the phone!
Web Services seminar
It's been a busy few weeks for us and our friends at CodeWorks. We're putting on a Web Services seminar for local businesses to help educate them on the benefits of Web Services. Fortunately we've been able to attract some good speakers for the event, including my old friend Werner Vogels from Amazon. Now that he's the CTO of Amazon he's finding it hard to spend time with us lesser mortals ;-) but I'm definitely going to make sure he has the opportunity to sample a few good pubs while he's here!
The trouble with transactions ...
The folks over at Microsoft working on Indigo have been doing some interesting stuff with their transaction engine. I've been keeping abreast on this as much as possible for some time, so it's nice to see it coming to fruition. What's even more interesting from a personal perspective, is that the architecture they've come up with and the requirements it fulfills, is very similar to what we've been using now for many years: basically a lightweight transaction engine that can be used in situations where not all of the ACID properties are required, but which can dynamically "step up to the plate" (as one Microsoft friend described it) if the need arises.
In some previous posts I've touched on the fact that we have in house something that fits that bill: ArjunaCore. This is a transaction coordinator (plus some associated tools and development frameworks) that has a very small footprint (hey, it runs on an old HP Jornada 720 in significantly less than 32 Meg of memory!) It took us several years of design and development to come to the current architecture, that allows it to be used within every transaction-related product we currently have. Without going into too many details (read the paper), it allows us to relax some or all of the various ACID properties in a controlled manner within products and is extremely fast and agile.
Note, this is not a "one-size fits all" protocol I'm talking about here: it's purely implementation. There's an important difference and the evolution of ArjunaCore has simply reinforced that distinction in my mind. I'm in the process of writing a paper on this, so will hold off saying too much more here.
Transaction processing is a difficult technology to implement well and also to convince people that they need. Terms such as "two-phase commit" and "persistence" are ingrained into people's minds as bad things, synonymous with "poor performance" and "high overhead". When talking to people about how they can use transactions, I've often heard reasons for them not using them begin with "Well, the trouble with transactions in our view is ..." But that needn't be the case and in many situations, the lack of transactions can lead to a much higher overhead if failures occur. Again, I'm writing a paper on this subject at the moment, but may blog on some aspects of it later.
I've had the opportunity to work for the Microsoft/Indigo crowd on several occasions but the timing has never been right. So it's nice to see two independent groups coming to the same ultimate conclusion about how to bring transactions to the masses.
There are many applications out there that don't use transactions and should; likewise, there are applications using transactions that really don't need to. I've believed for a long time that there are several things that we as an industry can (and should) do to help people understand where transactions fit into their architecture: education (why are transactions important? what happens if you don't have them? etc.), ease of use, flexibility (this crosses many different aspects, but includes what can be controlled, e.g., transactions existed before XA, so you don't have to limit yourself to XA-aware participants), performance etc.
We've managed to get a lot of the implementation-side of the equation into ArjunaCore and are constantly working on the education aspect. I know other companies and organisations are starting to look at a similar approach, and in the meantime it's always nice to get some implicit validation from a company like Microsoft.
In some previous posts I've touched on the fact that we have in house something that fits that bill: ArjunaCore. This is a transaction coordinator (plus some associated tools and development frameworks) that has a very small footprint (hey, it runs on an old HP Jornada 720 in significantly less than 32 Meg of memory!) It took us several years of design and development to come to the current architecture, that allows it to be used within every transaction-related product we currently have. Without going into too many details (read the paper), it allows us to relax some or all of the various ACID properties in a controlled manner within products and is extremely fast and agile.
Note, this is not a "one-size fits all" protocol I'm talking about here: it's purely implementation. There's an important difference and the evolution of ArjunaCore has simply reinforced that distinction in my mind. I'm in the process of writing a paper on this, so will hold off saying too much more here.
Transaction processing is a difficult technology to implement well and also to convince people that they need. Terms such as "two-phase commit" and "persistence" are ingrained into people's minds as bad things, synonymous with "poor performance" and "high overhead". When talking to people about how they can use transactions, I've often heard reasons for them not using them begin with "Well, the trouble with transactions in our view is ..." But that needn't be the case and in many situations, the lack of transactions can lead to a much higher overhead if failures occur. Again, I'm writing a paper on this subject at the moment, but may blog on some aspects of it later.
I've had the opportunity to work for the Microsoft/Indigo crowd on several occasions but the timing has never been right. So it's nice to see two independent groups coming to the same ultimate conclusion about how to bring transactions to the masses.
There are many applications out there that don't use transactions and should; likewise, there are applications using transactions that really don't need to. I've believed for a long time that there are several things that we as an industry can (and should) do to help people understand where transactions fit into their architecture: education (why are transactions important? what happens if you don't have them? etc.), ease of use, flexibility (this crosses many different aspects, but includes what can be controlled, e.g., transactions existed before XA, so you don't have to limit yourself to XA-aware participants), performance etc.
We've managed to get a lot of the implementation-side of the equation into ArjunaCore and are constantly working on the education aspect. I know other companies and organisations are starting to look at a similar approach, and in the meantime it's always nice to get some implicit validation from a company like Microsoft.
A book that changed my life
While dusting the copious books shelves we have in our house, I came across a book that really did help me through a pretty difficult time in my life. My mother has had multiple sclerosis for many years and while it's a difficult enough ailment for the sufferer to cope with, because of it's nature (few outward physical signs to start with, the ability to put symptoms down to stress, or strain etc.) it's often hard for the family and friends of the sufferer to understand what's going on. This book helped at a time when neither my mother nor the doctors could really put the why's, how's and what if's into words. I'd recommend it for anyone else in a similar situation.
Thursday, April 14, 2005
Research papers made easy
In my spare time (!) I'm a visiting research fellow at Newcastle University. I've written a few papers in my time and it's rarely an easy process. However, now some nice people at MIT have come up with a paper generator. It's fun to try out. Here's one I just tried, inputing a few friends names.
The scarey thing is, I'm sure one of the random ones it produced for me looked like a paper I did write ;-)
The scarey thing is, I'm sure one of the random ones it produced for me looked like a paper I did write ;-)
Subscribe to:
Posts (Atom)