Entries for Tag: 'AMF'

This past week I have been thinking much more about AMF support for cf to cf communication. Some preface first: We have been doing more and more, and talking more and more about a SOA architecture where I work lately. We have project managers, developers and all sorts of people (some of which don't know as much about what it means on a nuts and bolts level) talking about it. And on a lot of levels, it does make a lot of sense. On a lot of levels it doesn't though, but that really isn't the point of this particular post. The point of this post is what is wrong with webservices. At least in my experience (which I will readily admit is somewhat limited) they are a pain to work with if you are doing anything more complicated than taking a few parameters and returning a result. Plus the true reusability of them gets harder when you are talking about anything more than very simple tasks. For instance, we have 209 branches across our company. My boss comes to me and asks how hard it would be to make a webservice that would take a zip code and give a list of all the customers in the zip code, or a list of all the branches that service that zipcode. Sure, thats simple. Probably would take half an hour. But that is a very simple example. Take something a little more complex, especially where you start putting in a lot of business logic and things can get messy in a hurry. We just finished building a fairly large project that all of our branches use. It has some particularly hairy business logic, but it did have some elements to it that could need to be done from other applications as well. So from the get go, we decided we were going to write all of those things in webservices, so our asp.net buddies could use them too. But at the end of the project, we go back and realize, there was too much business logic that was specific to the application in there. So the reusability is shot without quite a bit of refactoring (we were on a crazy deadline with the project and even though we realized things were going this way, we couldn't do anything about it at the time), plus, just by using the code as a webservice was adding quite a bit of overhead to the application. The overhead is the real crux of the issue though. We wanted to be able to pull the webservices off to another machine, which meant webservices was really the only way we could do it, plus we wanted other languages such as asp.net or java to be able to use them as well. But sometimes we are seeing a very large amount of overhead (sometimes half a second or better) just because we are doing things as a webservice instead of application specific code. Thats a pretty serious tradeoff. So thats where AMf could really really come in handy. The ability to use objects on a seperate machine as if they were on the same machine, all in binary data transfers would have amazing impact. But that alone, cf to cf, doesn't really get the job done. SOA architecture is buzzword lately, and despite the problems you will have with reusability (I really shouldn't say problems, I should say concerns that have to be worked out) they really are a great way to do business. The ability for QA to test certain services independantly could really speed up development, not to mention the saved time not having to rewrite or even copy code to every application. But webservices aren't really good enough. AMF on CF to CF is great for us CF only guys, but that doesnt help the other languages that want to leverage the same code. So heres the answer: not only give us AMF for CF to CF, but also CF to any other language... Now, what do I know as far as how much work that would take? I would imagine that it would take an api of sorts for each and every other language that would need it. But wow, if you could do this, and standardize it, imagine the implications. SOAP would be dead. Webservices as they currently exist would be obsolete overnight. Forgetting about the performance improvements (which I would think would be massive) just the overall ease of use with AMF if done correctly I would think would be huge. Now, if I have to choose between having AMF for CF to CF or not having anything at all I think you know what I would choose. But if they took it a step further, Adobe could revolutionize applications for the forseeable future. Ah, dreams...

Posted on Sun. August 06, 2006 by Ryan Guill #
Design, Photograph, Work © Ryan Guill, aDeepBlue 2013: All Rights Reserved. | Contact | RSS Feed