Developing Real World Applications in .NET

quiverlickforkΛογισμικό & κατασκευή λογ/κού

2 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

296 εμφανίσεις



Developing Real World Applications in .NET



Mikael Sundfors
Software Architect
Research & Development
Beamex Oy Ab
Ristisuonraitti 10
FIN-68600 Pietarsaari
Finland
Tel: +358 6 784 0278
email: mikael.sundfors@beamex.com


KEYWORDS

Microsoft .NET, Web Services, Application Integration, Calibration Management System


ABSTRACT

This paper examines the issues and benefits concerning implementing applications based on
the Microsoft .NET architecture. The paper will especially focus on integration, both with
legacy code written for the Windows platform and application integration between applications
on both Windows and other platforms.


INTRODUCTION

In July 2000, Microsoft held the Professional Developers Conference (PDC) in Orlando,
Florida, where they first revealed information to the public about their next generation platform
for Windows and Internet software development – .NET.

Since then, much development has been done in the .NET architecture and much experience
has been gathered. This paper will reveal some of the experience gained and discuss some
of the topics concerned with developing real world applications based on the technology.

Because of the wide range of different application types that can be implemented in .NET, the
aspects concerning implementation applications is a broad subject. In order to limit the topic,
the paper will merely focus on the issues concerned with implementing a typical
manufacturing industry solution such as a Calibration Management System.

Copyright 2003 by ISA - The Instrumentation, Systems and Automation Society.
Presented at ISA Expo 2003; www.isa.org

What is the .NET initiative

Microsoft's .NET initiative is broad-based and ambitious. It revolves around the .NET
Framework, which contains the execution platform Common Language Runtime (CLR), plus
extensive class libraries providing rich built-in functionality. At its core, the .NET framework
embraces XML and SOAP to provide a high level of integration of software. Figure 1 shows
the relationships between the operating system, the .NET runtime environment and
programming languages.


















Fig. 1 – PRINCIPAL OVERVIEW


.NET Framework

The most important part of the .NET platform is the .NET Framework. It consists of the
Common Language Runtime (CLR) environment, a just-in-time compiler, and a set of libraries
packaged using the .NET object model.

One important feature of .NET Framework, is that it is language neutral. This is achieved by
translating all .NET languages into a common language called Intermediary Language (IL). It
is on this level languages interoperate. There is also a subset of rules defined by a Common
Language Specification (CLS) that all .NET compliant languages have to comply to.

The language neutrality may be of particular interest when creating applications for the
manufacturing industry, since it allows reusing old legacy program code and compile into new
.NET based systems. Manufacturing industry systems often consist of large code bases that
are rarely rewritten. For example Fujitsu Software, implementer of COBOL for .NET,
estimated that as late as year 2000, 70% of production business automation systems were
still written in COBOL.
.NET
Framework
Programming
languages
O
O
p
p
e
e
r
r
a
a
t
t
i
i
n
n
g
g


S
S
y
y
s
s
t
t
e
e
m
m


C
C
o
o
m
m
m
m
o
o
n
n


L
L
a
a
n
n
g
g
u
u
a
a
g
g
e
e


R
R
u
u
n
n
t
t
i
i
m
m
e
e


BBaassee CCllaassss LLiibb
r
raa
r
r
y
y
A
A
D
D
O
O
.
.
N
N
E
E
T
T
a
a
n
n
d
d
X
X
M
M
L
L
A
A
S
S
P
P
.
.
N
N
E
E
T
T


W
W
e
e
b
b

F
F
o
o
r
r
m
m
s
s
,
,

W
W
e
e
b
b

S
S
e
e
r
r
v
v
i
i
c
c
e
e
s
s
W
W
i
i
n
n
d
d
o
o
w
w
s
s


F
F
o
o
r
r
m
m
s
s
C
C
o
o
m
m
m
m
o
o
n
n


L
L
a
a
n
n
g
g
u
u
a
a
g
g
e
e


S
S
p
p
e
e
c
c
i
i
f
f
i
i
c
c
a
a
t
t
i
i
o
o
n
n


V
V
B
B
.
.
N
N
E
E
T
T


C
C
#
#


C
C
+
+
+
+


J
J
S
S
c
c
r
r
i
i
p
p
t
t






Operating system
Copyright 2003 by ISA - The Instrumentation, Systems and Automation Society.
Presented at ISA Expo 2003; www.isa.org


It is of course also possible to recompile legacy C/C++ code into managed IL code, which
may be of more practical interest when rewriting manufacturing industry solutions.

The programming language IL files are packaged together in deployable units called
assemblies. These assemblies are loaded into the common language runtime (part of the
.NET Framework), compiled by the just-in-time IL compiler, and executed within the Common
Language Runtime (CLR). The CLR provides many features we usually associate with a
particular language, including garbage collection, type definitions, polymorphic method
resolution, error handling, and the deployment model.


The CLR

The core of .NET is the Common Language Runtime (CLR). In a nutshell, the CLR is a run-
time environment in which .NET applications run. The CLR is layered on top of an operating
system, and exists to provide services by being a layer between .NET applications and the
operating system.

The CLR loads IL code, manages it, runs it and provides a number of support services. Some
of these vital support services include; managing memory and garbage collection, thread
management, enabling remote (distributed) method calls, supporting serialization of XML-
based SOAP, as well as enforcing code safety and security constraints. Code that is loaded
and running under the control of the CLR is referred to as managed code. Compiled code in
.NET does not contain any direct assembly language instructions.

In principle the CLR, somewhat resembles the runtimes of languages like Smaltalk and Java.
However, the similarity is only in principle: the CLR is not an interpreter. The IL is not
designed to be interpreted, but Just In Time (JIT) - compiled into native machine code. This
provides a much more efficient execution than if the code were interpreted. In practice the
difference is that, when a subroutine once is executed, it doesn’t have to be compiled again
the next time it is called in a loop.

The key benefits the CLR provides for Windows applications development and for the general
manufacturing industry, is first of all that it offers a consistent and simplified programming
model compared to the old Windows API. Other important things are:

• Automatic lifetime management of components and classes including
o Garbage collection and memory management
o Type safe method invocations and other specified exception checking
o Thread pooling and asynchronous message handling for scalability
o Side-by-side versions for managing shared components
Copyright 2003 by ISA - The Instrumentation, Systems and Automation Society.
Presented at ISA Expo 2003; www.isa.org


• Enhanced security of execution
o Evidence based security knows code origin and publisher
o Matches users permissions with codes profiles

• Better exception testing and handling
• Better debugging and profiling

In conclusion the .NET Framework CLR provides means for building more safe and robust
solutions than with previous technologies for Windows development.


.NET and application integration

Application integration is becoming increasingly important as businesses realize that
processes cannot stand alone. Most processes in a business are somehow related.
Unfortunately the applications that automate them are not usually integrated, or if integrated,
some kind of monolithic application is provided by one vendor. The trend however seems to
be that integration readiness is becoming a more important selling argument concerning
software.

End users would have much to benefit from application integration achieved in practice and
not just spoken about in technical papers.

Today’s industry software often consists of monolithic applications, where the same
application is automating a wide range of processes, e.g. from supply management to
maintenance/work order to calibration activities.

While the current situation may be beneficial for big software vendors to implement the wide
range of functionality required by the software, it may not be the best situation for end users.
Implementing software and automating a particular business process requires usually a high
level of expertise of the domain. The monolithic application approach may easily result in
software which can do a wide range of things, but which is not very good at it.

A different approach perhaps more positioned for future would be integrating highly
specialized solutions, implemented by companies specialized in the particular business
process the solution is intended to handle. This requires solutions designed with integration
readiness in mind. The applications should be able to exchange data with other applications.

With this is mind, the emphasis the .NET initiative puts on SOAP and XML based Web
Services as integration medium, is interesting and worth being explored.

Copyright 2003 by ISA - The Instrumentation, Systems and Automation Society.
Presented at ISA Expo 2003; www.isa.org


Web Services

Web Services is a new step in the application decentralisation direction. WebServices.org
defines Web Services as “encapsulated, loosely coupled contracted functions offered via
standard protocols.”

In Web Services, software functionality becomes exposed as a service that does not care
what the consumer of the service is. Web Services allow developers to build applications by
combining local and remote resources for an overall integrated and distributed solution.

Normally Web Services are implemented using XML on top of the HTTP protocol, but Web
Services as defined does not have to use HTTP. For example SMTP, FTP or some other
protocol can also be considered.

XML is a widely accepted format for exchanging data and its corresponding semantics. It is a
fundamental building block for every layer that is used for Web Services.
In .NET, Web Services are implemented as part of ASP.NET, which handles all web
interfaces. It allows programs to talk to each other directly over the web, using SOAP.

SOAP is a lightweight, extensible, XML-based protocol for information exchange in a
decentralized, distributed environment. Primarily, SOAP defines a framework for message
structure and a message processing model. SOAP also defines a set of encoding rules for
serializing data and a convention for making remote procedure calls

Since Web Services are intended to run in heterogeneous environments, the protocols used
to perform the data transfer between functions have to be independent of any runtime
environment. SOAP is a protocol having these characteristics.

Implementing a web service in .NET is not very hard. All that is needed is to indicate that a
member should be included in the Web Services interface, and the .NET Framework takes
care of the rest.

Web services can provide many types of value to the manufacturing industry information
technology. Web Services allow applications running in different parts of an organization, or in
different organizations, to talk to one another and/or exchange data.

Because Web Services are implementation agnostic, it allows pieces of software written in
different languages, or running on different operating systems, to talk to one another cheaply
and easily. Based on non-proprietary and universal data standards, Web Services allows
integration between new pieces of software and legacy systems.
Copyright 2003 by ISA - The Instrumentation, Systems and Automation Society.
Presented at ISA Expo 2003; www.isa.org


In the long run we can anticipate to see a replacement of enterprise- class monolithic
applications by smaller component applications, some written in-house and some rented on a
per use basis from outside specialists, communicating as web services, assembled by a
business process orchestration tool.




Fig. 2 – ARCHITECTURAL COMPARISION


The current widely accepted XML Web Services standards are the key enabler of this vision,
but what still is lacking is additional standards and tools for workflow, transaction and
business process management. Until we will see this kind of functionality mature, loosely
coupled, program-to-program communication, using Web Services, will be integrated on a
custom basis. In order to be ready for this, applications have to be designed with integration-
ready architecture and support for XML based interfaces.

Copyright 2003 by ISA - The Instrumentation, Systems and Automation Society.
Presented at ISA Expo 2003; www.isa.org


Other integration/reuse issues

When starting new software projects, one key question is often how to reuse existing
investments in software. There are several possibilities to achieve this in .NET.

Because the .NET Framework is in principle language neutral, a variety of languages can be
plugged into it. The standard Microsoft languages that ship with Visual Studio.NET are Visual
Basic, C++, and C#, but other languages are available through third parties. This includes for
example COBOL from Fujitsu and Eiffel from Interactive Software Engineering.

The language neutrality of the .NET platform is an important point concerning reuse and
integration of old code. In practice it means that old code, if only well structured and not
dependent on, for example, the UI can be compiled as part of a new .NET application and
operate as a Web Service. Differing from the other .NET languages, C++ code can be
compiled into either managed- or native code. Changing old C++ to managed C++ code,
requires marking the classes garbage collected and removing the code handling release of
memory. This makes the class destructor to be executed undeterministically, which can be a
major obstacle when converting some code, depending of destructor logic, to managed .NET
C++.

Legacy code can also be integrated as native DLL’s or COM components. The .NET
Framework makes it transparent to deal with a COM/COM+ component as if it were a .NET
component. Interface translation is automatic. And any .NET Framework component can also
be treated as a COM component by traditional COM-based software.


SUMMARY

Developing applications in the .NET architecture, using a broad, consistent framework, allows
developers to write less, and reuse more. Less code is possible because the system provides
a rich set of underlying functionality. Programs in .NET access this functionality in a standard,
consistent way, requiring less customization to interface with these functions than is typical.

Also a lot of programming infrastructure is either handled automatically by the CLR or
rendered completely unnecessary. Some of it is hidden and some of it is just not there any
more. One example of this hidden infrastructure is the memory management.

Another significant benefit is that .NET Framework introduces a new model aimed at
simplifying application deployment and avoiding versioning conflicts. Applications produced in
the .NET framework can as best be designed to install with a simple XCOPY.

This point cannot be overemphasized. The problems with the current Windows deployment
model, based on shared components and DLLs registered in Windows registry, has been an
endless source of problems for system administrators and developers, commonly known as
“DLL Hell”.
Copyright 2003 by ISA - The Instrumentation, Systems and Automation Society.
Presented at ISA Expo 2003; www.isa.org


Concerning integration issues, the consistent support for XML integration medium is worth
notifying. Support for XML is present in most scenarios and XML Web Services are easy to
create in .NET.

The .NET Framework can be concluded to bring at least significant benefits for certain types
of manufacturing industry application development. There are however some downsides.

One aspect is dependence of the Windows operating system. While technically the core parts
of .NET Framework are platform independent (and to some extent open standards), there are
parts tightly bound to Microsoft Windows like for example the Windows.Forms namespace.
So far there are no significant implementations of .NET Framework on other non-Microsoft
operating systems.

Another potential downside is syntax differences between programming languages. Making
languages work in .NET Framework sometimes means adjustment to the language syntax.
This introduces compatibility problems in moving existing code into .NET. Visual Basic is a
particular problem as the changes between the previous version 6, which wasn’t fully object
oriented, to VB.NET with full object inheritance is significant.

A third aspect worth considering is protection of intellectual property. The Intermediate
Language instructions are much higher level than the processor instructions in machine code.
While current machine code compiled programs can be disassembled, the result is of limited
use. .NET programs disassembled from IL, on the other hand, will more closely resemble
actual source code. They will also contain the information needed to understand data
structures. Such disassembled programs make algorithms and code processes more
transparent than with current environments, making it more difficult to protect intellectual
property.

Based on the information technology complexities faced by modern manufacturing industry,
the Microsoft .NET architecture has much to offer. So many new tasks must be performed
and the constant demand for more data mandate specialized software systems. Combined
with efficiency and productivity restraints, these systems must be easy to implement, integrate
and maintain. The future appears to favor the technology behind .NET.


Copyright 2003 by ISA - The Instrumentation, Systems and Automation Society.
Presented at ISA Expo 2003; www.isa.org

GLOSSARY

API (Application Program Interface) - Defines how a computer programmer should link one
application to another application or to a computer's operating system.

DLL (Dynamically Linked Library) is a library of executable functions or data that can be used
by a Windows application. A DLL can contain one or more functions that can be used by other
applications or components.

SMTP (Simple Mail Transfer Protocol) is a TCP/IP protocol that describes how information is
passed between reporting devices and data collection programs. SMTP is the standard
Internet protocol for distributing e-mail.

SOAP (Simple Object Access Protocol) - A standard for packaging and addressing an XML
message from one piece of software to another, that can be easily utilized regardless of the
programming technologies in use. SOAP may be used to make a request and receive a
response (known as RPC or Remote Procedure Style), or to deliver a document (known as
Document Style).

UI (User Interface) is the point of communication between the computer and the user.

Windows Forms - The .Net framework's Windows Forms are a set of class libraries and a
design environment for building Windows user interfaces.

XML (eXtensible Markup Language) - XML is a flexible way to create common information
formats and share both the format and the data on the World Wide Web, intranets, and
elsewhere. XML can be used by any individual or group of individuals or companies that
wants to share information in a consistent way. XML is "extensible" because the markup
symbols are unlimited and self-defining. XML is actually a simpler and easier-to-use subset of
the Standard Generalized Markup Language (SGML), the standard for how to create a
document structure.

.NET Assembly - A .NET Assembly is how .NET components are deployed. It is the .NET
equivalent of a DLL.



Copyright 2003 by ISA - The Instrumentation, Systems and Automation Society.
Presented at ISA Expo 2003; www.isa.org