1) SOA Development Lifecycle
Service-Oriented Development Life Cycle
Service-Oriented Life Cycle Strategy: Establishment of project stages, planning for predictable and unpredictable events, and founding service-oriented development process and life cycle iterations Service-Oriented Development Life Cycle Disciplines for Run-Time and Design-Time Seasons: Establishment of service-oriented development disciplines, such as service-oriented discovery and analysis, design, architecture, construction, deployment, and operations
Service-Oriented Life Cycle Roles and Responsibilities: development of SOA role models, accountabilities, and responsibilities
2) Error handling in SOAP.
When a Web service request is being processed, if an error is encountered, the nature of the error needs to be communicated to the client, or sender of the request. Because clients can be written on a variety of platforms using different languages, there must exist a standard, platform-independent mechanism for communicating the error.
The SOAP specification (available at http://www.w3.org/TR/soap/) defines a standard, platform-independent way of describing the error within the SOAP message using a SOAP fault. In general, a SOAP fault is analogous to an application exception. SOAP faults are generated by receivers to report business logic errors or unexpected conditions. In JAX-WS, Java exceptions (java.lang.Exception) that are thrown by your Java Web service are mapped to a SOAP fault and returned to the client to communicate the reason for failure. SOAP faults can be one of the following types:
Modeled—Maps to an exception that is thrown explicitly from the business logic of the Java code and mapped to wsdl:fault definitions in the WSDL file, when the Web service is deployed. In this case, the SOAP faults are predefined. Unmodeled—Maps to an exception (for example, java.lang.RuntimeException) that is generated at run-time when no business logic fault is defined in the WSDL. In this case, Java exceptions are represented as generic SOAP fault exceptions, javax.xml.ws.soap.SOAPFaultException.
The faults are returned to the sender only if request/response messaging is in use. If a Web service operation is configured as one-way, the SOAP fault is not returned to the sender, but stored for further processing.
How SOAP Faults Are Processed
3) UDDI Architecture
The Universal Description, Discovery, and Integration (UDDI) Project provides a standardized method for publishing and discovering information about web services. The UDDI Project is an industry initiative that attempts to create a platform-independent, open framework for describing services, discovering businesses, and integrating business services. UDDI focuses on the process of discovery in the service-oriented architecture.
The UDDI Project is an initiative that communicates with the public through www.uddi.org. The UDDI Community runs the UDDI Project. The Community consists of a group of Working Group members who develop the specifications and Advisory Group members who provide requirements and review the specifications. The Working Group is an invitation-based group and the Advisory Group is open to everyone.
Web services are becoming the basis for electronic commerce of all forms. Companies invoke the services of other companies to accomplish a business transaction. In an environment in which only a few companies participate, managing the discovery of business partners manually would be simple. After all, how difficult would it be to figure out if one of your few business partners has an access point that adheres to your requirements? This model breaks down, however, as the number of companies that you need to interact with grows, along with the number and types of interfaces they export. How do you discover all the business partners that you can do business with? If you attempted to account for them manually, you could never be sure that you discovered every partner. UDDI is a single conceptual registry distributed among many nodes that replicate the participating businesses' data with one another. The UDDI registry of services (hosted by different businesses on the Internet) attempts to solve this problem.
Technical Architecture depicts the makeup of the UDDI project. The UDDI Business Registry (UBR), also known as the Public Cloud, is a conceptually single system built from multiple nodes that has their data synchronized through replication. A series of operator nodes each hosts a copy of the content. The global grouping of operator nodes is jointly known as the UBR. Operator nodes replicate content among one another. Accessing any individual operator node provides the same information and quality of service as any other operator node. Content inserted into the UBR is done at a single node, and that operator node becomes the master owner of that content. Any subsequent updates or deletes of the data must occur at the operator node where the data was inserted.
Figure 6-2. The UDDI initiative
Note that the scope of the UDDI project is much more than the UBR; a company can provide a private operator node that is not part of the UBR. Private nodes do not have data synchronized with the UBR, so the information contained within is distinct. A grouping of companies can also create a "private cloud" of nodes that have information replicated between their private nodes, but that replication sequence will not have any interaction with the UBR nodes.
4) Overview of .NET and J2EE The .NET Framework is a technology that supports building and running the next generation of applications and XML Web services. The .NET Framework is designed to fulfill the following objectives:
To provide a consistent object-oriented programming environment whether object code is stored and executed locally, executed locally but Internet-distributed, or executed remotely. To provide a code-execution environment that minimizes software deployment and versioning conflicts. To provide a code-execution environment that promotes safe execution of code, including code created by an unknown or semi-trusted third party. To provide a code-execution environment that eliminates the performance problems of scripted or interpreted environments. To make the developer experience consistent across widely varying types of applications, such as Windows-based applications and Web-based applications. To build all communication on industry standards to ensure that code based on the .NET Framework can integrate with any other code.
The Application Server implements Java 2 Enterprise Edition (J2EE) 1.4 technology. The J2EE platform is a set of standard specifications that describe application components, APIs, and the runtime containers and services of an application server. J2EE applications are made up of components such as JavaServer Pages (JSP), Java servlets, and Enterprise JavaBeans (EJB) modules. These components enable software developers to build large-scale, distributed applications. Developers package J2EE applications in Java Archive (JAR) files (similar to zip files), which can be distributed to production sites. Administrators install J2EE applications onto the Application Server by deploying J2EE JAR files onto one or more server instances (or clusters of instances).
Clients can access J2EE applications in several ways. Browser clients access web applications using hypertext transfer protocol (HTTP). For secure communication, browsers use the HTTP secure (HTTPS) protocol that uses secure sockets layer (SSL).
Rich client applications running in the Application Client Container can directly lookup and access Enterprise JavaBeans using an Object Request Broker (ORB), Remote Method Invocation (RMI) and the internet inter-ORB protocol (IIOP), or IIOP/SSL (secure IIOP). They can access applications and web services using HTTP/HTTPS, JMS, and JAX-RPC. They can use JMS to send messages to and receive messages from applications and message-driven beans.
Clients that conform to the Web Services-Interoperability (WS-I) Basic Profile can access J2EE web services. WS-I is an integral part of the J2EE standard and defines interoperable web services. It enables clients written in any supporting language to access web services deployed to the Application Server.
The best access mechanism depends on the specific application and the anticipated volume of traffic. The Application Server supports separately configurable listeners for HTTP, HTTPS, JMS, IIOP, and IIOP/SSL. You can set up multiple listeners for each protocol for increased scalability and reliability.
J2EE applications can also act as clients of J2EE components such as Enterprise JavaBeans modules deployed on other servers, and can use any of these access mechanisms.
1) Write brief notes on XML technology
XML is a text-based markup language that is fast becoming the standard for data interchange on the web. As with HTML, you identify data using tags (identifiers enclosed in angle brackets: <...>). Collectively, the tags are known as markup.
But unlike HTML, XML tags identify the data rather than specify how to display it. Whereas an HTML tag says something like, "Display this data in bold font" (...), an XML tag acts like a field name in your program. It puts a label on a piece of data that identifies it (for example,
There are several basic ways to use XML:
Traditional data processing, where XML encodes the data for a program to process Document-driven programming, where XML documents are containers that build interfaces and applications from existing components Archiving--the foundation for document-driven programming--where the customized version of a component is saved (archived) so that it can be used later Binding, where the DTD or schema that defines an XML data structure is used to automatically generate a significant portion of the application that will eventually process that data
Document-Driven Programming
The newest approach to using XML is to construct a document that describes what an application page should look like. The document, rather than simply being displayed, consists of references to user interface components and business-logic components that are "hooked together" to create an application on-the-fly.
Of course, it makes sense to use the Java platform for such components. To construct such applications, you can use JavaBeans components for interfaces and Enterprise JavaBeans components for the business logic. Although none of the efforts undertaken so far is ready for commercial use, much preliminary work has been done. Traditional Data Processing
XML is fast becoming the data representation of choice for the web. It's terrific when used in conjunction with network-centric Java platform programs that send and retrieve information. So a client-server application, for example, could transmit XML-encoded data back and forth between the client and the server.
In the future, XML is potentially the answer for data interchange in all sorts of transactions, as long as both sides agree on the markup to use. (For example, should an email program expect to see tags named
Binding
After you have defined the structure of XML data using either a DTD or one of the schema standards, a large part of the processing you need to do has already been defined. For example, if the schema says that the text data in a
But when the data structure (and possibly format) is fully specified, the code you need to process it can just as easily be generated automatically. That process is known as binding--creating classes that recognize and process different data elements by processing the specification that defines those elements. As time goes on, you should find that you are using the data specification to generate significant chunks of code, and you can focus on the programming that is unique to your application.
Archiving
The Holy Grail of programming is the construction of reusable, modular components. Ideally, you'd like to take them off the shelf, customize them, and plug them together to construct an application, with a bare minimum of additional coding and additional compilation.
The basic mechanism for saving information is called archiving. You archive a component by writing it to an output stream in a form that you can reuse later. You can then read it and instantiate it using its saved parameters. (For example, if you saved a table component, its parameters might be the number of rows and columns to display.) Archived components can also be shuffled around the web and used in a variety of ways. When components are archived in binary form, however, there are some limitations on the kinds of changes you can make to the underlying classes if you want to retain compatibility with previously saved versions. If you could modify the archived version to reflect the change, that would solve the problem. But that's hard to do with a binary object. Such considerations have prompted a number of investigations into using XML for archiving. But if an object's state were archived in text form using XML, then anything and everything in it could be changed as easily as you can say, "Search and replace."
XML's text-based format could also make it easier to transfer objects between applications written in different languages. For all these reasons, there is a lot of interest in XML-based archiving.
Document Parts
Prolog Document Element (root element)
The Prologue
The prologue, equivalent to the header in HTML, may include the following:
An XML declaration (optional) such as:
A DTD or reference to one (optional). An example reference to an external DTD file:
Processing instructions - An example processing instruction that causes style to be determined by a style sheet:
An XML Document
Therefore a complete well formed XML document may look like:
The LAND element, above, is the root element.
The below document is not an XML document since it does not qualify by the rules of a well formed document. There is more than one top level element which disqualifies the document from being well formed.
Defining Display
If the HTML document is not linked to a style sheet, the XML document will be displayed with tags included. The elements and tags may be color coded to aid in viewing the document. The document is displayed without tags according to the style sheet if a link to one is specified. The following document shows a document with a link to a cascading style sheet:
The below line, which is a part of the XML document above, is a processing instruction and is a part of the prolog.
The style sheet, "xmlstyle.css", may look like: DATABASE { display: block } TITLE { display: block; font-family: arial; color: #008000; font-weight: 600; font-size: 22; text-align: center } TITLE2 { display: block; font-family: arial; color: #000080; font-weight: 400; font-size: 20 } LANGUAGES { display: block; list-style-type: decimal; font-family: arial; color: #000000; font-weight: 400; font-size: 18 } OTHER { display: block; list-style-type: square; font-family: arial; color: #0000ff; font-weight: 200; font-size: 14 }
In order to use DTDs with XML, the reader is encouraged to learn about the structure of DTDs. The document called "Document Type Definition (DTD)" on this website gives a more thorough explanation about how to read and construct a DTD than this document. The DTDs in this document are very basic and should, however, be easy to understand even for those who don't have familiarity with DTD's.
The DTD, whether included as part of the XML file or external to the XML file is used to define content. The DTD is used to determine the elements allowed in the file and which elements can be contained in other elements. It also describes the number of times specific elements may be contained in other elements.
The DTD document on this website was written for SGML DTDs and the main difference lies in the fact that XML requires a beginning and ending tag for all elements. SGML does not have this requirement .
Element Declaration
Therefore in an SGML DTD an element tag for the
element is:
If written for XML, the DTD would be:
The difference between the two examples is that the XML
declaration does not define whether the element requires a closing tag as done with the "- O" text. This is because all elements in XML are required to have closing tags and therefore defining whether a closing tag is required is pointless.
XML namespaces are used for providing uniquely named elements and attributes in an XML document. They are defined in a W3C recommendation.[1][2] An XML instance may contain element or attribute names from more than one XML vocabulary. If each vocabulary is given a namespace, the ambiguity between identically named elements or attributes can be resolved.
A simple example would be to consider an XML instance that contained references to a customer and an ordered product. Both the customer element and the product element could have a child element named id. References to the id element would therefore be ambiguous; placing them in different namespaces would remove the ambiguity.
Namespace declaration
An XML namespace is declared using the reserved XML attribute xmln or xmlns:prefix, the value of which must be a valid namespace name.
For example, the following declaration maps the "xhtml:" prefix to the XHTML namespace: xmlns:xhtml="http://www.w3.org/1999/xhtml"
Any element or attribute whose name starts with the prefix "xhtml:" is considered to be in the XHTML namespace, if it or an ancestor has the above namespace declaration.
It is also possible to declare a default namespace. For example: xmlns="http://www.w3.org/1999/xhtml"
In this case, any element without a namespace prefix is considered to be in the XHTML namespace, if it or an ancestor has the above default namespace declaration.
Attributes are never subject to the default namespace. An attribute without an explicit namespace prefix is considered not to be in any namespace.
XML Namespaces 1.1 also introduces the option to undeclare other namespace
2) Explain briefly about UDDI implementation and specifications WSDL service descriptions in a UDDI Registry. For each usage scenario, I will describe a method to publish a complete WSDL service definition in a UDDI registry. These methods are described based on the procedures in the UDDI best practices document, as well as usage conventions defined in both the UDDI Programmer's API Specification and UDDI Data Structure Reference
Scenario 1: Service interface without a service implementation
When a service interface provider publishes a WSDL service interface definition as a tModel, that tModel can be referenced from any UDDI businessService. This scenario shows how to publish a businessService with a reference to a tModel that is associated with a WSDL service interface. For this scenario, the UDDI businessService is not associated with a WSDL service implementation definition. This scenario can be implemented using the process described in the UDDI best practices document.
WSDL service interface definition
The service interface document contains all of the WSDL types, message, portType and binding elements. For this scenario, the Web service contains one operation, and the binding is specified using SOAP. This example does not include a types element, since this usage scenario does not require data type definitions for the messages.
Publishing the UDDI tModel
The WSDL service interface description is published by the service interface provider. This document must be published before a service provider can publish a businessService that references the service interface. This service interface is published as a tModel, and will contain a reference to the WSDL service interface document.
Publishing the UDDI businessService
A service provider that implements this service interface can publish a businessService description that references the tModel that is associated with the service interface. The service description for the service implementation does not have to be specified using WSDL.
Building a WSDL service implementation document
Since the UDDI businessService was not created from a WSDL service implementation document, a tool or runtime component that requires WSDL would have to build a WSDL document based on the contents of the businessService and the tModels that are referenced by its bindingTemplates. Service implementation with one service interface document
A service interface can be developed by one person, and then implemented and referenced by a different person. For the set of tools and runtime components that operate only on WSDL service descriptions, the WSDL service implementation document will contain a reference to the WSDL service interface document. In this scenario, the service implementation document references only one WSDL service interface document.
WSDL service interface definition
The service interface definition for this scenario is consistent with the one described in the UDDI best practices document. The service interface document contains all of the WSDL types, message, portType and binding elements.
The service that is described in this document contains one operation, and the binding is specified using SOAP. The highlighted fields will be referenced in the UDDI data entities.
Publishing the UDDI tModel
The service interface provider must publish the service interface description before the service implementation description can be published. This service interface is published as a tModel. The tModel will contain a reference to the WSDL service interface document.
WSDL service implementation definition
The service implementation document contains one import element that references the service interface document, as well as a service element that contains a reference to the location of the Web service.
Publishing the UDDI businessService
The WSDL service implementation description is published by the service provider. The service implementation is published as a businessService. The tModel associated with the service interface is referenced by the bindingTemplate within the businessService.
This method for publishing a service implementation is not defined in the UDDI best practices document. "Publishing Service Implementations" on page 7 of the best practices document contains a description of how the businessService is created from a WSDL service implementation document.
UDDI specification The UDDI project also defines a set of XML Schema definitions that describe the data formats used by the various specification APIs. These documents are all available for download at www.uddi.org. The current version of all specification groups is Version 2.0.
The specifications include:
UDDI Replication:
This document describes the data replication processes and interfaces to which a registry operator must conform to achieve data replication between sites. This specification is not a programmer's API; it defines the replication mechanism used among UBR nodes.
UDDI Operators:
This document outlines the behavior and operational parameters required by UDDI node operators. This specification defines data management requirements to which operators must adhere.
UDDI Programmer's API:
This specification defines a set of functions that all UDDI registries support for inquiring about services hosted in a registry and for publishing information about a business or a service to a registry. This specification defines a series of SOAP messages containing XML documents that a UDDI registry accepts, parses, and responds to. This specification, along with the UDDI XML API schema and the UDDI Data Structure specification, makes up a complete programming interface to a UDDI registry.
UDDI Data Structures:
This specification covers the specifics of the XML structures contained within the SOAP messages defined by the UDDI Programmer's API. This specification defines five core data structures and their relationships to one another.
The UDDI XML API schema is not contained in a specification; rather, it is stored as an XML Schema document that defines the structure and datatypes of the UDDI data structures.
The UDDI specification describes a registry of Web services and its programmatic interfaces. UDDI itself is a set of Web services. The UDDI specification defines services that support the description and discovery of:
Businesses, organizations and other providers of Web services; The Web services they make available; The technical interfaces which may be used to access and manage those services. UDDI specification does not define an access control mechanism. The UDDI specification allows modification of the specific entity only by its owner (creator). This does not scale in the enterprise environment where the right to modify or delete a specific UDDI entity must be assigned with more identities or even better with some role. BEA AquaLogic Service Registry addresses this issue with the ACL (Access Control List) extension to the UDDI security model. Every UDDI entity can be associated with the ACL that defines who can find (list it in some UDDI query result), get (retrieve all details of the UDDI object), modify or delete it. The ACL can reference either the specific user account or user group. The UDDI v3 specification provides support for digital signatures. In BEA AquaLogic Service Registry, the publisher of a UDDI structure can digitally sign that structure. The digital signature can be validated to verify the information is unmodified by any means and confirm the publisher's identity. The UDDI v3 specification introduces notification and subscription features. Any UDDI registry user can subscribe to a set of UDDI entities and monitor their creation, modification and deletion. The subscription is defined using standard UDDI get or find API calls. The UDDI registry notifies the user whenever any entity that matches the subscription query changes even if the change causes the entity to not match the query anymore. It also notifies about entities that were changed in a way that after the change they match the subscription query. The notification might be synchronous or asynchronous. By synchronous, we mean solicited notification when the interested party explicitly asks for all changes that have happened since the last notification. Asynchronous notifications are run periodically in a configurable interval and the interested party is notified whenever the matched entity is created, modified, or deleted. 3) Write brief notes on interoperability problem in .NET and J2EE
"Interoperability: The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units." —ISO/IEC 2382 Information Technology Vocabulary Many Enterprises have been building based on mixed environments i.e. J2EE and/or .Net. If company sees a need of new application to their current enterprise, first thinking is to reuse and/or integrate the new application with existing applications and systems. Integrating systems with partners and suppliers is another increasing demand by businesses/enterprises, where security, performance and scalability come as standard requirements. Migrating, rebuilding or replicating the functionality is not possible in most of cases. Even if we decide to migrate application(s) to other platform, most of the time migration has to be phased and integrated with other platform until complete system migration. Interoperability allows the core systems to communicate with internal and external applications including partners and suppliers. Performance overhead, security and reduction in functionalities should be considered while designing solutions for interoperability. In coming sections we will explore following topics:
1. Interoperability Scenarios and technology mapping 2. Interoperability Technologies 3. J2EE for .Net Developers 4. .Net and J2EE Feature Mapping 5. Interoperability using XML 6. Summary
Interoperability Scenarios and technology mapping Following are the common Interoperability scenarios in an Enterprise:
1. .Net Presentation Layer with J2EE Business Layer 2. J2EE Presentation Layer with .Net Business Layer 3. .Net Business Layer with J2EE Business Layer 4. Sharing resources between .Net and J2EE
Note: Above are most common scenarios but not all, for instance there is also a possibility of .Net Presentation and J2EE Presentation layer interoperability.Please See “Interoperability Technologies” section for mapping between scenarios and technologies recommendation. Following diagrams maps the layers and shows above interoperability scenarios: .Net Presentation Layer with J2EE Business Layer J2EE Presentation Layer with .Net Business Layer
Interoperability Technologies There are multiple technologies for .Net and J2EE interoperability. Each technology has pros and cons. It also depends on your functional and/or non-functional requirements i.e. performance or scalability. Following are the technologies, which we can use for interoperability between J2EE and .Net:
XML Web Services Runtime Bridges Message Orientated Middleware Shared Database Integration Brokers *Please note following is a high level overview of each technology from interoperability point of view. For more information please use appropriate resources. XML web services have been matured by the time and are supported by both J2EE and .Net. Web services provide an interface for communicating with other applications and systems. However, web services hide the method level implementation, therefore applications can only communicate through defined interfaces and contracts. Web service is a good choice for Presentation to Business, Business to Business and Business to Data interoperability. Using XML web services, you cannot call a class method or access J2EE classes from .Net or vice-versa. Runtime Bridges provides the ability to access classes from one platform to another. Runtime Bridges are developed by 3rd parties, JNBridgePro and Ja.Net are most prominent in the market. Runtime Bridges allows you to use .Net Remoting to handle classes at Java side. Messaging and Share databases provide asynchronous communication mechanism. Messaging is based on MSMQ and IBM MQSeries and both supports security, message recording and transactions. Using the share database technique, one common database (SQL Server or Oracle etc.) is being accessed by .Net and J2EE applications. .Net application uses ODBC and J2EE application uses JDBC. Integration Brokers are typically built on messaging framework that provides the integration and automation between business processes across distributed applications and Enterprise. Integration brokers are a good answer for integration of partners and suppliers. BizTalk Server, CommerceBroker and IBM MQSeries are the most well-known integration brokers in the market. Following table shows the mapping between interpretability scenarios and technologies. These recommendations are from Microsoft and could differ to your problem and solution.
Runtime Integration Web Services Messaging Share Databases Bridges Brokers Presentation to X X Presentation Presentation to X X X Business Business to X X X X Business Business to X X X Data
J2EE Overview for .Net Developers Unlike Microsoft .NET, Java 2 Platform, Enterprise Edition or J2EE is a set of linked specification but not a product. These specifications consist of a series of downloadable .PDF files that describe application agreements and the makeup of the containers in which these applications run. Sun Microsystems developed Java as platform and a programming language. There are currently three editions of the Java platform:
J2SE (Java 2 Standard Edition) J2EE (Java 2 Enterprise Edition) J2ME (Java 2 Micro Edition)
Note: The term “Java” mostly refers to functionality available within J2SE. Areas that require the Enterprise Edition include the term J2EE. For more information about J2EE history please visit http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#History As mentioned before J2EE is a series of specification but platform unlike .Net. There are other differences between J2EE and .Net, which should also be understood. Differences can be categorized in three main areas:
1. Operating System 2. Language Support 3. Execution Process or Technique
As we know, .Net can run only on Windows platform but Java was designed to run on multiple platforms i.e. Windows, UNIX, Linux, MacOS and BeOS. We can write applications in Java using Java Programming Language only but in .Net you can write applications in any language, which is supported by .Net. There is also a major difference between the two platforms at application run time. When you build a project based on a .NET language, the output consists of MSIL code that the JIT compiler compiles at runtime. To deploy a Java program, you compile the application to create Java bytecode. The JVM running on the target operating system then interprets this bytecode to produce the relevant instructions. Note: There are also Java JIT compilers that work in a similar fashion to the .NET Framework component. Some of the vendors have created their own implementations of J2EE specification, which were built by Sun Microsystems. Following vendors implemented these specifications:
Sun (Sun ONE Application Server) IBM (WebSphere) BEA (WebLogic) JBoss (Open source implementation) http://www.jboss.org/
J2EE also includes additional components, which were evolved over the past decade:
Java Server Pages (JSPs) Server side APIs or servlets Enterprise Java Beans (EJBs) Java Naming and Directory Interface (JNDI) Java Message Service (JMS) Java API for XML-based RPC (JAX-RPC) J2EE Connector Architecture J2EE Management Model J2EE Deployment API Java Management Extensions (JMX) J2EE Authorization Contract for Containers Java API for XML Registries (JAXR) Java Transaction API (JTA) Common Object Request Broker Architecture (CORBA) JDBC data access API
You can map few components in .Net e.g.,JMS is equivalent to System.Messaging namespace.
.Net and J2EE Feature Mapping Following table helps to understand the comparison of J2EE and .Net features. Feature J2EE .NET Type of technology Standard Product Middleware Vendors 30+ Microsoft Interpreter JRE CLR Dynamic Web Pages JSP ASP.NET Middle-Tier/Server Side EJB .NET Managed Components Components
Database access JDBC SQL/J ADO.NET
SOAP, WSDL, UDDI Yes Yes Implicit middleware Yes Yes (load-balancing, etc) Multiple (depends on vendor Web Apps Hosting Internet Information Server implementation) Java Naming and Directory Active Directory Services Directory Access Service (JNDI) through LDAP Interface (ADSI) through LDAP Remote Invocation RMI-IIOP .NET Remoting Messaging JMS Microsoft Message Queuing Transactional Support JTA COM+/Distributed Transaction Controller (DTC)