Aparna's Blog

I came across an integresting blog post about SOA and Agile methodology , which talks about differences in SOA and Agile world views and how to mitigate them both to work with each other. An excerpt:

" * Agile methodologies promote an incremental, iterative approach to development of functionality (including method signatures), with visibility of the impact of change given through test coverage. Basically, working on the premise that, change is cheap if supported correctly.

* SOA promotes a well defined service interface through contracts - these contracts are aligned against business processes, not implementation details. The rigidity of the service interface, and its non-technical alignment allows for internal change without impacting consumers of the service. Changing a service interface is an involved process, though; rather than an outright change, a versioning mechanism is needed due to the immutability of contracts, and therefore a migration process is required. The visibility of service usage is also very difficult to monitor as it could be external organisations rather than internally controlled systems. The upshot of these two factors is that change to the interfaces of a service are relatively expensive. "

Proving the need for another Agile survey, TrailRidge Consulting recently completed a survey of 550+ international respondents who currently practice Agile software development and use a tool. (And yes, for full disclosure’s sake, TrailRidge is a Rally partner.)

One of the most interesting findings: Over 40% of firms are now choosing to use specialized “Agile” tools instead of more traditional vendors that have ruled the software roost for over a decade. In contrast, traditional tools for requirements management, item workflow tracking and project management tools only get used around 10 to 20% by respondents. I suspect this figure was only that high because most teams used multiple tools.

"Machine tags" have been introduced into Flickr as generalization of things like geotagging. Machine tags are also known by many as "triple tags". These are tags with a specific syntax aimed primarily for "machine consumption" (that is, by programs) and not directly for display to the typical end-user. You can use machine values to store extra data elements for a given photo. I think that it's fair to say that most important example of such data has so far been the latitude and longitude associated with a photo. So important that Flickr ultimately introduced specialized functionality to handle this data, to take that data out of the realm of having people just shoehorning that info into tags.

I'd really like to know what uptake there has been on machine tags.

Advantages:

Absolute minimum barrier to use — By not using encryption or special authentication methods, anyone with access to the Internet should be able to begin working with your API quickly.

Easily distributed code — Login accounts or developer key programs that make use of your API can be widely distributed and used right out of the box.

Less to worry about — If you aren't managing user accounts or development keys, it's one less thing to keep track of, and your code efforts can concentrate solely on developing the API itself.

Disadvantages:

No control — Anyone, anywhere, can use the API, and while this may sound like the goal of web services, it drastically limits your response if abuse requests begin pouring in. If those requests are coming from an application on a single machine, it is easy enough to recognize the requests and block them at the firewall. But should an application that behaves poorly reach wide distribution, you will have a very difficult time dealing with the requests.

No encryption — All requests and responses are visible to anyone between the requesting server and the API server.

Can't contact developers — Because anyone anywhere can access the API without any prior registration, you are left without any method of directly engaging developers using the API. You may want to contact developers in situations where their application is being abusive, when changes are being made to the API that will affect their application, or to seek suggestions on how to improve the API itself.

Abuse — Unfortunately today, systems with little or no security or authentication make prime targets for abuse by some less ethical elements out there. Even if you feel that the risk is minimal, you may end up surprised at what others can take advantage of.

I was digging in through Ajax when I found an interesting article which talks about the challenges that Ajax might have to face.

" While Ajax promises to change the way we view and change the web, there are a number of challenges that it poses to developers. With Ajax, you have to do a lot of work yourself. It is comprised of a collection of web technologies that can be used to create sites which are quick and interactive. The Ajax trend has already made an impact on traditional web developers and development software. Some experts believe that if Ajax applications continue to become more prominent, they may force many online companies to change the ways in which they conduct business. Since people are resistant to change, the best way to deal with these changes is to understand and prepare for them."

As we have seen through many examples throughout this course, mashups are growing in popularity among a broad variety of organizations ranging from startups to large enterprises, efficiently and cost-effectively delivering data and business logic from disparate systems into portals and composite applications. Regardless of the size or complexity of the business, the reasons why enterprises choose to utilize mashups instead of traditional IT integration technologies come down to two main factors -- increased deployment speed and decreased cost.

I was digging in through the basic advantages of using mashups in the industry and bumpped into an article which described various reasons for using mashups in an enterprise. Few of them are :

Lower cost
Using mashups, the effort required becomes much less expensive compared to traditional integration for many reasons, including the need for fewer specialized programmers and no fundamental change in existing applications, security and firewall setup.

Non-intrusive integration
Mashups are created without modifying the application to be integrated, thereby lowering the risk and impact of the integration project through eliminating the need for architectural changes, re-factoring and avoiding the politics of cross-enterprise projects. Also, the mashup approach enables the integration of applications across the enterprise where there is no other alternative other than to integrate through a web front end.

Lower risk
Mashups allow for very short and cost-effective implementation cycles. The first integration can often be up and running in a matter of days, and further integration can be incremental and iterative, as rollouts and RO Is from the first integrations are realized. This allows enterprises to try out new approaches to building enterprise applications at a much lower risk than using traditional methods.

Time-to-market
Even complicated mashup projects that span multiple business units and geographies can be completed in weeks rather than months or years. Enterprises can gain competitive advantages by leveraging their existing enterprise applications much faster than competitors and thus increasing their business agility.

A faster and more accurate design phase
Since the web interface is intuitive and well understood by both the business person and the programmer, the application design process becomes a lot easier and less prone to errors.

Lower skill requirements
A traditional integration project requires highly skilled and specialized developers with extensive
knowledge of the individual applications and EAI technologies. With mashups, the work that involves connecting to web-enabled applications only requires developers with basic programming experience and HTML knowledge. This will reduce -- or even eliminate -- the need for highly skilled developers in an integration project.

Let me through some light on different types of mashups that we can create. Kapow Technologies has simplified mashups in the enterprise to three fundamental types:

Presentation-level mashups
Presentation-level mashups give the ability to extract and assemble various parts of applications and web sites, and other assets available via HTTP to create internal portals, wikis, and customer-facing sites.
For example, Kapow's banking clients was able to create a portal for high-net-worth brokerage clients.In about six weeks’ time, this major financial institution was able to integrate information from seven different internal enterprise systems to provide a seamless, secure single web page that gave customers everything they needed to know. Without enterprise mashup technology, this project would have cost millions of dollars more, not to mention the extra time required by consultants and IT workers.

Logic-based mashups
This class of mashups combines browsable logic with REST and SO AP services into a new logic component.
A good example is Momondo (www.momondo.com), which aggregates the airfares of low-cost carriers into a single web site that is easier for customers to use than hopping around to each travel site individually.

Data/content-based mashups
Data/content-based mashups join content from two or more sources (of which some or all are web based) and either combine them into a new data repository or transfer the data to a new place or application.

Thought I would let you all know what I learnt during the course of my miniproject.

• How to use xmlhttprequest to fetch a static file from the web server and integrate it into my webpage.


• How to make things work in both IE and FF


• Incorporating the results into the webpage and display


• Using an API through a Proxy Server


• Using event handlers , DOM methhods.


• Fixing various bugs in a phased manner.

It was completely a learning experience. Especially when it came to illustrating the process in a diagram , this is where I learnt how things are connected to each other and make them work.

I am glad that Dr. Gibson included miniproject in the course schedule apart from the team project. It really helped me to put together my creative thoughts ;) and build a mini tourist guide :D

I was trying to dig in more about JSON and this is an interesting article which I came through.

"There are a couple of web sites reporting about security issues that hackers can use to invoke AJAX methods or use the JSON output to get data from other web applications. Specificallly, these attacks use HTTP GET requests invoked via an HTML