1970-01-01 00:00:00 UTC
Question:
Six answers:
sashank_1234
2006-12-01 15:04:54 UTC
IF u are a real genius and want to prove your self in the real world choose java or .net cause they are the leaders in Internet.
If u wanna become famous and be remember for some time ,go for developing some games.Here choose c or c++
if u want to have fun in your career choose .only "C".
Now its up to you.Do let me know which one did u choose.
Venkatesh A
2006-12-01 13:51:34 UTC
Also learn the basics of Microsoft technologies.
pearl
2006-12-01 13:34:32 UTC
agent
2006-12-01 13:18:54 UTC
2006-12-01 12:49:26 UTC
mr nice
2006-12-01 04:49:23 UTC
C# (C-Sharp) is Microsoft's new programming language, promoted as "the first component-oriented language in the C/C++ family." Despite the claim, however, many people think that C# is rather a clone of, or Microsoft's replacement for, Java. Is it true?
This article shows the evidence that C# is more than a sibling of Java. If you are a Java programmer who wants to learn or know more about C#, reading this article is the first ten minutes you should invest in.
C#, C++ and Java
Given the current hype, it is always interesting to compare C#, whose specification was written by Microsoft's Anders Hejlsberg and Scott Wiltamuth, with both C++ and Java. Considering the tone of recent IT newspapers' headlines, it is not too surprising if you already know that C# is closer to Java than to C++. For those who just joined the discussion, Table 1 below lets you see for yourself. Conclusion: Java and C# are not Siamese twins, but C#'s most important features are closer to Java than to C++.
Introduction
An eCommerce site without a profit plan is like a car without gas. It may look nice. It may impress people. It may have cost you an arm and a leg. But in the end, it ain't goin' nowhere.
This lesson was driven home in the last year. EBusiness after eBusiness went bankrupt, not because of a lack of customers, but because of a lack of a plan to make a profit on those customers.
In the coming year, profit will be as important as ever. But the model for making that profit will increasingly evolve from one based on competition to one based on collaboration. Ironically, the most competitive companies will be those that don't worry about competing at all, but focus only on how well they collaborate.
The football metaphor ("crush your competition!") for business is passé. The business metaphor of the future is the symphonic orchestra. The success of the overall collaboration will define the success of each of the individual units.
In eCommerce, collaboration means selling through partner relationships. This means sharing profits. Sharing profits forces us to scrutinize our profit model at every step of the collaboration. We need enabling technologies for delivering eCommerce in a collaborative environment at the lowest possible cost.
Today, there are two technical visions for eBusiness and eBusiness collaboration. One of these is the Microsoft vision and goes by the overall name of the .NET platform. The other is the Sun vision and goes by the overall name of Java 2 Enterprise Edition (J2EE).
In this white paper I will compare and contrast the .NET platform and J2EE. I will focus on the main issues that I believe will drive eBusinesses over the next half decade: collaboration and profitability. I will discuss technical details of these two platforms, but only where they impact collaboration or profitability.
It should be pointed out that J2EE is a specification, not a product. Many vendors implement this specification in products. The two most important J2EE vendor/products are IBM's WebSphere and BEA's WebLogic. According to a recent study by Cutter Consulting, these two vendors account for 59% of the J2EE market. Sun is a relatively minor player but important in that it controls the J2EE specification.
It is beyond the scope of this white paper to compare each implementation of J2EE to Microsoft's .NET platform. I will therefore compare the overall J2EE vision as defined by Sun (the owner of the specification) to the overall .NET platform vision as defined by Microsoft. In order to make this whole discussion more concrete, I will relate the issues to a hypothetical business, MoneyBroker, but the issues discussed are relevant to any eBusiness.
About MoneyBroker
MoneyBroker is a made-up business used only for illustrative purposes. Let's say the purpose of MoneyBroker is to allow on-line payment of bills. Customers can deposit money in a MoneyBroker account and then use that money to pay bills on-line. To entice customers, MoneyBroker pays interest on outstanding balances.
Customer can pay bills either directly or indirectly. Direct payment occurs at the MoneyBroker web site where customers log on and arrange for bill payment. Indirect payment occurs through MoneyBroker partners. MoneyBroker partners are typically retailers who can accept MoneyBroker money from their customers when those customers place orders. When a customer goes to AustinKayaks.com (another made-up business) and orders a $500 kayak, one of the options AustinKayaks.com can offer is payment through a MoneyBroker account.
MoneyBroker makes its profit by investing outstanding customer balances. Its profit is the difference between the interest rate it pays its account holders and the interest rate it makes on its investment.
eBusiness Requirements
In order for MoneyBroker to support eCollaboration, or electronic collaboration, the computer systems that run MoneyBroker must include certain capabilities. In my experience, the most important are these:
Interoperability - the systems must be able to share information with collaborator systems.
Availability - systems must be highly available; the first time AustinKayaks loses a sale because the MoneyBroker system is down, it will be very unhappy. The second time, it will discontinue the partnership relationship.
Throughput - systems must be able to support high transactional throughput, since payment requests are now coming not only from MoneyBroker's own web site, but also indirectly from those of its partners.
In order to turn a profit, overall system cost must be kept as low as possible. In my experience, the most important determinants of system cost are these:
Development Costs - the cost or architecting and implementing the MoneyBroker system.
System Management Costs - the cost of managing the MoneyBroker system.
Unit of Work Costs - the cost of processing MoneyBroker payments.
Scalability Costs - the cost of adding throughput to the overall MoneyBroker system as the customer base increase.
These, then, will be the primary issues on which I will focus in this white paper: the three main collaborative requirements (interoperability, availability, and throughput) and the four main system cost determinants (development cost, system management costs, unit of work costs, and scalability costs).
A Typical eCommerce Architecture
Today's web-based eCommerce architectures are typically based on three tiers and two firewalls, as shown in Figure 1. These architectures do not support eCollaboration. We will discuss the changes necessary to support eCollaboration later.
Figure 1. Three Tier eCommerce Architecture
Each of the tiers shown in Figure 1 has a purpose, an architecture, and an API. In this section, I will give a generic architectural overview. In the next two sections I will look at the differences between J2EE and the .NET platform.
The presentation tier is responsible for working with clients. With the MoneyBroker application, this tier works with thin browser-based bill paying clients.
The presentation tier accepts an HTTP requests from a web browser and returns an HTML page that that browser can then display. Different browsers have different display capabilities, so the presentation tier must often tailor the HTML to the specific browser (or other thin client device) capabilities.
The business tier is where much of the business logic is implemented. For MoneyBroker, this includes the logic that maintains the customer accounts and the logic that transfers money as bills are paid. Because the business tier sits between the presentation tier and the database tier, it is often called the middle tier.
The presentation tier communicates with the business tier through a method transport protocol. For the .NET platform, this protocol is usually either DCOM or SOAP. For J2EE, it is RMI/IIOP.
In both J2EE and the .NET platform, business logic is typically packaged as components. A component is business logic with which one interacts through well defined interfaces.
Components are often confused with objects, a technology with which they have historical relationships, but share little else. In particular, the rules governing object-oriented programming and component packaging are quite different. I recently discussed the differences between these two technologies, so I won't do that here.
Business logic often requires expensive resources, such as database connections, threads, TCP/IP connections, and message queue connections. These resource requirements would normally make it difficult to support a large number of clients at any one time, a requirement of most eCommerce applications.
To address this problem, both the J2EE and the .NET framework business tier include a sophisticated middle tier infrastructure that supports resource sharing among clients. This infrastructure is critical to supporting large numbers of clients, and thereby achieving high system throughput. In J2EE, this middle tier infrastructure is called Enterprise JavaBeans (EJB). In the .NET framework, it is called COM+.
The third tier is the database tier, where actual data is stored. For our MoneyBroker system, this is where we store customer account information and histories of bill payments.
The business tier is the primary client of the data tier, although most large corporations also have internal applications (not going through the eCommerce architecture) that also make use of databases residing on the data tier. Communication between the business tier and the data tier use a specific API, ADO.NET for the .NET framework and JDBC for J2EE.
Now let's take a closer look at these two technologies.
The .NET Platform Architecture
The overall .NET platform architecture can be divided into four main areas:
.NET Infrastructure and Tools: The infrastructure and tools to build and operate eBusiness systems, including Visual Studio.NET, the .NET Enterprise Servers, the .NET Framework.
.NET Foundation Services: The .NET services are a set of information sharing services for the Internet, such as Passport.NET (for user authentication) and services for file storage, user preference management, calendar management. These services will be offered by both Microsoft and Microsoft partners.
.NET User Experience: This will be a broader, more adaptive user experience, where information is delivered in a variety of ways on a variety of different devices.
.NET Devices: This device software enables a new breed of smart Internet devices that can leverage Web services.
.NET Framework and Visual Studio.NET
Perhaps the most important part of the .NET platform is the .NET Framework. This is a general runtime environment closely associated with the operating system. It includes the component-oriented middle-tier infrastructure (COM+), the Common Language Runtime (CLR) environment, a just-in-time compiler, and a set of operating system libraries packaged using the .NET component model. Each of the server-side tiers in a .NET system (with the possible exception of the data tier, which I will discuss under interoperability) will be running an operating system supporting the .NET Framework.
Closely associated with the .NET Framework is the main programmer development tool, Visual Studio.NET. Programmers of the presentation tier use Visual Studio.NET to define the logic that delivers HTML pages to thin client systems. Programmers of the business tier use Visual Studio.NET to implement business logic in a wide variety of languages and then to package that business logic as COM+ components.
Visual Studio.NET is language neutral. It is best thought of as an open programming platform into which a variety of languages can be plugged. The "standard" Microsoft languages that will come with Visual Studio.NET are VisualBasic, VisualC++, and VisualC#. Other languages will be available through third parties, including COBOL from Fujitsu and Eiffel from Interactive Software Engineering. Many other Visual Studio compatible languages including Haskell, Mercury, Oberon, and Perl are being investigated by university research groups.
The language neutrality of Visual Studio.NET (and in fact, the whole .NET platform) is critical to the .NET platform strategy. It is achieved by translating all Visual Studio.NET languages into a common language called Intermediary Language (IL). In fact, it is through the creation of an IL translator that language vendors make their languages compatible with Visual Studio.NET. Such a language is referred to as a .NET enabled language.
IL files are typically packaged together in deployable units called assemblies. These assemblies are loaded into the common language runtime (part of the .NET Framework), compiled by the just-in-time IL compiler, and executed within the Common Language Runtime (CLR). The CLR provides many features we usually associate with a particular language, including garbage collection, type definitions, polymorphic method resolution, error handling, and the deployment model.
The incorporation of "language" features into a common language runtime, rather than a particular language, allows languages to freely interoperate within the overall .NET platform. Garbage collection, type definitions, and error handling are all handled in a unified fashion, giving a unparalleled degree of language interoperability. Perhaps the most impressive example of cross language interoperability is the ability to define a base class in one language (say, C#) and override methods in a completely unrelated language (say, COBOL). I gave an example of this in a recent article.
The use of the .NET Framework on the presentation tier means that any .NET enabled language (in other words, any language that has an IL interpreter) can be used as a scripting language for presentation logic. And because the .NET Framework includes the just-in-time compiler, it also means that the presentation tier scripts are compiled rather than interpreted, providing a significant performance boost.
We are seeing the beginning of a rapid increase in the types of thin clients (browsers, cell phones, electronic tablets, etc.), each supporting its own subset of HTML. Today's presentation tier scripts must first determine the type of client and then create HTML tailored for that client. This is very time consuming, error prone, and difficult to maintain as new clients systems become available.
Visual Studio.NET includes a new presentation-tier programming model designed to simplify programming for the proliferation of thin client systems. This new programming model is called ASP.NET. ASP.NET allows presentation tier logic to be client neutral. This programming model is based on today's very successful VisualBasic programming model.
Programming an ASP.NET application is a matter of dragging and dropping GUI controls (such as menus or pull down boxes) from a palette onto a canvas. The programmer then writes code in any Visual Studio.NET enabled language that responds to control events (such as a particular button being pushed). The control, not the programmer, is responsible for determining the best way to render itself based on the client's actual device. The ASP.NET framework is responsible for figuring out that a client took a particular action (pushed a button). Since all of this happens on the presentation-tier, the same code base can work correctly regardless of whether or not the actual client device supports any of the .NET technologies.
This control/event programming model, with device awareness built into the presentation controls rather than the presentation logic, greatly reduces work in both the development and the maintenance phases. The development work is reduced because a single simplified block of code can both decipher client requests and process the HTML needs of any ultimate client device. The maintenance work is reduced because we can incorporate support for new client devices just by downloading the latest versions of the controls we are using.
.NET Enterprise Servers
The .NET Enterprise Servers are a collection of add-on server products designed to provide specialized, enterprise level services. Each is priced independently, giving maximum financial flexibility in configuring an overall solution. One only pays for those services one needs.
The best known of the Enterprise Servers is Microsoft's SQL Server. This is Microsoft's high-end database product with a host of capabilities that are far beyond the scope of this article to cover. Suffice it to say that SQL Server is a high performance, high availability, and highly scalable relational database that is a formidable competitor for the enterprise market.
There is nothing, however, about the .NET platform that ties you to SQL Server. Many organizations will use the overall .NET platform to build their eCommerce systems with alternative data storage technologies such as Oracle or DB2. Every popular database can be used as a .NET data tier. Oracle, for example, can be accessed through the database neutral ADO.NET interface. The mainframe databases, CICS and IMS, can be accessed through the Host Integration Service (HIS).
The newest of the .NET Enterprise Servers is Application Center Server. This product is designed for companies that need either 24X7 availability and/or low cost scaleout. The Application Center Server is both a cluster coordinator and a cluster manager.
The Internet Security and Acceleration Server (ISA Server) is focused on the needs of the presentation tier. ISA Server provides two important functions: HTML page caching, a significant performance enhancement for many sites, and firewall functionality. Firewall functionality is, of course, critical for the security any serious eCommerce site. ISA Server provides a low-cost software solution to hardware-based firewall products. At the risk of being redundant, ISA can be used with the other pieces of .NET, but is not required.
BizTalk Server is an orchestration and integration product, used primarily to tie together the various pieces of an organization's operation and to allow that organization to interoperate with partner operations.
Commerce Server is a framework for building an eCommerce site. It primarily focuses on the needs of eCommerce retail operations. Such sites can build web sites very quickly using and specializing the components provided as part of Commerce Server.
The UDDI Collaborative Infrastructure
Collaboration is the future of eBusiness. The set of industry standards being defined to enable eCollaboration is grouped under the umbrella term Universal Description, Discovery, and Integration (UDDI).
While UDDI is independent of the .NET platform, most of the UDDI related activity was pioneered by Microsoft. Therefore it seems appropriate to describe UDDI in the .NET platform section.
The UDDI standards are owned by a consortium known as uddi.org whose web site is, not surprisingly, www.uddi.org. This consortium is led by Ariba, IBM, and Microsoft, and includes more than 100 supporting companies, including Andersen Consulting, Boeing, Compaq, Dell, Ford, HP, Loudcloud, Merrill Lynch, Rational, SAP AG, Sterling, and Sun. For a full list of current supporters, see the consortium's web site.
UDDI is based on an existing set of foundation standards that have themselves found widespread acceptance. These foundation standards include the following:
HTTP - the standard protocol for communication over the Internet.
XML - a widely accepted industry standard for packaging data as well architected strings.
SOAP - a rapidly emerging standard (primarily led by Microsoft and IBM) for packaging client work requests and system responses as XML strings. SOAP stands for Simple Object Access Protocol (a rather confusing acronym, since it is neither simple, nor related to objects!).
The combination of HTTP and SOAP is the presumed basis for all future eCollaboration. In this white paper, when I discuss SOAP I will assume we are using HTTP as the transport protocol. Although other protocols (such as those based on message queues) could be used for delivery of SOAP requests, this would not be likely in an eCollaboration architecture.
The most common SOAP based eCollaboration architecture is shown in Figure 2. Since it is easier to explain in the context of an example, I'll go back to my original prototypical eBusiness, MoneyBroker. Let's see how MoneyBroker might eCollaborate with AustinKayaks using SOAP, the ultimate result being that AustinKayaks can enable its customers to pay with a MoneyBroker account.
Figure 2. Typical SOAP based eCollaboration
Let's follow the eCollaboration between AustinKayaks and MoneyBroker, based on Figure 2. The eCollaboration begins when an AustinKayaks customer working at a browser (1) goes to the AustinKayaks URL and asks to buy a kayak. The request is transmitted over the Internet as a HTTP request (2). The request is received by the AustinKayaks presentation tier (3) which makes a request to the AustinKayaks business tier via whatever local protocol (4) is used by this site. If AustinKayaks is a Microsoft site, then the native protocol is probably (but not necessarily) DCOM.
The AustinKayaks business logic now realizes it needs to request a payment from the MoneyBroker business logic. This request is made on a local (in process) SOAP surrogate (5). The SOAP surrogate repackages the payment request as a SOAP request and transmits it using HTTP (6) over the Internet to the MoneyBroker site where the request is received by a SOAP receiver (7) on the MoneyBroker presentation tier.
The only purpose of the SOAP receiver (7) is to turn the SOAP request back into a native request that can be passed on, via the native protocol (8), to the MoneyBroker business tier (9), where the request can be processed and the payment made. Results are then returned from the MoneyBroker business tier back to the AustinKayaks presentation tier, which can then interpret the results into something appropriate for the AustinKayaks customer's browser.
SOAP is technology neutral. AustinKayaks and MoneyBroker do not need to agree on what technology they use for building their sites, as long as both technologies support SOAP for interoperability purposes.
SOAP is great for allowing AustinKayaks to make use of MoneyBroker services, but only if AustinKayaks already knows four things: that MoneyBroker exist; the URL at which MoneyBroker can be found; the services that MoneyBroker can provide; and the exact format of the SOAP requests that MoneyBroker can accept. What if AustinKayaks doesn't know any of these things? What if AustinKayaks only knows that it needs the services of a bill paying service, and doesn't know which exist, where they are located, or how to use them?
This is where UDDI comes in. UDDI defines the standards for allowing potential eCollaborators to find out about each other. It is beyond the scope of this white paper to describe all of the UDDI standards (this information is available on the web), but the following areas, among others, are covered:
URLs of registration facilities that contain information about industry standard interfaces, such as bill paying services.
Specific companies that have promised to support industry standard interfaces, such as MoneyBroker.
SOAP Interfaces to those registration facilities, which potential collaborators can use to programmatically find out about each other.
A standard technology neutral language for describing SOAP interfaces.
Between the UDDI foundation standards (HTTP, XML, SOAP) and the UDDI eCollaboration standards themselves, we have a technology neutral framework for allowing businesses to work together.
The .NET platform has already embraced XML and SOAP technologies. Microsoft is one of the three leaders of the UDDI effort (Ariba and IBM being the other two), so it is clear that as soon as these standards mature, we will see them incorporated into the .NET platform.
We have a special term to describe business logic that is SOAP callable, and whose site has used the appropriate UDDI standards to make those SOAP services widely available. We call such business logic a Web Service.
The .NET Platform: Putting it all together
Figure 3 shows how all the pieces of the .NET platform fit together. This figure should be compared to Figure 1, which shows the generic version of this architecture.
Figure 3. .NET Platform eCommerce Architecture
The J2EE Architecture
The J2EE architecture defined by the Sun standards can be discussed in less space than the .NET platform vision because there is less of it. If one looks at a specific vendor's offering, such as IBM's WebSphere, the largest part of its technology will be specific to WebSphere. It is beyond the scope of this article to compare all of the vendor specific enhancements to J2EE, and in my experience, most companies interested in J2EE as a platform are interested in the portability of the standard. Anybody interested in portability will need to limit themselves to what is defined by Sun.
The J2EE architecture can be divided into these five parts:
The Java language system
The client programming model
The middle tier infrastructure
The programmer enterprise API
Non programmer visible API
The last of these, the non programmer visible API, includes API that defines how other products plug into J2EE, such as the Connector API, and APIs that have been effectively superseded by later advancements in the J2EE model, such as the JTA (Java Transaction API). Since the non programmer visible APIs are not important from the perspective of comparing the Microsoft and Sun platform visions, I will not cover these areas in my J2EE overview (as I did not cover the equivalent APIs in the .NET platform overview).
The Java Language System
At a high level, the Java language system looks similar to the .NET Framework. In both cases, source code is translated into an intermediate language. Whereas in the .NET platform, that intermediate language is MSIL, in the Java system, it is Java Byte Code. In both cases, the intermediate language is brought into the runtime environment. In the Framework, that environment is the Common Language Runtime. For Java, that environment is the Java Virtual Machine. Overall, the Common Language Runtime and the Java Virtual Machine have similar functions, and both will undoubtedly evolve and leapfrog each other in technological advances.
The most important difference between the two systems has to do with the translation of source code to the intermediate language. In the .NET platform, the intermediate language has been designed to accommodate the needs of any language. In Java, the intermediate language is designed to meet the needs of Java. While is theoretically possible to generate Java Byte Code from languages other than Java, in practice that has not been demonstrated in any commercial product.
The Client Programming Model
The J2EE client programming model focuses on interacting with the browser. The client programming model has three pieces: Java Applets, Java Servlets, and Java Server Pages.
Java Applets are used to package Java code that will run within the browser. In the .NET platform space, this is functionally equivalent to ActiveX. In my experience, relatively little usage is made of either applets or ActiveX components. ECommerce architectures are typically based on a browser making HTTP requests to a presentation tier, and the presentation tier responding with HTML pages. This type of a system does not use either ActiveX components or Java Applets and therefore I do not cover either of these technologies in this white paper.
The important technologies that deal with HTTP requests and HTML responses are Java Servlets and Java Server Pages. These two technologies are analogous to ASP.NET (Active Server Pages) in the Microsoft space.
The major difference between the .NET platform presentation tier and the Java presentation tier is how each deals with different client functionality. The Java presentation tier follows the old Microsoft ASP (pre .NET) model, which makes it the presentation tier programmer's responsibility to determine the ultimate destination browser (or other thin client system), what the capabilities of that thin client system are, and how to generate HTML to best take advantage of that thin client system.
The Middle Tier Infrastructure
With J2EE, the middle tier infrastructure is Enterprise Java Beans (EJB). The current version of the specification is 2.0 which is available on-line. The .NET platform equivalent to J2EE is COM+.
There are very few architectural differences between EJB and COM+. Both are essentially derivative architectures from MTS (Microsoft Transaction Server), the original component-oriented middle tier infrastructure introduced by Microsoft in 1996. The key ideas first introduced by MTS and then incorporated into both EJB and COM+ included the following:
High scalability through sharing of component instances
Middle-tier centric security
Automatic transaction boundary management
EJB did add one new architectural idea, a technology for automatically managing component state. This technology is referred to as entity beans. While the idea of entity beans is attractive, the current implementations are dependent on middle tier data caches that are independent of the database caches. Unfortunately, there is no mechanism for maintaining coherency between the two caches. This means that any usage of entity beans introduces a high risk of database corruption. Until the cache coherency problem is solved, entity beans must continue to be considered at best experimental techology.
For a more in-depth comparison of EJB and COM+, see my most recent book.
The Programmer Enterprise API
The most important parts of what we might call the Java Enterprise API are the following:
Java Database Connection (JDBC) 2.0 - The API for accessing relational databases from Java . This is equivalent to ADO.NET in the .NET platform space.
Java Naming and Directory Interface (JNDI) - The API for accessing information in enterprise name and directory services from Java. This is somewhat similar to the Active Directory Services Interface (ADSI) in the .NET platform space.
Java Message Service (JMS) 1.0 - The Java API for asynchronous workflow. This is functionally equivalent to Microsoft Message Queue API, which, in the component space, has been superceded by queued components.
J2EE: Putting It All Together
Figure 4 shows the relationship between the main pieces of J2EE, which can be compared to Figure 3, which shows the equivalent picture for the .NET platform, and Figure 1, which shows the equivalent generic architecture.
Figure 4. J2EE eCommerce Architecture
Similarities between J2EE and the .NET Platform
A full listing of equivalencies between J2EE and the .NET platform is given in Figure 5. As you can see, many of the .NET platform functional areas have no counterpart in J2EE. In some of these cases, it is considered to be an implementation specific decision as to whether or not to support the functionality, and if so, how. Note: for unfamiliar abbreviations, see the glossary.
Figure 5. Technology equivalences
Technology .NET J2EE
Support technologies
Distribution protocol DCOM, SOAP RMI/IIOP
Firewall ISA* not specified
HTML page caching ISA*, ASP.NET not specified
Presentation tier technologies
Infrastructure IIS not specified
Programming model ASP.NET Servlets, JSP
High availability NLBS*, ACS*, other not specified
Load balancing NLBS*, ACS*, other not specified
Management ACS* not specified
Middle tier technologies
Infrastructure COM+ EJB
Programming tool Visual Studio.NET not specified
High availability ACS* not specified
Load balancing ACS* not specified
Security API COM+ Security Call Context JAAS
Message Queue API MSMQ JMS 1.0
Asynchronous components Queued (COM+) Message driven beans (EJB 2.0)
Naming and Directory Service ADSI JNDI
Data tier technologies
Distributed transaction MS-DTC JTS
Relational DB API ADO.NET JDBC 2.0
Hierarchical DB API ADO.NET -
Database storage SQLServer** -
Mainframe DB connectivity HIS* Java Connectors
Framework technologies
eCommerce framework Commerce Server* -
Business to business orchestration BizTalk Server* -
* Optional add-ons services for the .NET platform.
** SQLServer is the official .NET platform database technology, but any ADO.NET compliant database, which includes most major databases, can be used.
Differences between J2EE and the .NET Platform
You can see that there is tremendous overlap between the J2EE and .NET platform technologies. How, then, does one choose between them? In this section I will discuss what I see as the main differences.
Vendor Neutrality
Many companies buy into J2EE believing that it will give them vendor neutrality. And, in fact, this is a stated goal of Sun's vision:
A wide variety of J2EE product configurations and implementations, all of which meet the requirements of this specification, are possible. A portable J2EE application will function correctly when successfully deployed in any of these products.
In fact, few non-Sun J2EE proponents believe this is achievable. One of the most prominent independent J2EE spokespersons is Paul Harmon, a principal consultant for the Cutter Consortium and the writer of the widely read Architecture/e-Business E-Mail Advisory. While Harmon is usually very pro-J2EE, he recently wrote this unusually frank assessment of J2EE vendor portability
Has the EJB model reached the point where I can move EJB components from one EJB application server to another? Not in most cases. The EJB specification isn't comprehensive enough. EJB application server vendors have "filled in" by providing proprietary solutions to complete the model and to guarantee that their clients can build production systems.
Harmon summarizes the vendor neutrality situation today, as do many, with this assessment:
The reality, at the moment, is that if you want to develop an EJB application, you should stick with a single vendor.
The reality today is that there is no such thing as vendor neutrality. Of course, the .NET platform is not vendor neutral, it is tied to the Microsoft operating systems. But neither are any of the J2EE implementations. The best advice I can give is to choose some vendor, plan on staying with that vendor, and leverage the heck out of the platform that vendor provides.
Overall Maturity
The first of the J2EE specifications, the EJB specification, came out in 1998, and the first beta versions in 1999. This was three years after the first implementation of the equivalent .NET platform technologies, MTS, the forerunner of COM+. I discussed the evolution from MTS to COM+ to the .NET platform in a recent article.
Given that the .NET platform has a three year lead over J2EE, it should be no surprise to learn that the .NET platform is far more mature than the J2EE platform. Whereas we have high volume highly reliable web sites using .NET technologies (NASDAQ and Dell being among many examples), we have none that I am know of that use a J2EE platform. Again, Paul Harmon:
Any company attempting a [J2EE based] company-wide, enterprise system today is working on a cutting-edge effort and better have a team of really good developers to help it over the rough spots. More important, it should probably reconsider a comprehensive project and settle for an initial approximation.
Interoperability and Web Services
The .NET platform eCollaboration model is, as I have discussed at length, based on the UDDI and SOAP standards. These standards are widely supported by more than 100 companies. Microsoft, along with IBM and Ariba, are the leaders in this area. Sun is a member of the UDDI consortium and recognizes the importance of the UDDI standards. In a recent press release, Sun's George Paolini, Vice President for the Java Community Development, says:
"Sun has always worked to help establish and support open, standards-based technologies that facilitate the growth of network-based applications, and we see UDDI as an important project to establish a registry framework for business-to-business e-commerce.
But while Sun publicly says it believes in the UDDI standards, in reality, Sun has done nothing whatsoever to incorporate any of the UDDI standards into J2EE. This includes the most basic of the UDDI standards, SOAP, that has been around for more than a year. As IBM's Rod Smith, Vice President of Emerging Technologies, and one of Sun's strongest J2EE partners, recently said:
So far, Sun hasn't said too much about [UDDI] Web Services. And I think there are reasons for that. I think that they're looking at Java. When we look at Web Services, we're listening to customers and the requirements that they're doing, and the fact is, customers have existing systems which are not Java-based, as well as Java applications. So Sun has been still shepherding Java but has been very quiet on this subject.
In fact, Smith's analysis of Sun's interoperability strategy is right on target. Sun has primarily focused on interoperability between J2EE vendors and, to a limited extent, with CORBA vendors. Sun's idea of interoperability is that it should be based on the communications protocol called IIOP.
There are three major flaws with IIOP based interoperability.
First, it requires the whole world to be running J2EE or CORBA, an assumption that even Sun's J2EE partners reject. IBM's Rod Smith explained why IBM is supporting SOAP rather than IIOP as the open standard for interoperability:
When the announcement came out and we said we [IBM] were going to promote SOAP as an open standard and bring it forward accordingly, the response was unbelievable and positive because people want to do this type of integration. They have Microsoft-based solutions. They also have Java-based solutions. They have [Windows] NT-based solutions and they have Linux-based solutions.
The second flaw is that IIOP, like all proprietary communications protocols, is not amenable to transport over the Internet. This makes it impossible to serve as a widespread mechanism for eCollaboration.
The third flaw is that even if the whole world agreed to use both IIOP and J2EE, the current specification of IIOP is inadequate to ensure interoperability even among the J2EE vendors. As Paul Harmon says:
Are EJB application servers from different vendors standardized in such a way that they can be snapped together in larger systems? In spite of the use of Internet InterORB Protocol (IIOP) to support inter-EJB application communication, one can't casually plan to link multiple EJB products in a network.. getting two EJB application servers that each rely on several nonstandard utilities to communicate smoothly takes some serious programming.
The reality today is that the .NET platform has a much stronger technology neutral eCollaboration strategy that does J2EE. IBM is so convinced that UDDI, rather than IIOP, is the correct approach to interoperability that it has broken with Sun over this issue. At this point, it is painfully obvious that IIOP, despite its ten year head start over UDDI, has been a complete failure.
Scalability
Scalability refers to the ability to add more workload. Typically the additional workload comes through the addition of customers. Scalability is a complex topic which I have written about in depth in several readily available articles. To simplify this discussion, I will discuss scalability in the context of the issues MoneyBroker will likely face over the next three years. I will further simplify this discussion by only considering the cost of running the business and database tiers, not the presentation tier, although a similar analysis of the presentation tier would yield similar results.
Let's assume the business model for MoneyBroker calls for it to be processing 100,000 payments per day this year, ten times that the second year, and ten times that the third year. What would be the relative cost of choosing an J2EE/Unix solution or a .NET Framework/Windows solution?
In order to gauge the size of the machines MoneyBroker will need over the next three years, we need a standard benchmark for transactional performance. The industry standard benchmark for transactional throughput is specified by a consortium called the Transaction Performance Council (TPC) and the benchmark is called the TPC-C benchmark. TPC members include Sun, IBM, Oracle, BEA, Microsoft, and most other companies that sell for the middle/data tier.
The TPC-C benchmarks rates the highest workload that a system can achieve. The unit of measure is tpmC, for transactions per minute as defined by the TPC-C benchmark. I will not discuss that benchmark, other than to say that it considers a transaction within the context of a distributed order entry system. The specifications of that benchmark are available at the TPC web site.
There are two problems MoneyBroker faces in trying to use the TPC-C numbers to make its platform choice.
The first problem is that the TPC-C specified transactions are quite different than the MoneyBroker transactions. This requires MoneyBroker to look through the TPC-C specification and guess how many TPC-C transactions it takes to be equal in workload to one MoneyBroker transaction. Let's say MoneyBroker calculates that one of its transactions is equal to 10 TPC-C transactions, allowing plenty of margin for error.
The second problem is that no J2EE vendor has publicly released its TPC-C numbers. This makes it difficult for MoneyBroker to calculate the throughput of a particular J2EE implementation on, say, AIX. Interestingly, while all of the major J2EE vendors have submitted TPC-C benchmarks, none have submitted numbers based their J2EE technology.
For example, there are six benchmarks with IBM's WebSphere technology, the IBM brand which includes its J2EE technology. However if one studies the WebSphere results, one finds that none of the benchmark code was written in Java, and therefore none of it used any of the WebSphere J2EE capability. Instead, these benchmarks used IBM's traditional Encina transaction processing monitor technology, a product that, coincidentally, is included under the general WebSphere brand. Similary, BEA runs their benchmarks using the traditional Tuxedo technology, part of its WebLogic brand, but not the part that include J2EE.
Since we have no J2EE performance numbers, we must estimate the relative performance of a J2EE implementation. Since J2EE will be layored on traditional transaction processing monitors (which the vendors have benchmarked), but will add the overhead of the Java programming language, the Java virtual machine, and the EJB (middle tier) infrastructure, a reasonable guess is that J2EE will perform at 50% of the equivalent non J2EE (e.g. Tuxedo performance). I will therefore use a 50% adjustment factor to estimate the J2EE throughput capabilities.
Let's follow the analysis MoneyBroker conducts using the TPC-C information. Money Broker is trying to determine what kind of a system to buy. It obviously wants to spend as little as possible, but still be sure that it can achieve the throughput it needs at its peak customer usage, and to be sure that its systems can scale up to meet the demands over the next three years
This year MoneyBroker needs 100,000 transactions per day. This is about 70 transactions per minute with a peak load of about 700 transactions per minute. Since 1 MoneyBroker transaction equals 10 tpmC transactions, this equates to about 7,000 tpmC at the peak work load. In the second year, this is multiplied by 10 to be 70,000 tpmC, and in the third year, this is again multiplied by 10 to be 700,000 tpmC.
So what are these systems going to cost (including both hardware and software), over the next three years? Let's start by looking at the J2EE/Unix possibilities. I can't go through all of the J2EE/Unix choices, so I will look at what is probably the most representative J2EE/Unix system: IBM's AIX operating system, WebSphere, and Oracle 8i databases. There are six benchmarks for this configuration. Sorted in order of lowest to highest tpmC, and with the J2EE adjustments (which I discussed earlier) we have:
Company System tpmC Total Sys. Cost
Bull Escala T610 c/s 16,785 $1,980,179
IBM RS/6000 Enterprise Server F80 16,785 $2,026,681
Bull Escala EPC810 c/s 33,375 $3,037,499
IBM RS/6000 Enterprise Server M80 33,375 $3,097,055
Bull Escala EPC2450 110,403 $9,563,263
IBM IBM eServer pSeries 680 Model 7017-S85 110,403 $9,560,594
If we look at some representative .NET platform systems (there are too many to look at them all, and the numbers are very consistent) we have these:
Company System tpmC Total Sys. Cost
Dell PowerEdge 4400 16,263 $273,487
Compaq ProLiant ML-570-6/700-3P 20,207 $201,717
Dell PowerEdge 6400 30,231 $334,626
IBM Netfinity 7600 c/s 32,377 $443,463
Compaq ProLiant 8500-X550-64P 161,720 $3,534,272
Compaq ProLiant 8500-X700-64P 179,658 $3,546,582
Compaq ProLiant 8500-X550-96P 229,914 $5,305,571
Compaq ProLiant 8500-X700-96P 262,244 $5,305,571
Compaq ProLiant 8500-700-192P 505,303 $10,003,826
You can see the choices that MoneyBroker faces. This year it only needs a 7,000 tpmC system. This will cost about $2 million dollars in the Unix market and $273 thousand in the .NET platform market. Next year MoneyBroker will need a 70,000 tpmC system, which will cost it about $9.5 million in the J2EE/Unix market and $3.5 million in the .NET platform market. In three years, MoneyBroker will need a 700,000 tpmC system. None of these systems are rated at 700,000 tpmC, but the one that is by far the closest is the $10 million dollar .NET platform system. An equivalent J2EE/Unix machine would be expected to cost $47.5 million dollars, if it existed.
Clearly if the cost of the system is a serious consideration, the .NET platform has a major advantage of J2EE. One can expect to spend five to ten times as much for the same functionality on the J2EE/Unix platform as one would spend on the .NET platform. If a unit of work costs ten cents on .NET platform, that same unit of work will probably cost fifty cents to a dollar on J2EE/Unix.
I need to point out again that while these .NET platform benchmarks are real benchmarks of real machines, none of these J2EE benchmarks actually exist. These are extrapolated benchmark results which real systems may or may not be able to actually achieve. Until the J2EE vendors release their benchmark numbers, we must remember that not one J2EE platform has been proved able to handle these high workloads at any price.
Framework Support
When building a large, eCommerce solution, it goes without saying that one does not want to start from scratch. One wants to build on top of a well defined and tested eCommerce framework. The use of such a framework can dramatically reduce development costs, probably by a factor of at least 10.
The .NET platform includes such an eCommerce framework called Commerce Server. At this point, there is no equivalent vendor-neutral framework in the J2EE space. With J2EE, you should assume that you will be building your new eCommerce solution from scratch. Paul Harmon appears to agrees with this assessment, saying
Moreover, no matter what [J2EE] vendor you choose, if you expect a component framework that will allow you to quickly field complete e-business applications, you are in for a frustrating experience.
If MS Commerce Server can serve as your eCommerce foundation, then it will likely have a tremendous impact on the cost of developing your system. Commerce Server is particularly well suited for retail operations. Such eCommerce systems should look carefully at this technology.
Language
In the language arena, the choice is about as simple as it gets. J2EE supports Java, and only Java. It will not support any other language in the foreseeable future. The .NET platform supports every language except Java (although it does support a language that is syntactically and functionally equivalent to Java, C#). In fact, given the importance of the .NET platform as a language independent vehicle, it is likely that any language that comes out in the near future will include support for the .NET platform.
Some companies are under the impression that J2EE supports other languages. Although both IBM's WebSphere and BEA's WebLogic support other languages, neither does it through their J2EE technology. There are only two official ways in the J2EE platform to access other languages, one through the Java Native Interface and the other through CORBA interoperability. Sun recommends the later approach. As Sun's Distinguished Scientist and Java Architect Rick Cattell said in a recent interview,
You can invoke C++ code through the Java Native Interface capability or through CORBA. CORBA would probably be the recommended approach since it offers more flexibility, and we have designed J2EE to work well with CORBA in passing context.
Building any new code in a CORBA architecture is a highly questionable strategy. CORBA, the darling architecture of the 90's, is now all but dead. As best I can tell, none of the major CORBA vendors (with the exception of IONA) have made a profit on CORBA, and none (including IONA) are continuing to invest in this technology. The bottom line is that if one wants to develop in any language other than Java, then J2EE is a bad platform choice.
Some companies that are currently non-Java are considering the possibility of re-standardizing on Java. There are three possible ways of approaching this:
Retraining existing staff
Hiring new staff and possibly replacing existing staff
Outsourcing
Retraining is probably the most expensive option. In my experience there is tremendous overhead associated with retraining traditional programmers to be proficient object-oriented Java programmers. This is borne out by a recent study of the Gartner group, who concluded it costs approximately $60,000 to retrain a COBOL programmer to be a Java programmer. I believe the costs will be similar for a Visual Basic programmer. And at the end of this exercise, you have gained nothing in productivity. You will simply have a programmer who can now write the same code they could have written $60,000 ago, but can now write that code in Java. In many companies, I have seen productivity hurt by the adoption of object-oriented technologies, as work-time often gets squandered in endless and non-productive theoretical discussions about "correct" object-oriented design and analysis.
Hiring and/or replacing staff is also expensive. Currently, Java programmers command about 30% higher salaries than equivalent Visual Basic/COBOL programmers. They also, in my experience, have higher turnover rates. And there is no evidence that they are even slightly more productive.
Outsourcing is probably the only viable option for a company wanting to switch to Java. But it is unrealistic to assume that outsourcing will completely shield you from the problems mentioned above, especially the additional programmer cost, which is, obviously, going to be passed on to you.
What language should you use? The bottom line is that if you have a staff trained in Java and good policies already in place to ensure effective management of the programming process, then by all means, continue on this path. I personally like Java as a programming language, although I think there are others at least as good. On the other hand, if your shop is primarily made up of Visual Basic or COBOL, then switching to Java is almost certainly going to be an expensive and frustrating experience.
Your choice of language does not necessarily determine your choice between J2EE and the .NET platform. Of course, if you want to use something other than Java, you are out of the J2EE space. But an affinity for Java need not disenfranchise you from the .NET platform. The .NET platform includes support for C# (pronounced C sharp), a language that is so close to Java, many people can't tell them apart at first glance. An experienced Java programmer could learn the C# syntax in a few hours.
However if you have chosen Java not because of the language but because of the portability strategy represented by the J2EE platform, then C#, or anything else that runs on the .NET platform is not likely to make you happy. In this case, J2EE is clearly your choice. Be sure to read my section on portability before you make this decision, however.
Portability
Much of the appeal of J2EE lies in the promise of portability. There are two flavors of portability. The first is vendor portability. I refer to this as vendor neutrality, and have already discussed (and rejected) this idea earlier. The second flavor of portability is operating system portability. This refers to the ability to move a code base from one operating system to another without having to change the code itself. Operating system portability, unlike vendor portability, is a possibility with most implementations of J2EE.
The reason that operating system portability is a possibility with J2EE is not so much because of any inherent portability of J2EE, as it is that most of the J2EE vendors support multiple operating systems. Therefore as long as one sticks with a given J2EE vendor and a given database vendor, moving from one operating system to another should be possible. This is probably the single most important benefit in favor of J2EE over the .NET platform, which is limited to the Windows operating system. It is worth noting, however, that Microsoft has submitted the specifications for C# and a subset of the .NET Framework (called the common language infrastructure) to ECMA, the group that standardizes JavaScript.
It is obvious why vendor portability/neutrality would be desirable, but what is the benefit of operating system portability? There are typically two types of companies that think they need operating system portability: independent software vendors (ISVs) and corporations looking for scalability solutions.
ISVs need operating system portability when they have a significant customer base on non-Windows platforms. One can't sell a product to Unix customers that is tied to the .NET platform. It doesn't matter if the .NET platform is better than J2EE or not. It doesn't run on Unix.
J2EE offers an acceptable solution to ISVs when the product must be marketed to non-Windows customers, particularly when the J2EE platform itself can be bundled with the ISV's product as an integrated offering.
If the primary customer base for the ISV is Windows customers, then the .NET platform should be chosen. It will provide much better performance at a much lower cost.
Many companies that want operating system portability are not ISVs. Most of these companies think portability is the path to scalability. These companies believe that they can achieve higher scalability by migrating applications to higher and higher end hardware platforms as throughput requirements expand.
If you believe operating system portability will in any way help you achieve scalability, you are making a serious mistake. Scalability is not a hardware problem; it is a software problem. The highest scalability is achieved by writing for a highly scalable platform and then leveraging that platform as much as possible. Writing for a J2EE implementation that just happens to run on multiple platforms will be a distant second in terms of achievable scalability. The platform that is by far the best documented in terms of its ability to achieve high scalability is the .NET platform.
Using the numbers given in my section on scalability, the .NET/Windows platform can scale from 16,000 transactions per minute to over 500,000 transactions per minute. The IBM WebSphere J2EE/Unix technology, one of the best representatives of the J2EE genre, will probably do no better than a 17,000 to 110,000 range of transactions per minute, at a much higher cost per transaction.
So portability is not as simple as it appears. If you really want scalability, the .NET platform is a clear winner over J2EE. If you must support non-Windows platforms, then J2EE is the clear winner over the .NET platform.
If you want portability so that you are independent of the whims or fortunes of a particular vendor, then forget it. That kind of portability doesn't exist. So choose your vendor carefully. Make sure that you understand and are comfortable with the technical direction of that vendor. Make sure that your vendor has a long-term commitment to that platform. And finally, make sure that your vendor has the financial resources to be a survivor in this highly competitive technical arena.
Client device independence
I discussed the difference between the Java and the .NET platform presentation tier programming models. The major difference being that with Java, it is the presentation tier programmer that determines the ultimate HTML that will be delivered to the client, and with .NET, it is a Visual Studio.NET control.
This Java approach has three problems. First, it requires a lot of code on the presentation tier, since every possible thin client system requires a different code path. Second, it is very difficult to test the code with every possible thin client system. Third, it is very difficult to add new thin clients to an existing application, since to do so involves searching through, and modifying a tremendous amount of presentation tier logic.
The .NET Framework approach is to write device independent code that interacts with visual controls. It is the control, not the programmer, that is responsible for determining what HTML to deliver, based on the capabilities of the client device.. In the .NET Framework model, one can forget that such a thing as HTML even exists!
This approach solves all three of the problems of the Java/old-ASP approach. One can write an effective presentation tier application with much less code, since a single code path works for all possible thin clients. It is much easier to test that code, since one is only testing one's interaction with the control, rather than the client devices themselves. And finally, one can add new client devices very easily, but simply downloading the latest version of the control that has hopefully been updated with the latest knowledge about thin client devices.
From a cost perspective, the .NET Framework approach is a clear winner. Development, debugging, and maintenance are all much easier (and much cheaper) when the presentation tier developer is not responsible for determining what will be displayed on the client device.
Conclusions
We have two competing visions for eCommerce architectures.
Sun's J2EE vision is based on a family of specifications that can be implemented by many vendors. It is open in the sense that any company can license and implement the technology, but closed in the sense that it is controlled by a single vendor, and a self contained architectural island with very limited ability to interact outside of itself.
One of J2EE's major disadvantages is that the choice of the platform dictates the use of a single programming language, and a programming language that is not well suited for most businesses.
One of J2EE's major advantages is that most of the J2EE vendors do offer operating system portability.
Microsoft's .NET platform vision is a family of products rather than specifications, with specifications used primarily to define points of interoperability. The major disadvantage of this approach is that if is limited to the Windows platform, so applications written for the .NET platform can only be run on .NET platforms. Their are several important advantages to the .NET platform:
The cost of developing applications is much lower, since standard business languages can be used and device independent presentation tier logic can be written.
The cost of running applications is much lower, since commodity hardware platforms (at 1/5 the cost of their Unix counterparts) can be used.
The ability to scale up is much greater, with the proved ability to support at least ten times the number of clients any J2EE platform has shown itself able to support.
Interoperability is much stronger, with industry standard eCollaboration built into the platform.
The single most important differentiating characteristic between these two platforms is overall system profitability. Companies seeking a low cost eCommerce platform would be negligent to ignore the Microsoft offering. eCommerce has always required high reliability and excellent scalability. For the first time, these functionalities are available at on a commodity hardware platform for a fraction of the cost of Unix based solutions.
Glossary
ADO.NET - The .NET API for accessing the data tier.
Application Center Server - The .NET technology that provides middle tier load balancing and general management of cluster farms.
Assembly - The unit of application deployment for the .NET platform.
BizTalk Server - The .NET technology that provides orchestration between business processes, especially legacy business processes.
C# - A new C++ derivative programming language that is similar in functionality, look, and feel to Java.
CICS - An IBM mainframe transactional processing monitor technology.
COBOL - One of the primary business programming languages.
COM+ - The .NET middle tier infrastructure designed to support business components.
Commerce Server - The .NET eCommerce framework.
CORBA (Common Object Request Broker Architecture) - The earliest of the component architectures defined by the OMG.
Common Language Runtime - The .NET runtime that provides support for compiled IL.
DB2 - An IBM relational database product that competes with SQLServer.
DCOM - The Microsoft protocol typically (but not exclusively) used for communicating to components within the .NET architecture.
eBusiness - A company that does all or an important part of its business over the Internet.
eCollaboration - Business to business collaboration conducted over the Internet
eCommerce - Business that is conducted over the Internet.
Eiffel - An important research programming language, used in some businesses.
EJB (Enterprise JavaBeans) - The J2EE middle tier infrastructure designed for business components.
Entity Beans - A component model that is specific to the EJB technology that provides varying degrees of state management.
HIS (Host Integration Server) - The .NET technology that interoperates with IBM mainframes.
HTML - The industry standard for describing browser displays.
HTTP - The industry standard for communications over the Internet.
IL (Intermediary Language) - The intermediary language used by the .NET platform.
IMS - An IBM mainframe database technology.
ISAS (Internet Security and Acceleration Server) - The .NET technology that provides firewall protection and HTML page caching.
ISV (Independent Software Vender).
J2EE - Java 2 Enterprise Edition.
JAAS (Java Authentication and Authorization Service) - The J2EE API for managing security.
Java - The programming language associated with J2EE.
Java Applets - A packaging technology for downloading and running Java code on the client side in a browser.
Java 2 Enterprise Edition - A general term describing Sun's family of eCommerce specification.
Java Byte Code - The intermediary language run within the Java Virtual Machine.
Java Connectors - The J2EE API used for plugging in different database technologies (not programmer visible).
Java Server Pages - The J2EE technology that, along with Java Servlets, is the programming model for the presentation tier.
Java Servlets - The J2EE technology that, along with Java Server Pages, is the programming model for the presentation tier.
Java Virtual Machine - The Java language environment.
JDBC (Java Database Connection) - The J2EE API for accessing the data tier.
JMS (Java Message Service - The J2EE API for accessing message queues.
JNDI (Java Naming and Directory Interface) - The API for naming and locating specific instances used in J2EE.
JTS (Java Transaction Server) - The J2EE API used for managing transactions boundaries, largely superseded by EJB automatic transaction boundary management.
MS-DTC (Microsoft Distributed Transaction Coordinator) - The .NET technology that manages the two phase commit protocol used in distribution transaction coordination.
MTS (Microsoft Transaction Server) - The original middle tier, component based infrastructure designed to support highly scalable applications.
.NET - A general term for describing Microsoft's eCommerce platform.
.NET Building Block Services - Collaborative services that help businesses work together.
.NET Client Systems - Subsets of the .NET platform designed to support various thin client platforms.
.NET Enterprise Servers - A collection of optional enterprise level products available for the .NET platform.
.NET Framework - The overall infrastructure in which .NET applications run.
NLBS (Network Load Balancing Service) - A .NET technology for load balancing and providing high scalability to the presentation tier.
Oracle - A relational database product that competes with SQLServer.
OMG (Object Management Group) - An early industry consortium that defined the original CORBA specifications.
RMI/IIOP (Remote Method Invocation over Internet InterOrb Protocol) - The protocol used for communicating with components in J2EE based on the CORBA protocol.
SOAP (Simple Object Access Protocol) - An industry standard for packaging of method requests.
SQLServer - Microsoft's high-end database product.
TCP/IP - A low-level communications protocol powering the Internet.
TPC-C - An industry standard benchmark based on a distributed order entry system for measuring throughput at the middle tier/data tier combination.
tpmC (Transactions per Minute, as defined by C benchmark) - A standard measure of a transaction as defined by the TPC-C benchmark.
UDDI (Universal Description, Discovery, and Integration) - A set of industry standards controlled by uddi.org that define eCollaboration.
uddi.org - The consortium controlling UDDI.
VisualBasic - A popular business programming language developed by Microsoft.
Visual Studio.NET - The programming environment for .NET.
WebLogic - BEA's eCommerce platform, a superset of J2EE.
WebSphere - IBM's eCommerce platform, a superset of J2EE.
web service - A middle tier business component that is callable over SOAP.
URL (Universal Resource Locator) - A standard Internet location.
XML - An industry standard for architecting text strings.
Trademark Information
Sun, Sun Microsystems, Java, JDBC, JavaBeans, Enterprise JavaBeans, JavaServer Pages, Java Naming and Directory Interface, Write Once, Run Anywhere are all claimed as trademarks or registered trademarks of Sun Micrososytems, Inc. ObjectWatch is a registered trademark of ObjectWatch, Inc. All other trademarks are owned by their respective companies.
ⓘ
This content was originally posted on Y! Answers, a Q&A website that shut down in 2021.