Web Services in ChevronTexaco
Contents
Introduction
What is a Web Service?
.Net Applications
SAP Interfaces
We do not currrently have a great deal of experience with using web services
in ChevronTexaco. This note will suggest some applications that we think
will be particularly attractive. That is, we are trying to predict what
the low hanging fruit will be.
What is a Web Service?
A web service
Web Services in .Net Web Applications
Current "best practice" in ChevronTexaco is to develop web applications in a
three-tier COM architecture. Briefly, one creates COM components, hosted
by MTS, that specialize in data access, business logic, and perhaps design
logic. The data layer components encapsulate interactions with the data
sources, the business layer components invoke the data layer components
encapsulate the business rules of the application and are, in turn, called
either by the design layer or directly by an ASP hosted by the web server.
Data in this architecture are passed between components primarily in the form of
ADO recordsets.
A sensible way to move into the .Net environment is to keep using the same
basic architecture and introduce new .Net functions in an incremental manner.
Although it is possible to use existing COM components in .Net applications, in
order to take full advantage of the managed .Net environment it is better
program entirely in the managed environment if possible. In the business
logic layer this probably means using .Net classes and passing data as ADO.Net
datasets. However, we would like to suggest that it may be desirable to
implement the data layer components as web services. It seems that there
would be several potential advantages to this approach and, as far as we can
see, no significant negatives. Potential advantages include the following:
- Cross-platform availability. Should it be desirable, the data layer
web services could be invoked by applications on non-Microsoft platforms.
This might, as discussed below, include usage from within SAP.
- Easy access across network. Although we have discussed in the COM
context the potential advantages of putting the data layer components on one
machine (probably physically close to the data) and the business layer
components on another more closely associated with the application itself, in
practice we have seldom done this. In fact, some experiments along these
lines revealed practical roadblocks in the COM environment. Using web
services however, this architecture would be extremely easy.
- Infrastructure for re-use. Reusing COM components has always been an
objective, but in practice there have been barriers, one of which has been the
lack of a commonly accepted infrastructure for expediting this reuse. In
contrast, UDDI forms a natural starting point for cataloging, finding and
reusing web services. .Net is fully UDDI aware and one may expect other
platforms to understand UDDI as well.
- Flexibility in handling and processing data. Although it seems
unlikely to be a common occurrence, should it be desirable it would be
possible to examine and process the XML used by the web service to transmit
data, using the DOM, XSLT style sheets or other techniques. Although
ADO.Net datasets are also transmitted as XML, we think it likely that the XML
involved with datasets will be significantly more complex and difficult to
handle than that created by web services. It may be also be an
advantage in this regard that a schema for the XML data can be derived from
the WSDL description of the web service.
Areas where we believe that using web services is approximately a wash
include the following:
- Performance. This needs to be checked, of course, but we think that
there will be marshalling overhead involved both with passing ADO.Net datasets
and web services XML. We see no reason to expect the web services
overhead to be higher, and in fact it might be lower if the XML turns out to
be simpler than that used by datasets.
- Learning Curve. Both web services and ADO.Net require learning new
concepts and techniques. The facilities offered by .Net make working
with web services extremely easy.
Web Services and SAP
The DCOM Component Connector is currently an attractive way to interface into
SAP from the COM application environment. This facility looks inside SAP
to find the desired interfaces and generates code that wraps selected SAP
interfaces into COM components that also take care of data format conversions
(into ADO recordsets, for example). These COM components can then easily
be used from within COM oriented applications.
Looking forward into the .Net environment, however, as discussed above it is
possible to continue using COM components but desirable to find more .Net
compliant techniques. Fortunately, SAP is currently developing web
services wrappers for their standard interfaces and it is expected that this
will be available in production shortly. Use of these SAP web services is
obviously desirable in the .Net environment.
In addition, if SAP also provides the ability within their system (either in
ABAP or Java) to consume web services this could open the door to re-using
within SAP business logic developed in .Net. This direction of integration
has in the past been very difficult and it could, in fact, become quite easy
using web services.
