Service Oriented Network Architecture

Here is a very informative article on Service oriented architecture principles and SO Network Architecture

Biggest mistakes in Web design

If we visit any website, and if we can stay for more than 10 seconds then chances of revisiting the same website is more, else we may not visit that website again. What makes us to stay or leave with a website is decide by the usability experts of the website. If the users cannot get what they want in a website in 10 seconds, they would leave. If you want to test this, check out your own browsing habits ...

here is a informative website pointing out various things to keep in mind while designing websites. Vincent seems to have done extensive research on usability and keeps the website live.

Step by Step procedure to install Tomcat 6

This is the first website that I have come across so far, providing detailed installation instruction on Apache Tomcat 6

Ola Bini in Bangalore

Ola Bini core committer of JRuby is in Bangalore. Thoughtworks would be hosting this event.

Architecture lingo

Being in the architect's world, I keep hearing so many different types of Architecture. I thought I would list them here and keep updating this post as and when I hear a new type . Many of the listed architectures could be related to one another, subsets, supersets of each other. My intention is to just list them without worrying how they are related to each other !!

(Not in any specific order)
1. Business Architecture (goes hand in hand with Enterprise Architecture)
2. Application Architecture
3. Information Architecture/Information Management Architecture
4. Technical Architecture
5. Enterprise Architecture
6. Solution Architecture
7. Data Architecture
8. System Architecture
9. Infrastructure Architecture
10. Development Architecture
11. Execution Architecture
12. Operations Architecture
13. Population Architecture (related with DataWearhousing)

Manipulating the data in temporary tables

The question asked by Sophie was "Can you use a Stored Procedure to open a table and copy data to a sort of virtual table (or a records set) so that you can change the values with and not affect the actual data in the actual table. And then return the results of the virtual table? Thanks!"

The solution, Yes it is possible to do it is explained in detail here

History of Javascript and overview of Client and Server Side scripts

This article provides the history of javascript and the different types(client side, server side and core)

Web trends in 2007

Here is a cool and cute image depicting web trends in 2007. Looks like Web 2.0 would become even more popular in coming months !!

Scaling without a Database

Found this nice article on "Scaling web application without a Database". Really thought provoking !!

CORBA Vs Web Services

I came across this nice article bringing out the clear details about CORBA and Web Services. One of the best articles that I came across so far on this topic

Testing Private Methods

There are a lot of discussion going on in test infected community on how to go about testing private methods. One of the suggested approach is to nest a static test class within the production class. This package level access static class can be called from our testing class, which in turn would call the private methods.

I strongly disagree with this method. Couple of reasons:

1. We would be adding extra code in the production code.
2. It might add more cost to the customer

First we have to understand that, the reason why we want to test the application is to ensure that our application works well and conforms to certain requirements given by the customer. We need to weigh the cost of maintaining these tests also. Customer pays money for the product, and the testing is the extra burden we are putting on the customer to ensure we deliver something right.

When we deliver the nested class with the production code, we are in fact sending something that was not requested by the customer. This class in turn might introduce its own defect.

Let us take a simple analogy, process of car manufacturing. Consider that the testing team inserts a device into the car during car manufacturing. This device would ensure that they can test "engine temperature" accurately. This device would go with the car to the customer also. Problem here is, we may not know the impact of this device on mileage of the car !!. Even though it has made the lives of developers easy, we are charging the customer for this device too.

I strongly feel that, if we want to test something, we should do so without touching the production code.

Document style Vs RPC

Here is a good introduction bringing out the difference between RPC Vs document style web services

Distributed SOA

Nice article on distributed SOA

It's hard to turn anywhere today without seeing something about
service-oriented architecture, or SOA, and a debate about the "right"
way to do it. That's not surprising, I guess, since every new
computing trend generates debate and every vendor tries to promote
their technology as the right technology – the right product – that
will allow customers to take the most advantage of a new approach.
It's a scramble as vendors try to aggressively reposition their
existing product suites to take advantage of customer interest in a
hot IT trend. It's unfortunate, though, because this behavior often
creates a lot of confusion and potential disillusionment, as promises
made often do not turn into promises kept and technology solutions
sold as appropriate for SOA may turn out not to be.

To set the right perspective on this, it's important to note that SOA
is, by definition, distributed. The purpose of a service is to
communicate remotely with another service, typically to share data.
The purpose of an SOA is to change the approach of IT from building
bespoke, monolithic applications to building applications that are
developed and integrated more and more using assets from a collection
of shared, reusable functionality, i.e. services.

A distributed SOA infrastructure represents the easiest way to deploy
and consume shared, reusable services, facilitating incremental
adoption (both economically and technically) and enable greater
deployment flexibility, adaptability and maintainability (e.g., single
services can be certified for update more easily than an entire
application) .

Unfortunately, centralized approaches to SOA infrastructure continue
to be developed and proposed. Vendors will go to great lengths to
convince the technology buying public that what they're offering is
already SOA compliant, always was, always will be and was truly
designed from the beginning to facilitate their customers' move to
SOA, no matter whether it was originally designed to be a JEE
application server or EAI system.

In other words, vendors taking an opposing view to distributed SOA
infrastructure often do so because that's the nature of the software
infrastructure they already have. A refried EAI hub or JEE-based stack
or any other solution that requires request messages to be passed
through a central control point, cannot be considered truly
distributed since all access to services must be routed through a
central hub or a server. This centralized approach to SOA adds cost,
limits reuse, reduces flexibility and introduces a potentially
expensive bottleneck. In the worst case it could even negate the
reasons for moving to SOA in the first place. People are bound to be
disappointed if the flexibility of their SOA infrastructure does not
meet their requirements.

One only has to look to the World Wide Web to see an example of a
distributed application that very successfully meets its users'
requirements. The Web is the largest distributed application ever
built and it's distributed by nature, like an SOA should be. When you
use a browser to click on a link to a URL, your request is not routed
through some kind of central controlling authority deployed in a
server or a hub. Your request goes directly from your browser to the
Web server hosting the page you have requested. This approach works
fine for the Web and it also works fine for an enterprise's SOA. Web
endpoints can be updated individually without breaking clients,
affecting other sites or requiring any update to a central hub or
server, since requests do not have to pass through one in the first
place. A good SOA infrastructure also supports these capabilities.

Fortunately, an infrastructure solution exists that embraces the
distributed nature of SOA. The distributed approach to SOA
infrastructure uses smart endpoints that service enable applications
and allow them to find and directly communicate with other services.
Enterprise qualities of service, such as high availability or advanced
security, can also be included in the endpoints to preserve the
capabilities upon which existing mission critical applications rely.
Distributed SOA infrastructure is about creating an IT environment
that is platform neutral, standards-based and highly flexible, so that
it can respond better to an ever-changing technology and business
landscape. A distributed SOA environment is therefore better able to
support the technical and economic requirements of an SOA based
application. Finally, a distributed approach to SOA infrastructure
allows you to move at your own pace, deploying services one or two at
a time, adding features such as orchestration, registry/repository ,
management and so on as needed and not before.

I'm not saying that EAI systems, hub and spoke based applications or
JEE server centric approaches to SOA infrastructure are all bad or
wrong. Many times existing corporate application functionality depends
upon one or more of these implementation styles. All I'm saying is
that a good SOA infrastructure shouldn't constrain your design options
to what any one of these things can do – in fact a good SOA
infrastructure embraces and includes them among the collection of
reusable service assets.

A parallel between the benefits of distributed SOA and the airline
industry can be seen in the way in which the low-cost operators are
challenging the established carriers. The approach of the established
operators is based on an expensive hub and spoke model that funnels
passengers through a small number of dedicated travel hubs. Large
planes that cost more to operate, fly from spoke airport to hub
airport, where passengers are processed for further travel to their
final destinations. In this model the planes cost more to operate and
airport facility charges are higher. With the rise of low-cost
airlines, which operate on a more distributed, point-to-point model
(smaller planes directly flying to smaller airports), the airlines
that are tied to the traditional hub model are taking a significant
financial hit.

SOA customers do not need more of the same old bloated and expensive
software stacks. Customers need better software specifically designed
for the requirements represented by the SOA trend – to improve the way
in which existing (and new) IT functional assets are provide to
applications. SOA designs need a good way to create and deploy
reusable services that can be called upon simply and directly when and
where needed. Customers need low cost options that allow them to start
small with incremental adoption, using point-to-point communication
solutions that avoid expensive new servers and hubs, adding quality of
service and other features as required. In short, they need SOA
infrastructure that really meets the inherently distributed nature of
an SOA.

You can read the above article here