DCE Transformation Strategies: Evolution of DCE to SOA

estrapadesherbetSoftware and s/w Development

Nov 18, 2013 (4 years and 1 month ago)

72 views


DCE
Transformation

Strategies: Evolution of DCE to SOA

By Kevin Barnes, eCube Systems, LLC


DCE

History



What is DCE?


Is your company running
DCE
? If you are running IBM AIX or HP
-
UX, the answer is a qualified
Yes. You are running some components of
DCE

on a regular basis if you use RPC or multi
-
threading.
Ever since IBM announced that support for DCE will be discontinued in 1999, parts of
DCE

is showing up in all kinds of places. For those of you who don’t know,
DCE

or Distributed
Computing Environment
is a
legacy
middleware product that runs so well that, unless you are an
administrator, you might not be aware that you are using it. DCE’s origins began w
hen
two tier
Client
-
Server architectures first started making in
-
roads on the monolithic mainframe ap
plications
of the 19
7
0s, most developers were using Cobol,
PL/1,
C and Fortran as languages.
The advent
of high
-
speed reliable networks made diverse computing environments easily accessible to a
large portion of computers in the U.S.

This changed the way t
hat n
etworks were being
viewed:
they began to be
recognized as computers
themselves

-

ones
that could extend the computing
power
and disk space
of any single computer system.
At the same time,
different vendor’s
implementations of
Unix
System V R4 became

t
he

emerging development platform of choice and
socket layer

communication
or RPCs were

the standard

for applications to communicate
.
It was
at this time that
Distributed
Computing Environment (
DCE
)
was
developed.
DCE

was

a
revolutionary middleware develope
d by the Open Software Foundation (
OSF
) that provided

a
stable
and secure
multi
-
language, multi
-
platform environment for Enterprise applications on Unix,
mainframe, VMS, and Windows.
DCE

used a three
-
tier client server model as its environment:
the Prese
ntation or User Interface layer, the Business logic or Computational layer and Database
or Information Storage layer.
DCE

introduced several revolutionary programming structures which
are standard components of distributing computing today: the Interface D
efinition Language (
IDL
)
and a Naming Service
(
called Cell Directory Service
CDS
).
DCE

was also innovative in
introducing threads as a way to increase program performance
, and it

had support for Object
-
Oriented Programming (
OOP
) even though it had no tools

for development.
DCE

also supported
asynchronous programming or Message Queueing, and Transaction Processing.
DCE

was
internationally accepted and was comp
liant

with the best know
n

computing
standards of its time:
Domain Name System (
DNS
), Berkley Interne
t Name Domain (
BIND
), and ITT Consultative
Committee (
CCITT
)

X.500

directory structures
.
While not compliant,
DCE

threads was close to
the International St
a
ndards Organization’s model for Open System Interconnection or POSIX
1003.4a (Draft 4) standard.



With the emergence of Object
-
Oriented Programming
concepts
in the 19
8
0s,
C++ was
invented by Bjarne Stroustrup to add object support to the C language. C++ was picked to be the
ultimate OOP programming language because it supported inheritance, abstracti
on,
polymorphism and encapsulation,

Soon afterwards,
distributed objects was thought to be a better
approach to middleware and
the
C
ommon
O
bject
R
equest
B
roker
A
rchitecture or
Corba

was
largely picked to replace
DCE

as the most popular middleware.
Many com
panies jumped on the
Corba

wagon

and wrote their new applications using
OOP

and
Corba
, but
left their existing large
applications in
DCE
. To move these applications to
Corba

meant that
they

would
almost
have to
be re
-
written
from scratch
in either C++ or t
he emerging Java language. This was not too
daunting a task for
smaller
C
applications
, but quite a
quite a different matter

for
larger
applications and those
applications written in Cobol, Fortran, RPG and other languages.
Language translators like Cobol
to Java emerged, but only a fraction of the Cobol shops
attempted this risky transformation.
In many cases, the
se

applications had to be
isolated on
separate platforms for legacy systems
.
As time went on,
more complex programming techniques
were required f
or
OOP

and

Java and C++ dominated these
new
programming environments. The
Model View Controller design pattern
gave way to newer patterns like the Factory Design pattern,
the Adapter pattern and others.
Ultimately, distributed objects proved to be too slow

and difficult
to administer, just as DCE cells once were.


Web Services became the next new paradigm, but their adoption was slowed by the
performance of the UDDI and XML parsing. One thing soon became apparent during
the rise of
each of these leading

edge paradigms: the
ir solutions

did not account for the large majority of
l
egacy applications
running on older platforms with legacy programming languages
which were
running
continuous
ly and were never migrated to newer technologies.

While the cost to mig
rate to
to newer architectures was high, t
he main reason
these applications never changed
was that
there was no compelling reason to migrate. These applications had been running for years and
were capable of being upgraded with hardware to stay current.
Th
e beauty of the three tier model
became immediately apparent: with the business logic written in a portable and stable
programming language, the other tiers could be modified and not affect the overall structure of
the application.
The
RPC and
TCP/IP netwo
rks that these applications ran on had not
changed
very much in 20 years.
T
he
relational
databases were
all
SQL
-
92 compliant and had standard
ODBC APIs for access.

The legacy programming languages has significant momentum behind
them to ensure their surviv
al, so there was little justification to
re
-
write the application from
scratch. Now that most applications have the requirement to run over the internet, SOAP and
XML solutions abound for these types of applications.
and Service Oriented architectures have

special requirements that complicate the development and operation of solutions built on these
platforms.

NXTera
, from eCube Systems, provides the tools and application services needed to develop,
implement and manage flexible, cross
-
platform, multi
-
tier

client/server applications that comply
with Open Group's DCE and, in conjunction with other tools from eCube, interoperates with
CORBA, .NET, and J2EE.

NXTera

simplifies the development of distributed, multi
-
tier service
-
based applications without
forcin
g developer to worry about the communications routines that link them together and insure
their availability. Business applications developed using
NXTera

operate independently of the
underlying network infrastructure


freeing developers to focus on busin
ess functionality.

The
NXTera

development model insulates developers from the distributed computing
infrastructure while enabling the rapid development of open, scalable, multi
-
tiered service
-
based
applications for
VMS, MPE, Macintosh, OS390, OS400,
LINUX
,
BSD,
SGI

IRIX
, AIX, HP
-
UX,
S
olaris

and Windows.

Now using familiar platforms and languages
--

such as C,
COBOL, Fortran, PL/1, Pascal,
C++,
Delphi, Java, Visual Basic, and PowerBuilder


reliable enterprise class applications can be
quickly built and eas
ily maintained.


D
C
E’s

Infrastructure

Components

DCE was designed to make heterogenous computing environments

open to each other in a way
that would extend the computing power of each system. The problems with different languages or
different data represen
tations were masked by DCE.
In a typical DCE environment, there are
many layers with which applications can interact with DCE. clients locate their services via the
Cell Directory service, communications are accomplished using the connectivity provided by
the
DBMS environment. The developer must identify the location of the database system within the
application, and the client application and/or the database system performs the necessary
security checks.


Distributed Service Oriented Computing Infrastruct
ure


Integral to the workings of a service
-
based or multi
-
tier application is a distributed computing
infrastructure. A distributed computing infrastructure provides the environmental underpinnings
that enable the service to respond to service requestors a
nd client applications as they interact
with distributed business logic
,
transparently across any number of physical systems.

This partitioning of application logic components across a number of different systems introduces
a new spectrum of technological

issues:



Where should a server run?



How many copies of the server should be running?



How does a client know where the server is running?



How does a client learn of the existence of a new replica of a server?



How do you transfer requests between a clien
t and a server?



How do you manage security across the distributed environment?

Conversely, in the multi
-
tiered environment, communications are performed through an abstract
interface. The abstract interface does not indicate the actual location of the re
quested server
object. The application programmer does not need to directly address these issues. Server
location, security checks and communications should be handled dynamically at run time by the
distributed computing infrastructure.

A dynamic distribut
ed computing infrastructure allows the distributed application environment to
be reconfigured to accommodate additional users, increased workloads, or unexpected hardware
failures as they happen, without loss of service. Physical partitioning of applicatio
n systems is the
most effective means to support scalability, reliability and availability issues. As additional users
are added to the system, CPU utilization exceeds acceptable levels, or database connections
overwhelm memory, server modules can be shift
ed to alternate machines or can be replicated
across a number of machines. Physical partitioning maximizes hardware utilization since partially
idle machines can be incorporated into a load
-
balancing mechanism. Overall system load can be
spread evenly acro
ss a number of different machines. Since each application component can be
replicated independently, virtually any server machine can be used to run some part of the
application for some set of users.

Service distribution and replication do more than elimi
nate processing bottlenecks. They also
provide a mechanism for fault tolerance and increased system availability. The replication of
services removes any single point of failure. If a particular process encounters a problem, a
replica can handle subsequent

service requests. If a server machine unexpectedly shuts down or
an entire network subnet becomes unavailable, the requests can be directed to application
replicas on other systems.

Obviously, the distributed computing infrastructure, which enables applic
ation partitioning,
transparency, security, scalability, reliability, availability, and manageability, is a critical
component for the development and deployment of mission
-
critical multi
-
tiered client/server
applications. There are three major environment
al services that must be provided by the
distributed computing infrastructure:


Directory Service

A directory service maintains a dynamic list of all application services throughout the enterprise.
Whenever a client makes a request, the directory service
locates an application
service that

can
handle the request and tells the client how to communicate with the service.


Security Service

A security service maintains a registry of all authorized users throughout the enterprise and keeps
track of which func
tions each user or groups of users are allowed to perform. The security service
provides a single login service for all systems throughout the enterprise. Once a user is
authenticated by the security service he is authenticated on all systems.


Applicati
on Management Service

An application management service maintains a dynamic configuration of application services. It
is responsible for starting the appropriate application services on the appropriate machines and
monitoring the application services to en
sure that they are available and performing within
required parameters. If any application services are lost, the management service must restart
the service or perform some other appropriate action according to the configuration. As load
increases or decr
eases, the management service can start or stop replica services on various
nodes throughout the enterprise.


Transforming the DCE Legacy

There is more to creating three
-
tiered, distributed, dynamic applications than simply writing some
application logic.

Typically, as in the case of
DCE

(the Distributed Computing Environment) a
tremendous amount of code must be written in order to create the abstract interface and integrate
the application with the distributed computing infrastructure. Each application se
rver must register
with the directory service. Each application component must be able to construct and interpret
messages from other application components. Each application component must also be able to
interface with the security service. The infrastru
cture code is inherently more difficult to write than
the application itself, yet one of our core requirements for the multi
-
tiered service oriented
architecture is the ability to rapidly develop and deploy applications. Since the prospects of
creating and

supporting this plumbing seems to outweigh its potential benefits, the architecture
for the future also requires that the application developers be shielded from the underlying
infrastructure.

The communications between application modules presents the g
reatest barrier. Application
developers do not want to write and support network and process communications code.
Therefore the multi
-
tiered architecture requires the use of an automated tool for the generation of
the abstract interfaces. An Interface Defi
nition Language (IDL) is used to define the interface, its
functions, and the parameters required for each function. The IDL is processed by an IDL
Compiler to automatically generate the code, or communications stubs, which make up the
abstract interface.
The communications stubs are compiled with the application logic and handle
all the network and process communications. Application developers therefore need not write any
communications code.

Adherence to Industry Standards

Just as DCE did in its day, a
n
y architecture
solution
for the future must be based on accepted
industry standards and must allow for the incorporation of emerging standards. Without
compliance with industry
standards, the architecture
solution developed

will do nothing more than
facili
tate the building of multi
-
tiered distributed, dynamic, automated,
proprietary

systems!
Industry standards
accepted by multiple vendors ensure that you are

protect
ed

from vendor lock
-
in. Standards help you
r applications

achieve
a certain amount of
environm
ent
al

independence.

Standards that ought to be considered when developing your architecture include those related to
open systems, transactional systems, and distributed systems. Some of the most useful
standards to consider are the
de facto

standards, the

standards that everyone uses. Standards
are especially critical if they involve the interoperability or integration of multi
-
vendor products.
Probably the most universal of de facto standards is the TCP/IP communications protocol. The
SQL standard
is SQL
-
92 and it
provides a common interface to multi
-
vendor database systems.
It’s very tempting to make use of the proprietary extensions offered by each of the database
vendors

(such as stored procedures)
, but it results in database lock
-
in

and will create a
d
ependence on that feature.

Probably the most critical set of standards to consider, though, are those related to a distributed
computing infrastructure. It is absolutely essential that the distributed computing services required
by the multi
-
tiered Service
s Oriented Architecture accessible from all systems throughout the
enterprise. The OSF Distributed Computing Environment (
DCE
), OMG CORBA and SOAP meet
the minimum requirements for an open multi
-
tiered Services Oriented Architecture. Of the three,
DCE is t
he most established and mature.
DCE

provides a dynamic, integrated directory and
security service. It provides an IDL compiler for the automatic generation of abstract interfaces. It
is available from multiple vendors on an exceptionally wide range of plat
forms. Best of all, DCE
was designed to support enterprise
-
class applications with thousands of users accessing
thousands of servers and business logic services.

As SOAP continues to mature, good SOA solutions must allow SOAP (both .NET/J2EE) inclusion
of
these technologies as they emerge.

Distributed Service Oriented Development with Infrastructure Independence

eCube Systems is dedicated to helping you be successful as you develop you SOA and
distributed computing implementations. Our
NXTera

and our
NXTw
are

family of software
products are designed to make multi
-
tiered Service Oriented development easy. Whatever
distributed model you select eCube can help you simplify development and integrate legacy
systems.

Take
DCE
, for example.
DCE

is an extremely pow
erful and robust distributed computing
infrastructure, perfectly suited to support a multi
-
tiered Services Oriented Architecture. But
building multi
-
tiered applications with
DCE

requires knowledge and experienced programmers. It
can be very difficult. Alth
ough
DCE

provides an IDL Compiler to generate the communications
stubs, those stubs can only be generated in C. There are also over 600 APIs used to
communicate with the infrastructure in order to interface with the directory service, the security
service,

remote procedure call service, and the threading service.

Given that the multi
-
tiered architecture demands rapid application development and utilization of
existing staff skill sets in COBOL, C++, JAVA, Visual Basic, Delphi and PowerBuilder, native
DCE

d
evelopment may not suit your requirements. Besides, there are other distributed object
technologies that you may need to integrate with.

NXTera

is designed to help you rapidly develop multi
-
tiered service oriented applications, and at
the same time insulat
e you from the distributed computing infrastructure. It lets you build your
application components using the languages and tools that you are accustomed to.
NXTera’s

IDL
compiler automatically generates the communications stubs, and it generates all the ot
her code
that’s required to interface with the directory service, the security service, and the threading
service (if there is one).
NXTera

completely hides the complexity of the underlying infrastructure.
The runtime, security, and directory service behav
ior are configured simply via deployment
descriptor files. And since your programmers don’t need to code at the infrastructure level,
NXTera

provides environment independence even from the distributed computing infrastructure.
NXTera

currently supports two

infrastructures natively and others via interoperability:



OSF
DCE

--

using
DCE

Cell Directory Service,
DCE

Security Service,
DCE

Threads, and
DCE

RPC.
DCE

is available for LINUX, HP, SUN, IBM, SGI and many others. (Contact
Entegrity Solutions

for more information.)



TCP



a lightweight computing infrastructure

(that easily ports to OSF DCE) and based
on TCP/IP, with an integrated directory service, security service, and RPC.
NXTera

/TCP
is available on Windows, NT
, OS/2, AIX, HP
-
UX, Tru64, and Solaris.



SOAP/CORBA


Using Agile Transformation Components
NXTera
applications can
integrate with applications, services and clients that rely on CORBA and SOAP (J2EE,
.NET and WS Management Suites)

Applications developed w
ith
NXTera

can easily be configured to run with either infrastructure or
leverage Web Services Management Suites such as, AmberPoint, Talking Blocks and Confluent.
NXTera

leverages such WS Management Suites
to

fulfill all application and service management

requirements. eCube continues to support other standard distributed computing infrastructures
and management technologies as they emerge

Generating Code for Database Interaction

To simplify the development of data access servers,
NXTera

leverages the
NXTw
are

Data Broker

and the
SQLmake
tool. Most two
-
tiered client/server tools provide automated tools to connect a
GUI window to a database table through a SQL statement. When moving to multi
-
tiered Service
Oriented Architecture you want to represent data acce
ss logic as a set of services isolated from
the presentation and business logic.

To accomplish this in a simple to use automated fashion,
NXTera

leverages
the

SQLmake

tool. In
fact, it may make your job even easier. Most two
-
tiered tools require that you
code more than just
a SQL statement. You also need to identify the name and location of the database, establish a
connection to the database, prepare the SQL statement for execution, declare and manage
cursors, and transfer the data to and from the data bu
ffers. These operations generally require
dozens of lines of code in each application client that connects to the database.

With
SQLmake
, all you need to write is the ANSI
-
standard SQL statement to generate a reusable
Data Broker.

SQLmake

automatically ge
nerates all the database
-
specific connection and
processing code necessary to interact with the database.
SQLmake

provides standard support for
DB2, Informix, Ingres, Oracle, Oracle Rdb, SQL Server, MySQL and Sybase. IBI provides support
for EDA/SQL. Custo
mized support can be created for any RDBMS gateway that supports ANSI
SQL.

(For more information on

NXTware Data Broker,
please refer to the white paper

NXTware Data
Broker: Data Services for Service Oriented Architecture.)

Debugging Distributed Applicatio
n Components

As application components get spread further and further apart, application debugging and
problem resolution becomes much trickier. At development time, each application component
must be tested as a standalone program to verify its logic. How
ever, proper behavior as a
standalone program does not imply proper behavior as an application server.

The only way to fully qualify a server’s behavior when it receives an external request (an RPC) is
to test it with an external request (an RPC). Therefo
re a test client must be written to send it an
RPC. But the test client might introduce an additional error. If the RPC fails to return the correct
results, how can you determine where the problem actually occurred?

NXTera

includes a testing tool,
RPCdebu
g
, which eliminates the need to write a test client. It is a
standard universal client that can be used to test any server module, regardless of the server
functionality.

NXTera

also includes built
-
in logging and tracing capabilities to track all runtime
communications
errors, which might result from a lost network link or communications session.

Achieving a Multi
-
tiered Services Oriented Architecture

The multi
-
tiered Services Oriented Architecture provides a flexible, open, environment
-
independent archit
ecture to meet the future head on. It supports plug
-
and
-
play application
component integration. It allows enterprise
-
wide access to information, regardless of its location
or data structure. It enables integration of legacy environments with new environmen
ts. It
leverages your existing investments in hardware, applications, and staff skill sets.

NXTera

provides you with the tools you need to achieve a multi
-
tiered Services Oriented
Architecture. It provides rapid application development tools to assist you

in the development of
application components. It automatically generates abstract interfaces in the languages that your
developers are using. It automates the integration of the application components with the
distributed computing infrastructure. It insu
lates you from lock
-
in to any proprietary product or
technology. It also provides a viable migration path to incorporate new technologies as they
emerge.

Does It Pass the Test?

As vendors continue to offer more and more enterprise
-
wide application develop
ment tools, put
any such offerings to this test:



Does it clearly support the multi
-
tier Services Oriented Architecture?



Does it allow for support of new infrastructure models


CORBA, SOAP, etc



Does it clearly separate the presentation rules, business rule
s and data access rules?



Does it support rapid development and deployment of new application systems?



Does it support rapid modification of existing application systems?



Does it support the integration of new and existing application systems?



Does it a
llow you to leverage existing investments in hardware, applications, and staff
skill sets?



Does it support current and emerging technologies and standards?



Does it encourage reuse of software?



Does it support the dynamic reconfiguration of systems for s
calability or networking
requirements?



Does it support portability, interoperability, distribution, manageability, reliability,
availability, and security?



Does it allow you to choose your own GUI front
-
end programming languages and data
sources?


For m
ore information about NXTera and the NXTware family of products contact
eCube Systems

at
sales@ecubesystems.com

or visit us at
www.ecubesystems.com
.


All brand and p
roduct names are trademarks or registered trademarks are the property of
their respective owners.