I appreciate the authors for presenting the papers on Virtual Machines and their architectural and design details. Last chapter and this one are interesting to me as I use J2EE heavily but never got a chance to read about the design and implementation of JVM. After reading these 2 chapters i felt like discovered lot of details. Specifically, I also liked portion of the chapter that talked about the JVM myths. This chapter focused more on the details of VM implementation more than architecture of it.
Major portion of the chapter talked about the Meta circular virtual machine. It is a VM where the runtime environment is coded in the same language as that being hosted. Jikes is coded in Java and acts as a Java runtime environment. This allows for many techniques to increase performance and functionality. I completely agree that using Java’s collection simplifies the development by allowing the components to focus on their roles. It is a great advantage of Java compared to languages likes C where the programmer needs to take care of managing the underlying data structure and memory.
Jikes RVM implemented its own threading because of lacking multithreading support in the previous century. However, chapter noted a reference for making an API for their thread usage supposedly allowing easy substitution of other threading techniques. Another successful open source project!!!
Tuesday, September 29, 2009
Our Pattern Language (OPL)
This paper is about parallel pattern language for parallel programming. Over all I like the paper as it gives overview of different parallel patterns but lacks details of any pattern.
The author organized the patterns into layered system. The layers in which the patterns are organized are:
• Architectural patterns
• Computational patterns
• Parallel algorithm strategy patterns
• Implementation strategy patterns
• Concurrent execution patterns
Author defined the full range of design patterns that programmers are likely to encounter when designing software for parallel platforms. he grouped patterns into a language to give conceptual framework view for the developers at each layer.
In near future I like to invest some time in exploring the co-ordination patterns as this parallel world make everything run independently and then co-ordination with others on to finish the tasks. Also security play bit more role than usual as different processor communicates with each other. So designing these items carefully are worthwhile.
The author organized the patterns into layered system. The layers in which the patterns are organized are:
• Architectural patterns
• Computational patterns
• Parallel algorithm strategy patterns
• Implementation strategy patterns
• Concurrent execution patterns
Author defined the full range of design patterns that programmers are likely to encounter when designing software for parallel platforms. he grouped patterns into a language to give conceptual framework view for the developers at each layer.
In near future I like to invest some time in exploring the co-ordination patterns as this parallel world make everything run independently and then co-ordination with others on to finish the tasks. Also security play bit more role than usual as different processor communicates with each other. So designing these items carefully are worthwhile.
Thursday, September 24, 2009
Adaptive Object-Model (AOM) Architecture Style
This is a bit long Paper, presents Adaptive Object-model (AOM), which can be thought of it as more flexible than conventional object-oriented design (OOD). Good examples are given and style is explained in details along with advantages and disadvantages.Very interesting concept for OO developers as i am one of them…
In AOM system, classes and their attributes and methods are represented as metadata and this model will be stored in database and system interprets and translates these models. So changing the application or class does not require changing the actual code but just the metadata. Changes to metadata are immediately interpreted and reflected in the running application and doesn’t need to deploy the code changes or make the system offline to release the new version. I think this is a very nice feature compared to conventional OOD systems.
I think this architectural style works great for system which needs flexibility and runtime configuration. I never work on this type model but definitely like to keep it in mind for future, but it was very cool to see the system be automatically changed in production whenever there was a change in the metadata.
It was mentioned in the paper that these type of projects are hard to understand and maintain not completely sure why can’t they be easily understood. Prof. Johnson may reveal the background in the evening class.
In AOM system, classes and their attributes and methods are represented as metadata and this model will be stored in database and system interprets and translates these models. So changing the application or class does not require changing the actual code but just the metadata. Changes to metadata are immediately interpreted and reflected in the running application and doesn’t need to deploy the code changes or make the system offline to release the new version. I think this is a very nice feature compared to conventional OOD systems.
I think this architectural style works great for system which needs flexibility and runtime configuration. I never work on this type model but definitely like to keep it in mind for future, but it was very cool to see the system be automatically changed in production whenever there was a change in the metadata.
It was mentioned in the paper that these type of projects are hard to understand and maintain not completely sure why can’t they be easily understood. Prof. Johnson may reveal the background in the evening class.
Tuesday, September 22, 2009
BA Ch8 : Guardian - A fault-tolerant System
Guardian was the Tandem’s OS, used in the 1970’s. It tried to be fault-tolerant, selling itself as a very reliable system. The core idea was that everything should be duplicated in case one goes down. The T/16 machines had at least two processors, two buses, (often) two disks, etc.
Each process would be duplicated on two processors. On one processor it would be active and on the other it would be passive waiting for the first one to die or give up control. In the reliability world there are basically three ways to recover in the face of failure - check pointing or job replication, or to attempt to repair the state of the execution. For the Guardian they chose to do application-controlled check pointing to allow for recovery. As such each program would be responsible for check pointing its state at various intervals and if a processor goes down the other one would start from the last checkpoint.
In my opinion, Fault-tolerant software is something really hard to achieve but trying to achieve the fault tolerant software is highly desirable in some important application like airplane apps or military apps etc…I don’t have any experience in this area but I like reading this chapter and its interesting to see how they focused on fault-tolerance parameter more than other parameters. I think they did good as this system is developed in 70’s.
Each process would be duplicated on two processors. On one processor it would be active and on the other it would be passive waiting for the first one to die or give up control. In the reliability world there are basically three ways to recover in the face of failure - check pointing or job replication, or to attempt to repair the state of the execution. For the Guardian they chose to do application-controlled check pointing to allow for recovery. As such each program would be responsible for check pointing its state at various intervals and if a processor goes down the other one would start from the last checkpoint.
In my opinion, Fault-tolerant software is something really hard to achieve but trying to achieve the fault tolerant software is highly desirable in some important application like airplane apps or military apps etc…I don’t have any experience in this area but I like reading this chapter and its interesting to see how they focused on fault-tolerance parameter more than other parameters. I think they did good as this system is developed in 70’s.
Big Ball of Mud
This paper definitely is the most interesting of the papers I have read so far in this class which described real world situations of the software field and also seems like very straight talk on how they emerged and what we can do about it. I like reading it and also it has nice relevant pictures with each main topic.
Software field has the notion of architecture is luxury or Architecture is a long-term concern? Can a building construction be started without blue prints of the architecture of the building? Can a person who just knows how to put walls together can start building a house without having the architecture of the house in hand? I am guessing the root cause for this style of thinking in software field is due to ignoring this is also engineering.
Big Ball of Mud - big, ugly systems emerge from throw-away prototypes and quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or non-existent documentation. It works, so why fix it?
One of mud's most effective enemies is sunshine. Subjecting convoluted code to scrutiny can set the stage for its refactoring, repair, and rehabilitation. Code reviews are one mechanism one can use to expose code to daylight.
Throw away code – created for immediate fix for a small problem, or a quick prototype or proof of concept but emerges into actual project. I like the examples presented to show most of us include our experiments in the actual code.
When you build a prototype, there is always the risk that someone will say "that's good enough, ship it". One way to minimize the risk of a prototype being put into production is to write the prototype in using a language or tool that you couldn't possibly use for a production version of your product.
Piecemeal Growth - Master plans are often rigid, misguided and out of date. Users’ needs change with time. Incrementally address forces that encourage change and growth. Allow opportunities for growth to be exploited locally, as they occur refactor unrelentingly.
Keep it working – Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system. Therefore, do what it takes to maintain the software and keep it going. Keep it working.
Layers - Different artifacts change at different rates. Therefore, factor your system so that artifacts that change at similar rates are together.
Sweeping it under the rug - Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control. Therefore, if you can’t easily make a mess go away, at least cordon it off. This restricts the disorder to a fixed area, keeps it out of sight, and can set the stage for additional refactoring.
Reconstruction - Your code has declined to the point where it is beyond repair, or even comprehension. Therefore, throw it away and start over.
I like this from the paper –
Kent Beck has observed that the way to build software is to: Make it work. Make it right. Make it fast [Beck 1997]. "Make it work" means that we should focus on functionality up-front, and get something running. "Make it right" means that we should concern ourselves with how to structure the system only after we’ve figured out the pieces we need to solve the problem in the first place. "Make it fast" means that we should be concerned about optimizing performance only after we’ve learned how to solve the problem, and after we’ve discerned an architecture to elegantly encompass this functionality. Once all this has been done, one can consider how to make it cheap
Software field has the notion of architecture is luxury or Architecture is a long-term concern? Can a building construction be started without blue prints of the architecture of the building? Can a person who just knows how to put walls together can start building a house without having the architecture of the house in hand? I am guessing the root cause for this style of thinking in software field is due to ignoring this is also engineering.
Big Ball of Mud - big, ugly systems emerge from throw-away prototypes and quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or non-existent documentation. It works, so why fix it?
One of mud's most effective enemies is sunshine. Subjecting convoluted code to scrutiny can set the stage for its refactoring, repair, and rehabilitation. Code reviews are one mechanism one can use to expose code to daylight.
Throw away code – created for immediate fix for a small problem, or a quick prototype or proof of concept but emerges into actual project. I like the examples presented to show most of us include our experiments in the actual code.
When you build a prototype, there is always the risk that someone will say "that's good enough, ship it". One way to minimize the risk of a prototype being put into production is to write the prototype in using a language or tool that you couldn't possibly use for a production version of your product.
Piecemeal Growth - Master plans are often rigid, misguided and out of date. Users’ needs change with time. Incrementally address forces that encourage change and growth. Allow opportunities for growth to be exploited locally, as they occur refactor unrelentingly.
Keep it working – Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system. Therefore, do what it takes to maintain the software and keep it going. Keep it working.
Layers - Different artifacts change at different rates. Therefore, factor your system so that artifacts that change at similar rates are together.
Sweeping it under the rug - Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control. Therefore, if you can’t easily make a mess go away, at least cordon it off. This restricts the disorder to a fixed area, keeps it out of sight, and can set the stage for additional refactoring.
Reconstruction - Your code has declined to the point where it is beyond repair, or even comprehension. Therefore, throw it away and start over.
I like this from the paper –
Kent Beck has observed that the way to build software is to: Make it work. Make it right. Make it fast [Beck 1997]. "Make it work" means that we should focus on functionality up-front, and get something running. "Make it right" means that we should concern ourselves with how to structure the system only after we’ve figured out the pieces we need to solve the problem in the first place. "Make it fast" means that we should be concerned about optimizing performance only after we’ve learned how to solve the problem, and after we’ve discerned an architecture to elegantly encompass this functionality. Once all this has been done, one can consider how to make it cheap
Big Ball of Mud
This paper definitely is the most interesting of the papers I have read so far in this class which described real world situations of the software field and also seems like very straight talk on how they emerged and what we can do about it. I like reading it and also it has nice relevant pictures with each main topic.
Software field has the notion of architecture is luxury or Architecture is a long-term concern? Can a building construction be started without blue prints of the architecture of the building? Can a person who just knows how to put walls together can start building a house without having the architecture of the house in hand? I am guessing the root cause for this style of thinking in software field is due to ignoring this is also engineering.
Big Ball of Mud - big, ugly systems emerge from throw-away prototypes and quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or non-existent documentation. It works, so why fix it?
One of mud's most effective enemies is sunshine. Subjecting convoluted code to scrutiny can set the stage for its refactoring, repair, and rehabilitation. Code reviews are one mechanism one can use to expose code to daylight.
Throw away code – created for immediate fix for a small problem, or a quick prototype or proof of concept but emerges into actual project. I like the examples presented to show most of us include our experiments in the actual code.
When you build a prototype, there is always the risk that someone will say "that's good enough, ship it". One way to minimize the risk of a prototype being put into production is to write the prototype in using a language or tool that you couldn't possibly use for a production version of your product.
Piecemeal Growth - Master plans are often rigid, misguided and out of date. Users’ needs change with time. Incrementally address forces that encourage change and growth. Allow opportunities for growth to be exploited locally, as they occur refactor unrelentingly.
Keep it working – Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system. Therefore, do what it takes to maintain the software and keep it going. Keep it working.
Layers - Different artifacts change at different rates. Therefore, factor your system so that artifacts that change at similar rates are together.
Sweeping it under the rug - Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control. Therefore, if you can’t easily make a mess go away, at least cordon it off. This restricts the disorder to a fixed area, keeps it out of sight, and can set the stage for additional refactoring.
Reconstruction - Your code has declined to the point where it is beyond repair, or even comprehension. Therefore, throw it away and start over.
I like this from the paper –
Kent Beck has observed that the way to build software is to: Make it work. Make it right. Make it fast [Beck 1997]. "Make it work" means that we should focus on functionality up-front, and get something running. "Make it right" means that we should concern ourselves with how to structure the system only after we’ve figured out the pieces we need to solve the problem in the first place. "Make it fast" means that we should be concerned about optimizing performance only after we’ve learned how to solve the problem, and after we’ve discerned an architecture to elegantly encompass this functionality. Once all this has been done, one can consider how to make it cheap.
Software field has the notion of architecture is luxury or Architecture is a long-term concern? Can a building construction be started without blue prints of the architecture of the building? Can a person who just knows how to put walls together can start building a house without having the architecture of the house in hand? I am guessing the root cause for this style of thinking in software field is due to ignoring this is also engineering.
Big Ball of Mud - big, ugly systems emerge from throw-away prototypes and quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or non-existent documentation. It works, so why fix it?
One of mud's most effective enemies is sunshine. Subjecting convoluted code to scrutiny can set the stage for its refactoring, repair, and rehabilitation. Code reviews are one mechanism one can use to expose code to daylight.
Throw away code – created for immediate fix for a small problem, or a quick prototype or proof of concept but emerges into actual project. I like the examples presented to show most of us include our experiments in the actual code.
When you build a prototype, there is always the risk that someone will say "that's good enough, ship it". One way to minimize the risk of a prototype being put into production is to write the prototype in using a language or tool that you couldn't possibly use for a production version of your product.
Piecemeal Growth - Master plans are often rigid, misguided and out of date. Users’ needs change with time. Incrementally address forces that encourage change and growth. Allow opportunities for growth to be exploited locally, as they occur refactor unrelentingly.
Keep it working – Maintenance needs have accumulated, but an overhaul is unwise, since you might break the system. Therefore, do what it takes to maintain the software and keep it going. Keep it working.
Layers - Different artifacts change at different rates. Therefore, factor your system so that artifacts that change at similar rates are together.
Sweeping it under the rug - Overgrown, tangled, haphazard spaghetti code is hard to comprehend, repair, or extend, and tends to grow even worse if it is not somehow brought under control. Therefore, if you can’t easily make a mess go away, at least cordon it off. This restricts the disorder to a fixed area, keeps it out of sight, and can set the stage for additional refactoring.
Reconstruction - Your code has declined to the point where it is beyond repair, or even comprehension. Therefore, throw it away and start over.
I like this from the paper –
Kent Beck has observed that the way to build software is to: Make it work. Make it right. Make it fast [Beck 1997]. "Make it work" means that we should focus on functionality up-front, and get something running. "Make it right" means that we should concern ourselves with how to structure the system only after we’ve figured out the pieces we need to solve the problem in the first place. "Make it fast" means that we should be concerned about optimizing performance only after we’ve learned how to solve the problem, and after we’ve discerned an architecture to elegantly encompass this functionality. Once all this has been done, one can consider how to make it cheap.
Thursday, September 17, 2009
Layers
This architectural pattern is very well known pattern to me but reading this paper revealed new thoughts and information. From the paper:
The Layers pattern helps structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction
Developing applications in layers provides an advantage for allowing incremental coding and testing to occur without disturbing other protocols. When thinking about layering, you should consider the following forces:
• Late source code changes should not ripple through the system.
• Interfaces should be stable.
• Parts of the system should be exchangeable.
• Possibility of building other systems at a later date with the same as the system currently being designed.
• Similar responsibilities should be grouped to help understandability and maintainability.
• The system will be built by a team of programmers, and work has to be subdivided along clear boundaries.
Layers pattern is very useful and seems very natural to apply in development. As long as interfaces are stably defined, new layers can be inserted, removed, or combined as necessary. Layering done poorly often results in complications for maintainability, understandability and upgradability etc. One also need to be more carful about deciding how many layers are needed and how design them etc. which are given in this paper.
The Layers pattern helps structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction
Developing applications in layers provides an advantage for allowing incremental coding and testing to occur without disturbing other protocols. When thinking about layering, you should consider the following forces:
• Late source code changes should not ripple through the system.
• Interfaces should be stable.
• Parts of the system should be exchangeable.
• Possibility of building other systems at a later date with the same as the system currently being designed.
• Similar responsibilities should be grouped to help understandability and maintainability.
• The system will be built by a team of programmers, and work has to be subdivided along clear boundaries.
Layers pattern is very useful and seems very natural to apply in development. As long as interfaces are stably defined, new layers can be inserted, removed, or combined as necessary. Layering done poorly often results in complications for maintainability, understandability and upgradability etc. One also need to be more carful about deciding how many layers are needed and how design them etc. which are given in this paper.
BA 7: Xen and Beauty of Virtualization
This is another intresting chapter. I read considerable amount about the virtualization but never really developed or used technology. Xen is a virtualization platform that allows one PC or server to run multiple operating systems simultaneously. This allows the users to do things like running different operating systems from the same machine or to provide one operating system for each application. Since I never used this technology directly, I wonder how the hardware can cope up with software demands. My PC struggles to run cleverly, with single operating system. I can’t imagine hosting multiple on it. If I decided to have sophisticated system I wouldn’t dare to run multiple operating system on it and they may take me where I was with my old one… In work I have seen CPU and RAM spike up when I use 2 or 3 tools with local test server. So, if I decided to run each tool in different OS does that help me gain more CPU or Memory?
So for me virtualization is still virtual. I think, I have to use it to believe that there is certain advantage with respect to performance and be able to run different application on different operating system successfully.
I like the distrust concept that was decried in this chapter. when distrust is built into the architecture, it minimizes the number of trusted components, and this therefore provides security by default. As it virtualizes entire computer itself, any possible problem or attack is isolated within that virtualized computer while the system as a whole works perfectly normal except the problematic virtual computer. I am interested in knowing more of this. Probably, I will try to read more on it later..
Xen is a very good example of successful open source project. It started from a university student and it became a successful project which had great influence to the whole computer industry.
As I juggle between my duties as wife, mom, software engineer and a student……open source industry looks promising…. What I mean is that if I have a great idea there are people out there who can help achieve thoughts to software...
So for me virtualization is still virtual. I think, I have to use it to believe that there is certain advantage with respect to performance and be able to run different application on different operating system successfully.
I like the distrust concept that was decried in this chapter. when distrust is built into the architecture, it minimizes the number of trusted components, and this therefore provides security by default. As it virtualizes entire computer itself, any possible problem or attack is isolated within that virtualized computer while the system as a whole works perfectly normal except the problematic virtual computer. I am interested in knowing more of this. Probably, I will try to read more on it later..
Xen is a very good example of successful open source project. It started from a university student and it became a successful project which had great influence to the whole computer industry.
As I juggle between my duties as wife, mom, software engineer and a student……open source industry looks promising…. What I mean is that if I have a great idea there are people out there who can help achieve thoughts to software...
Tuesday, September 15, 2009
Pipes and Filters:
The Pipes and Filter Architectural Pattern: Divides the task of a system in to sequential processing steps and these are connected through by the data flow through the system – The output data of a one step is input to the subsequent step. Each processing step is implemented by filter component. A filter consumes and delivers the data incrementally (so it delivers output before consuming whole input). Each pipe implements the data flow between adjacent processing steps. Filter components are the processing units of the pipeline.
There two types of filters: passive and active. Passive filters can either have data pushed to them or have data pulled from them. Most commonly, active filters are in a loop pulling its data from and pushing it down the pipeline. An active filter will begin processing on its own as a separate program or thread.
The Pipes and filters pattern is very popular and simple. I think, it’s better to use passive filters when data available asynchronously and Active filters are good when data is available all the time for processing.
There two types of filters: passive and active. Passive filters can either have data pushed to them or have data pulled from them. Most commonly, active filters are in a loop pulling its data from and pushing it down the pipeline. An active filter will begin processing on its own as a separate program or thread.
The Pipes and filters pattern is very popular and simple. I think, it’s better to use passive filters when data available asynchronously and Active filters are good when data is available all the time for processing.
BA Chapter 6 : The Architecture of the Facebook Platform
Very nice chapter. Author chosen a good example application to illustrate how architecture can help to extend a simple social web site to a powerful platform with rich features. Each new change caused architects to change the system using even more powerful design decisions to add the features while keeping the fundamental requirements of data privacy and sites integrity.
This chapter has good amount of details about the Facebook system. It more seems like application design than applications architecture. Since I am also in web/ enterprise applications design and development, I am able to grasp and relate to the concepts but thought it maybe too much for those who are new to these items.
I like the key ides presented in this paper like how the web service hand shake make the data accessible with in the Facebook user’s notion of privacy, how it implemented the external data access pattern, FBML Architecture, how FBML can combine the social data and privacy business logic, FBJS to make app dynamic and yet limits the any violations that may occur if they use general java script.
Here are my answers –
How are social networking sites, like Facebook, helpful to other applications?
I like the comment from the Eric “he who controls the data controls the web” good summarization …. For this question. Other applications who need the data which is available in these social networking sites can help them to get it and use it for their needs.
How / why did Facebook open itself up to 3rd party applications?
Well, give a cent and take a cent saying goes well here I guess. Facebook API, which allowed 3rd party applications to make calls to the social data of a Facebook users. I am guessing, Facebook opening up for query based web services may have lead to more people in putting their own data to Facebook to begin…..
How did FQL help to optimize Facebook service calls?
FQL helped to optimize Facebook service calls by pushing some of the processing for client (who may have to make multiple calls to get various data for different stages of the processing) on to the Facebook servers
Why was FQL particularly of value to developers?
FQL is veryo valuable to developers because it is almost like other well known data query language SQL. So they can easily get data by querying to it.
How did FBML help shape the current environment of third party integration with Facebook?
More and more traffic to the site for sure and more and more outside applications will access the face book’s social data wealth.
Do you think FBJS is a fair compromise to javascript for developers of applications on the Facebook platform? Why or why not?
I believe FBJS is fair. It limits Javascript that may violate the rules of the face book and also make sure to present the developer provided content when it is safe.
What do you think architectures such as the Facebook Platform mean for the future of online computing?
I think, more business approach these social networks to get the data and use it to promote their product and for that they use online business to catch users eye through these sites…again so we see more online computing…
This chapter has good amount of details about the Facebook system. It more seems like application design than applications architecture. Since I am also in web/ enterprise applications design and development, I am able to grasp and relate to the concepts but thought it maybe too much for those who are new to these items.
I like the key ides presented in this paper like how the web service hand shake make the data accessible with in the Facebook user’s notion of privacy, how it implemented the external data access pattern, FBML Architecture, how FBML can combine the social data and privacy business logic, FBJS to make app dynamic and yet limits the any violations that may occur if they use general java script.
Here are my answers –
How are social networking sites, like Facebook, helpful to other applications?
I like the comment from the Eric “he who controls the data controls the web” good summarization …. For this question. Other applications who need the data which is available in these social networking sites can help them to get it and use it for their needs.
How / why did Facebook open itself up to 3rd party applications?
Well, give a cent and take a cent saying goes well here I guess. Facebook API, which allowed 3rd party applications to make calls to the social data of a Facebook users. I am guessing, Facebook opening up for query based web services may have lead to more people in putting their own data to Facebook to begin…..
How did FQL help to optimize Facebook service calls?
FQL helped to optimize Facebook service calls by pushing some of the processing for client (who may have to make multiple calls to get various data for different stages of the processing) on to the Facebook servers
Why was FQL particularly of value to developers?
FQL is veryo valuable to developers because it is almost like other well known data query language SQL. So they can easily get data by querying to it.
How did FBML help shape the current environment of third party integration with Facebook?
More and more traffic to the site for sure and more and more outside applications will access the face book’s social data wealth.
Do you think FBJS is a fair compromise to javascript for developers of applications on the Facebook platform? Why or why not?
I believe FBJS is fair. It limits Javascript that may violate the rules of the face book and also make sure to present the developer provided content when it is safe.
What do you think architectures such as the Facebook Platform mean for the future of online computing?
I think, more business approach these social networks to get the data and use it to promote their product and for that they use online business to catch users eye through these sites…again so we see more online computing…
Wednesday, September 9, 2009
Pattern Language: Excerpts from Christopher Alexander (A timeless way of building)
These 3 chapters are talking about the buildings and their construction process and not so directly related to software architecture or software building but they naturally convenes us that it is our nature to observe a pattern and apply it when ever we needed to achive what ever we are looking to achieve. These chapters are very interesting to read and were given with great but simple examples. Author explained an analogy of how a flower can't be made rather it is generated from a seed. Similarly, The quality in towns and buildings cannot be made but rather generated indirectly by the ordinary actions of the people. Later on, author explains how patterns allow people to build new buildings in unique workable way but resembles similarities in the basics in building structures. This chapter includes an example of how farmer build his barn using / following basic patterns like barn shape , size and how to divide the barn space etc.. (Very interesting)
I like this from book:
"A pattern languages gives each person who uses it, the power to create an infinite verity of new and unique buildings, just as his ordinary language gives him the power to create an infinite variety of sentences."
3rd chapter beginning talks about how natural it is a person to choose a best place to build something to utilize the existing benefits of that place. But this chapter gives some reasoning’s on how to choose and what to keep in mind while choosing it. Example it suggest to keep open the south side of the building to get more light in to the house and asks to build the house around the trees and not to destroy them as they take more time to grow again. This one solely talks about building layout needs and patterns to choose based on different conditions of the area. Example – if it is impossible to get lighting to both sides of the room then suggest having more windows on the side of the room where you get light so that reflection can fill the whole room.
So, based on above I am implying this for software building:
You can’t create a quality solution rather generate it by following patterns and applying them according to needs to achieve required functionality and still create it your own unique way. Make sense!!!! Right? One more thing, this also supports prof. Johnson’s saying “don’t reinvent the wheel but rather reuse it in your own unique way”
ArchJava
ArchJava: Connecting Software Architecture to Implementation by Jonathan Aldrich, Craig Chambers and David Notkin
ArchJava is described as a small, backwards-compatible extension to Java that integrates software architecture specifications into Java implementation code.
The communication integrity that is enforced by Archjava looks like presented to only one or few views of architecture. As we saw in 4+1 or any other architecture style, there are other views which are just as important. I am thinking it may not be a good idea to enforce one and not the others and it may introduce inconsistencies or at least allow them to go undetected.
Overall, I think this type tools may be useful to enforce the design with actual implementation of the application. But need to make sure that it can cover wide range of languages and tools. As industry uses lot of tools and languages to implement a single application(ex: enterprise web application may choose to use J2EE, EJB, Spring, Struts, JSPs, etc…) limitation presented in this paper like only applicable to programs written in a single language and running on a single JVM needs may not help much.
ArchJava is described as a small, backwards-compatible extension to Java that integrates software architecture specifications into Java implementation code.
The communication integrity that is enforced by Archjava looks like presented to only one or few views of architecture. As we saw in 4+1 or any other architecture style, there are other views which are just as important. I am thinking it may not be a good idea to enforce one and not the others and it may introduce inconsistencies or at least allow them to go undetected.
Overall, I think this type tools may be useful to enforce the design with actual implementation of the application. But need to make sure that it can cover wide range of languages and tools. As industry uses lot of tools and languages to implement a single application(ex: enterprise web application may choose to use J2EE, EJB, Spring, Struts, JSPs, etc…) limitation presented in this paper like only applicable to programs written in a single language and running on a single JVM needs may not help much.
Sunday, September 6, 2009
Architectural Blueprints – The 4+1 Views:
Beginning of this paper reminded me of MVC (Model-View-Controller) architecture style. At the end of reading this paper I am convinced that this architecture model can work well for big projects and may not be worth of including this much over head for small / medium size projects.
Here is the brief of this architecture –
Software architecture model proposed in this paper is made up of five main views
- The logical view, which is the object model of the design.
- The process view, which captures the concurrency and synchronization aspects of the design.
- The physical view, which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect.
- The development view, which describes the static organization of the software in its development environment.
- The description of an architecture—the decisions made—can be organized around these four views, and then illustrated by a few selected use cases, or scenarios which become a fifth view.
I like the fact that it is focusing on key elements and key users
- End-user –Functionality
- Programmers - Software management
- System engineers – Topology - Communications
- Integrators – Performance – Scalability
It is interesting to see these views developed. I tried to look back and see how the initial design of Design Town’s architecture views are (pretty interesting, try it out). I think, experience may be required to fully apply the “4+1” strategies in a project.
Beautiful Architecture - First 4 Chapters
I am new to blogging, so I thought I would wait for a week to watch and learn and also do little experiment of seeing how much I can learn just by reading all your blogs. So I did. I was able to grasp first 4 chapters of Beautiful Architecture (by Diomidis Spinellis & Georgios Gousios) by just reading your blogs. I started reading actual book this week. Here is my take on it –
Introduction of the Beautiful Architecture:
This book is compilation of papers written by other authors but each of these chapters has nice co-ordination with others. This book describes different architectures like Enterprise Application Architecture, Resource – Oriented Architecture, End-User Application Architectures etc. Looks like this is a good book suggestion to software Architects who like to read! (I will give my full review at the end of this semesterJ)
Chapter 1: What is Architecture
What is Architecture? Well, definition may depend on what field are we talking about. But besides the any differences, there are many items that are common among the different disciplines. Particularly, architecture can help build the system that meets the needs of its stakeholders, and it can help to manage the complexity of system that needs to be build, planning, building, and maintaining the system. Architecture helps to assure that the building, bridge, or system has the desired properties and behaviors, when it has been built.
Architecture helps teams to focus on functional and non-functional requirements and keeps all on the same page with respect to the system’s building and provides a conceptual integrity of the system.
Principles gathered from “Foreword” by Stephen J. Mellor –
These are universal principles which make an architect beautiful.
One fact in one place: avoid duplicity; common functionality should be factored out into separated modules. Be aware of changes.
Automatic propagation: maintain consistency and correctness; propagation must be carried out automatically at construction time.
Architecture includes construction: architecture must include not only the runtime system but also how it is constructed.
Minimize mechanisms: less code to write, verify, maintain and occupy memory.
Construct engines: extensible systems rely on the construction of engines that are “programmed” by data provided by higher layers and that implement multiple application functions at a time.
O(G), the order of growth: consider the direction of likely growth and account for it.
Resist entropy: beautiful architecture are preserved over time. Changes will be consistent with it and not increase system entropy.
Whenever we are evaluating or designing architecture we should consider these principles to tell if the architecture in question is beautiful or not.
Chapter 2: A Tale of 2 systems
Author presents 2 software systems like a city. One is called Messy Metropolis which is not build based on any structure or order as name says very messy one. Other one is called design town which is structured very carefully.
I feel like this chapter showed extremes of both good and bad systems. But none the less, I also have seen similar to messy metropolis style and design town style. In my view, A system will end up as a Messy metropolis style if it is build to save the money or to meet aggressive dead line or let novice developers develop the system (believe or not , these days, In a software development teams software engineers are out numbered to others). There is this other category where legacy systems started long back as small project and with those old software platforms, but have grown over the years into messy systems. I agree with the author that it was very brave for the organization to take the step of rewriting the application.
Design town system shows how little efforts of planning and foreseeing the system in the long run help to build a beautiful system. The author mentioned great points to consider for making a good architecture. This is very important and useful when building a new system.
Chapter 3: Architecting for Scale
So far in my career, I mostly developed enterprise applications, this chapter is very interesting one for me. It talks about flexibility in scaling the system according to current and future needs. Nice reading of the chapter, find few contradiction with respect to Latency but can’t really comment on it. Gaming is not my schedule in near or far future…
Chapter 4: Making Memories
This chapter talks about the architecture used for photography labs, where pictures are taken in a studio, enhanced and ordered at the studio. They are then sent to a processing center where they are rendered and printed, then sent back to the studio for pickup by the customer.
In designing the new software, the architects solved many problems, including concurrency issues at the studios, compiling the software, making the GUI easy to use and making the most use of the bottleneck - the rendering pipeline. They also recognized the need to make everything easy to upgrade since there are hundreds of distributed sites.
Most of the ideas presented in this chapter like incremental design, code reviews, unit testing etc. seems to be very common to me but reminded me to keep learning them and applying them while I develop applications.
Introduction of the Beautiful Architecture:
This book is compilation of papers written by other authors but each of these chapters has nice co-ordination with others. This book describes different architectures like Enterprise Application Architecture, Resource – Oriented Architecture, End-User Application Architectures etc. Looks like this is a good book suggestion to software Architects who like to read! (I will give my full review at the end of this semesterJ)
Chapter 1: What is Architecture
What is Architecture? Well, definition may depend on what field are we talking about. But besides the any differences, there are many items that are common among the different disciplines. Particularly, architecture can help build the system that meets the needs of its stakeholders, and it can help to manage the complexity of system that needs to be build, planning, building, and maintaining the system. Architecture helps to assure that the building, bridge, or system has the desired properties and behaviors, when it has been built.
Architecture helps teams to focus on functional and non-functional requirements and keeps all on the same page with respect to the system’s building and provides a conceptual integrity of the system.
Principles gathered from “Foreword” by Stephen J. Mellor –
These are universal principles which make an architect beautiful.
One fact in one place: avoid duplicity; common functionality should be factored out into separated modules. Be aware of changes.
Automatic propagation: maintain consistency and correctness; propagation must be carried out automatically at construction time.
Architecture includes construction: architecture must include not only the runtime system but also how it is constructed.
Minimize mechanisms: less code to write, verify, maintain and occupy memory.
Construct engines: extensible systems rely on the construction of engines that are “programmed” by data provided by higher layers and that implement multiple application functions at a time.
O(G), the order of growth: consider the direction of likely growth and account for it.
Resist entropy: beautiful architecture are preserved over time. Changes will be consistent with it and not increase system entropy.
Whenever we are evaluating or designing architecture we should consider these principles to tell if the architecture in question is beautiful or not.
Chapter 2: A Tale of 2 systems
Author presents 2 software systems like a city. One is called Messy Metropolis which is not build based on any structure or order as name says very messy one. Other one is called design town which is structured very carefully.
I feel like this chapter showed extremes of both good and bad systems. But none the less, I also have seen similar to messy metropolis style and design town style. In my view, A system will end up as a Messy metropolis style if it is build to save the money or to meet aggressive dead line or let novice developers develop the system (believe or not , these days, In a software development teams software engineers are out numbered to others). There is this other category where legacy systems started long back as small project and with those old software platforms, but have grown over the years into messy systems. I agree with the author that it was very brave for the organization to take the step of rewriting the application.
Design town system shows how little efforts of planning and foreseeing the system in the long run help to build a beautiful system. The author mentioned great points to consider for making a good architecture. This is very important and useful when building a new system.
Chapter 3: Architecting for Scale
So far in my career, I mostly developed enterprise applications, this chapter is very interesting one for me. It talks about flexibility in scaling the system according to current and future needs. Nice reading of the chapter, find few contradiction with respect to Latency but can’t really comment on it. Gaming is not my schedule in near or far future…
Chapter 4: Making Memories
This chapter talks about the architecture used for photography labs, where pictures are taken in a studio, enhanced and ordered at the studio. They are then sent to a processing center where they are rendered and printed, then sent back to the studio for pickup by the customer.
In designing the new software, the architects solved many problems, including concurrency issues at the studios, compiling the software, making the GUI easy to use and making the most use of the bottleneck - the rendering pipeline. They also recognized the need to make everything easy to upgrade since there are hundreds of distributed sites.
Most of the ideas presented in this chapter like incremental design, code reviews, unit testing etc. seems to be very common to me but reminded me to keep learning them and applying them while I develop applications.
Subscribe to:
Posts (Atom)