DEVELOPMENT OF APPLICATIONS
WITH SERVICE ORIENTED
ARCHITECTURE FOR GRID
assoc. prof., dr. Vladimir Dimitrov
University of Sofia, Bulgaria
Service Oriented Architecture (SOA) is the most attractive approach in the
last years for development of highly distributed integrated enterprise
applications. SOA is based on web services specified in WSDL and
registered in repositories with UDDI. The basic mechanism for message
exchange between services is SOAP. BPEL is used for specification of
business processes described as networks of communicating services.
Development of SOA applications needs of: process orchestration software
for specified in BPEL business process; mediation software for exchange
of messages between services; and repositories for registration and
discoveries of services.
Grid is service oriented; it has repositories for service definition and
discovery; but still there are no wide accepted mechanisms for
orchestration and mediation. One more problem is end user
communication which has to be supported by Grid portals.
In this paper IBM approach to SOA is investigated and its applicability to
Grid for scientific applications is discussed.
SOA by IBM
IBM defines SOA as: “… an architectural style for
creating an Enterprise IT Architecture that exploits
the principles of service orientation to achieve a
tighter relationship between the business and the
information systems that support the business.”
From this definition is clear that SOA is following
principles of service orientation. SOA is an
architectural style. The main achievement of SOA is
tighter relationship between the business and the
information systems that support the business.
From IBM point of view SOA is applied for
development of Enterprise IT Architecture that
integrates business information systems.
To clarify IBM SOA we give the definitions of used terms:
orientation is a way of integrating your business as a set of linked
services.” Or in other words service
orientation looks at business (business
processes) as structured in services linked with each other.
“…a service is a repeatable task within a business process.” This definition of the
service as repeatable task is not precise. From here it is not clear what is
granularity of this repeatable task. Right understanding of service granularity is
the condition for success or fail of a SOA based project. If the services are very
small much execution time is spend for communications. If services are very
large they are complex and hardly manageable. The experience shows that well
designed business services are well granulated services. What the business name
a service it is a service. It is possible some system services to appear later in the
development, but they only support software design and implementation
do not extract any functionality from the business services, they utilize
implementation of some functionality of business services. This approach is in
contradiction with IBM’s Service
Oriented Modeling and Architecture (SOMA)
approach, but comments on this topic are out of scope of this paper.
“A composite application is a set of related and integrated services that support
a business process built on SOA.” This means that composite application is a
SOA implementation of business process.
The language is Business Process Execution Language
(BPEL). This is a XML based language developed by OASIS
consortium. In BPEL the business process is described as
communicating web services.
Web services are specified with Web Services Description
XML based description language of
web services. In WSDL are specified: operations on web
service, messages that web service interchange through its
operations and where web service resides.
Message exchange among web services follows Simple
Oriented Access Protocol (SOAP)
exchange protocol of
XML messages over a transport level protocol usually HTTP.
Web services are registered (published) in repositories
supporting Universal Description, Discovery and
Integration (UDDI) protocol.
Sample View of a WebSphere Business
Developer Process Diagram
Example of Interaction of
Process Server/ESB with WSRR
Grid by IBM
IBM defines Grid infrastructure objectives as:
Creates a virtual application operating,
storage, and collaboration environment;
Virtualize application services execution;
Dynamically fulfils requests over a virtual
pool of system resources;
Offers an adaptive, self
environment that offers high availability.
IBM Grid Solutions
Network Grid Infrastructure for File Downloading. A network of distributed file servers enables an
optimized download upon a client request for a particular file. The system is built as a grid of
dispersed download servers. This solution primarily addresses the enterprise optimization
business driver. This is the first IBM project on Grid computing. Grid vision presented here is very
much like that one in . From architect point of view Grid consists of Grid coordinator and Grid
nodes. Grid coordinator (downloadGrid management center) accepts jobs and distribute them
work nodes. In this case the job is to download some file from the repository (Registration Module
& Data Unit Distribution Module). The Grid coordinator creates optimized downloading plan using
Feedback and Statistical Module and Optimized Plan Module. The system information database
can be replicated by Replication Module. This system implements GSI as security mechanism.
Public Health Data Grid. A network of servers stores digital mammographies that are associated with
explanatory notes and comments about each image. The system is built up as a grid
federated database. This solution primarily addresses the productivity and collaboration business
driver. The Grid element is Globus Toolkit 3.0
Computational Grid Infrastructure for the Upstream Oil and Gas Industry. A network of servers provides
performance virtual cluster to process oil field exploration applications, such as upstream
petroleum processing. This solution helps to accelerate the business process and to optimize the
enterprise. In this solution Globus Toolkit is used, but job submission is organized through Grid
Portal. The last one automates user interactions with the Grid environment.
IBM Grid Solutions
Industrial Sector Data Grid. A network of data servers enables users to access
heterogeneous files in different systems, regardless of where they are. This
solution primarily addresses productivity and the collaboration business driver.
This solution is for data intensive Grid computing how is presented in previous
Computational Grid Infrastructure for Trading Analysis. A network of desktops and
servers helps to gain the necessary computing power to run long and complex
algorithms that are required for trading analysis. This solution helps to
accelerate the business process and to optimize the enterprise. In this example
IBM WebSphere MQ is used to connect client software to
. The last one is cluster management software. The most important
idea here is that IBM WebSphere MQ can be used as mediator in standard client
server architecture between the client, Grid software and the server.
Computational Grid for the Consulting Industry. A solution aims to release the
computation consumption of an IBM mainframe by submitting heavy algorithm
jobs to grid nodes. This solution addresses IT optimization as its primary
business driver. This solution is like one presented above.
Grid SOA Application
Status and performance
provider and enforcer
Random security probe
Transfer result files
How SOA could be supported
SOA standards are: BPEL, WSDL, UDDI, SOAP, and XML. This means
that these standards have to be implemented in Grid. Processes
running on Grid have to be specified in BPEL and orchestrated by
specialized nodes. Such candidate orchestration software for
these nodes can be WebSphere Process Server,
BPEL Process Manager, or BEA
. The most advanced
orchestration software is WebSphere Process Server. It can be
integrated in Grid environment, but it works in combination with
other WebSphere products, so it is hardly to imagine that
nowadays WebSphere Process Server can be the software for the
orchestration node. Oracle BPEL Process Manager and BEA
have just a same problem
they are not open enough
to be well integrated with software not deployed by their
vendors. The only realistic candidate is
. Its problem is that
it is not mature enough for serious usage.
How SOA could be supported
It a standard for repositories to support WSDL and UDDI, so
services could be registered and searched in Grid. The
problem from mediation point of view is how effectively to
support message exchange between services. ESB concept
is based on the fact that it works in cluster where the
communications are highly reliable and are at a level higher
than inter cluster exchange. It is clear that first SOA
applications will be cluster based.
Grid is diverging to SOA support environment, but many more
work has to be done before we will have an environment in
which processes are orchestrated on overall Grid
when process services are geographically
Can Grid be reengineered in
Nowadays SOA is an ultimate architecture for
development of distributed system. Grid
software is older and does not have this
architecture. It is possible to develop
adapters for Grid software and start
orchestrate it, but it is not sensible, because it
would not run effectively. The only way is to
redevelop Grid software in SOA which is very
What is the realistic scenario for development of SOA based
Grid application? First, processes have to be executed as
much as possible on one cluster. A worker node has to be
specialized for orchestration with software like
Application software has to be reengineered for SOA. For
this reengineering currently available tool like that one of
WebSphere can be used. Some kind of ESB has to be
developed for message exchange between services in the
cluster. This ESB like software can be MPI based.
At University of Sofia we are doing research on deployment of
SOA based applications for Grid. Currently, we are
investigating deployment of BPEL processes to
There are many technical problems. Our intention is to
demonstrate some SOA based CMS software.
Thank for Your Attention!