How to Develop with an Emerging Standard, Today

Jan. 1, 2000 12:00 AM

Click here for FREE software from Oracle http://www.oracle.com/go/?&Src=1170761&Act=6

Introduction
Web services are the "new kids on the block" and as with all adolescent technologies they are can be a little troublesome, take time to understand and always testing you with something new. Given this, how does a developer get started with Web services? And for those more experienced, how does the developer speed up the developing, debugging, and deployment cycle?

In this paper we will hope to provide a jump-start to both these questions. We will run through the basics of building Web services using the following steps:

Modeling Web services
Building a Web service based on a EJB
Publishing an EJB Web service
Deploying a Web service to an Oracle9i Application Server and Apache SOAP server
Working with WSDL
Building a Web service Client
Incorporating 3rd Party Web services

For maximum productivity for developing, debugging, and deployment of the Web service we will be using Oracle9i JDeveloper a single integrated Java, XML, and Web services environment.

Web Services Overview
Web services are Internet applications that expose a well-described interface that application developers working in any language can easily call. There are a number of popular, simple standards that are used to publish applications as a Web services including:

Simplified Object Access Protocol (SOAP): The protocol used to invoke a Web service.

Web Services Description Language (WSDL): The descriptor or definition of a Web service.

Universal Description, Discovery and Integration (UDDI): The registry where Web services can be located.

These standards are Internet friendly and enable easy distributed programming calls across the Internet, as compared to more internally focused protocols like J2EE RMI (Remote Method Invocation), Net9i (Oracle9i Database network protocol) and DCOM (Microsoft's distributed component model protocol).

Business logic performed by Web service applications can be written in any language including Java and PL/SQL. In fact, much of the development cycle including modeling, programming, security and the underlying component model do not change with Web services. What does change is that additional steps are done to describe it (WSDL), to access it (SOAP) and to publish it (UDDI). Figure 1 provides an overview of a Web service in action.

Figure 1: Web Services with SOAP, WSDL and UDDI

Web services are often touted as a radically new concept; in fact, conceptually they are very similar to other distributed programming models such as J2EE, Corba and DCOM. One important difference, however, is that Web service standards are really just an XML metadata layer on top of an application implementation, describing the underlying application. They are not standards for developing business logic or processes; they merely describe it.

For example, using CORBA as an analogy, it is possible to liken the Interface Definition Language (IDL) to WSDL - both describe the services that will be implemented by the business logic and the interfaces necessary for clients to call the business logic. They are not the application logic or process. CORBA's remote invocation protocol is called Internet Inter-ORB Protocol, which is conceptually comparable to SOAP. Both provide ways of marshalling and un-marshalling arguments - in SOAP's case underlying marshalling language happens to be XML. CORBA's Naming Service (Cos Naming) and Interoperable Object References (IOR) provide a way to locate individual CORBA objects whereas the combination of WSDL and UDDI standards provide similar ways to locate Web services.

What tends to be revolutionary about Web services is the ease in which they enable distributed component models to interact programmatically, particularly across the Internet using protocols like HTTP. By focusing initially on simplicity and interoperability Web services have garnered significant support, adoption and innovation across the industry.

Interestingly, with simple Web services now well underway to becoming a popular development approach, much interest and impetus has been started in the area of complex Web services. Complex Web services take the foundation standards of SOAP, WSDL and UDDI and move them to higher level business processes that have requirements for long running transactions, asynchronous interactions, authentication, encryption and non-repudiation. In this area Web services vendors like Oracle are leveraging the knowledge and standards of ebXML (Electronic Business XML) and RosettaNet as well as real life business process knowledge from its E-Business Suite line, where much work has been previously done in implementing complex business processes in thousands of implementations.

Building and Assembling Web Services
Requirements
How does a Java developer respond to the emergence of Web services? Oracle believes that Web services are synergistic and complementary to existing J2EE development approaches. Web services are becoming natural extensions of the J2EE platform through the Java Community Process with J2EE 1.4 and Java Specification Request 109. With this in mind, a Web service developer must first choose a development environment that meets the requirements of an enterprise J2EE developer. The tool must support modeling, software configuration management, rapid application development, debugging, performance tuning and testing.

Web services add additional requirements on the development environment such as publishing and consuming Web services, locating and introspecting Web services and finally composing and orchestrating Web services. For maximum productivity these should be features in the standard development environment rather than separate un-integrated tools.

This is the vision behind Oracle9i JDeveloper. Oracle9i JDeveloper is a Java IDE completely written in Java. It is available on Windows, Solaris and Linux. It has all the enterprise features described above for J2EE development but has combined them with rich Web service capabilities throughout the product.

Using Oracle9i JDeveloper to Build Web Services
Modeling Web Services
Oracle9i JDeveloper provides a set of UML modellers to help developer visually describe their business application. The Class Modeller describes the relationships between business objects and the Activity Modeller describes the business processes. In a Web services context activity modellers are useful for describing Web service orchestrations where as class modellers are useful for describing individual Web service implementations.

One of the important values that tools like activity modellers offer beyond visualizing the business process is the ability to extend simple Web services (e.g. remote procedure calls) into complex Web services where a series of Web services are invoked, sequenced and coordinated with other Web services and non-Web service applications. Creating complex Web services also necessitates an infrastructure that can deal with event handling, asynchronicity, parallel processing and notifications. Oracle9i JDeveloper, for example, enables developers to use its activity modeller to generate business processes with these capabilities for Web services using the workflow engine and the integration capabilities offered by Oracle9i Application Server.

Figure 2 provides an example Web service scenario built in the Oracle9i JDeveloper Activity Modeller. The scenario illustrates three Web service processes: a Trip Planning Service, a Trip Costing Service and Trip Booking Service. At this stage, no details are provided behind the activities in each process; however, the rest of this paper focusses on providing a J2EE Web service centric implementation of this activity model.

Figure 2: Modeling Web Services in the Oracle9i JDeveloper Activity Modeller

Building a Web Service Based on an EJB
To build a Web service with Oracle9i JDeveloper, one can start with a standard Enterprise Java Bean. Ordinary Java classes could be chosen as could all the varieties of Enterprise Java Beans such as stateless or stateful session EJB's or, alternatively, Bean Managed, Container Management Entity EJBs or Message Driven Beans. For example, using the activity model from Figure 2, the Plan Trip activity could be implemented as a stateless Enterprise Java Bean called TravelSearchEJB as shown in Figure 3. For simplicity, this EJB has a single method, findFlight, which returns a list of flights given an origin airport and destination airport.

Figure 3: Using Oracle9i JDeveloper to Declaratively Build an EJB

The implementation code of the findFlight method is provided in Listing 1. This code shows the retrieval of flights names from a TRAVEL database schema via a SQL statement that takes the origin and destination airport as parameters. This is traditional java code that a typical J2EE developer would have little difficulty constructing.

Listing 1: The findFlight Method Implementation
public String[] findFlight(String origin,String dest) throws RemoteException
{
String[] flights = new String[5];
String SQL = "select flight.air_code, flight.flight_number, " +
"fare.standard_price," +
"to_char(departure.departure_date, 'Mon DD, RRRR'), " +
"departure.departure_time " +
"from flight_routes flight, fare_schedules fare, " +
"flight_departures departure " +
"where origin_arp_code = ? " +
"and dest_arp_code = ? " +
"and departure.flr_id = flight.route_id " +
"and flight.route_id = fare.flr_id " +
"and (sysdate < departure.departure_date) " +
"order by departure.departure_date asc";
try { conn = getConnection(dsName);
ps = conn.prepareStatement(SQL);
ps.setString(1, origin);
ps.setString(2, dest);
ps.executeQuery();
ResultSet rs = ps.getResultSet();
int i = 0;
while ((rs.next()) && (i < 5)) {
flights [i] = new String(rs.getString(1)+" "+
rs.getString(2)+
" / " + rs.getString(4)+
" / $"+rs.getString(3));
i++;
}
} catch (SQLException e) {
throw new RemoteException(e.getMessage());
} finally {
try {
ps.close();
} catch (Exception e) {}
try {
conn.close();
} catch (Exception e) {}
}
return flights;
}

Depending on the type of Java application developed different J2EE archive deployment options can be used: Enterprise Java Bean JAR files for EJB's, Web Archive files for web applications and ordinary JAR files for simple Java classes. Oracle9i JDeveloper makes deployment easy by providing graphical tools for configuring the J2EE descriptors and by making the actual deployment process a single mouse click.

This point and click deployment is provided for the Oracle9i Application Server Containers for J2EE and other third party application servers like BEA Weblogic. Figure 4 shows the deployment options available in Oracle9i JDeveloper and Figure 5 shows the user experience deploying Enterprise Java Beans for the TravelSearchEJB built here.

Figure 4: Oracle9i JDeveloper J2EE Deployment Options

Figure 5: One click EJB Deployment from Oracle9i JDeveloper

Publishing an EJB Web Service
Publishing a Web service in Oracle9i JDeveloper is as simple as running a Web service tool that introspects the EJB remote interface and allows the developer to select which methods should be published as a Web service. Oracle9i JDeveloper supports publishing J2EE Web services for Oracle9i Application Server, based upon the specificiations emerging for J2EE 1.4 or JSR 109 from the Sun Java Community Process. Also fully supported is Web services using the Apache SOAP infrastructure. Publishing the TravelSearchEJB as a Web service would typically be done in a sequence such as that shown in Figures 6 through 9.

Figure 6: Selecting the Web Service Tool

Figure 7: Figure 7: Choose the Remote EJB Interface and Providing a URI Identifier
(Note Deployment platforms include Oracle9i Application Server Web Services (based on J2EE 1.4/JSR 109) and Apache SOAP 2.0 and 2.2)

Figure 8: Selecting the Methods to Publish as Web Services

Figure 9: Generating the WSDL Description of the Web Service

To deploy the Web service, the metadata collected by the Web service wizard has to be packaged and deployed to the application server. For Web services published to the Oracle9i Application Server Containers for J2EE, this metadata is packaged as a J2EE web.xml file and deployed using a standard WAR file. The web.xml file configures a servlet, automatically generated by Oracle9i Application Server during the deployment process, which converts incoming SOAP messages to calls to the underlying EJB and the outgoing results back into SOAP messages . The WAR deployment process is a one-click deployment as shown in Figure 10.

Figure 10: One Click Web Service Deployment to Oracle9i Application Server

It is correct to conclude that with Oracle9iAS Web Services each Enterprise Java Bean has its own auto-generated servlet for marshalling and unmarshalling SOAP messages.

In the case when Apache SOAP is selected, the Oracle9i JDeveloper Web service wizard will generate a deployment descriptor required to register the Web service with Apache SOAP. Unlike the Oracle9iAS Web Services, Apache SOAP uses a single generic servlet for handling SOAP messages and as such requires the descriptor to map each SOAP service's to the underlying component. Figure 11 shows the registration process for Apache SOAP Servers of the automatically generated SOAP descriptor for the TravelSearchEJB EJB.

Figure 11: One Click Apache SOAP Service Deployment from Oracle9i JDeveloper

In both cases, the work required by the developer is to invoke the Web service wizard, choose the Enterprise Java Bean and methods to be published as Web services and then a single click to deploy to the Web services infrastructure. This is a simple publishing process, leaving the developer free to focus on the application itself, rather than Web service idiosyncracies.

Working with WSDL
Once the Web service has been published, a natural next step is to build a client to call the Web service. The standard that enables tools like Oracle9i JDeveloper to automate client creation is WSDL - the Web Service Description Language. Oracle9i JDeveloper can take a WSDL file and automatically generate a client stub that is capable of marshalling and un-marshalling the SOAP messages expected by the Web service implementation.

The question is where does a developer find a WSDL file? There are a number of standard places one can get a WSDL file. For existing Web services, a common place to look is popular Web service registries like XMethods (Error! Bookmark not defined.) and SalCentral (Error! Bookmark not defined.). These sites and others often publish lists of publicly available Web services and their correspondingWSDL files as URL's and more recently have been making their Web service lists available to UDDI inquiries. For those who already have a Web services infrastructure, internal UDDI registries are where the WSDL files can be located. Oracle9i Application Server, for example, includes a UDDI Registry as a feature of its Web services implementation.

For new or existing J2EE applications, like the TravelSearchEJB example used in this paper, the Oracle9i JDeveloper Web service wizard automatically generates the WSDL file. Figure 12 shows the WSDL generated for the sample Enterprise Java Bean created in this paper.

Figure 12: Editing the WSDL Generated by the Oracle9i JDeveloper Web Service Tool

For Web services deployed to Oracle9i Application Server, an additional option is available to retrieve the WSDL. The servlet that is automatically created during the Web service deployment accepts a WSDL argument and will produce the WSDL on demand.

For example, for the TravelSearchEJB Web service, the WSDL could be retrieved from the URL:

http://localhost:8888//Travel-context-root/urn:ws.TravelSearchEJB?WSDL

This can be useful for developers wanting to access the Web service WSDL stand-alone, outside of Oracle9i JDeveloper.

There can be times when developers would like to fine tune a WSDL file, perhaps as part of the process defining a Web service before implementing it, or to handle complex parameters. Oracle9i JDeveloper facilitates the creation and editing of WSDL files by offering a Schema Driven XML editor and a WSDL creation tool. Oracle9i JDeveloper's XML editor allows XML Schemas to be registered such that the editor can provide code insight while editing XML Schema constrained documents.

Figure 12, in addition to showing the TravelSearchEJB Web service WSDL file, shows WSDL file editing with code insight in action, the XML document structure navigator and the XML property editor functionality of Oracle9i JDeveloper. Figure 13 shows the ability to register schemas in Oracle9i JDeveloper. By default, the schema for WSDL and other common XML Schemas are pre-registered out-of-the-box.

Figure 13: Schema Driven Editor Configuration

Building a Web Service Client
In the scenario developed so far, the next activity for developers interested in using the TravelSearchEJB Web service would be to build a Web service client. Importantly, these developers need to know nothing about the implementation of the Web service itself, rather they only need the WSDL file to construct the appropriate SOAP messages to invoke the Web service. Locate that WSDL file, either generated directly from Oracle9i JDeveloper, on a site like XMethods or SalCentral or by browsing a UDDI registry like that in Oracle9i Application Server and the developer is ready to go. Oracle9i JDeveloper automates the process of creating a Web service client directly from WSDL. Figures 14 through 16 show the Web Service Stub/Skeleton tool in action.

Figure 14: Selecting the Web Service Stub/Skeleton Tool

Figure 15: Defining the Location of the WSDL File for the Service to be Accessed

Figure 16: Selecting the Methods for the Web Service Client

The stub that is generated from the Web Service Stub/Skeleton Wizard is a simple Java class that marshals and un-marshals SOAP messages from the Web service itself, without knowing anything about the Web service implementation. In the example used in this paper, the method findFlight method of the TravelSearchEJB EJB accepts a string parameter containing the origin airport and destination airport as parameters and returns an array of matching flights. The Web service client, or stub, converts incoming Java parameters into SOAP messages to send to the Web service, and, in reverse, converts the Web service SOAP results into Java equivalents. Listing 2 shows the Java stub generated from a WSDL file.

Listing 2: An Apache SOAP Client Automatically
Generated by Oracle9i JDeveloper from WSDL

package ws;
import oracle.soap.transport.http.OracleSOAPHTTPConnection;
import java.net.URL;
import org.apache.soap.Constants;
import org.apache.soap.Fault;
import org.apache.soap.SOAPException;
import org.apache.soap.rpc.Call;
import org.apache.soap.rpc.Parameter;
import org.apache.soap.rpc.Response;
import java.util.Vector;
import java.util.Properties;
/**
* Generated by the Oracle9i JDeveloper Web Services Stub/Skeleton Generator.
* Date Created: Wed Nov 21 00:02:21 PST 2001
*/
public class TravelSearchEJBStub
{
public String endpoint =
"http://localhost:8888/soap/servlet/soaprouter";
private OracleSOAPHTTPConnection m_httpConnection = null;

public TravelSearchEJBStub()
{
m_httpConnection = new OracleSOAPHTTPConnection();
}

public String[] findFlight(String origin, String dest) throws Exception
{
String[] returnVal = null;

URL endpointURL = new URL(endpoint);
Call call = new Call();
call.setSOAPTransport(m_httpConnection);
call.setTargetObjectURI("urn:ws.TravelSearchEJB");
call.setMethodName("findFlight");
call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);
Vector params = new Vector(); params.addElement(new Parameter("origin", String.class, origin, null));
params.addElement(new Parameter("dest", String.class, dest, null));
call.setParams(params);

Response response = call.invoke(endpointURL, "");
if (!response.generatedFault())
{
Parameter result = response.getReturnValue();
returnVal = (String[])result.getValue();
}
else
{
Fault fault = response.getFault();
throw new SOAPException(fault.getFaultCode(), fault.getFaultString());
}

return returnVal;
}
public void setMaintainSession(boolean maintainSession)
{
m_httpConnection.setMaintainSession(maintainSession);
}

public boolean getMaintainSession()
{
return m_httpConnection.getMaintainSession();
}

public void setTransportProperties(Properties props)
{
m_httpConnection.setProperties(props);
}

public Properties getTransportProperties()
{
return m_httpConnection.getProperties();
}
}

Note, developers are not expected to maintain this Web service stub. As shown in Figure 17, Oracle9i JDeveloper can regenerate the Web service stub via a simple right mouse click, should the WSDL file ever be updated. Also, for Web services deployed to Oracle9i Application Server, an additional option is available to retrieve the stub. The servlet that is automatically created during the Oracle9i Application Server Web service deployment accepts a proxy_source argument and will produce the Java stub on demand.

For example, for the TravelSearchEJB Web service, the Java stub could be retrieved from the URL:

http://localhost:8888//Travel-context-root/urn:ws.TravelSearchEJB?proxy_source

This second approach can be useful for developers wanting access the stub independent of Oracle9i JDeveloper.

Figure 17: One-Click Re-Generation of the SOAP Service Stub

Calling this TravelSearchEJB Web service stub from within an application, Java Server Page or even an Enterprise Java Bean is the final step. Figure 18, shows calling the stub and illustrates Oracle9i JDeveloper code insight while writing the JSP scriptlet to call the TravelSearchEJB Web service.

Figure 18: Java Server Page Code Insight While Calling a Web Service in Oracle9i JDeveloper

The end result of building a client, in this case a JavaServer Page, to the Web service looks remarkably like an ordinary application. Figure 19 shows the finished client returning Web service results. The differences, however, are two fold:

The client is interacting with the Web service using SOAP messages over HTTP even though the Web service itself is implemented as an Enterprise Java Bean. The Enterprise Java Bean could be located inside or outside of the organization's firewall.
The development environment for exposing the Enterprise Java Bean as a Web service and subsequently consuming the Web service was a seamless extension to a traditional J2EE IDE

Figure 19: Running a Java Server Page as a Web Service Client

Incorporating 3rd Party Web Services
If we return to the scenario outlined in the Activity Model in Figure 2, only the Trip Planning process has been implemented. The Enterprise Java Bean, TravelSearchEJB, representing the activity has been exposed as a Web service and a Web service client has been built to invoke it. The next step is to integrate this implementation with the subsequent Trip Costing process.

In this case the Trip Costing process will be implemented as a simple currency conversion activity. One approach to save time and effort would be to use an external Web service that specializes in currency conversion and then incorporate it into the application flow. Fortunately, there are several currency conversion services available on the Internet exposed as Web services. One, illustrated in Figures 20 and 21, shows how such services are published and advertised on web sites like XMethods.

Figure 20: A Currency Conversion Service on the Web Site Xmethods

Figure 21: The WSDL for the Currency Conversion Service

The steps to incorporate the currency conversion Web service into the overall travel application are very straightforward:

Build a Web service stub using the WSDL available from the XMethods site
Incorporate the Currency Conversion stub into the existing application

Figures 22 and 23 show the steps to build a Web service client using the Web Service Stub/Skeleton Wizard in Oracle9i JDeveloper.

Figure 22: Defining the URL location of the Currency Conversion WSDL

Figure 23: Adding the Currency Conversion Web Service to the Travel Web Service Java Server Page

Then, like with the TravelSearchEJB example, the call to the currency conversion Web service can be incorporated into a JavaServer Page, or for that matter, any other J2EE component. Figure 23 shows the JavaServer Page call to the currency conversion Web service call. Figure 24 shows running a JavaServer Page combining both the TravelSearchEJB Web service and the currency conversion Web service.

Figure 24: Running the Combined Travel Service and Currency Conversion Service

More Web Service Choices
To ensure developers can choose the most productive and familiar development paradigm as well as the most suitable business logic candidates for Web services, Oracle9i JDeveloper also helps developers expose EJB's developed using its J2EE framework, Business Components for Java, and stored procedures programmed in PL/SQL as Web services.

Business Components for Java is a J2EE framework built from industry best practices that helps developers rapidly construct, high quality and fast performing J2EE applications. It provides a graphical workbench for object relational mapping, declarative business logic and a presentation-binding layer for XML, JSP and Swing clients. Components developed in the framework are typically coarse-grained business objects that are deployed as Enterprise Java Beans and, as such, can be exposed as Web services using the same Oracle9i JDeveloper tools discussed in this paper.

Many businesses using the Oracle Database have a significant investment in PL/SQL and are looking to Web services as a way to leverage that investment with a new audience. Oracle9i JDeveloper caters to the PL/SQL developer by providing a full PL/SQL development and debugging environment. To help expose stored procedures as Web services, Oracle9i JDeveloper also has built-in a utility called JPublisher that can, through a single mouse-click, wrap any PL/SQL stored procedure in a Java class. Once wrapped as a Java class, a PL/SQL stored procedure can be published as a Web service, again using the same Oracle9i JDeveloper Web service tools discussed in this paper.

Conclusion
This paper has given an overview of the powerful Web service features that are in Oracle9i JDeveloper. Developers are able to create Web services from UML models, easily expose Java and database applications as Web services and rapidly build Web service clients. In addition, all the capabilities in Oracle9i JDeveloper including modeling, profiling, software configuration management, debugging and powerful Java, XML and PL/SQL editing work seamlessly with Web services. These broad Web service capabilities make Oracle9i JDeveloper one of the only Java IDE's on the market to have implemented Web services in a fully integrated way, covering the entire application development lifecycle.

Click here for FREE software from Oracle http://www.oracle.com/go/?&Src=1170761&Act=6

Web Services for J2EE: How to Develop for an Emerging Standard Today
January 2002
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com
Oracle is a registered trademark of Oracle Corporation. Various product and service names referenced herein may be trademarks of Oracle Corporation. All other product and service names mentioned may be trademarks of their respective owners.
Copyright © 2000 Oracle Corporation
All rights reserved.

About Mike Lehmann
Mike Lehmann is a senior principal product manager with the Oracle Application Server 10g team at Oracle Corporation. In this role he is focused primarily on building out the Oracle Application Web services infrastructure.

Reader Feedback: Page 1 of 1

Hmm commented on 13 Sep 2002

I have an alternative title for your article: How to promote oracle 9i application server, a tutorial on how to click your way through its menues..
an article not worth the paper its written on. sorry

Pilla G Patrudu commented on 11 Sep 2002

Your article is too big, I did not read the whole thing. However, your article provoked me to ask the question, which is already heating-up the APP. Server market.

Web service is same as EJB but with a
better transport protocol.

As far as the server portion of EJB is concerned, THERE IS A LITTLE SECRET -

THE EJB SERVER WAS BASED ON RPC (A LAN TECHNOLOGY), AND IS INTRICATELY TIED TO THE LAN TRANSPORT PROTOCOL. MANY PEOPLE DO NOT UNDERSTAND THE IMPACT OF TRANSPORT PROTOCOL ON SERVICES, THEY THINK THEY ARE UNRELATED, BUT IN REALITY THEY ARE STRANGELY RELATED.

NOW IF THE TRANSPORT IS GONE, THE EJB SERVER IS REDUNDANT.

LET US SEE HOW THE LOGISTICS WORK.

1) THE LAN TECHNOLOGY HAS A COST FACTOR,
AND HAD ATMOST ONE SERVER.
2) THE PRICE OF SERVER IN LAN ERA WAS
HUGE, AND ALMOST UNAFFORDABLE.

IN VIEW OF THE ABOVE, ONLY ONE SERVER EXISTED FOR PRACTICAL PURPOSES.

NOW IN CURRENT "WINTEL" ERA -
1) THE SERVER IS LIKE A SOAPBOX. WE CAN
BUY IN SCORES.
2) THE HTTP/SOAP TRANSPORT IS HIGHLY
FLEXIBLE, AND YOU CAN ROUTE TO
DIFFERENT SERVERS BASED ON LOAD.

DUE TO THE ABOVE, THE NEED FOR A EJB SERVER IS HIGHLY QUESTIONABLE.

A COMPANY LIKE MICROSOFT DID NOT JUMP AT EJB SERVERS, BUT IT UNDERSTOOD THAT JAVA IS TOO GOOD.

NOW THE BIG QUESTION I HAVE FOR YOU IS -
WHY SHOULD A WEB SERVICE USE EJB'S?

webservice commented on 20 Jun 2002

web service at:
http://www.sys-con.com/java/article.cfm?id=1292

Your Feedback

How to Develop with an Emerging Standard, Today

Hmm wrote: I have an alternative title for your article: How to promote oracle 9i application server, a tutorial on how to click your way through its menues.. an article not worth the paper its written on. sorry