Updates to the ALF Website
Well I've been out of the loop for a few days in the UK. Here is a summary of the news and what's happening this week.
ALF is going to be shown off at EclipseCon in March in Santa Clara, CA. Serena is a Gold level sponsor and investing the money to showcase the Proof of Concept code. This is great opportunity for networking with other Eclipse community members and software vendors. This is where the big push for building the ecosystem will occur.
The Requirements Team's next meeting is the 25th of January - they are skipping this week. There is a new Requirements Document, just published, out there for review. Also just published are the minutes of the last Requirements meeting in the ALF Newsgroup.
The Archtecture team is meeting this week on Thursday the 19th at 11:00 PST.
The Planning team is meeting this week on Friday the 20th at 11:00 PST.
Major activities this week are further preparation for the publication of the Proof of Concept code. We have all the vendors' products installed on the VMWare image and the ALF framework code too. We are spending this week configuring and tuning the installation.
Kevin
posted by Kevin Parker, ALF Project Evangelist @ 9:23 AM
5 comments
5 Comments:
Thanks for visite my blog.
If you like my blog put here in your blog a link to them,
Tanks
Hey Kevin, I don't want to sound dense or anything, but what exactly is ALF?
I'm coming from the viewpoint of a developer. If you were to explain ALF to a developer, how would you do it? Why should I care? Any concrete examples would be fantastic.
Right now, you guys have the award for most vague project description :)
I'm sorry you think our project definition is vague. I'll try to help.
ALF Definition
ALF is SOA for Application Lifecycle Management. (ALM) That helps, right? I'll try to be a bit more specific with an example.
Assume you have an ALM process (it might simply be a manual procedure) where high priority defects need to be added to the project plan of the currently worked release, assuming the release is still in development. You can think of how it would work: A defect comes in and a bunch of people sit around in a CCRB and decide whether it is high priority. Then once they decide someone sends email to the project manager and the development manager. The dev mgr finds and assigns a resource and the project manager adds the defect to the project plan. If everything goes exactly right, and nobody forgest to email, and nobody is on vacation, then the release date will automatically be re-calculated, the defect will be fixed and tested and everything will be peachy.
Yea, that's going to happen.
The more likely scenario is that there will be a lot of arguing in the CCRB about the exact definition of 'high' priority. Then the product manager will forget to send the email right off. When she does remember, she gets the data wrong and has to meet with everyone to get the right one being worked and the wrong one dropped off the release.
Once the product manager has got the right data to the project manager and the development manager, the PM forgets to revise the schedule and the dev mgr forgets to assign the task.
Once that gets fixed, then someone has to remember to talk to documentation, QA and support to make sure the bug gets tested, support knows the fix is in the release and doc knows to update the readme. Of course, none of those tasks will ever be forgotten or delayed.
Now consider what the scenario would be with ALF.
First, when a bug is entered, there is an ALF event captured by the ALF Event Manager that spawns off a BPEL process associated with the event. The BPEL process uses Web Services (This is SOA, remember) to call back the issue and defect tracking (IDT) system and get the details of the defect. Once the BPEL process gets the defect information, it can use business rules to classify the defect automatically and update the defect with the classification in the IDT system.
If the defect happens to have high priority, then the BPEL process will next call a web service associated with the development task management system and will add the defect to the development task list. It will do the same for project management, QA, documentation and support.
All the manual coordination goes away, replaced by events and web service orchestration.
The process is automated, orchestrated, synchronized and dependable. Yadda, yadda, yadda.
So much for your example, and now for some architectural details.
ALF for Developers
ALF is essentially two components, an event manager and a BPEL engine. The role of the event manager is to handle or manage important 'events' that happen in the world of Application Lifecycle Management. (ALM) For example, when a defect is created. The role of the BPEL engine is to orchestrate the services and implement the business rules defined by the BPEL process designer.
It's that simple. ALF is a very simple, very minimal, very functinal SOA platform for organizations that don't need all the bells and whistles provided by products such as Tibco, Fiorano, Oracle, BEA, etc.
Hope this help.
Dear Chris,
Thanks for the feedback. I will try and bring some clarity to the description - its time I updated it in any case and your insight prompts me to do so. I will use some of Shaw's articulate desciption as my starting point.
Sincerely,
Kevin
Very interesting post. I need help in finding more information on "online ebook responders". Have a look at this link http://www.digiserveonline.com. I am thinking of subscribing to it. Any pointers?
Post a Comment
<< Home