Through the workshop series presented in this subject i have gained a deeper understanding of how to utilize web frameworks such as Rails and Django as well as the Ruby language itself, working my way through the workshop series i continually found myself adapting to the Convention over Configuration style and in turn found myself applying it to other areas of work.

Coming into this subject i didn’t know what to expect and thought it was going to be another theory based subject, but overall i found it to be educational, informative and most of all enjoyable.

So in conclusion I say lets look forward to the future of the internet and embrace all the prospective advancements that will come with it.

My audio recording can be found at the following link:

http://athene.riv.csu.edu.au/~jrankm01/elevatorpitch2.mp3

Thanks For The Great Subject.

Cheers.

Jason Rankmore

1. List what you consider to be the three strengths of Ruby on Rails workshop series:

• One of the strengths which i found that the workshop had is that it encourages the use of new technologies and frameworks to not only expand our knowledge but also technical skills.
• Another strength of this workshop series is that it pushed you to go beyond the workshop and also read other articles, books etc. to gain a further understanding of the concepts being taught.
• The major strength that i found this workshop had is that it did not give you detailed step by step instructions on how to develop the OTBS, rather it promoted us to research and develop it ourselves which in the end increased my technical skills in terms of RoR applications and Ruby Programming.

2. List what you consider to be the three weaknesses of Ruby on Rails workshop series:

• I found the first few workshops to be rather confusing, they lacked any real sense of instruction and direction.
• I also found that it took a little too long to start programming with ruby, this may have led to my lack of focus in relation to the development of the OTBS.
• Apart from the two weaknesses listed above i also consider the division of the workshop into developer/manager groups to be rather confusing, as a developer in the later workshops i found that the instructions were vague and that they were more focused on the management side of things.

3. List what aspects of Ruby on Rails workshop series that you found to be most difficult:

• The most difficult aspect that i found was the conceptualization and development of the OTBS, this was due to the fact that the actual development of the OTBS was introduced a  little too late in the series.

4. List what improvements could be made to the Ruby on Rails workshop series:

• Provide a clearer sense of direction for the series as a whole.
• Provide clearer instructions on the work that is to be completed for each workshop.
• Focus more on the workings of rails rather than architectural patterns, other frameworks etc.

5. Reflect on your experiences with the other Web framework used in this subject: Was it effective? How can it be improved? Should other Web frameworks be used as well or instead of Ruby on Rails?

I believe that the subject should focus the majority of it’s attention on Ruby on Rails, even though it is important to know that other frameworks and technologies i believe that Ruby on Rails is the superior framework, it emphasizes not only good programming styles but shows how frameworks can be used to rapidly develop web application while reducing the coding effort on behalf of the programmer/s.

6. Did the Developer’s or IT managers Team that you joined after workshop 4 have a preference towards using other tools to facilitate collaboration? Comment on the differences between these use of the sub-forum or Interact wiki tools from your experiences in this subject.

I wasn’t able to provide any input to either team as i had to focus a lot of my time on the major project which i was developing for another subject, but from what i have seen there has not been as much discussion as initially intended.

7. Further comments to add?

Apart from the weaknesses i found the series to be instructional, informative, educational and overall quite enjoyable.

This workshop looks at the migration and deployment of the OTBS as well as other RoR applications after the development process has been completed, this means moving the developed system onto a compatible platform and web server, some popular options for this include:

1. Phusion: Which is a module for the Apache web server for the development of Ruby Applications. Phusion boasts a number of features, these include:
   • Deployment is only a matter of uploading application files. No Ruby (on Rails)-specific server configuration required.
   • Allows Ruby on Rails applications to use about 33% less memory, when used in combination with Ruby Enterprise Edition.
   • Zero maintenance. No port management, server process monitoring or stale file cleanup required. Errors are automatically recovered whenever possible.
   • Designed for performance, stability and security. Phusion Passenger should never crash Apache even in case of crashing Rails applications.
2. JRuby: Which is a Java implementation of Ruby, this allows cross platform deployment of ruby application, although JRuby does provide an easy configuration and cross platform deployment it does suffer from some performance issues which may affect client side users.
3. Mongrel/Mongrel Cluster: Mongrel is a single threaded web server devoted to the deployment of Ruby applications and with the addition of Mongrel Cluster (which is a gem that runs several mongrel processes under the one config) is a formidable opponent to the two options mentioned above, Mongrel uses plain HTTP to provide faster performance speeds by reducing the execution steps.

References

http://www.modrails.com/

From a developers point of view the this workshop pushes the idea that systems like the OTBS could be modified to provide some sense of social networking functionality, whether it be by performing tasks such as passing messages, creating schedules, managing drivers etc. Other aspects of social networking could also be applied to the OTBS in ways such as tracking the current location of drivers, availability statuses etc. These functions would not only extend the functionality of the OTBS system but may also have an affect on the overall scalability of the end product.

Online systems use the integration of web services and functions to provide a functional system, this is achieved through the use of service descriptions. These service descriptions consist of three parts:

• Schema definition.
• Interface definition
• Location definition.

XML can be used alongside web services can be used to make a service definition, which will allow the system to be integrated. XML is particularly effective in this area as it allows the creation of custom schemas, these schemas allow the data within the system to be described and formatted. This aids in the integration of the system components, especially if one standard schema is used.

Web services are used in online systems as they are designed to support communications between components to achieve a level of integration, there are a number of ways which can be achieved. A common method is the use of SOAP messages, although another has arose recently, this is REpresentation State Transfer or REST; which uses HTTP methods which often provide a higher level of integration with HTTP and web browsers.

I have taken a particular interest in this area due to my experience with online systems and my recent use of Ruby on Rails and Java.

Wikipedia defines a location based service as:

A location-based service (LBS) is an information and entertainment service, accessible with mobile devices through the mobile network and utilizing the ability to make use of the geographical position of the mobile device. LBS services can be used in a variety of contexts, such as health, work, personal life, etc. LBS services include services to identify a location of a person or object, such as discovering the nearest banking cash machine or the whereabouts of a friend or employee. LBS services include parcel tracking and vehicle tracking services. LBS can include mobile commerce telecommunication convergence. when taking the form of coupons or advertising directed at customers based on their current location. They include personalized weather services and even location-based games.

Basically a Location Based Service is an online application or system that is accesible by a mobile device, whether it be a mobile phone, PDA, iPod etc. or perform functions for other devices such as smart cards, biometric scanners etc. which use online services. Technologies such as WLAN, BlueTooth, InfraRed are used in location based services to not only track the location of the mobile device being used but also to allow the devices to access information or services based on the geographic location of the device.

Some examples of location based services are:

• Turn by turn navigation.
• Viewing devices located in a certain range.
• Location based advertising.
• Finding nearest ATM’s, Banks, Restaurants etc.
• PDA’s for nurses, restaurants etc.

Describe the Purpose of The Open Mobile Alliance Initiative.

The Open Mobile Alliance describes their purpose and goals as:

MA was formed in June 2002 by nearly 200 companies including the world’s leading mobile operators, device and network suppliers, information technology companies and content and service providers. The fact that the whole value chain is represented in OMA marks a change in the way specifications for mobile services are done. Rather than keeping the traditional approach of organizing activities around ‘technology silos’, with different standards and specifications bodies representing different mobile technologies, working independently, OMA is aiming to consolidate into one organization all specification activities in the service enabler space.

OMA is the focal point for the development of mobile service enabler specifications, which support the creation of interoperable end-to-end mobile services. OMA drives service enabler architectures and open enabler interfaces that are independent of the underlying wireless networks and platforms. OMA creates interoperable mobile data service enablers that work across devices, service providers, operators, networks, and geographies. Toward that end, OMA will develop test specifications, encourage third party tool development, and conduct test activities that allow vendors to test their implementations.

OMA has pioneered significant consolidation of mobile service enabler organizations with the integration of the WAP Forum, Location Interoperability Forum (LIF), SyncML Initiative, MMS-IOP (Multimedia Messaging Interoperability Process), Wireless Village, Mobile Gaming Interoperability Forum (MGIF), and the Mobile Wireless Internet Forum (MWIF) into OMA. This consolidation promotes end-to-end interoperability across different devices, geographies, service providers, operators, and networks, and further supports OMA’s market and user requirements focus to guide the specification work.

Significant new work in OMA is leading to the development of mobile service enablers in areas such as Device Management, Push-to-talk Over Cellular, Mobile Broadcast, and more.

The Goals of OMA

1. Deliver high quality, open technical specifications based upon market requirements that drive modularity, extensibility, and consistency amongst enablers to reduce industry implementation efforts.
2. Ensure OMA service enabler specifications provide interoperability across different devices, geographies, service providers, operators, and networks; facilitate interoperability of the resulting product implementations.
3. Be the catalyst for the consolidation of standards activity within the mobile data service industry; working in conjunction with other existing standards organizations and industry fora to improve interoperability and decrease operational costs for all involved.
4. Provide value and benefits to members in OMA from all parts of the value chain including content and service providers, information technology providers, mobile operators and wireless vendors such that they elect to actively participate in the organization.

What are the main components for a mobile Web Services Framework?

The IEEE Distribute Systems Online states that the components of a mobile web services framework are:

Figure 1 shows our proposed framework’s architecture. We built it on the standard Web service architecture’s three pillars—a service provider, requestor, and registry—but we also introduced three new components: a service broker, a workflow engine, and a mobile Web service agent.

Figure 1. Our proposed framework’s architecture. The framework preserves the three roles in the standard Web service architecture, but also introduces three new components.

The new architecture complies with wireless portal networks and attempts to overcome both the processing overhead on mobile devices and the data load on wireless links with limited bandwidth.

Service broker

The service broker augments data stored on the UDDI registry with nonfunctional attributes such as service-area location, service time, and accessible network types. Each provider that implements a new service supplies this information; for this reason, we defined a service broker service ontology similar to one described elsewhere.⁹ Figure 2 shows this ontology’s Unified Modeling Language (UML) class diagram.

Figure 2. UML class diagram for the service broker service ontology. The service broker provides Web services for mobile clients. By invoking these Web services, mobile clients can specify their domain or service-class-specific preferences and search all available services.

The service broker service ontology specifies a domain (such as food, rental, or entertainment) and a set of synonyms for flexible search. The rental domain, for example, includes “rent” and “lease” as synonyms as well as a set of service classes to define properties. Each service that belongs to a service class must have a unique name.

A service class is further specified by its attributes, which are service-class specific and can include URIs. These attributes also hold nonfunctional attributes, which the mobile agent uses to select available services that match user preferences and context. In the food domain, for example, the “pizza” class might have attributes such as minimum delivery time and minimum delivery amount.

Workflow engine

The workflow engine uses standard orchestration languages to execute any processes the service providers give as workflows. While executing a workflow, the engine communicates with Web service providers and invokes related services. All messaging between the engine and the provider is via standard SOAP messaging. Having several workflow engines on the network helps avoid a single point of failure.

Mobile Web service agents

A mobile Web service agent acts as a gateway to Web services for mobile clients and handles all communication between mobile clients and the service broker or workflow engine.

The mobile Web service agent is located inside the mobile network. It receives the input parameters required for service execution from the mobile device and returns the executed service. The agent also selects services according to user preferences and context information such as location, air-link capacity, or access-network type.

The evolution of these mobile web frameworks and Location Based Services are fast emerging as worthy competitors of traditional desktop based e-commerce systems, this is mainly due to the fact that the systems are now being optimized for mobile access, they are also allowing users to access services and functions whilst on the move, this reduces the need for users to physically go to the company (eg. Bank, Airline etc.) to perform the required tasks and therefore improves efficiency.

References

http://en.wikipedia.org/wiki/Location-based_service

http://dsonline.computer.org/portal/site/dsonline/menuitem.9ed3d9924aeb0dcd82ccc6716bbe36ec/index.jsp?&pName=dso_level1&path=dsonline/2006/06&file=w3bener.xml&xsl=article.xsl&;jsessionid=KpYBFSRQpRDR5sYwVKVZbvv4llF4TRPvqT1nptYFNHhj7dfsdQHy!-2054397236

A spider is a web based program which ‘trawls’ the internet so to speak to harvest information for systems such as search engines and similar sites, the information it collects may contain the following:

• Links on the web pages
• Title, Content, Meta data etc.
• URL
• Email addresses.
• Dead Links
• Statistics

Although this data may be collected the common use of a spider is to index web pages/sites so that they can be used by a search engine.

Spiders are not the only programs that are on the internet trawling through our sites there are a number of ‘bots’ or ‘agents’ which are being used to collect information and perform other functions. Some of the different types of bots are listed below (followed by a short description from Darrel Ince):

Chatterbots

A chatterbot is an agent which converses with the user in some restricted form of natural language. For example a bot of this type may retrieve a web site in response to a natural language question.

Commerce Agents

These carry out large scale, e-commerce functions as distinct from the more specialized agents such as electronic shopping agents. A typical example of a commerce agent is one which mediates between two companies who have a business relationship, this would perform processes such as reconciling invoices, notifying product arrival etc.

Data Management Agents

These are agents which carry out tasks associated with corpora of data. For example, processing the text on a web site and providing a summary of that text with keywords and keyphrases.

Government Agents

These are agents which carry out some activity related to the government such as searching for government regulations or extracting government statistics. Most of these agents are American.

News Agents

A news agent is concerned with tasks that are associated with Web Based news services. Some functions that these agents may perform are:

• Displaying breaking news on your desktop as it is notified to the web site which contains the news.
• Scan news sites for articles of interest to the user.
• Send an email when a news story on a particular interest is published.
• Develop a personalized newspaper which contains only stories of interest to the user.
  

Newsgroup Agents

These are agents which carry out some tasks with Internet newsgroups. Some typical tasks are:

• Filtering posts to match keywords.
• Scanning and prioritizing postings.
• Notifying users of posted URL’s
• Searching newsgroups for pictures and displaying them.
  

Shopping Agents

These are used to carry out tasks associated with the accessing of retail sites. Examples include:

• Finding the cheapest prices for a product.
• Scan bid prices and auction times.

Software Agents

These are agents which carry out tasks associated with software eg. notifying when updates are available, downloading updates, installing components etc.

Stock Agents

Which are associated with the purchasing and selling of stocks and shares.

Update Agents

Which notifies a user when a change has occurred which is of significance to the user. Exmaples of these are:

• Alerting user when news has been posted on a website about a company.
• Alerting a user when a book published by a particular becomes available.
• Reporting when a particular web page has changed.
• Announce when a particular job becomes available on a job board.
  

Web Developer Agents

Which are used by webmasters to carry out their job. The most popular agent of this type is one to check links on a website to identify if they are active or dead. Other examples of functions which these agents may perform are:

• Track statistics like page hits, searches etc.
• Caching pages
• Identifying if users are trying to illegally access a restricted page/site etc.

Although some bots may be used for malicious activities they can be extremely useful and provide additional functionality to business to business and e-commerce systems. In the current online e-commerce marketplace there are a number of the previously mentioned bots or agents which are already being used to provide users with valuable functionality some activities which are using these bots include:

• Using shopping agents to trawl sites for the cheapest price of a particular product.
• Emailing a user when products/jobs etc become available.
• Notifying users when new products are released.
• Create custom news/product/topic listings based on personal preferences.

This workshop delves deeper into rails and shows how to create, run and manage ruby on rails applications. I found this workshop useful as a starting block to understand the abilities of rails to easily create complete a complete scaffolding for a web system in literally minutes. I successfully created an animal application using: rails animal, this automatically creates the scaffolding for a blank rails application, after this i generated the controller Mammal by using the command: ruby script/generate controller Mammal which creates a blank controller class under the app/controllers directory. After creating a breathe method in the Mammal controller i then created a view for the same method under the app/views/mammal, this all ran successfully. This section showed how views are made and how they relate back to the controller.

Part B once again identified how to create a blank application, generate controller views etc. but it also identified how rails passes data between actions and views. So once again i created a blank application using: rails scenery, and created a Demo controller using: ruby script/generate controller Demo and added a method through a text editor, i then created a view template for the action and added the time function, once again no problems arose. Now in Part C this is where our taxi booking system becomes more relevant, this section shows a basic demonstration of how rails applications communicate with objects as web forms. I created the cabs application and the appropriate controllers and views as well as the html input form.

In conclusion this workshop identified the basic methods of creating and integrating rails applications, it also provided a further insight into the inner workings of rails applications and how the provided scaffolding can be effectively utilised in the rapid development and production of business to business systems.

Models

• Customer Model for storing customer information.
• Order Model for processing orders.
• Shopping Cart model for the addition of books to the order.
• A book model to hold information and functions for the books.

Views

• Book controller index page to display list of books etc.
• Book controller lookup page.
• Book controller return page.
• Order controller index page to place order.
• Order Controller check order status page.
• Order controller order confirmation/validation page.
• Shopping cart controller index page, with a list of books that have been added etc.
• Shopping cart controller purchase page.

Controllers:

• Books Controller to contain methods for books (Lookup, Return).
• Orders Controller to contain methods for placing a book order (Create, Cancel, Check Status).
• Shopping Cart controller to contain methods for the addition of books etc. (Add to Cart, Purchase, Cancel Purchase).