Service Oriented Architecture (SOA) - Which is best suitable for SOA: .NET or J2EE?

This is the most complicated question among many people. Microsoft claims that its architecture is great; similar claims come from Sun also.  None of them could beat each other in any of its technologies. No one can give an immediate decision or solution to any of such questions. 

Although the rivalry between .NET and J2EE continues, neither platform is expected to dominate business-application development in the near term. Instead, their roughly equal capabilities will win roughly equal market share for .NET and J2EE. That means the two technologies will be used in 80 to 90 percent of business-application development over the next five years. 

Both .NET and J2EE are good platforms for developing and hosting business applications. Both support n-tier architectures via client- and server-side component models for assembling enterprise applications. This allows for use of either fat or thin user interfaces with both platforms.

However, .NET and J2EE are far from identical, and each platform has distinct strengths. The primary strength of .NET is its use of multiple programming languages running on a single platform to finish of 2007 eyar , because mono-project goes on scene. This eliminates the programming language as a barrier for adoption. Further .NET strengths include ease of use and speed of development as programmers might be transitioning from COBOL or C. (In contrast, transitioning to Java usually takes greater skill in object orientation.)

J2EE takes .NET's multiple programming-language/single-platform paradigm and turns it around: The primary strength of J2EE is its use of a single programming language capable of running on multiple platforms. This eliminates the platform as a barrier for adoption. Further J2EE strengths include vendor neutrality and the active involvement of a large, open-source community.

From an integration standpoint, JDBC is actually more promising than J2CA. This API provides access to virtually any data source, from relational databases to spreadsheets and flat files. With a JDBC driver, all corporate data can be connected, even in a heterogeneous environment. In addition to its support for actual relational databases, JDBC can also support emulated relational models based on legacy information sources. But to do this, JDBC requires an integration product that can map the legacy-application functions to emulate a relational database model. The .NET platform, with its dependence on Microsoft BizTalk Server, has the same drawbacks for legacy-application integration as it does for packaged-application integration. So, despite the very real integration potential of .NET and J2EE, both platforms have their associated limitations. And when it comes to legacy-application integration, neither platform can complete the job on its own.

Although Web services were not conceived as an integration technology, they can be effective in the application-integration process. Web services provide a standard way to expose application interfaces through XML (Extensible Markup Language) and WSDL (Web Services Description Language). They also use a standard way to communicate, via SOAP (Simple Object Access Protocol). These features help reduce the cost and complexity of integration, as well as the cost and complexity of building new applications. Web services are made even more interesting by the fact that they are supported by both .NET and J2EE, and run equally well on both platforms. Therefore, Web services are ideal for bridging the two platforms.

Only large businesses are in a position to adopt both .NET and J2EE, due to two circumstances: 1) they have sufficient resources to train their development staff on both platforms, and 2) they have the capacity to develop best practices for managing environments that include elements from both platforms. Unlike very larger counterparts, small and midsize organizations won't have the luxury of supporting both platforms simultaneously. Due to limited resources, they will probably be forced to choose between .NET and J2EE. And because Microsoft has established a strong presence in small and midsize businesses, .NET can reasonably be expected to prevail in this market.

 Software as a Service

A profound shift in the development and distribution of software has transformed the industry. The Software as a Service (SaaS) business model is impacting the software industry and how your customers acquire business functionality and solutions. In this model,

application functionality is delivered through a subscription model over the Internet. The customer does not take ownership of the software, but instead rents a total solution

that is delivered remotely. With the SaaS model, you can reduce up-front support costs because you no longer need to support multiple platforms and versions. This rapidly emerging delivery model can help you, as an ISV, enter new markets.

In the software as a service model,

the application, or service, is deployed from a centralized data center

across a network - Internet or private network - providing access and use on a recurring fee basis. Users
"rent," "subscribe to," “are assigned”, or "are granted access to" the application from a central provider.
Business models vary according to the level to which the software is streamlined, to lower price and
increase efficiency, or value-added through customization to further improve digitized business processes.
The potential benefits of the model are significant for both the vendor and the customer.
In the past few years, many new companies have been established that took this new paradigm into
consideration from the onset. However, what about the traditional independent software vendor (ISV)
whose products were not designed or optimized to be utilized in a service model? Should they be worried
that their products will become relics in today's distributed computing environment? Or is a service model
even appropriate for these products? Many ISVs are therefore asking themselves whether to
service or not to service?

ISVs contemplating such a move want to consider the following:

·  What is the strategic motivation for considering offering Software as a Service?
·  Has a competitor created one yet?
·  Is there pressure from the customer community to offer one?
·  Is the company highly profitable and in no hurry to threaten the current business model?
·  Is the company losing money and feels a need to offer a new product?
·  Does the application lend itself EASILY to an application-hosted product or is there a significant
development investment needed to get it ready?
·  Is the service offering targeted at existing prospects (and can therefore threaten current revenue
from license sales) or is targeted at new markets?
The decision to develop a service offering necessitates significant changes in the software development
cycle and can have a profound effect on the operations and bottom line of a company. It requires a new
skill set that many traditional ISVs may not currently possess. Once this strategic decision to proceed has
been made, a whole new set of questions comes to the fore.
·  Does the ISV host and manage its own service? Do they go with a third-party xSP to manage it for
them? How do they get to either?
·  Does the ISV hire an application infrastructure provider to provide the technology for the service and
the integration with legacy systems?
·  And what about the changes in the ISV business model. How does it impact internal operations? How
does it impact revenue streams?
·  What about the channel?
·  Where to begin?

The answers to these and other questions lie in this white paper. Through real world explanations and
examples, it outlines such topics as the technical considerations of selecting a SaaS partner, how
applications will integrate into your current business model, the long-range impact on revenue, and how
to manage this new channel. It's a tool to assist the ISV as they begin to address this burgeoning model
of software as a service.

Today's Web has terabytes of information available to humans, but hidden from computers. It is a paradox that information is stuck inside HTML pages, formatted in esoteric ways that are difficult for machines to process. The so called Web 3.0, which is likely to be a pre-cursor of the real semantic web, is going to change this. What we mean by 'Web 3.0' is that major web sites are going to be transformed into web services - and will effectively expose their information to the world.

The transformation will happen in one of two ways. Some web sites will follow the example of Amazon, del.icio.us and Flickr and will offer their information via a REST API. Others will try to keep their information proprietary, but it will be opened via mashups created using services like Dapper, Teqlo and Yahoo! Pipes. The net effect will be that unstructured information will give way to structured information - paving the road to more intelligent computing. In this post we will look at how this important transformation is taking place already and how it is likely to evolve.

The Amazon E-Commerce API - open access to Amazon's catalog

We have look about Amazon's visionary WebOS strategy. The Seattle web giant is reinventing itself by exposing its own infrastructure via a set of elegant APIs. One of the first web services opened up by Amazon was the E-Commerce service. This service opens access to the majority of items in Amazon's product catalog. The API is quite rich, allowing manipulation of users, wish lists and shopping carts. However its essence is the ability to lookup Amazon's products.

Why has Amazon offered this service completely free? Because most applications built on top of this service drive traffic back to Amazon (each item returned by the service contains the Amazon URL). In other words, with the E-Commerce service Amazon enabled others to build ways to access Amazon's inventory. As a result many companies have come up with creative ways of leveraging Amazon's information.

The rise of the API culture

The web 2.0 poster child, del.icio.us, is also famous as one of the first companies to open a subset of its web site functionality via an API. Many services followed, giving rise to a true API culture. John Musser over at programmableweb has been tirelessly cataloging APIs and Mashups that use them. This page shows almost 400 APIs organized by category, which is an impressive number. However, only a fraction of those APIs are opening up information - most focus on manipulating the service itself. This is an important distinction to understand in the context of this article.

The del.icio.us API offering today is different from Amazon's one, because it does not open the del.icio.us database to the world. What it does do is allow authorized mashups to manipulate the user information stored in del.icio.us. For example, an application may add a post, or update a tag, programmatically. However, there is no way to ask del.icio.us, via API, what URLs have been posted to it or what has been tagged with the tag web 2.0 across the entire del.icio.us database. These questions are easy to answer via the web site, but not via current API.

Standardized URLs - the API without an API

Despite the fact that there is no direct API (into the database), many companies have managed to leverage the information stored in del.icio.us. Here are some examples...

How Web Scraping Works

Web Scraping is essentially reverse engineering of HTML pages. It can also be thought of as parsing out chunks of information from a page. Web pages are coded in HTML, which uses a tree-like structure to represent the information. The actual data is mingled with layout and rendering information and is not readily available to a computer. Scrapers are the programs that "know" how to get the data back from a given HTML page. They work by learning the details of the particular markup and figuring out where the actual data is. For example, in the illustration below the scraper extracts URLs from the del.icio.us page. By applying such a scraper, it is possible to discover what URLs are tagged with any given tag.

This sounds great, but is this legal?

Scraping technologies are actually fairly questionable. In a way, they can be perceived as stealing the information owned by a web site. The whole issue is complicated because it is unclear where copy/paste ends and scraping begins. It is okay for people to copy and save the information from web pages, but it might not be legal to have software do this automatically. But scraping of the page and then offering a service that leverages the information without crediting the original source, is unlikely to be legal.

But it does not seem that scraping is going to stop. Just like legal issues with Napster did not stop people from writing peer-to-peer sharing software, or the more recent YouTube lawsuit is not likely to stop people from posting copyrighted videos. Information that seems to be free is perceived as being free. 

The opportunities that will come after the web has been turned into a database are just too exciting to pass up. So if conversion is going to take place anyway, would it not be better to rethink how to do this in a consistent way?

Why Web Sites should offer Web Services

There are several good reasons why Web Sites (online retailers in particular), should think about offering an API. The most important reason is control. Having an API will make scrapers unnecessary, but it will also allow tracking of who is using the data - as well as how and why. Like Amazon, sites can do this in a way that fosters affiliates and drives the traffic back to their sites.

The old perception is that closed data is a competitive advantage. The new reality is that open data is a competitive advantage. The likely solution then is to stop worrying about protecting information and instead start charging for it, by offering an API. Having a small fee per API call (think Amazon Web Services) is likely to be acceptable, since the cost for any given subscriber of the service is not going to be high. But there is a big opportunity to make money on volume. This is what Amazon is betting on with their Web Services strategy and it is probably a good bet.