Distributed Systems

Looking into Distributed systems for this blog actually led me to the discovery of something else as well. I was unaware that Google had complete tutorials on computer science related areas as well as environments to experiment with via code.google.com. I learned this because I found a whole section on Distributed systems with tutorials from Google, from various universities, and tools to aid in your learning. Looking into Google's tutorial, their definition of a distributed system is accomplished by defining many other things, they call this a cascading definition. "
What is a distributed system? It's one of those things that's hard to define without first defining many other things. Here is a "cascading" definition of a distributed system:

A program

is the code you write.

A process

is what you get when you run it.

A message

is used to communicate between processes.

A packet

is a fragment of a message that might travel on a wire.

A protocol

is a formal description of message formats and the rules that two processes must follow in order to exchange those messages.

A network

is the infrastructure that links computers, workstations, terminals, servers, etc. It consists of routers which are connected by communication links.

A component

can be a process or any piece of hardware required to run a process, support communications between processes, store data, etc.

A distributed system

is an application that executes a collection of protocols to coordinate the actions of multiple processes on a network, such that all components cooperate together to perform a single or small set of related tasks."

 

Basically as I understand everything, a distributed system is like taking a server, with all of its services and components, and spreading it out over many systems that interact with each other. This makes it very powerful but difficult to implement because so many things must communicate to each other. The biggest concern in distributed systems are software errors.  Software failures are a significant issue in distributed systems. Even with rigorous testing, software bugs account for a substantial fraction of unplanned downtime (estimated at 25-35%)Any way, this site is really cool and there is so much information that I will definitely be giving it another look. 

http://code.google.com/edu/parallel/

Domain Exploitation

Twenty - six hundred (usually used with numerals instead of written out) is a magazine that I enjoy reading to find out what the latest security holes are from those who find them. In an interesting article from one of my older issues I came across an article detailing how to turn a 'local machine' administrator into a 'domain' administrator.

I am not going to post the code that was detailed in the article but it is a fairly straightforward  procedure that I will vaguely describe (in case this has not been patched). Using a batch file with the basically four lines of code and placing it in the all users startup folder will allow it be run by any user logging onto that computer, most importantly a current domain administrator.

If you don't want to rely on that you can create another batch file that will propagate over the entire domain. Kinda spooky but good to keep an eye on.

Dunn, D. (2010, Autumn 00). How to turn local admin into domain admin. 2600: The Hacker Quarterly, 27(3), 68.

SOA Design Patterns

According to an article about SOA design patterns, they are patterns that relate to other patterns. What that means is that "in order to apply one pattern, you may be required to apply (or have already applied) another."(PCWORLD)

What these SOA patterns do, aside from relate to one another is to provide a framework for real world applications. For example:" a pattern called Logic Centralization essentially establishes a rule whereby, for any given reusable body of solution logic, only one official service can exist. This reduces the risk of redundancy and maximizes reuse potential among services within a given domain." Here this pattern is applied: "imagine a service that encapsulates several databases and a legacy system. Even if we centralize the logic represented by the service, we are still not doing anything to prevent all of these underlying resources from being accessed directly via traditional-style integration channels. This is where Contract Centralization enters the picture.
The Contract Centralization design pattern limits external access to a service to its published technical contract (or interface or API), which means that the underlying resources cannot be touched by outside programs or applications (which we can refer to as service consumers), because the sole point of entry is the service contract.


As you can see this is quite involved but below is the link to the article for further reading.


http://www.pcworld.com/businesscenter/article/150569/working_with_soa_pattern_relationships.html

System Modeling

A water supply authority in Florida needed a good way to model potential sources of water. Turning to developers. the water supply asked for a way to model for the future. "The modeling tool would compare candidate systems based on ability to meet projected future demands for water. This ability is a function of both the actual raw water supplies available and configuration of the system components—the reservoirs, wells and water treatment facilities that produce finished water."

Using Microsoft Access, Visual basic, and a core modeling system called STELLA, developers were able to provide a fluid way to enter data and generate a model.

 One of the biggest challenges to this project was probably the development time frame of six months.

Beckers, C., Moore, E., Coates, M., & Hochuli, S. (2007). Modeling System Helps Authority Plan for Water Supply Needs. WaterWorld, 23(11), 16. Retrieved from EBSCOhost.

http://0-content.ebscohost.com.library.acaweb.org/pdf19_22/pdf/2007/WWR/01Nov07/27584355.pdf?T=P&P=AN&K=27584355&S=R&D=f5h&EbscoContent=dGJyMNLe80Sep7M40dvuOLCmr0mep65SsK64SbOWxWXS&ContentCustomer=dGJyMPGsr0y1q7NPuePfgeyx44Dn6QAAuthority

Issues with requirements

The biggest issue when obtaining software requirements lies in communication. According to the article I read Businesses often like to respond with lengthy, wordy descriptions about what they want to accomplish. Software developers on the other hand like to make diagrams and mock-ups (visual prototypes) of what the finished product should be like.

The problem lies in making sure that the requirements that are given in the first place are correct. According to the article rather than jumping straight into prototyping what is initially presented, developers should go back over the wordy documents presented to them by the client and analyze and verify it in the same manner. After this verification developers can move onto graphic representations of what they think the client is going to want. In this manner "Garbage in Garbage out" can be avoided.

Marasco, Joe. Dr. Dobb's Journal32. 9 (Sep 2007): 10.

Transitioning to Agile

An article in PC World Magazine (based on an excerpt from a book) details the best way a company can transition to an Agile methodology. This article is great because instead of focusing on any one project it describes how an organization can change their methodology, say from a waterfall, to an agile one. The key is change within, not from without.

When changing to an agile method in a company, Gregory Smith writes that the key is to have a core group that are not part of management but instead the actual developers. These core group members should also come from all "functional" areas of the company. "What better way to create awareness than to have Agile Core Team members come from each functional area. Imagine a member being from quality and going back to the quality team and telling them what is going on with the new methodology, or a developer doing the same with the development team." (Smith) The author, who is a CIO, strongly believes that by growing the agile methodology from within, instead of having outside consultants come in makes adaptation much more effective. This makes sense as you are much more likely to trust in a change from someone you "know" rather than a "know it all stranger". 

www.pcworld.com
The Core Dev Team's Role in an Agile Project
http://www.pcworld.com/businesscenter/article/153213-2/the_core_dev_teams_role_in_an_agile_project.html

Introduction

Hi Everyone,
                   my name is Hans and I am a Junior in the program. I have a daughter in first grade, go to school full time, and recently snagged a position as a full time IT Systems Administrator. All this means is that I am very busy but love what I do. This summer was a great time for me as I was able to travel to Europe with the school and to truly find my center during the break. I am looking forward to this year and everything there is to learn.