OPC SERVER GATEWAY

NATIONAL INSTITUTE OF ELECTRONICS AND INFORMATION
TECHNOLOGY (NIELIT), AURANGABAD
(An Autonomous scientific society of Department of Inforamation Technology and Ministry of
communication and information Technology,Govt Of India,Aurangabad,Maharashtra state,India)
Dissertation on
DEVELOPMENT OF GATEWAY FOR
LEGACY OPC SERVER
Submitted in the partial fulfillment for the award of degree of
MASTER OF TECHNOLOGY
IN
ELECTRONICS DESIGN
Submitted by: Under the Guidance of
AAKANKSHA DHIDHI Mr.Ravi Shankar(AGM)
SAIL(INCOS Department)
Mr.Yashpal Gogia(NIELIT)

LETTER OF RECOMMENDATION
The Report entitled “Development of Gateway for Legacy OPC Server ” submitted by
Ms.Aakanksha Dhidhi for the partial fulfillment of the award of Master of Technology in
Electronics Design from DR.Babasaheb Ambedkar Marathwada
university,Aurangabad(Maharashtra) is a record work carried by them on the project title.
The work is comprehensive and and is of sufficient standard,as found after proper
evaluation.It is recommended as a creditable work for the award of Degree of Master of
Technology in Electronics Design. However,the statement made in the report are outcome of
the project work carried out by the student and the undersigned will not be responsible for
it,if this report is presented for the purposes other than the award of degree.
Project Guide Counter Signed By
Mr.Ravi Shankar(AGM) Dr.Ranjan Maheshwari
SAIL(INCOS Department) (Director ,NIELIT)

CERTIFICATE OF DISSERTATION ACCEPTANCE
This is to certify that the project entitled “Development of Gateway for Legacy OPC Server”
carried out by Ms.Aakanksha Dhidhi(2013/M/12) student of final year MTECH 2015 at
National Institute of Electronics and Information Technology,Aurangabad(Maharashtra) is
hereby accepted and approved after proper evaluation as a creditable work submitted in the
partial fulfillment of the requirement for awarding the degree of MTECH in Electronics
Design from Dr.Babasaheb Ambedkar Marathwada University,Aurangabad(Maharashtra).
It is understood that by this approval,the undersigned does not necessarily endorse or
approve any statement made,opinion expressed and conclusion there in,but approve the
report for the purpose for which it is submitted.
Internal Examiner External Examiner

DECLARATION
I undersigned solemly declare thet the report of the project work entitled “Development of
Gateway for legacy OPC Server” is based on my work carried out during the course of my study
under the supervision of Mr.Ravi Shankar(AGM),SAIL,INCOS Department,Bhilai Steel
Plant,Bhilai and Mr.Yashpal Gogia(NIELIT)
I assert that the statements made and conclusions drawn are an outcome of the project
work.We further declare that to the best of our knowledge and belief that report does not
contain any work which has been submitted for the award of any other
degree/diploma/certificate in this university/deemed university.
(Signature of the candidate)

ACKNOWLEDGEMENT
The real spirit of achieving a goal through the way of excellence and austere discipline.I
Would have never succeded in completing our task without the cooperation,encouragement
and help provided to us by various personalities.When I truly wish to express my warm
gratitude and indebtedness toward somebody concerned,we are always at loss of words.
I gratefully take this opportunity to express our gratitude and indebtedness to Dr.Ranjan
Maheshwari,Director,National Institute of Electronics and Information
Technology,Aurangabad,Maharashtra
With deep sense of gratitude,I express my sincere thanks to our esteemed and worthy
supervisors,Mr.Ravishankar and Mr.Yashpal Gogia for their valuable guidance in carrying
out this work under their effective supervision,encouragement,enlightenment and co-
operation,
I pay my sincere gratitude to the Management of National Institute of Electronics and
Information Technology and Management of Steel Authority of India (SAIL) for providing
the necessary support as and when required. I also thank the entire faculty and staff
members of the institute and Steel Authority of India, who directly or indirectly helped me in
the completion of this project.
Aakanksha Dhidhi(2013/M/12)

CERTIFICATE OF PROJECT COMPLETION
This is to certify that Ms.Aakanksha Dhidhi,thee bonafide students of Master of Technology
in Electronics Design,2015,National Institute of Electronics and IT,Aurangabad(Maharashtra)
have successfully completed their MTECH Final year project titled: “Development of
Gateway for legacy Opc Server” under my guidance and supervision.
While forwarding the project work and report on the topic above. I certify that the candidate
have completed their project work in the prescribed period and the project work
incorporates the result of the job done by them.
Aakanksha Dhidhi(2013/M/12)
Project Guide Counter Signed By
Mr.Ravi Shankar(AGM) Dr.Ranjan Maheshwari
SAIL(INCOS Department) (Director ,NIELIT)

ABSTRACT
Steel Authority Of India Limited (SAIL) is the leading steel making company in India. SAIL
has its own private network connecting different production units located at Durgapur,
Bokaro, Bhilai, Rourkela steel plants etc and corporate offices at Delhi, Kolkata etc. Some of
the links in private network are also connected to open and larger network such as internet to
communicate with suppliers and customers. Therefore the internal network of SAIL is private
as well as public network. So security for this network is most important. Everyday a number
of attacks are launched. Among them service attacks are growing exponentially. Since private
network of SAIL is indirectly connected to public network through internet. Therefore OPC
connected to PLC in steel plants are also indirectly connected to internet. Since it is not
possible to route data from OPC through firewall and switching off the firewall makes the
plant network insecure and prone to viruses like STUXNET. In this paper, I will propose a
security model to secure OPC client and server communication.

CHAPTER-1 INTRODUCTION
1.1 General Introduction
Since the private network of SAIL is private as well as public network it is necessary to
protect or secure OPC server and client communication. Since OPC ver-2 is based on
COM/DCOM technology it is not possible for OPC Data client/OPC service consumer to
access data from OPC server through firewall.
1.2 OPC SERVER
OLE for process control (OPC) is a software interface technology used to facilitate the
transfer of data between industrial control systems, Human Machine Interfaces (HMI),
supervisory systems and enterprise systems such as historical databases. The primary use of
OPC is that it provides a common interface for communicating with diverse industrial control
products, regardless of the software and hardware used in the process. OPC is an industrial
standard based on Microsoft Distributed Component Object Model (DCOM) interface of the
Remote Procedure Call (RPC) service. OPC is being increasingly used to interconnect.
Human Machine Interface (HMI) workstation, data historians and other servers on the control
network with enterprise databases.
1.3 Service Oriented Architecture (SOA)
A Service Oriented Architecture (SOA) is an architectural pattern in which application
components provide services to other components via a communication protocol typical over
a network. The principles of service orientation are independent of any vendor, product or
technology. SOA is based on the concept of service. SOA contains three softwares:-
1. Service provider
2. Service consumer
3. Service broker
1.3.1 Service
Each service is built as a discrete piece of code. Service is well defined function that does not
depend on the state of other services. Service consumer needs to know how to call the service
and what to expect in response. It is possible to reuse the code in different ways throughout
the application by changing only the way an individual service interoperate with other
services that make up the application.

1.3.2 Service Provider Software
Service provides software which helps to register OPC web services with the Service Broker.
Service Broker stores service metadata information in a repository connected to Service
Broker service.
1.3.3 Service Consumer Software
It is the one who want to access data of OPC server. Service Consumer Software helps to
select the relevant service from the set of services retrieved from the Service Broker
repository. Repository will be a Data Dictionary. The service consumer also provides for the
service composition and then this service is returned to the client who requested the service.
1.3.4 Data Dictionary (OPC Web Service Repository)
It contain Domain specific information related to E-Learning Data Dictionary is also called as
metadata repository. The content of it are automatically updated as changes occur in the
database. It may interact with the modules and provides the necessary information for its
functioning.
1.3.5 OPC Service Broker
The important in this Broker based OPC web services are played by OPC Web Service
Broker. The Broker communicates with the service provider who wants to register and
provide its OPC Web Services. The Broker also interacts with OPC data client when he wants
to search for particular OPC web services. It also searches the OPC web service Repository
when the service provider and OPC Data Client perform publishes and search operations.

1.4 Working Principle Of Service Oriented Architecture (SOA)
1. OPC Web Service Provider publishes its web services to OPC Web Services
Broker.
2. OPC Web Service Broker registers OPC Providers Web Service and stores it in
repository.
3. When OPC Data Client connects to OPC Web Service Broker, Broker searches its
registry and provides the OPC Data Client required OPC Web Services metadata
information.
1.5 OPC Client and OPC Server Current Communication Scenario
Control System/PLC/DCS
In the current OPC Client and OPC server communication scenario communication is
through DCOM based technology because OPC ver-2 server is based on COM/DCOM
technology. Thus the use of OPC connectivity in control systems and servers leads to DCOM
OPC Web Service
Broker
OPC Web Service
Provider
Invokes
OPC Web Service
Data Client
DCOM DCOM
OPCSERVER
OPCCLIENT
NETWORK

based control protocol attacks (Such as STUXNET). STUXNET is a computer worm
discovered in June 2010. It was designed to attack Industrial Programming Logic Controllers.
It functions by targeting machines using Microsoft windows operating system and networks,
then seeking out Siemens step 7 software.
1.6 Proposed Model To Secure OPC Data Client And OPC Server Communication
In the proposed security model 9 will migrate OPC Data Client and OPC Server
communication from DCOM based architecture to potentially more secure. NET based
architecture or service oriented architecture in which communication will be through
firewalls
PLC
OPC SERVICE REGISTRY
& GATEWAY
OPC SERVICE
CONSUMER
OPC SERVICE
PROVIDER
OPC SERVER OPC CLIENT
FIREWALL
PUBLISHES
FIND
INVOKES

CHAPTER - 3
SOCKETS,COM & DCOM

CHAPTER-2
Sockets ,COM & DCOM
2.1 SOCKET
Sockets allow communication between two different processes on the same or different
machines. To be more precise, it's a way to talk to other computers using standard Unix file
descriptors. In Unix, every I/O action is done by writing or reading a file descriptor. A file
descriptor is just an integer associated with an open file and it can be a network connection,
a text file, a terminal, or something else.
To a programmer, a socket looks and behaves much like a low-level file descriptor. This is
because commands such as read() and write() work with sockets in the same way they do
with files and pipes.
Sockets were first introduced in 2.1BSD and subsequently refined into their current form
with 4.2BSD. The sockets feature is now available with most current UNIX system releases.
2.1.1Socket-Definition
A Socket is used in a client-server application framework. A server is a process that
performs some functions on request from a client. Most of the application-level protocols
like FTP, SMTP, and POP3 make use of sockets to establish connection between client and
server and then for exchanging data.
2.1.2 SocketTypes
There are four types of sockets available to the users. The first two are most commonly used
and the last two are rarely used.
Processes are presumed to communicate only between sockets of the same type but there is
no restriction that prevents communication between sockets of different types.
 Stream Sockets: Delivery in a networked environment is guaranteed. If you send
through the stream socket three items "A, B, C", they will arrive in the same order -
"A, B, C". These sockets use TCP (Transmission Control Protocol) for data
transmission. If delivery is impossible, the sender receives an error indicator. Data
records do not have any boundaries.

 Datagram Sockets: Delivery in a networked environment is not guaranteed. They're
connectionless because you don't need to have an open connection as in Stream
Sockets - you build a packet with the destination information and send it out. They
use UDP (User Datagram Protocol).
 Raw Sockets: These provide users access to the underlying communication
protocols, which support socket abstractions. These sockets are normally datagram
oriented, though their exact characteristics are dependent on the interface provided
by the protocol. Raw sockets are not intended for the general user; they have been
provided mainly for those interested in developing new communication protocols, or
for gaining access to some of the more cryptic facilities of an existing protocol.
 Sequenced Packet Sockets: They are similar to a stream socket, with the exception
that record boundaries are preserved. This interface is provided only as a part of the
Network Systems (NS) socket abstraction, and is very important in most serious NS
applications. Sequenced-packet sockets allow the user to manipulate the Sequence
Packet Protocol (SPP) or Internet Datagram Protocol (IDP) headers on a packet or a
group of packets, either by writing a prototype header along with whatever data is to
be sent, or by specifying a default header to be used with all outgoing data, and
allows the user to receive the headers on incoming packets.
The IP host address, or more commonly just IP address, is used to identify hosts connected
to the Internet. IP stands for Internet Protocol and refers to the Internet Layer of the overall
network architecture of the Internet.
An IP address is a 32-bit quantity interpreted as 48-bit numbers or octets. Each IP address
uniquely identifies the participating user network, the host on the network, and the class of
the user network.
An IP address is usually written in a dotted-decimal notation of the form N1.N2.N3.N4,
where each Ni is a decimal number between 0 and 255 decimal (00 through FF
hexadecimal).
Address Classes
IP addresses are managed and created by the Internet Assigned Numbers Authority (IANA).
There are five different address classes. You can determine which class an IP address is in
by examining the first four bits of the IP address.

 Class A addresses begin with 0xxx, or 1 to 126 decimal.
 Class B addresses begin with 10xx, or 128 to 191 decimal.
 Class C addresses begin with 110x, or 192 to 223 decimal.
 Class D addresses begin with 1110, or 224 to 239 decimal.
 Class E addresses begin with 1111, or 240 to 254 decimal.
Addresses beginning with 01111111, or 127 decimal, are reserved for loopback and for
internal testing on a local machine [You can test this: you should always be able to ping
127.0.0.1, which points to yourself]; Class D addresses are reserved for multicasting; Class
E addresses are reserved for future use. They should not be used for host addresses.
Example
Class Leftmost bits Start address Finish address
A 0xxx 0.0.0.0 127.255.255.255
B 10xx 128.0.0.0 191.255.255.255
C 110x 192.0.0.0 223.255.255.255
D 1110 224.0.0.0 239.255.255.255
E 1111 240.0.0.0 255.255.255.255
Subnetting
Subnetting or subnetworking basically means to branch off a network. It can be done for a
variety of reasons like network in an organization, use of different physical media (such as
Ethernet, FDDI, WAN, etc.), preservation of address space, and security. The most common
reason is to control network traffic.
The basic idea in subnetting is to partition the host identifier portion of the IP address into
two parts:

 A subnet address within the network address itself; and
 A host address on the subnet.
For example, a common Class B address format is N1.N2.S.H, where N1.N2 identifies the
Class B network, the 8-bit S field identifies the subnet, and the 8-bit H field identifies the
host on the subnet.
Most of the Net Applications use the Client-Server architecture, which refers to two
processes or two applications that communicate with each other to exchange some
information. One of the two processes acts as a client process, and another process acts as a
server.
Client Process
This is the process, which typically makes a request for information. After getting the
response, this process may terminate or may do some other processing.
Example, Internet Browser works as a client application, which sends a request to the Web
Server to get one HTML webpage.
Server Process
This is the process which takes a request from the clients. After getting a request from the
client, this process will perform the required processing, gather the requested information,
and send it to the requestor client. Once done, it becomes ready to serve another client.
Server processes are always alert and ready to serve incoming requests.
Example: Web Server keeps waiting for requests from Internet Browsers and as soon as it
gets any request from a browser, it picks up a requested HTML page and sends it back to
that Browser.
Note that the client needs to know the address of the server, but the server does not need to
know the address or even the existence of the client prior to the connection being
established. Once a connection is established, both sides can send and receive information.
2-tier and 3-tier architectures
There are two types of client-server architectures:
 2-tier architecture: In this architecture, the client directly interacts with the server.
This type of architecture may have some security holes and performance problems.

Internet Explorer and Web Server work on two-tier architecture. Here security
problems are resolved using Secure Socket Layer (SSL).
 3-tier architectures: In this architecture, one more software sits in between the client
and the server. This middle software is called ‘middleware’. Middleware are used to
perform all the security checks and load balancing in case of heavy load. A
middleware takes all requests from the client and after performing the required
authentication, it passes that request to the server. Then the server does the required
processing and sends the response back to the middleware and finally the
middleware passes this response back to the client. If you want to implement a 3-tier
architecture, then you can keep any middleware like Web Logic or Web Sphere
software in between your Web Server and Web Browser.
Types ofServer
There are two types of servers you can have:
 Iterative Server: This is the simplest form of server where a server process serves
one client and after completing the first request, it takes request from another client.
Meanwhile, another client keeps waiting.
 Concurrent Servers: This type of server runs multiple concurrent processes to serve
many requests at a time because one process may take longer and another client
cannot wait for so long. The simplest way to write a concurrent server under Unix is
to fork a child process to handle each client separately.
2.2 SocketClient Implementation
The system calls for establishing a connection are somewhat different for the client and the
server, but both involve the basic construct of a socket. Both the processes establish their
own sockets.
The steps involved in establishing a socket on the client side are as follows:
 Create a socket with the socket () system call.
 Connect the socket to the address of the server using the connect () system call.
 Send and receive data. There are a number of ways to do this, but the simplest way is
to use the read () and write () system calls.

2.3Socket ServerImplementation:
The steps involved in establishing a socket on the server side are as follows:
 Create a socket with the socket () system call.
 Bind the socket to an address using the bind () system call. For a server socket on the
Internet, an address consists of a port number on the host machine.
 Listen for connections with the listen () system call.
 Accept a connection with the accept () system call. This call typically blocks the
connection until a client connects with the server.
 Send and receive data using the read () and write () system call.

Following is the diagram showing the complete Client and Server interaction:
2.4 Description of COM?
The Microsoft Component Object Model (COM) is a platform independent, distributed,
object oriented system for creating binary software components that can interact. COM is the
foundation technology for Microsoft’s OLE (Compound documents), Active X (Internet
enabled components), as well as other.
COM is not an object oriented programming language but a standard, nor does COM specify
how an application should be structured, language, structure and implementation details are
left to the application developer.

COM is a software architecture that allows applications and systems to be built from the
components supplied by different software vendors. It is a set of binary and network
standards that allows any software to communicate with each other regardless of the
hardware, the operating system, and programming language used for development. COM is
not a Programming language but a specification that defines how components can
communicate with each other. COM is a local component object model on one single
machine.
In a component based system, components interact with each other by calling methods and
passing data. COM ensures that there is a standard method of interaction between the
components. All the COM objects need to follow these standards when providing the
functionality. Standards are as important to component architecture as they are to any system
with interchangeable parts. For example, the signal that a television or radio receives is
specified in a standards. Without standards, nothing will function together.
2.5 COM Principles
 COM specifies an object model and programming requirements that enable COM
objects (also called COM components or sometimes simply objects) to interact with
other objects.
 These objects can be within a single process, in other processes on one single
machine .
 COM is referred to as binary standard, a standard that applies after a program has
been translated to binary machine code.
2.5.1 How COM Object Are Made Up Off?
 COM defines the essential nature of COM object. In general, a software object is
made up of set of data and the functions that manipulate the data.
 A COM object is one in which access to objects data is achieved exclusively
through one or more sets of related functions.
 These functions sets are called Interface, and the functions of a interface are called
methods.
 COM object are exposed through a set of interface that represent the only point of
contact between client and object.

COM defines a binary structure for the interface between the client and the object.
2.6 DCOM
Distributed Component Object Model (DCOM) is a proprietary Microsoft technology for
communication among software components distributed across networked computers.
DCOM, which originally was “Network OLE” extends Microsoft’s COM and provides the
communication substrate under Microsoft COM+ application server structure.
The addition of the “D” to COM was due to extensive use of DCE/RPC (Distributed
Computing Environment/ Remote Procedure Calls) more specifically enhanced version
known as MSRPC. DCOM is a distributed component object model working across several
machines
2.6.1 Problems Solved By DCOM
DCOM had solved the problems of:-
 Marshalling – Serialising and deserialising the arguments and return values of method
calls “Over the Wire”.
 Distributed garbage collection – Ensuring that references held by clients of interfaces
are released when for example, the client process crashed, or the network connection
was lost.
The use of DCE/RPC as the underlying RPC mechanism behind COM is the key factor
solving these problems which has strictly defined rules regarding marshalling and who is
responsible for freeing memory.

CHAPTER -4
SERVICE ORIENTED ARCHITECTURE

4.1 Evolution of SOA
Evolution is the nature’s law. Just like Human beings who evolved from Primate to Modern
age Humans just to adapt the moving environment and competitions, Programming style or
we can say technique also evolved to overcome the challenges in the changing programming
world.
4.1.1 Procedural Programming
Initially programmers used this approach for developing applications where Functions were
everything.
In this approach Functionalities will be encapsulated inside one or more functions, which can
call each other, pass some parameters and get some return value. Here one of the functions
will be made as entry point (like in C programming we had main method).The biggest
challenges with this approach were.
 How to reuse the same code?
 Difficulties in code Management
4.1.1 Object oriented Programming
To overcome the problems in the Procedural programming, object oriented era comes into the
picture where people start talking in terms of objects and classes. Everything is treated and
considered as real world objects created from the blue print that is class. Lots of Object
oriented principles like Abstraction, Encapsulation, Inheritance, polymorphism and solid has
been introduced are introduced in this era.OOP increased the reusability and thus improved
the code management. But one thing which was not addressed here was how two or more
applications will communicate each other, especially when they have been written using
different languages or technologies. For instance inventory module which is written using
Java will not be able to call function inside classes of accounting module written in .NET.
4.1.2 Service oriented Programming
Service oriented Programming progressed from objects in OOP(Object Oriented
Programming) to services in Service Oriented Programming which is implemented using
architectural style named Service Oriented Architecture(i.e. SOA). In SOA functions and
tasks are created as loosely connected independent services communicating via
messages. Service provider publishes the service via standard interfaces in a publicly

accessible directory called Service Repository and Service consumer make a service request
and in response gets the Service Response.
4.2 SOA DEFINITION
SOA or Service oriented architecture is an architecture style for building business
applications by means of services. Application comprises collection of services which
communicate through messages.
4.2.1 Service
 Services are logical encapsulation of self-contained business functionality
 Every Service encapsulates one action such as Register User, Send Email etc.
4.2.2 Messages
Services communicate with each other using SOAP messages. Messages are standard formats
which everyone (every service) can read and understand.
4.3 Characteristics of SOA
 In SOA, Services should be independent of other services. Altering a service should not
affect calling service.
 Services should be self-contained. When we talk about a Register Consumer service it
means, service will do all the necessary work for us, we are not required to care about
anything.
 Services should be able to define themselves. Services should be able to answer a question
what is does? It should be able to tell client what all operations it does, what all data types it
uses and what kind of responses it will return.
 Services should be published into a location (directory) where anyone can search for it.
 SOA comprises of collection services which communicate via standard Messages.
Standard messages make them platform independent. (Here standard doesn’t mean standard
across Microsoft it means across all programming languages and technologies.)

 Services should be able to communicate with each other asynchronously.
 Services should support reliable messaging. Means there should be a guarantee that request
will be reached to correct destination and correct response will be obtained.
 Services should support secure communication.
4.3 SOA registry
SOA Registry and repository is something that has to keep track of all the available business
services that you created to represent your most important business processes. All those
reusable components have to be recorded somewhere, and that somewhere is the SOA
registry. SOA registry as a kind of electronic catalogue where you store information
describing what each component does. It has two roles:
1. One rooted in the operational environment
2. One rooted in the world of programmers and business analysts
In the operational environment, the SOA registry provides reference information about
software components that are running or available for use. This information is of particular
importance to the service broker — the software in a SOA framework that brings components
together by using the rules associated with each component. For programmers and business
analysts, on the other hand, the SOA registry acts as a reference that helps them select
components and then connect them to create composite applications that represent business
processes. It also stores information about how each component connects to other
components. In other words, the SOA registry documents the rules and descriptions
associated with every given component. The SOA registry is extremely important because it
acts as the central reference point within service oriented architecture. The SOA registry
contains information (metadata) about all the components that the SOA supports. For that
reason, it defines the domain of the architecture. The SOA registry is where you store
definitions and other information about your software components so that developers,
business analysts, and even your customers and business partners can find the services they
need. Business services are published in a registry to make them easier to find and use. The
idea of publishing Web services is critical to SOA. You can only reuse services that are
available for reuse, which means they have to be published first. Comparatively, the
repository is like a central reference point within the software development environment. It
stores the source code and the linking information used to build all the programs that run in
the operational environment. The SOA
 1. Repository: Central reference point for all the components within the software
development environment from which services are built

 2. Registry: Central reference point for definitions, rules, and descriptions associated
with every service within a SOA environment.
4.3 Terminologies used in SOA
 Services
 A service is a unit of functionality exposed to the world. In that respect, it is the next
evolutionary step in the long journey from functions to objects to components to
services.
 Service orientation (SO) is an abstract set of principles and best practices for building
service- oriented applications provides a concise overview and outlines The
motivation for using this methodology. The rest of this book assumes you are familiar
with these principles. A service-oriented application aggregates services into a single
logical application, similar to the way a component-oriented application aggregates
Components and an object-oriented application aggregate objects. The services can be
local or remote; can be developed by multiple parties using any Technology, can be
versioned independently, and can even execute on different timelines. Inside a
service, you will find concepts such as languages, technologies, platforms, Versions,
and frameworks, yet between services, only prescribed communication patterns are
allowed.
 The client of a service is merely the party consuming its functionality. The client can
be literally anything—for instance, a Windows Forms, WPF, or Silver light class,
anASP.NET page, or another service. Clients and services interact by sending and
receiving messages. Messages may be transferred directly from the client to the
service or be sent via an intermediary such as the Windows Azure App Fabric Service
Bus. With WCF, messages are usually SOAP messages. These messages are
independent of transport protocols—unlike web services, WCF services may
communicate over a variety of transports (not just HTTP).WCF clients may
interoperate with non-WCF services, and WCF services can interact with non-WCF
clients. That said, if you develop both the client and the service, you can typically
construct the application so that both ends require WCF in order to utilize WCF-
specific advantages.
 Because the making of the service is opaque from the outside, a WCF service
typically exposes metadata describing the available functionality and possible ways of
communicating with the service. The metadata is published in a predefined,
technology-neutral way, such as using WSDL (Web Services Description Language)
over HTTP-GET or an industry standard for metadata exchange over any protocol. A

non-WCF client can import the metadata to its native environment as native types.
Similarly, a WCF client can import the metadata of a non-WCF service and consume
it as native CLR classes and interfaces.
4.4 WORKING OF SOA

CHAPTER -5
WCF (WINDOWS
COMMUNICATION FOUNDATION)

5.1 Introduction of WCF (Windows Communication Foundation)
Windows Communication Foundation (WCF) is a framework for building service-oriented
applications. Using WCF, you can send data as asynchronous messages from one service
endpoint to another. A service endpoint can be part of a continuously available service hosted
by IIS, or it can be a service hosted in an application. An endpoint can be a client of a service
that requests data from a service endpoint. The messages can be as simple as a single
character or word sent as XML, or as complex as a stream of binary data.WCF enables us to
create service oriented applications. The services have the general advantage of being
loosely-coupled instead of hard-coded from one application to another. A loosely-coupled
relationship implies that any client created on any platform can connect to any service as long
as the essential contracts are met.SOA(Service Oriented Architecture) is implemented using
WCF(Windows Communication Foundation)
.
.
5.2 Features of WCF
 Interoperability
WCF implements modern industry standards for Web service interoperability.
 Multiple Message Patterns
Messages are exchanged in one of several patterns. The most common pattern is the
request/reply pattern, where one endpoint requests data from a second endpoint. The
second endpoint replies. There are other patterns such as a one-way message in which
a single endpoint sends a message without any expectation of a reply. A more
complex pattern is the duplex exchange pattern where two endpoints establish a
connection and send data back and forth, similar to an instant messaging program.
 Service Metadata
WCF supports publishing service metadata using formats specified in industry
standards such as WSDL, XML Schema and WS-Policy. This metadata can be used to
automatically generate and configure clients for accessing WCF services. Metadata
can be published over HTTP and HTTPS or using the Web Service Metadata
Exchange standard.
 Data Contracts
Because WCF is built using the .NET Framework, it also includes code-friendly
methods of supplying the contracts you want to enforce. One of the universal types of
contracts is the data contract. In essence, as you code your service using Visual C# or
Visual Basic, the easiest way to handle data is by creating classes that represent a data
entity with properties that belong to the data entity. WCF includes a comprehensive
system for working with data in this easy manner. Once you have created the classes
that represent data, your service automatically generates the metadata that allows
clients to comply with the data types you have designed.
 Security
Messages can be encrypted to protect privacy and you can require users to
authenticate themselves before being allowed to receive messages. Security can be
implemented using well-known standards such as SSL or WS-Secure Conversation.
 Multiple Transports and Encodings
Messages can be sent on any of several built-in transport protocols and encodings.
The most common protocol and encoding is to send text encoded SOAP messages

using is the Hyper Text Transfer Protocol (HTTP) for use on the World Wide Web.
Alternatively, WCF allows you to send messages over TCP, named pipes, or MSMQ.
These messages can be encoded as text or using an optimized binary format. Binary
data can be sent efficiently using the MTOM standard. If none of the provided
transports or encodings suit your needs you can create your own custom transport or
encoding.
 Reliable and Queued Messages
WCF supports reliable message exchange using reliable sessions implemented over
WS-Reliable Messaging and using MSMQ.
 Durable Messages
A durable message is one that is never lost due to a disruption in the communication.
The messages in a durable message pattern are always saved to a database. If a
disruption occurs, the database allows you to resume the message exchange when the
connection is restored. You can also create a durable message using the Windows
Workflow Foundation (WF).
 Transactions
WCF also supports transactions using one of three transaction models: WS-Atomic
Transactions, the APIs in the System. Transactions namespace, and Microsoft
Distributed Transaction Coordinator.
 AJAX and REST Support
REST is an example of an evolving Web 2.0 technology. WCF can be configured to
process "plain" XML data that is not wrapped in a SOAP envelope. WCF can also be
extended to support specific XML formats, such as ATOM (a popular RSS standard),
and even non-XML formats, such as JavaScript Object Notation (JSON).
 Extensibility
The WCF architecture has a number of extensibility points. If extra capability is
required, there are a number of entry points that allow you to customize the behaviour
of a service.
5.3 Basic Infrastructure of WCF services.
The term WCF Services describes a standardized way of integrating service based
applications using XML, SOAP (Simple Object Access Protocol), WSDL(web service
description language) and UDDI open standard over an internet protocol backbone. These
facilities allow the integration of system written in different languages and running on
different computers in different platforms. A WCF service is a standalone software
component that has a unique URI (Uniform Resource Identifier is a unique address) and that
operates over networked computers. The basic premise is WCF service has 2 major softwares
a. Service Provider
b. Service Consumer or users

5.4 Description of Implementation of SOA Using WCF
Software Development is subject to a constant process of change. In the meantime Web-
services, distributed applications or access to remote services are already the standard. Side
by side with these techniques their demands rise significantly. Defined support for security
issues, coordination of transactions and reliable communications are expected. Windows
Communication Foundation (WCF) - as a part of the present and succeeding .NET
Framework - by Microsoft Corporation supports these requirements in line with wide range
interoperability. WCF.NET provides the development of distributed and interconnected
software applications by a service-oriented programming model.
5.4.1 Message Exchange Patterns
WCF offers various ways to exchange messages between client and service. These operation
types are often referred to as Message Exchange Patterns (MEPs). In general, the type of
operation used to communicate with the service is part of the service; a certain MEP may
even place some constraints on the allowed bindings as not every WCF binding actually
supports all available MEPs [1].
A.Request-Reply
Request-Reply is WCF‟s default operation mode. Using this MEP, the client issues a call to
the service in the form of a message and blocks until it gets a reply. If the service does not
respond within the specified timeframe, the client will get a „Timeout-Exception‟. Using

request-reply operations is very simple and resembles programming using the classic
client/server model [1].
B. One-Way
In case an operation has no return value and the client does not care about success or failure
of the call, WCF offers one-way operations to support this kind of „fire-and-forget‟
invocation. Contrary to request-reply calls, one-way calls usually block the client only for the
briefest moment required to dispatch the call. As only a request message but no reply
message is generated by WCF, values (as well as exceptions thrown on the service side) can't
be returned to the client [1].
C. Call-back / Duplex
Using duplex communication (or call-backs) WCF allows a service to call back to its clients
and invoke a client method. Call-back operations are especially useful when it comes to
events and notifying the client that some event has happened on the service side. However, in
order to enable the service to call back to the client, it has to know the clients endpoint.
Therefore, it is necessary for the client to call a service method (see Fig. 1/step 1) first, which
saves the call-back channel to the clients endpoint for later use (see Fig. 1/step 2). Through
that channel it is possible for the service to send messages to the client and invoke certain
methods [1].
Fig. 1: Base schema of call-back /duplex communication [3]
D. Streaming
When client and service exchange messages, they are buffered on the receiving side and
delivered only once the entire message has been received. This means, that the client is
unblocked only if the request message and the services reply message have been sent and
received in its entirety. This works well for small messages.

However, when it comes to larger messages (e.g. multimedia content) blocking until the
entire message has been received may be impractical. Therefore, WCF enables the receiving
side to start processing the receiving data while the message is still being received. This type
of operation is called streaming transfer mode and improves throughput and responsiveness
with large payloads [1].
E. Asynchronous Calls
Using asynchronous calls the client will not block and control returns immediately after the
request has been issued. The service then executes the operation in the background. As soon
as the operation completed execution the client is provided with the results of the execution.
Asynchronous calls improve client responsiveness and availability [1].
F. Queued Calls
Queued messages use Microsoft Message Queue (MSMQ). WCF encapsulates each SOAP
message in an MSMQ message and posts it to the designated queue. Thus, the client does not
communicate directly with a certain service but with a message queue. As a result, all calls
are inherently asynchronous and disconnected. On the service side, queued messages are
detected by the queues listener, which sequentially takes messages from the queue and
dispatches it to a service instance [1]
5.5 Technologies Used For Implementing WCF
WCF is a software development kit for developing and deploying services on Windows. But
WCF is much more—it is literally a better .NET. WCF provides a runtime environment for
your services, enabling you to expose Common Language Runtime (CLR) types as services
and to consume other services as CLR types. Although in theory services can be built without
WCF, in practice, building services is significantly easier with WCF. WCF is Microsoft’s
implementation of a set of industry standards defining service interactions, type conversions,
marshalling, and the management of various protocols. Consequently, WCF provides
interoperability between services.WCF provides developers with the essential off-the-shelf
plumbing required by almost all applications and, as such, it greatly increases productivity.
The first release of WCF(as part of .NET 3.0) provided many useful facilities for developing
services, such as hosting, service instance management, asynchronous calls, reliability,
transaction management, disconnected queued calls, and security. The second release of
WCF (as part of .NET 3.5) provided additional tools and extended the original offering with

additional communication options. The third release (as part of .NET 4.0) includes
configuration changes, a few extensions, and the new features of discovery.
5.6 HOSTING WCF SERVICES
o SELF hosting
 In order to run and access a WCF service it needs to be hosted in an appropriate
environment. Such an environment consists of a process in which the service itself is
running. The only requirement for the host is to support .NET application domains.
For this reason the following four common hosting methods are to be considered:
Managed .NET applications, Windows Services, Internet Information Services (IIS)
and Windows Activation Services (WAS). Hosting in any custom application type is
possible as long as it supports application domains. Each of these types can be
classified to one of two categories: Self-Hosted and Hosted.
 A type of host, which the developer has to write on his own is considered a self-
hosted environment. As it has to be written completely by the developer himself,
these hosts do not contain any manageability features by default. However, this
approach offers full control over the hosted service and its life cycle.
 Hosted environments – contrary to self-hosted environments – are prefabricated hosts
that do not need to be developed and already contain several management features. As
these pre-existing hosts handle the service in their own way the developer only has
limited influence on the service’s life cycle while hosted in this type of host [2].
 Each of these hosting environments has certain advantages and disadvantages. Thus,
they are not suitable for every application area. In a service-oriented architecture the
right host is essential for service robustness. When choosing a hosting environment, it
is important to identify the type of service and its availability demands. As the service
implementation in WCF is platform agnostic it can easily be ported from one host to
another.
 Over the next sections each of WCF‟s standard hosting environments is introduced.
o IIS
WCF services can also be hosted using Microsoft’s Internet Information Services (IIS)
version 5.1 or higher. As IIS is primarily used as web server it only supports HTTP as
transport protocol for WCF services. However, IIS 7.0 already includes Windows Activation
Services (WAS) which enables support for all WCF protocols. IIS is categorized as a hosted
environment and therefore controls each WCF services instantiation. This can only be

influenced by a custom Factory written by the developer. The huge advantage of IIS lies in its
many management features like process health monitoring, idle shutdown, process recycling,
resource throttling and logging. It offers the same functionality for WCF services as for
ASP.NET applications. Since IIS is a complete, stable environment no additional
development effort is necessary. Everything is done solely by configuration. In comparison to
managed applications and Windows Services, IIS uses automatic, message-based activation.
It is important to know that many of its features as well as its activation mechanism can also
cause unexpected behaviour compared to other hosting methods [2].
o WAS (Windows process activation services)
Windows Activation Services (WAS) features all advantages of IIS. Although it is part of IIS
7.0, it can be installed, configured and operated independently. WAS also uses message-
based activation for services but contrary to IIS, WAS supports all available transport
protocols of WCF, including HTTP, TCP, MSMQ and Pipe. For that purpose it installs
listener adapters for each protocol. WAS is only available on Windows Vista and Windows
Server 2008 or higher [2].
o Windows services
A Windows Service is maintained by the operating system's Service Control Manager
(SCM). Although the developer has to write the Windows Service which in turn hosts the
WCF service, this Windows Service itself is hosted and maintained by the SCM. This allows
the developer to have full control over the life time of the WCF service as it has to be
explicitly opened and closed by the code. Windows Services are easy to develop but do not
provide any graphical user interface. This type of host is ideal for long-running services as
they are continuously monitored by the SCM of Windows. It offers limited support for
features like auto-start on system boot and recovery in case of an error. This makes the
service available as soon as the computer starts, regardless of whether a user is logged in or
not. Furthermore, it allows each service to have its own account and security permission.
Windows Services are easy to maintain by administrators as they often do already have
knowledge about how to configure them. Nonetheless, installation software is necessary to
install a service on the system [2].
 WS-DISCOVERY
In order to access a service, it is necessary for the client to know its address. One possibility
would be to include all relevant service addresses in the clients code or configuration files.

However, as this approach results in a tight coupling between service and client, it is often
either not desired or simply not suitable for the client's application area. Therefore, methods
exist which allow the client to dynamically locate the desired service and its address.
Message transmission - Messages can be transmitted between clients and service via various
transport protocols and encodings such as SOAP using http and binary data using TCP.
 Serialization - Web services uses Xml Serializer for transferring data between service calls
whereas WCF supports multiple Serializers
o DataContractSerializer(faster and supports versioning)
o NetDataContractSerializer(when it required to include CLR type information in the serialized
XML)
o XmlSerializes(mostly to support backward compatibility).
 Multiple technologies at one place - WCF unites following four technologies
 .NET remoting
 MSMQ
 Web Services.
 COM+
 Message Contract - In Web services customizing the headers of the SOAP message was a
tedious task. For that we were supposed to derive a class from SoapHeader and then
SoapHeaderAttribute is used to indicate the presence of the header.
But with WCF we can make it easily with the help of simple attributes like
MessageContractAttribute, MessageHeaderAttribute, and MessageBodyMemberAttribute.
 Multiple Message Patterns - WCF supports three message patterns that describe how client
and service pass messages
o Request-Reply Pattern – Client sends message to service and waits for reply.
o One-Way Message Pattern – Client sends message to service but service does not reply
message to client.
o Duplex pattern – Both client and the service can initiate communication. The client calls a
method of the service. The service can then use a client callback to call a method in the client.
 Security - In WCF security can be implemented with the help of well-known standards such
as SSL.
 Reliable - WCF supports reliable messages with the help of Queues and reliable sessions.
 REST - WCF can be extended to support plain xml data that is not wrapped in a soap
envelope, xml formats such as ATOM and non xml standard such as JSON.
 WCF Transaction - - WCF supports to create distributed transactions for your service
application. Transaction is a collection of logical operations which need to be run as a single

logical unit. (Either all operations will successfully execute and completes or in case any of
them fail others will rollback).
 WCF instancing - In WCF we can control the way WCF service objects are instantiated in
the WCF server. WCF Framework comes up with following instancing models
o Per Call - A new instance will be created for every client request.
o Per session - A new instance is created for each new client session and maintained for the
lifetime of that session.
o Single - A single instance handles all client requests for the lifetime of the application.
 WCF Concurrency - With WCF Concurrency features we can control how service instances
can serve multiple requests at the same time. We have three choices
o Single – Only one request will be served at a time.
o Multiple - Multiple requests can be handled by the WCF service object at any given moment
of time.
o Re-entrant - A single request thread has access to the WCF service object, but the thread can
exit the WCF service to call another WCF service or can also call a WCF client through call-
back and renter without deadlock.
5.6 ABC in WCF
ABC or Address, Binding and Contract are the three elements which constitutes and Service
Endpoint.
 Address - Where Service is residing (URL of the service.)
 Binding – How to talk to the service?
Example – basicHttpBinding, wsHttpBinding, webHttpBinding etc.
 Contract – What can the service do for me?

CHAPTER -6
COMMUNICATION PROTOCOLS

6.1 INTRODUCTION TO SOAP
SOAP originally stood for "Simple Object Access Protocol". SOAP is a lightweight protocol
intended for exchanging structured information in a decentralized, distributed environment.
SOAP uses XML technologies to define an extensible messaging framework, which provides
a message construct that can be exchanged over a variety of underlying protocols. The
framework has been designed to be independent of any particular programming model and
other implementation specific semantics.
SOAP defines a way to move XML messages from point A to point B (see Figure 1). It does
this by providing an XML-based messaging framework that is 1) extensible, 2) usable over a
variety of underlying networking protocols, and 3) independent of programming models
Any Communication Protocol
Figure-6.1 Simple Soap Messaging
6.3 SOAP VERSIONS
Table 6.1 SOAP Version Information
SOAP 1.1
Namespace Name http://schemas.xmlsoap.org/soap/envelope/
SpecLocation http://www.w3.org/TR/SOAP/
SOAP 1.2
SOAP
SENDE
R
SOAP
RECEIVER
A B
SOAPMESSAGE

Namespace Name http://www.w3.org/2002/12/soap-envelope
SpecLocation http://www.w3.org/TR/soap12-part0/ (Primer)
http://www.w3.org/TR/soap12-part1/
http://www.w3.org/TR/soap12-part2/
6.4 Messaging Framework
The core section of the SOAP specification is the messaging framework. The SOAP
messaging framework defines a suite of XML elements for "packaging" arbitrary XML
messages for transport between systems. The framework consists of the following core XML
elements: Envelope, Header, Body, and Fault, all of which are from
the http://schemas.xmlsoap.org/soap/envelope/namespace in SOAP 1.1. I've provided the
full XML Schema definition for SOAP 1.1
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://schemas.xmlsoap.org/soap/envelope/"
targetNamespace="http://schemas.xmlsoap.org/soap/envelope/" >

<xs:element name="Envelope" type="tns:Envelope" />
<xs:complexType name="Envelope" >
<xs:sequence>
<xs:element ref="tns:Header" minOccurs="0" />
<xs:element ref="tns:Body" minOccurs="1" />
<xs:any namespace="##other" minOccurs="0"
maxOccurs="unbounded" processContents="lax" />
</xs:sequence>
<xs:anyAttribute namespace="##other"
processContents="lax" />
</xs:complexType>
<xs:element name="Header" type="tns:Header" />
<xs:complexType name="Header" >
<xs:sequence>
<xs:any namespace="##other" minOccurs="0"
</xs:sequence>
<xs:anyAttribute namespace="##other"
</xs:complexType>
<xs:element name="Body" type="tns:Body" />
<xs:complexType name="Body" >
<xs:sequence>
<xs:any namespace="##any" minOccurs="0"

</xs:sequence>
<xs:anyAttribute namespace="##any"
</xs:complexType>

<xs:attribute name="mustUnderstand" default="0" >
<xs:simpleType>
<xs:restriction base='xs:boolean'>
<xs:pattern value='0|1' />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="actor" type="xs:anyURI" />
<xs:simpleType name="encodingStyle" >
<xs:list itemType="xs:anyURI" />
</xs:simpleType>
<xs:attribute name="encodingStyle"
type="tns:encodingStyle" />
<xs:attributeGroup name="encodingStyle" >
<xs:attribute ref="tns:encodingStyle" />
</xs:attributeGroup>
<xs:element name="Fault" type="tns:Fault" />
<xs:complexType name="Fault" final="extension" >
<xs:sequence>
<xs:element name="faultcode" type="xs:QName" />
<xs:element name="faultstring" type="xs:string" />
<xs:element name="faultactor" type="xs:anyURI"
minOccurs="0" />
<xs:element name="detail" type="tns:detail"
minOccurs="0" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="detail">
<xs:sequence>
<xs:any namespace="##any" minOccurs="0"
</xs:sequence>
<xs:anyAttribute namespace="##any"
</xs:complexType>
</xs:schema

Table 6. 2. SOAP 1.1 Fault Codes
Name Meaning
Version
Mismatch
The processing party found an invalid namespace for the SOAP Envelope element.
Must
Understand
An immediate child element of the SOAP Header element that was either not understood or no
SOAP mustUnderstand attribute with a value of "1".
Client The Client class of errors indicates that the message was incorrectly formed or did not contain
the appropriate information in order to succeed. It is generally an indication that the message
should not be resent without change.
Server The Server class of errors indicates that the message could not be processed for reasons not
directly attributable to the contents of the message, but rather to the processing of the
message. For example, processing could include communicating with an upstream processor,
succeed if re-sent at a later point in time.
6.5 Processing Model
SOAP defines a processing model that outlines rules for processing a SOAP message as it
travels from a SOAP sender to a SOAP receiver. Figure 1 illustrates the simplest SOAP
messaging scenario, where there's one application (SOAP sender) sending a SOAP message
to another application (SOAP receiver).The processing model, however, allows for more
interesting architectures like the one in Figure6.3 3, which contains
multiple intermediary nodes.

Figure 6. 3 Sophisticated SOAP messaging
6.6 Protocol Bindings
SOAP messaging framework is independent of the underlying protocol, each intermediary
could choose to use a different communications protocol without affecting the SOAP
message. Standard protocol bindings are necessary, however, to ensure high levels of
interoperability across SOAP applications and infrastructure.
A concrete protocol binding defines exactly how SOAP messages should be transmitted with
a given protocol. In other words, it defines the details of how SOAP fits within the scope of
another protocol, which probably has a messaging framework of its own along with a variety
of headers. What the protocol binding actually defines depends a great deal on the protocol's
capabilities and options. For example, a protocol binding for TCP would look much different
than one for MSMQ or another for SMTP.
The SOAP 1.1 specification only codifies a protocol binding for HTTP, due to its wide use.
SOAP has been used with protocols other than HTTP but the implementations weren't
following a standardized binding. There's nothing wrong with forging ahead without standard
protocol bindings in place as long as the interoperability issues once you try to integrate with
other SOAP implementations using the same protocol.
6.6.1 HTTP Binding
The HTTP protocol binding defines the rules for using SOAP over HTTP. SOAP
request/response maps naturally to the HTTP request/response model. Figure 6. 4 illustrates
many of the SOAP HTTP binding details.

Figure 6.4 SOAP HTTP binding
The Content-Type header for both HTTP request and response messages must be set
to text/xml (application/soap+xml in SOAP 1.2). As for the request message, it must
usePOST for the verb and the URI should identify the SOAP processor. The SOAP
specification also defines a new HTTP header called SOAPAction, which must be present in
all SOAP HTTP requests (even if empty). The SOAPAction header is meant to express the
intent of the message. As for the HTTP response, it should use a 200 status code if no errors
occurred or 500 if the body contains a SOAP Fault.
6.6.2 RPC and Encoding
Although the SOAP specification has evolved away from objects, it still defines a convention
for encapsulating and exchanging RPC calls using the messaging framework described
above. Defining a standard way to map RPC calls to SOAP messages makes it possible for
infrastructure to automatically translate between method invocations and SOAP messages at
runtime, without redesigning the code around the Web services platform.
To make a method call using SOAP, the infrastructure needs the following information:
1. Endpoint location (URI)
2. Method name
3. Parameter names/values
4. Optional method signature
5. Optional header data

Chapter -7
WSDL(WEB SERVICE DESCRIPTION
LANGUAGE)

7.1 Overview
XML makes it possible for developers to expose valuable resources in a highly interoperable
fashion, where a resource is any type of application or data store used within an organization.
The XML Web services architecture defines a standard mechanism for making resources
available via XML messaging. Being able to access a resource by simply transmitting XML
messages over standard protocols like TCP, HTTP, or SMTP greatly lowers the bar for
potential consumers. The term "Web service" (or simply "service") typically refers to the
piece of code implementing the XML interface to a resource, which may otherwise be
difficult to access (see Figure 1).
Figure 7. 1: Resources and services
7.2 Messages and Operations
A message exchange is also referred to as an operation. Operations are what consumers care
about most since they're the focal point of interacting with the service (see Figure 7.2).
Whenever a new WCF service is developed, it first inspect the list of supported operations to
get an overall feel for what it offers. This architecture makes it possible for any consumer
with XML support to integrate with WCF service applications. However, in order to
accomplish this, consumers must determine the precise XML interface along with other
miscellaneous message details. XML Schema can partially fill this need because it allows
developers to describe the structure of XML messages. XML Schema alone, however, can't
describe the additional details involved in communicating with a Web service.
A schema definition simply tells what XML messages may be used but not how they relate to
each other. Hence, in addition to being aware of the messages, consumers must also be aware
of the possible message exchanges supported by the Web.

Figure 2: Messages and operations
7.3 Interfaces and Bindings
. A binding specifies the concrete details of what goes on the wire by outlining how to use an
interface with a particular communication protocol. A binding also influences the way
abstract messages are encoded on the wire by specifying the style of service (document vs.
RPC) and the encoding mechanism (literal vs. encoded). Check out Understanding SOAP for
more background on these concepts.
A service can support multiple bindings for a given interface, but each binding should be
accessible at a unique address identified by a URI, also referred to as a Web service endpoint
(see Figure 7.3).
It's common for developers to group related operations into interfaces. Consumers must be
aware of these groupings since it impacts the way they write their code. This is especially
important to developers working with WCF services in object-oriented environments since
the XML interfaces can map to programmatic interfaces (or abstract classes) in their language
of choice.Consumers must also know what communication protocol to use for sending
messages to the service, along with the specific mechanics involved in using the given
protocol such as the use of commands, headers, and error codes

Figure7. 3: Interfaces and bindings
7.4 WCF Basic Profile
Consumers must discover all of the details described above before they can interact with a
Web service. The Web Services Description Language (WSDL) provides an XML grammar
for describing these details. WSDL picks up where XML Schema left off by providing a way
to group messages into operations and operations into interfaces. It also provides a way to
define bindings for each interface and protocol combination along with the endpoint address
for each one. A complete WSDL definition contains all of the information necessary to
invoke a Wcf service. Developers that want to make it easy for others to access their services
should make WSDL definitions available.
WSDL plays an important role in the overall Web services architecture since it describes the
complete contract for application communication (similar to the role of IDL in the DCOM
architecture). Although other techniques exist for describing Web services, the WS-I Basic
Profile Version 1.0 mandates the use of WSDL and XML Schema (see Figure7. 4) for
describing Web services. This helps ensure interoperability at the service description layer.

Figure 4: WS-I Basic Profile 1.0 technologies
Since WSDL is a machine-readable language (e.g., it's just an XML file), tools and
infrastructure can be easily built around it. WSDL definitions to generate code that knows
precisely how to interact with the WCF service it describes. This type of code generation
hides the tedious details involved in sending and receiving SOAP messages over different
protocols and makes Web services approachable by the masses.
The Microsoft® .NET Framework comes with a command-line utility named wsdl.exe that
generates classes from WSDL definitions. Wsdl.exe can generate one class for consuming the
service and another for implementing the service. (Apache Axis comes with a similar utility
named WSDL2Java that performs the same function for Java classes.) Classes generated
from the same WSDL definition should be able to communicate with each other through the
WSDL-provided interfaces, regardless of the programming languages in use (see Figure 7. 5).
Figure7. 5: WSDL and code generation
WSDL 1.1 is considered the de-facto standard today because of it's industry-wide support.
Most Web services toolkits support WSDL 1.1, but there have been some interoperability
problems across the different implementations. Many developers believe that the extensive
flexibility of WSDL (and the resulting complexity) is the fundamental source of these
problems. The WS-I has helped resolve some of these issues by encouraging developers to
use certain parts of the specification and discouraging them from using others.
The W3C is actively working on the next "official" version of WSDL, WSDL 1.2, but it's
currently only a Working Draft and not supported by the mainstream toolkits, if any

7.6 WSDL Basics
A WSDL definition is an XML document with a root definition element from the
http://schemas.xmlsoap.org/wsdl/ namespace. The entire WSDL schema is available
athttp://schemas.xmlsoap.org/wsdl/ for reference. The definitions element may contain
several other elements including types, message, portType, binding, and service, all of which
come from the http://schemas.xmlsoap.org/wsdl/ namespace. The following illustrates the
basic structure of a WSDL definition:

<definitions
name="YourServiceNmae"
targetNamespace="http://yuor targetnamespac.org/math/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
>

<types> ...
<message> ...
<portType> ...

<binding> ...
<service> ...
</definition>
Specify a target namespace for your WSDL definition, just like you would for an XML
Schema definition. Anything named in the WSDL definition (like a message, portType,
binding, etc.) automatically becomes part of the WSDL definition's target namespace defined
by the targetNamespace attribute. Hence, when something is referenced by name in your
WSDL file, remember to use a qualified name.
The first three elements (types, message, and portType) are all abstract definitions of the
WCF service interface. These elements constitute the programmatic interface that you
typically interface with in your code. The last two elements (binding and service) describe
the concrete details of how the abstract interface maps to messages on the wire. These details
are typically handled by the underlying infrastructure, not by your application code. Table 7.1
provides brief definitions for each of these core WSDL elements and the remaining sections
discuss them in more detail.
Table 7.1 WSDL Elements
Element
Name
Description
types A container for abstract type definitions defined using XML Schema

message A definition of an abstract message that may consist of multiple parts, each part may be of a
different type
portType An abstract set of operations supported by one or more endpoints (commonly known as an
interface); operations are defined by an exchange of messages
binding A concrete protocol and data format specification for a particular portType
service A collection of related endpoints, where an endpoint is defined as a combination of a binding
an address (URI)
7.6.1 Types
The WSDL types element is a container for XML Schema type definitions. The type
definitions you place here are referenced from higher-level message definitions in order to
define the structural details of the message. Officially, WSDL 1.1 allows the use of any type
definition language, although it strongly encourages the use of XML Schema and treats it as
its intrinsic type system. The WS-I enforces this by mandating the use of XML Schema in the
Basic Profile 1.0.
The types element contains zero or more schema elements from the
http://www.w3.org/2001/XMLSchema namespace. The basic structure of the types element
(with namespaces omitted) is as follows (* means zero or more):
<definitions .... >
<types>
<xsd:schema .... />*
</types>
</definitions>
Any XML Schema construct can be used within the schema element, such simple type
definitions, complex type definitions, and element definitions.
7.6.2 Messages
The WSDL message element defines an abstract message that can serve as the input or output
of an operation. Messages consist of one or more part elements, where each part is associated

with either an element (when using document style) or a type (when using RPC style). The
basic structure of a message definition is as follows (* means zero or more and ? means
optional):
<definitions .... >
<message name="nmtoken"> *
<part name="nmtoken" element="qname"? type="qname"?/> *
</message>
</definitions>
The messages and parts must be named making it possible to refer to them from elsewhere in
the WSDL definition. If it is RPC style service, the message parts represent the method's
parameters. In this case, the name of the part becomes the name of an element in the concrete
message and its structure is determined by the supplied type attribute. If you're defining a
document style service, the parts simply refer to the XML elements that are placed within the
body (referenced by the element attribute
Although the message parts typically refer to XML types or elements, they can also refer to
non-XML types. This allows WSDL to represent a wide range of messages that contain a
mixture of data formats, as is the case with multi-part MIME.
Note The message and type definitions in WSDL are considered to be abstract definitions.
This means you don't know how they'll appear in the concrete message format until you've
applied a binding to them. For example, if you use one abstract message with two different
bindings, it's possible that the two concrete messages will look different. Only with 'literal'
bindings are the abstract definitions guaranteed to accurately describe the concrete message
format. See the Bindings section for more details.
7.6.3 Interfaces (portTypes)
The WSDL portType element defines a group of operations, also known as an interface in
most environments. Unfortunately, the term "portType" is quite confusing so you're better off
using the term "interface" in conversation. WSDL 1.2 has already removed "portType" and
replaced it with "interface" in the current draft of the language.
A portType element contains zero or more operation elements. The basic structure of a
portType is as follows (* means zero or more):
<definitions .... >
<portType name="nmtoken">
<operation name="nmtoken" .... /> *
</portType>
</definitions>
Each portType must be given a unique name making it possible to refer to it from elsewhere
in the WSDL definition. Each operation element contains a combination
of input andoutput elements, and when you have an output element you can also have
a fault element. The order of these elements defines the message exchange pattern (MEP)
supported by the given operation.
For example, an input element followed by an output element defines a request-response
operation, while an output element followed by an input element defines a solicit-response
operation. An operation that only contains an input element defines a one-way operation,
while an operation that only contains an output element defines a notification operation.
Table 2 describes the four MEP primitives defined by WSDL.

Table 7.2 Message Exchange Patterns
MEP Description
One-way The endpoint receives a message.
Request-response The endpoint receives a message and sends a correlated messag
Solicit-response The endpoint sends a message and receives a correlated messag
Notification The endpoint sends a message.
A portType is still considered an abstract definition because you don't know how its
messages are represented on the wire until you apply a binding.
7.6.6 Bindings
The WSDL binding element describes the concrete details of using a particular portType
with a given protocol. The binding element contains several extensibility elements as well as
a WSDL operation element for each operation in the portType it's describing. The basic
structure of a binding element is as follows (* means zero or more and ? means optional):
<wsdl:definitions .... >
<wsdl:binding name="nmtoken" type="qname"> *
<-- extensibility element providing binding details --> *
<wsdl:operation name="nmtoken"> *
<-- extensibility element for operation details --> *
<wsdl:input name="nmtoken"? > ?
<-- extensibility element for body details -->
</wsdl:input>
<wsdl:output name="nmtoken"? > ?
</wsdl:output>
<wsdl:fault name="nmtoken"> *
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>

A binding must be a given a unique name so you can refer to it from elsewhere in the WSDL
definition. The binding must also specify which portType it's describing through the type
attribute. For example, the following binding is called “YourBindingName” and it describes
the concrete details for the YourInterface portType:
<definitions
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:y="http://example.org/math/"
xmlns:ns="http://example.org/math/types/"
targetNamespace="http://example.org/math/"
>
...
<binding name="YourBindingNmae" type="y:YourInterface">
... <-- extensibility element -->
<operation name=”YourInterface">
<input>
</input>
<output>
</output>
</operation>
...
</binding>
...
</definitions>
The WSDL binding element is generic. It simply defines the framework for describing
binding details. The actual binding details are provided using extensibility elements. This
architecture allows WSDL to evolve over time since any element can be used in the
predefined slots. The WSDL specification provides some binding elements for describing
SOAP bindings, although they're in a different namespace. The following example illustrates
a SOAP/HTTP binding for the YourInterface portType:
<definitions
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:y="http://example.org/math/"
xmlns:ns="http://example.org/math/types/"
targetNamespace="http://example.org/math/"
>
...
<binding name="YourBindingName" type="y:YourInterface">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="YourOperationName">
<soap:operation
soapAction="YourOperationNamespace"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
...
</binding>
...
</definitions>
The soap:binding element indicates that this is a SOAP 1.1 binding. It also indicates the
default style of service (possible values include document or rpc) along with the required
transport protocol (HTTP in this case). The soap:operation element defines
the SOAPAction HTTP header value for each operation. And the soap:body element defines
how the message parts appear inside of the SOAP Body element (possible values
include literal or encoded). There are other binding-specific details that can be specified this
way.
Using document style in SOAP indicates that the body will contain an XML document, and
that the message parts specify the XML elements that will be placed there. Using rpcstyle in
SOAP indicates that the body will contain an XML representation of a method call and that
the message parts represent the parameters to the method.
The use attribute specifies the encoding that should be used to translate the abstract message
parts into a concrete representation. In the case of 'encoded', the abstract definitions are
translated into a concrete format by applying the SOAP encoding rules. In the case of 'literal',
the abstract type definitions become the concrete definitions themselves (they're 'literal'
definitions). In this case, you can simply inspect the XML Schema type definitions to
determine the concrete message format. For example, the youroperation for the
above document/literal binding looks like this on the wire:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
>
<SOAP-ENV:Body>
<m:your operation name xmlns:m="http://example.org/math/types/">
<x>3.14159265358979</x>
<y>3.14159265358979</y>
</m:Your operation name>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Notice that the SOAP Body simply contains an instance of the Add element defined in the
schema—this is what makes document/literal so attractive. Now let's see what the message
would look like using an rpc/encoded binding. The following WSDL fragment contains a
revised rpc/encoded binding and the message definitions use type instead of element:

...
<message name="YourMessage">
<part name="parameter" type="ns:YourInput"/>
</message>
<message name="YourResponseMessage">
<part name="parameter" type="ns:YourOutput"/>
</message>
...
<binding name="yourBindingName" type="y:YourInterface">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="YourOperationName">
<soap:operation
soapAction="http://example.org/math/#Add"/>
<input>
<soap:body use="encoded"/>
</input>
<output>
<soap:body use="encoded"/>
</output>
</operation>
...
</binding>
With these definitions in place, the Add operation looks much different as you can see here:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:m0="http://example.org/math/types/"
>
<SOAP-ENV:Body>
<m:your operation xmlns:m="http://example.org/math/">
<parameter xsi:type="m0:your inputInput">
<x xsi:type="xsd:double">3.14159265358979</x>
<y xsi:type="xsd:double">3.14159265358979</y>
</parameter>
</m:your operation>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
7.6.7 WSDL Services
The WSDL service element defines a collection of ports, or endpoints, that expose a
particular binding. The basic structure of the service element is as follows:

<definitions .... >
<service .... > *
<port name="nmtoken" binding="qname"> *
<-- extensibility element defines address details -->
</port>
</service>
</definitions>
You must give each port a name and assign it a binding. Then, within the port element, you
use an extensibility element to define the address details specific to the binding. For
example,

CHAPTER -8
PROBLEMS WITH COM/DCOM
COMMUNICATION & STUXNET VIRUS

8.1 Problems with COM/DCOM Communication
The difficulties involved in getting either of COM/DCOM technology is to work over
internet firewall, and on unknown and insecure machines, meant that normal HTTP request in
combination with web browsers won out over both of them.
8.2 Problem Faced with Current OPC Server and Client Communication using
COM/DCOM Technology
OPC data client located on remote location when try to access data from OPC server through
firewall, it is not able to read or log data from OPC server because of COM/DCOM
technology and RPC/DCE network communication. Since communication is not possible
through firewall in COM/DCOM technology. Internet network of SAIL become insecure and
prone to viruses like STUXNET.
OPC CLIENT
WINDOWSPC
FIREWALL
WINDOWS PC
OPC DATA
SERVER
PLC HMI SCADA

8.3 STUXNET
STUXNET is a computer worm that was discovered in June 2010. It was designed to attack
Industrial programmable logic controllers (PLCs). It is the 1st discovered malware to include
the programmable logic controller (PLC). STUXNET virus on targeted
Iranian nuclear including Busnehr nuclear power plant or the natanz nuclear facility. It may
have shut down 100 centrifuges or gas pipelines.
8.4 Operation of STUXNET
 STUXNET functions by targeting machines using Microsoft windows operating
system and networks, then seeking out Siemens step7 software.
 The worm then propagates across the network scanning for Siemens step7 software
on computers controlling PLC.
 In the absence of PLC and SCADA software, STUXNET becomes dormant inside
the computer.
 If the PLC or SCADA software is found STUXNET introduces the infected
commands to the PLC and step7 software, modifying the codes and giving
unexpected commands to the PLC.
 It returns a loop of normal operation values to the system operations operating it
while introducing unexpected commands to the PLC.
After the malware installs in the PLC software it periodically modifies the frequency from
high to low or vice versa thus effect the normal operation of connected motors, centrifuges
and causing them to shutdown or damage the machine

9.1 Broker Based Registry Architecture
Introducing Broker based Registry Architecture using SOA(SERVICE ORIENTED
ARCHITECTURE) to consume services through firewall. Broker based Registry
Architecture Service will be having 3-softwares which communicates with each other. Broker
based Registry Architecture will be based on WCF (Windows Communication Foundation
).It uses SOAP based on XML to talk to Service Description stored in Registry and
WSDL(also based on XML) is used for describing services which provides a machine and
human readable description of how the service operates and what parameter it expects.
9.2 Implementing SOA in Broker based registry Architecture
WCF is an implementation of service oriented architecture.
1. OPC Service Provider publishes its Service Description to OPC Service Broker .OPC
Service Broker with the help of its Interface and OPC broker Service accepts service
descriptions from the provider and stores it in Service registry. All OPC Service Providers
publishes their service description and registers themselves with service broker.
2. OPC Service providers communicate to the directory using SOAP protocol in order to send
its service description written in WSDL (an XML based language).
OPC Service
Consumer
OPC Service
Provider
Broker Interface
Broker Service
Service Registry
Database
PUBLISHES
FINDS

3. OPC Service Consumers make queries against this directory to know what services are
available and how to communicate with those services using industry standard SOAP
protocol.
4.OPC Service Providers and consumers use industry standard SOAP(XML tag based
language) protocol because it is language independent ,platform independent and helps to
get around firewalls which is a major problem is OPC Server and Client Communication.
5. The Response generated by the Service Provider is also a SOAP message based on
specification defined in service description using WSDL
9.3 Augmenting above service Publication and Announcement using Broker based
registry Architecture for secure OPC Server and Client Communication
Steps
1. Design of OPC Service Broker for OPC Service Discovery and Announcement.
2. Design of OPC Service Registry /Repository to save Service Descriptions written in
WSDL (Web service Description Language).
3. Creating sockets for Discovery and Announcement Service. Sockets will be
continuing listening for announcement from OPC Providers and discovery from
OPC Data Client.
4. When announcement message is received by OPC Service Broker, announcement
service at announcement endpoint is invoked which accepts service description from
OPC Service Providers and stores it in OPC Service Repository connected to it.
5. When Discovery message or find message is by OPC Service Broker, Discovery
Proxy Service at discovery endpoint is invoked which accepts the query message and
after searching the queried service in a Repository displays appropriate results.

9.4 ABSTRACT ARCHITECTURE FOR BROKER BASED SECURE OPC SERVER
AND CLIENT COMMUNICATION
3.3.3 XML (Extensible Mark-up Language)
XML stands for Extensible Mark-up Language. It is a text-based mark-up language derived
from Standard Generalized Mark-up Language (SGML).XML tags identify the data and are
used to store and organize the data, rather than specifying how to display it like HTML tags,
which are used to display the data. XML is not going to replace HTML in the near future,
but it introduces new possibilities by adopting many successful features of HTML.
Characteristics of XML:
 XML is extensible: XML allows you to create your own self-descriptive tags, or
language, that suits your application.
 XML carries the data, does not present it: XML allows you to store the data
irrespective of how it will be presented.
 XML is a public standard: XML was developed by an organization called the
World Wide Web Consortium (W3C) and is available as an open standard.
9.4.1. OPC DATA CLIENT
OPC SERVICE
PROVIDER
UDDI (API)
OPC SERVICE
BROKER
OPC SERVICE
DATA CLIENT
OPC SERVICE
REGISTRY/REPOSITORY
ABSTRACT ARCHITECTURE FOR BROKER BASED SECURE OPC SERVER AND CLIENT
COMMUNICATION
INVOKESOR
CONSUMES
ANNOUNCESOR
REGISTERS
PUBLISH /FIND
SERVICES
STORES SERVICE
METADATA
GET SERVICE
INFORMATION

OPC Data Client is the one who wants to consume OPC Service.OPC Data client may be
located anywhere or on any location on the internal network of SAIL or on public network at
corporate offices of Delhi and Kolkata. The OPC Data Client does not have direct access to
service registry/repository and OPC service. The Data Client should communicate with the
OPC Service Broker and if the connection is successful after authentication and
authorization, client is able to search the available service stored in repository. If the service
is available Broker gives the metadata information (Address, Binding and Contract ) of the
service using which the Data Client can communicate with OPC Service Provider.
9.4.2 OPC SERVICE PROVIDER
OPC Service Provider after getting connected to Broker publishes its metadata information
enclosed in SOAP message to OPC Service Broker. Service Description or metadata
information is written in tag based language XML also called WSDL (Web service
Description language).OPC Service Broker stores published services description in service
repository connected to it.
9.4.3 UDDI
UDDI registry is normally used to search and publish services. The UDDI data entities
provide support for defining both business and service information. The service description
information defined in WSDL is complementary to the information found in UDDI Registry.
The UDDI refers to the entity tables defined in it, to provide service requested by the broker.
The entity referred by the UDDI is Business entity, Business service and Binding Template.
The Service Specific information of OPC server is published in UDDI for global visibility.
9.4.4 OPC SERVICE REGISTRY/REPOSITORY
OPC Service registry/repository is designed to save announced service description or
metadata information from OPC service providers. Publishing metadata information is
enabled using behaviour element and I-metadata exchange interface in application
configuration Publishing service.
9.4.5 OPC SERVICE BROKER
The most important role in OPC Broker based secure client server communication is played
by OPC Service Broker. The Broker is also a WCF service with service API using which the
OPC Data Client can avail various OPC Services. The Broker communicates with provider

who want to register and also with OPC Data Client who want to consume/find or search
OPC Service Registered by the provider. It also searches the repository using UDDI when
the OPC Service Provider and OPC Data Client perform publish and search operation
respectively.
9.4.5.1 INTERNAL ARCHITECTURE OF OPC SERVICE BROKER
D
A
T
A
D
I
C
T
I
O
N
A
R
Y
Y
A
REQUEST
ANALYZER
SERVICE
SELECTOR
UDDI
DI
OPC
SERVICE
REGISTRY
SERVICE
PUBLISHER
SEARCH OPC
SERVICE
SERVICESER
P
U
B
L
I
S
H

9.5 The Announce OPC Service Mechanism
The UDDI refers to the Business Entity and stores all the necessary information like the
Provider’s name and address and its unique ID (key) . During publish operation the key is
returned to the service provider. Figure 3 shows the sequence of activities involved in
announce OPC service operation. The sequence of activities involved in OPC service
publishing is described below.
• First the OPC Service provider should register the service with the broker which is listening
at announcement socket for announcements, by enabling Metadata exchange of application
configuration file of the service
• The broker then stores its description and metadata Information using UDDI APIS to the
OPC Service registry/Repository connected.
• The broker also sends an acknowledgement to the OPC service provider that it has been
registered and available for OPC Data Client for consuming.
Connects Registers Service
At
Stores Service
Metadata Information
Send Acknowledgement Send Acknowledgement
Figure: Sequence Diagram for Announcing OPC Service Operation
OPCSERVICE
PROVIDER
OPCSERVICE
BROKER
ANNOUNCEMENT
SOCKET
OPCSERVICE
REGISTRY/REPOSITORY

9.6 The OPC Service Discovery Mechanism
When the OPC Data Client searches OPC services by sending the SOAP request to the OPC
Service broker in the form of a query, the broker receives the query at Discovery endpoint
which is continuously listening for query client and invokes Discovery Proxy service, the
broker finds the perfect match for the keywords entered by the OPC Data Client. This is done
with the help of data dictionary (WorldNet). Using these keywords the appropriate
information about the OPC Service is then retrieved from OPC Service registry/Repository
and then encapsulated in an Object. The search result will contain the service agreed on the
contract. The sequence of activities involved in OPC service(discovery) is described below.
 The OPC Data Client sends the query using UDDI API, enriched with functional
semantics to the broker for the Discovery of relevant OPC services.
 The Discovery Proxy Service running at Discovery Endpoint resolves the query and
finds the specific keywords to search the OPC Services in the OPC Service
registry/Repository.
 The Discovery Proxy Service using Data Dictionary finds the perfect match for the
query using Word Net and obtains the Keywords in XML form
 Using these matched keywords the Discovery Proxy Service searches the relevant
information about the OPC Service from OPC registry/Repository.
 Once the contents are found, the URIs, object name, object type are encapsulated in
an Object and returned to the Discovery Proxy Service which in turn return it to the
OPC Data Client

Sends Query Invokes
Searches
Returns Object
Returns Service Information
Figure Sequence Diagram for OPC Service Discovery Operation
OPCData
Client
OPCService
Broker
OPCDiscovery
Proxy
OPCService
Repository

Chapter-10
Implementation
The OPC service discovery architecture is implemented on Intel Core i5-2430M machine
with Microsoft Windows 7 as computing environment. The OPC service Announcement and
discovery mechanism is developed using Microsoft Visual Studio 2010 with .NET
Framework 4.0. To find the similar words (synonyms) of query the WordNet.Net 2.1 (2005)
API is used.
10.1. Implementation of Announcement and Discovery (OPC SERVICE BROKER)
The service provider registers its service through the user interface which calls
register_provider_details () function. Figure 5 depicts the user interface created to announce
the OPC services. Figure 6 presents the user interface designed to search relevant OPC
Services. When the OPC Data Client requests the broker by sending a query, the query is
given as a Parameter to the readxml () function used by the Data Dictionary. This makes use
of Word Net 2.1 to differentiate the exact keywords. The readxml ( ) function implicitly calls
the Word Net 2.1 Using words match ( ) function to find the synonyms and displays the result
in an XML format. Using these synonyms the appropriate information about the service
content is then retrieved and encapsulated in an object. This object is returned by the function
display object ( ). The search result will contain the type of the content (Address, Binding and
Contract or Metadata Information of the service), brief information about the searched
content and it’s URI. This Object is used by the Discovery proxy service the contents of this
object based on the object type and stores it. The service selector also responsible for finding
the perfect Address, binding and contract from the OPC Service registry to retrieve suitable
URI based on the order of precedence.

10.2 IMPLEMENTATION OF DISCOVERY PROXY SERVICE OF OPC SERVER
GATEWAY
The WCF discovery feature enables mechanisms where the service broadcasts its status to all
clients and provides its address. That is, each announcement contains the endpoint address, its
scopes and its contract. The service host broadcasts Hello and Bye announcements when it is
being online and offline. . But if the host is aborted ungracefully, no “bye” announcement is
sent. Clients can listen for such announcement messages and then do necessary stuffs. This
announcement services reduces the amount of probing/multicast messaging.
A service is configured with an announcement endpoint by using the service
Discovery behaviour. The service Discovery behaviour allows you to define a collection of
announcement endpoints that will be exposed by the service. You can use the
standard udpAnnouncementEndpoint for most cases. Announcement Endpoints add one
udpAnnouncementEndpoint(programmatically or in configuration file) that will
broadcast the messages when it comes online as well as offline. We also need to be aware
about endpoint Discovery. It should enable to true to make a particular endpoint
automatically discoverable.Clients host an Announcement Service to listen for announcement

OPC SERVER GATEWAY

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Viewers also liked

Viewers also liked (7)

Similar to OPC SERVER GATEWAY

Similar to OPC SERVER GATEWAY (20)

OPC SERVER GATEWAY