Embed Size (px)
Citation preview
FRAMEWORK FOR INTEGRATING SORCER
WITH RPC STYLE WEB SERVICES
by
KIRAN MASAPARI, M.C.A.
A THESIS
IN
COMPUTER SCIENCE
Submitted to the Graduate Faculty of Texas Tech University in
Partial Fulfillment of the Requirements for
the Degree of
MASTER OF SCIENCE
Approved
Michael Sobolewski Chairperson of the Committee
Hector Hernandez
Yu Zhuang
Accepted
John Borrelli Dean of the Graduate School
May, 2005
ii
TABLE OF CONTENTS
TABLE OF FIGURES .......................................................................................... vi ABSTRACT ........................................................................................................viii CHAPTER I .......................................................................................................... 1 1. INTRODUCTION.............................................................................................. 1
1.1 Background................................................................................................. 1 1.2 Problem Description.................................................................................... 3 1.3 Thesis Outline............................................................................................. 4
2. SERVICE ORIENTED ARCHITECTURE ......................................................... 5
2.1 Key Components of SOA............................................................................ 6
2.1.1 Service ................................................................................................. 6 2.1.2 Message............................................................................................... 6 2.1.3 Directory Service .................................................................................. 6 2.1.4 Web Service ......................................................................................... 7
2. 2 Service ORiented Computing EnviRonment (SORCER) ........................................................................................................ 7
2.2.1 Service Oriented Programming Paradigm............................................ 7 2.2.2 Context/Method/Exertion (CME) Paradigm ........................................ 11
3. SORCER OVERVIEW.................................................................................... 13
3.1 Job Execution ........................................................................................... 15 3.2 Exertion Dispatchers................................................................................. 17
4. WEBSERVICES ............................................................................................. 20
4.1 RPC Style WebServices ........................................................................... 23
iii
4.2 Difference between RPC Style and Document Style Web Services........................................................................................ 26 4.3 XML .......................................................................................................... 27 4.4 SOAP........................................................................................................ 31
4.4.1 SOAP and XML .................................................................................. 32 4.4.2 SOAP namespaces ............................................................................ 33 4.4.3 SOAP Messages ................................................................................ 33
4.5 WSDL ....................................................................................................... 35 4.6 UDDI ......................................................................................................... 38
4.6.1 Businesses benefit from UDDI ........................................................... 40 4.6.2 Problems the UDDI specification can help to solve: ...................................................................................................... 40 4.6.3 Registering for UDDI .......................................................................... 42 4.6.4 Searching UDDI.................................................................................. 42
5. JAX-RPC (JAVA API FOR XML BASED RPC) WEB SERVICES ................................................................................................ 43
5.1 J2SE SDK CLASSES............................................................................ 44 5.2 Primitives............................................................................................... 45 5.3 Arrays.................................................................................................... 45 5.4 Value Types .......................................................................................... 46 5.5 JavaBeans Components ....................................................................... 47
6. SKARINGA..................................................................................................... 48
6.1 Serializable Java types ............................................................................. 49 6.2 XML documents ........................................................................................ 50
iv
6.3 Handling the state of an object.................................................................. 50 6.4 Using a certain class loader...................................................................... 51 6.5 Properties to customize the XML output ................................................... 52 6.6 Field order................................................................................................. 53 6.7 Lexicographical field order ........................................................................ 53
7. SORCER WEB SERVICES INTEGRATION FRAMEWORK (SWIF) ....................................................................................... 54
7.1 Introduction ............................................................................................... 54 7.2 Objective / Approach................................................................................. 55 7.3 Architecture............................................................................................... 56 7.4 Design....................................................................................................... 57 7.5 Implementation ......................................................................................... 59
7.5.1 Technical Architecture........................................................................ 59 7.5.2 Package Diagram............................................................................... 60 7.5.3 Physical Architecture.......................................................................... 62
7.6 Validation .................................................................................................. 67
7.6.1 SORCER Requestor :........................................................................ 68 7.6.2 WebService Client : ............................................................................ 71
8. FUTURE RESEARCH .................................................................................... 78 9. CONCLUSION................................................................................................ 79 GLOSSARY / ACRONYMS ................................................................................ 80 REFERENCES................................................................................................... 81 APPENDICES .................................................................................................... 84
v
A. SORCER WEB SERVICES INTEGRATION FRAMEWORK INTERFACES ............................................................................ 84 B. SORCER WEB SERVICES INTEGRATION FRAMEWORK JAVA DOCUMENTATION ......................................................... 86
vi
TABLE OF FIGURES
1.1 Context Data................................................................................................ 11
1.2 SORCER Architecture ................................................................................. 15
1.3 Job execution in SORCER .......................................................................... 16
1.4 Operation of the Service Broker and Service Provider ................................ 18
1.5 WebServices Architecture ........................................................................... 22
1.6 RPC WebServices Architecture................................................................... 25
1.7 Supported Classes of the Java Collections Framework .............................. 47
1.8 Integration Framework................................................................................. 57
1.9 AirportWeatherRequestor ............................................................................ 58
1.10 SWIFClient ................................................................................................ 58
1.11 Technical Architecture ............................................................................... 60
1.12 Package Diagram...................................................................................... 61
1.13 SWIFExertionDispatcher ........................................................................... 62
1.14 SWIF SORCER Providers ......................................................................... 63
1.15 Web service Client..................................................................................... 65
1.16 AirportWeatherRequestorUI ...................................................................... 68
1.17 The Jobber getting the codes from SORCER Provider ............................. 69
1.18 The SORCER Provider providing the codes.............................................. 70
1.19 The AirportWeatherRequestorUI showing the codes................................. 71
1.20 The Jobber getting result from remote web service................................... 72
1.21 AirportWeatherRequestorUI displaying result............................................ 73
vii
1.22 SWIFServlet gateway Web Service End point........................................... 74
1.23 The WSDL file of the gateway Web service............................................... 75
1.24 SWIFClient getting result from SWIFServlet.............................................. 76
viii
ABSTRACT
Ever since the introduction of Web Services, it has become one of
software industry�s most used buzzwords. Web services, in the general meaning
of the term, are services offered by one application to other applications via the
World Wide Web. An RPC-based Web service is a collection of procedures that
can be called by a remote client over the Internet. The integration of
WebServices into existing environments is becoming more and more important.
The SORCER environment provides the means to create interactive service-
oriented programs and execute them without writing a line of source code where
jobs and tasks are created using web-based user interfaces. SORCER is service
oriented but is object based where as WebServices are protocol based.
This thesis presents a comprehensive technical overview of RPC Style
WebServices and the integration framework that allows Protocol-based RPC
Web Services and Object-oriented SORCER service providers to coexist and
complement each other in the same environment. My main emphasis would be to
develop a framework with generic gateway that would allow SORCER Services
to be accessed both as RPC WebServices for web clients and as SORCER
Service Providers for SORCER Service requestors
1
CHAPTER I
INTRODUCTION
1.1 Background
SORCER(Service Oriented Computing EnviRonment) system is service-
based, network-centric, and web-centric and the architecture of SORCER houses
the large pool of distributed services that execute business logic and integrate
tools and applications in the underlying engineering domain. The web-centric
architecture enables HTTP communication between a web-based client and the
SORCER system, as well as transparent access to the globally distributed data
and the pool of federated services.
SORCER (object, network, service-oriented approach) is used in this
framework but not other grid technologies for various reasons. SORCER uses
Object-oriented virtual services - applying OO concepts directly to the network,
not protocols as in web and grid services. SORCER uses a new SO
programming approach in which SORCER is required to run programs(exertions)
in the grid instead of writing grid programs in conventional programming
languages (C, C++, Java, Perl, etc.) that have not been designed for grid
computing environments
SORCER offers a simple way to construct networks of services that can
be accessed by clients,exploiting the Java environment, with its portable source
code, dynamic downloading, and polymorphic object-oriented properties.
SORCER provider is only required to be an implementation of an interface (which
2
is used to identify the object in the Jini Lookup service). This allows the client of
the service to know what calls to make to gain access to the service. But how the
proxy communicates with the service itself is completely up to the proxy and the
service from which it comes.
The proxy can be an RMI reference (a common, and easily supported
case), an object that communicates using some other common and well known
protocol (such as CORBA's IIOP protocol), a piece of code that uses a
specialized protocol known only to the proxy and the service itself, or a full
implementation of the service that runs locally in the client's address space. All of
this is transparent to the client, who only sees the interface. Everything in
SORCER is based on an object model.
The implementation makes extensive use of features such as object
serialisation, remote method invocation and portability of executables. Access is
via a lookup service; server objects register with the lookup, and clients discover
about servers by querying the lookup service.
In comparison to other grid technologies, SORCER is much simpler and
cleaner. as other grid technologies provides a rather low level toolkits, solving
many of the difficult systems problems inherent in the Grid but giving the user a
rather skeletal foundation on which they must build. SORCER provides a much
neater ``out-of-the-box'' environment which makes it much easier to experiment
with Grid-like environments and investigate the more interesting aspects such as
resource brokers, application managers etc.
3
1.2 Problem Description
Web Services are seen by many as the next wave of the Internet
revolution. The vision is of a Web as rich with functionality as the current Web is
with information. The challenge is to expose this functionality in a consistent and
usable way. Web Services takes advantage of common Web protocols to make
component instances easily accessible both within and outside an organization.
They are essentially application components that can be accessed using Web
protocols and data encoding mechanisms, such as HTTP and XML. They can
provide a consistent, cross-organization, cross-vendor framework that will speed
up the integration of applications and application components. By selecting
existing, widely-used standards, the Web Service framework removes many
barriers to integration that existed when using other frameworks. The Web
Service model is language- and platform-neutral, so developers anywhere can
potentially build and consume Web Services. SOAP, WSDL, HTTP, XML are
some of the open standards used.
The majority of web services efforts to date employ a basic client/server
style, using an RPC connector. Remote Procedure Calls (RPCs) made over
Web-based protocols are essentially no different from those made over other
protocols. Service Oriented Computing Environment (SORCER) is a service-
based concurrent engineering project. The architecture of the SORCER system
is service-based, network-centric, and web-centric. This architecture houses the
large pool of distributed services that execute business logic and integrate tools
and applications in the underlying engineering domain. The web-centric
4
architecture enables HTTP communication between a web-based client and the
SORCER system, as well as transparent access to the globally distributed data
and the pool of federated services. My research extends this functionality to
enable web-based clients to also access RPC webservices in SORCER.
1.3 Thesis Outline
This paper is roughly divided into 4 parts. Introduction and background is
provided in Chapters 1 and 2. Chapter introduces SORCER in detail. Chapters 4,
5 and 6 introduce web services and underlying technologies in full detail. Chapter
7 discusses the approach and framework developed to attain the objective of this
thesis. It explains the design architecture for the complete Framework developed.
Chapters 8 and 9 are discussions and conclusion and it will also quote the
contribution of the work and further research.
5
CHAPTER II
SERVICE ORIENTED ARCHITECTURE
Service Oriented Architecture can be simply generalized as a collection of
services communicating with each other. SOA is an architectural style whose
goal is to achieve loose coupling among interacting software agents. A service is
a function that is well defined, self-contained, and does not depend on the
context or state of other services.
A service is a unit of work done by a service provider to achieve desired
end results for a service consumer. The service is self-contained. That is, the
service maintains its own state. Both provider and consumer are roles played by
software agents on behalf of their owners .SOA basically comprises of simple
and ubiquitous set of interfaces universally available for all service providers and
consumers.
For architecture to be SOA certain rules have to be satisfied.
• The messages must be descriptive, rather than instructive, because the
service provider is responsible for solving the problem.
• Service providers will be unable to understand your request if your
messages are not written in a format, structure, and vocabulary.
• Extensibility is important without which consumers and providers will be
locked into one particular version of a service.
• SOA must have a mechanism that enables a consumer to discover a
service provider under the context of a service sought by the consumer
6
2.1 Key Components of SOA
In the context of SOA, we have the terms service, message, dynamic
discovery, and web services.
2.1.1 Service
A service in SOA is an exposed piece of functionality with three properties:
• The interface contract to the service is platform-independent.
• The service can be dynamically located and invoked.
• The service is self-contained. That is, the service maintains its own state.
2.1.2 Message
Service providers and consumers communicate via messages. Services
expose an interface contract. This contract defines the behavior of the service
and the messages they accept and return. Because the interface contract is
platform and language independent, the technology used to define messages
must also be agnostic to any specific platform/language. Therefore, messages
are typically constructed using XML documents that conform to XML schema
2.1.3 Directory Service
The Directory Service acts as an intermediary between the Service
Provider and the Service Consumer. Providers register with the directory service
and consumers query the directory service to find service providers. A Service
Consumer discovers the service using some criteria and finds the right service
provider for the service. It then invokes the service using the Proxy from the
7
provider.
Embedding a directory service within SOA accomplishes the following:
• Scalability of services; you can add services incrementally.
• Decouples consumers from providers.
• Allows for hot updates of services.
• Provides a look-up service for consumers.
• Allows consumers to choose between providers at runtime rather than
hard-coding a single provider
2.1.4 Web Service
Web services are built on top of well-known and platform-independent
protocols. These protocols include HTTP, XML, UDDI, WSDL, and SOAP. It is
the combination of these protocols that make web services so attractive.
Moreover, it is these protocols that fulfill the key requirements of a SOA. That is,
a SOA requires that a service be dynamically discoverable and invokable. This
requirement is fulfilled by UDDI, WSDL, and SOAP. SOA requires that a service
have a platform-independent interface contract. This requirement is fulfilled by
XML. SOA stresses interoperability. This requirement is fulfilled by HTTP. This is
why web services lie at the heart of SOA.
2. 2 Service ORiented Computing EnviRonment (SORCER)
2.2.1 Service Oriented Programming Paradigm
Service Oriented Programming (SOP) is a paradigm for distributed
computing built over Object Oriented Programming (OOP) paradigm
8
emphasizing the point that problems can be modeled in terms of services rather
than objects. SOP differs from OOP by focusing on what things can do whereas
OOP focuses on what things are and how they are constructed. SOP defines set
of core principles to maintain interoperability of services over time.
The structured computing paradigm is a method based on a concept that
a system has data and functionality (behavior) separated into two distinct parts. A
structured program is composed of one or more units or modules such that each
module is composed of one or more functions (procedures, routines, subroutines,
or methods, depending on programming language). It is possible for a structured
program to have multiple levels or scopes, with functions defined inside other
functions. Each scope can contain variables, which cannot be seen in outer
scopes. Usually the structured computing is based on splitting programs into sub-
sections, each with a single point of entry and of exit, by using only structured
looping constructs, often named "while", "repeat", "for" with simple, hierarchical
program flow structures. Often it is recommended that each loop should only
have one entry point and one exit point.
The object-oriented paradigm, on the other hand, defines a system as a
collection of interacting active objects. These objects do things and know things,
or stated equivalently they have functions and data that complement each other.
Usually an object-oriented system creates its own object space instead of
accessing a data repository. This object space constitutes an object-oriented
program. The execution of the object-oriented program is a collection of
dialoguing objects (sending and receiving messages).
9
Building on the object-oriented paradigm is the service-oriented paradigm,
in which the objects are distributed, or more precisely they are network objects
and play some predefined roles. A service provider is an object that accepts
messages from service requestors to execute an item of work � a task. The task
object is a service request � a kind of elementary service executed by a service
provider. A service broker is a specialized service provider that executes a job �
a compound request in terms of tasks and other jobs.
The job object is a service-oriented program that is dynamically bound to
all relevant and currently available service providers on the network. This
collection of service providers dynamically identified by a broker is called a job
federation. This federation is also called a job space. While this sounds similar to
the object-oriented paradigm, it really isn�t.
In the object-oriented paradigm the object space is a program itself; here
the job space is the execution environment for the job itself and the job is a
service-oriented program that federates relevant providers at runtime. This
changes the game completely. In the former case the object space is a virtual
machine, but in the latter case the job space is the virtual federating network.
This runtime federation is the jobs� execution environment and the job object is a
service-oriented program. In other words, we apply the object-oriented concepts
directly to the network in the service-oriented paradigm.
Tasks and jobs as elementary and compound service-oriented programs,
respectively, are called exertions. The complexity of the problems to be solved is
directly related to the kind and quality of abstraction. The primary network
10
abstraction still requires us to think in terms of structure of many computing
nodes and devices rather than the structure of the problem we are trying to solve.
Instead of modeling the multiple computing devices the service-oriented
programming provides the paradigm that allows us to model the problem to be
solved in terms of services and define the computing processes in terms of
exertions.
The core principles of SOP are
• Service provider is a remote process invoked by service requestors. The
provider is a service which contractually defines a behavior.
• The grid: a collection of service providers.
• A service provider runs a set of service-oriented routines (SOR). SORs
are exposed to service requestors via a provider interface methods
• ServiceMethod: reference to SOR defined by (i, s), where i is a name
of provider interface, s is a name of method selector
• Service data: argument to SOR, called a context model, for short c
• Elementary exertion a pair of ServiceMethod and context model,
i.e., (c, m), where m = (i, s)
• Elementary exertion is called a task � grid operation
• Compound exertion is called a job � aggregation of tasks and other jobs �
grid program
• Exertions are service-oriented programs
• Job (c, m) follows semantics of SOP
c: a set of exertions along with control strategy to execute the job
11
m: a reference to a service provider that coordinates execution of job
exertions, called Service Broker or Jobber
2.2.2 Context/Method/Exertion (CME) Paradigm
SORCER complies with SOP paradigm and defines CME model
conforming to the core principles. The core data structures in the SORCER
environments include the Exertion (tasks/ jobs), ServiceMethod and
ServiceContext [10, 16]. A ServiceContext is the basic element of SORCER data
structures and is based on percept-calculus knowledge representation scheme
(Kulpa et al.1991, Sobolewski & Kulpa 1984). Context Model �c� is a tree like
structure of data being processed. It contains a name space, which is path of a
tree and a data node where the data resides.
A ServiceMethod is primarily defined by the following pair: (Provider
Interface, selector}, where Provider Interface is the name of the interface of the
service to be bound with during runtime, selector is the name of the method to be
executed on the provider.
1.1 Context Data
These information in the method defines how a dynamic federation is
created (i.e., how network objects are bound in runtime). These network objects
Name space (Context)
Data
12
provide the business logic to be applied to context model. The ServiceMethod
may also represent a piece of code to be downloaded and executed by a
provider.
Exertion: e = (c, (i, s)), is an abstract representation of service-oriented
program: task or job. All interactions in an executing job are defined in terms of
component exertions and control strategy
13
CHAPTER III
SORCER OVERVIEW
Service Oriented Computing Environment (SORCER) is a service-based
concurrent engineering project which is based on evolution of the concepts and
lessons learned in the FIPER project [9-14], a $21.5 million program founded by
NIST (National Institute of Standards and Technology)[1,2,14,15] at GE
Corporate Research and Development. The goal of the SORCER project is to
develop a means for global communication of product information, data, methods
and tools while satisfying stringent product performance requirements. The
architecture of the SORCER system is designed to be flexible enough to handle
the needs of almost any product from aircraft engines to manufactured goods
such as plastics.
The architecture of the SORCER system is service-based, network-
centric, and web-centric. This architecture houses the large pool of distributed
services that execute business logic and integrate tools and applications in the
underlying engineering domain. The web-centric architecture enables HTTP
communication between a web-based client and the SORCER system, as well as
transparent access to the globally distributed data and the pool of federated
services.
The individual services requested by the SORCER system act on behalf of
the web client, both in the role of providing services (provider mode) and
requesting services (requestor mode). When requesting services, the SORCER
14
system also brokers the requests, delegating them to the appropriate registered
service providers. All services in SORCER Environment are peers. All service
providers implement the global interface called the Servicer. A service is an act
of invoking a method of following signature: �service (Exertion)� on a service
provider.
All peers in SORCER extend ServiceProvider, which is a system level
abstract class, implementing Servicer. The default implementation of �service
(Exertion)� in ServiceProvider looks into the ServiceMethod inside the exertion
and checks if the ServiceProvider itself implements the interfaces defined in
exertion. If it does, then via reflection the method defined by the selector is
invoked with the ServiceContext inside the Exertion as argument to the method
call. Hence all providers can implement any number of interfaces with methods
accepting ServiceContext as argument. If the interface defined by
ProviderInterface in the ServiceMethod is not implemented by the
ServiceProvider, the ServiceProvider dynamically finds the right provider with the
aid of object registry lookup service and forwards this exertion to the right peer in
the network to be bound for execution.
The clear separation of method, data & control strategy and having a
global interface helps us to build dynamic federation of services in grid. Also, no
service requires any prior knowledge of another service in the grid and there�s no
hassle of requiring an interface in the requestor side to invoke a service provided
by a provider. Thus all components in SORCER environment act as true peers.
15
1.2 SORCER Architecture
3.1 Job Execution
Specialized ServiceProviders that are called Jobbers do Job execution. A
Jobber co-ordinates execution of a job using the job context model called
ControlContext. The ControlContext defines a job�s execution strategy. A
strategy implements a master/slave-computing model (Freeman et al. 1999) with
sequential or parallel execution of slave exertions with the master exertion
executed as the last one. Jobbers use dispatchers to dispatch jobs to the right
providers in the grid. In SORCER environment there are four types of dispatchers
that implement different type for control strategies. These include sequential and
parallel dispatchers for Catalog and Space. A relevant dispatcher is assigned to
a jobber by the dispatcher factory based on ControlContext. UML diagram for job
execution is presented in Figure 1.3. The core of the architecture consists of
service providers and service brokers interacting with lookup registries, a catalog
16
1.3 Job execution in SORCER of services, and exertion shared space.In general, a service provider executes a
task (elementary exertion), and a service broker executes a job (compound
exertion or a nested transaction). While executing a job, the service broker
coordinates exertion execution within the nested transaction. It interprets the
transaction map supplied by the service requestor and completes the nested
exertions accordingly as presented in the transaction map.At the start of the
transaction the service broker reads all the exertions in the transaction and
executes those exertions, which have no precedence relationships. At each step
it executes the services for which all the precedence relationships have been
satisfied (services complete).
Whenever it gets a notification of a service being completed it evaluates
the remaining unfinished activities and invokes one or more exertions based on
their precedence relationships. The service broker, by using an appropriate
17
exertion dispatcher, can directly access the service provider through a service
catalog and select a provider or drop the exertion into Exertion Space for the first
available provider to process the request. While the service broker is servicing a
job, a nested job within the job being currently serviced can be executed locally,
or can be dropped into the Exertion Space, or passed on directly to another
service broker. Another available service broker can then federate and
collaborate in the job execution by executing the nested job, and so on. Thus not
only can the service providers federate to execute a job for a particular service
broker, but the service brokers can also federate along with other service
providers.
The federated brokers with the originating broker execute the nested jobs
while the regular service providers execute all the tasks within all jobs including
the originating one. A service broker uses a factory design pattern to request a
relevant exertion dispatcher that matches the control structure of the executed
job.
3.2 Exertion Dispatchers
Two main types of exertion dispatchers are used: a catalog exertion
dispatcher and a space exertion dispatcher. The catalog exertion dispatcher finds
needed service providers using the service catalog. The space exertion
dispatcher drops exertion into the exertion space to be picked up by matching
available service providers. When the exertion is picked up from the space and it
is executed by a matching provider then the provider returns it into the space and
18
the space exertion dispatcher gets it back from the space for the service broker.
The service grid also defines a common service provider interface (Provider that
extends the top level interface Servicer) and a set of utilities to create and
register providers with the grid as service peers. A Service Joiner is used for
bootstrapping service providers and also for maintaining leases on registered
proxies. The grid service brokers can also use dynamic provisioning based on
Rio technology (Rio Project) for deploying and maintaining required federation
Figure 1.4 shows the different ways in which a provider (the service broker or
service provider) can submit requests to the providers.
ServiceRequestor
ExertionSpace
ServiceCatalog
ServiceProvider
LookupService
Discoveryand lookup
Discoveryand lookup
Lookup
Discovery, registration and
leasing
Droptask or job
Execute task
Gettask
Execute job
Getjob
ServiceBroker
Execute task
Lookup
Discoveryand lookup
1.4 Operation of the Service Broker and Service Provider
For a direct connection to the service provider the provider can either use
discovery to find a lookup service or use a Service Catalog provider for selecting
a service. The lookup service caches all the proxies for services that have
19
registered with it for a particular group(s) of services. The Catalog provider is a
service-grid cache that periodically polls all relevant lookup services and
maintains a cache of all the proxies that are registered with the lookup services
for a particular group or groups of services. Thus, multiple service catalogs may
be used for different logical overlay sub networks. The provider has to discover
lookup services each time it needs to use them where as it finds one of required
catalogs only once when it (provider) is instantiated and then the Catalog
continues service discovery for the provider.
In case the provider finds an available service using a lookup registry or
the Catalog, a proxy for the service is downloaded on to the provider who
invokes the service by calling service (Exertion). Alternately the provider submits
the service request to an Exertion Space that holds the request and waits for a
matching service provider to accept the exertion. This is essential so that the
transaction does not have to abort due to non-availability of a service. This also
helps in better load balancing of the services since available providers will act at
their own pace to process the exertions in the space. A notification management
framework (Lapinski 2002) based on a notification provider allows federated
providers notify the service requestor on their collaborative actions. Additionally
the File Store provider (Sobolewski 2003) allows federated providers to share
exertion input as well as output data is a uniform service-oriented way.
20
CHAPTER IV
WEBSERVICES
Web services, in the general meaning of the term, are services offered by
one application to other applications via the World Wide Web. Clients of these
services can aggregate them to form an end-user application, enable business
transactions, or create new Web services. A Web Service is programmable
application logic accessible using standard Internet protocols. Web Services
combine the best aspects of component-based development and the Web. Like
components, Web Services represent black-box functionality that can be reused
without worrying about how the service is implemented. Unlike current
component technologies, Web Services are not accessed via object-model-
specific protocols, such as DCOM, RMI, or IIOP. Instead, Web Services are
accessed via ubiquitous Web protocols (ex: HTTP) and data formats (ex: XML).
In a typical Web services scenario, a business application sends a request
to a service at a given URL using the SOAP protocol over HTTP. The service
receives the request, processes it, and returns a response. An often-cited
example of a Web service is that of a stock quote service, in which the request
asks for the current price of a specified stock, and the response gives the stock
price. This is one of the simplest forms of a Web service in that the request is
filled almost immediately, with the request and response being parts of the same
method call. Web services and consumers of Web services are typically
businesses, making Web services predominantly business-to-business (B-to-B)
21
transactions. An enterprise can be the provider of Web services and also the
consumer of other Web services. Web services depend on the ability of parties to
communicate with each other even if they are using different information
systems. XML (Extensible Markup Language), a markup language that makes
data portable, is a key technology in addressing this need. Enterprises have
discovered the benefits of using XML for the integration of data both internally for
sharing legacy data among departments and externally for sharing data with
other enterprises. As a result, XML is increasingly being used for enterprise
integration applications, both in tightly coupled and loosely coupled systems.
Because of this data integration ability, XML has become the underpinning for
Web-related computing.
Web services also depend on the ability of enterprises using different
computing platforms to communicate with each other. In addition to data
portability and code portability, Web services need to be scalable, secure, and
efficient, especially as they grow. They are a new breed of Web application, self-
contained, self-describing, modular applications that can be published, located,
and invoked across the Web. Web Services are �Libraries� providing data and
services to other applications over Web through a consistent set of interfaces
and protocols. Web Services perform functions, which can be anything from
simple requests to complicated business processes. Once a Web service is
deployed, other applications (and other Web Services) can discover and invoke
the deployed service. The really hard part of developing Web services is
programming the infrastructure, or "plumbing." The infrastructure includes
22
features such as security, distributed transaction management, and connection
pool management, all of which are essential for industrial strength Web services.
And because components are reusable, development time is substantially
reduced.
1.5 WebServices Architecture
The Web services architecture is implemented through the layering of
several types of technologies. These technologies can be organized into the
following four layers that build upon one another:
• Discovery (UDDI)
• Description (WSDL)
• Packaging/Extensions (SOAP)
• Transport (HTTP)
23
To summarize: a Web Service is
• A programmable application, accessible as a component via standard
Web protocols,
• Uses standard Web protocols like HTTP, XML and SOAP,
• Works through existing proxies and firewalls,
• Can take advantage of HTTP authentication,
• Encryption for free with SSL,
• Easy incorporation with existing XML messaging solutions,
• Takes advantage of XML messaging schemas and easy transition from
XML RPC solutions,
• No conflict between proprietary component based solutions like CORBA
and COM,
• Combines the best aspects of component�based development and the
Web, and
• Available to a variety of clients (platform independent).
In a nutshell, a Web Service is an application that can be called over the
Web using standards such as SOAP over HTTP.
4.1 RPC Style WebServices
An RPC-based Web service is a collection of procedures that can be
called by a remote client over the Internet. RPC style websevices and clients use
remote procedure calls and XML. RPC mechanism often used in distributed
client/server model enables clients to execute procedures on other systems. The
24
remote procedure call is represented by an XML-based protocol such as SOAP.
The SOAP specification defines the envelope structure, encoding rules, and
convention for representing remote procedure calls and responses. These calls
and responses are transmitted as SOAP messages (XML files) over HTTP.
The majority of web services efforts to date employ a basic client/server
style, using an RPC connector, but further constrained in three important ways.
The XML constraint on data elements imparts several important properties. First,
it allows further independence between client and server components, because
XML is an implementation-independent format. This is in contrast to other
formats that encode data in language-specific ways. For example, a Java object
serialized using Java language serialization will be completely unusable in a C++
environment. Second, XML document may be processed in a stream-oriented
fashion, allowing components and connectors to process requests and
responses incrementally. Third, XML processors are readily available in many
languages, which should ease implementation.
SOAP messaging provides several important features in an RPC
environment. SOAP defines a standard XML message structure, allowing
different connector implementations to communicate effectively. Within this
structure, SOAP also defines a standard RPC protocol, further enhancing
connector interoperability. Finally, SOAP defines a standard error representation,
called a fault. Taken together, these features allow for the development of many
alternative connectors, which can be selected independently by clients and
servers without losing interoperability.
25
1.6 RPC WebServices Architecture
Perhaps more interesting is the RPC connector's hiding of the underlying
transport protocol. A connector may be capable of using several different
protocols to transport the SOAP message from client to server and vice-versa.
The most common protocol employed is HTTP, but others such as Simple Mail
Transport Protocol (SMTP) may be used. HTTP-based RPC web services
commonly establish a single HTTP "service endpoint" that will receive procedure
invocation messages via an HTTP POST. Regardless of the transport utilized,
the connector presents the same interface to the component. As with the overall
client/server style, this constraint offers separation of concerns between a
component and a connector, allowing each to evolve independently.
The various SOAP toolkits provide concrete examples of RPC web
services client and server connectors. When using these toolkits, client-to-server
communication functions much like basic RPC. A web services client will invoke
a "client-side version" of the procedure made available by a remote server. On
26
the server, the RPC web services connector receives the request, likely from
another connector that handles the underlying transport protocol. The RPC web
services server connector examines the procedure invocation message, invokes
the corresponding procedure, and sends back the response.
4.2 Difference between RPC Style and Document Style Web Services
There are two SOAP message styles, called document and rpc. Document
style indicates that the SOAP body simply contains an XML document. The
sender and receiver must agree on the format of the document ahead of time,
such as traditional messaging systems. The agreement between the sender and
receiver is typically negotiated through literal XML Schema definitions. Hence,
this combination is referred to as document/literal. RPC (Remote Procedure Call)
style, on the other hand, indicates that the SOAP body contains an XML
representation of a method call such as the traditional distributed component
technologies of DCOM, Corba, and others. RPC style uses the names of the
method and its parameters to generate structures that represent a method's call
stack.
These structures can then be serialized into the SOAP message
according to a set of encoding rules. The SOAP specification defines a standard
set of encoding rules for this purpose that codify how to map the most common
programmatic data structures, such as structs and arrays, into an XML 1.0
format. Since RPC is traditionally used in conjunction with the SOAP encoding
rules, the combination is referred to as rpc/encoded. Such metadata made it
27
possible for toolkits to automatically map between existing components and
SOAP messages without explicitly defining what the messages looked like ahead
of time. The SOAP style is described in the generated WSDL definition so
consumers know what to expect.
The style is specified on the soap:operation element while the encoding
technique is specified on the soap:body element's use attribute. The SOAP
encoding rules facilitate the representation of object graphs in XML such as the
cyclical reference. Since there is no way to represent this with just XML Schema,
the document/literal example will throw an exception if you try to return
something that cannot be represented as a natural tree structure, where
rpc/encoded is more capable than document/literal
4.3 XML
What Is XML?
XML(Extensible Markup Language) is an industry-standard, system-
independent way of representing data. Like HTML (HyperText Markup
Language), XML encloses data in tags, but there are significant differences
between the two markup languages. First, XML tags relate to the meaning of the
enclosed text, whereas HTML tags specify how to display the enclosed text. The
following XML example shows a price list with the name and price of two coffees.
<priceList>
<coffee>
<name>Mocha Java</name>
28
<price>11.95</price>
</coffee>
<coffee>
<name>Sumatra</name>
<price>12.50</price>
</coffee>
</priceList>
The <coffee> and </coffee> tags tell a parser that the information between
them is about a coffee. The two other tags inside the <coffee> tags specify that
the enclosed information is the coffee's name and its price per pound. Because
XML tags indicate the content and structure of the data they enclose, they make
it possible to do things like archiving and searching.
A second major difference between XML and HTML is that XML is
extensible. With XML, you can write your own tags to describe the content in a
particular type of document. With HTML, you are limited to using only those tags
that have been predefined in the HTML specification. Another aspect of XML's
extensibility is that you can create a file, called a schema, to describe the
structure of a particular type of XML document. For example, you can write a
schema for a price list that specifies which tags can be used and where they can
occur. Any XML document that follows the constraints established in a schema is
said to conform to that schema.
Probably the most-widely used schema language is still the Document
Type Definition (DTD) schema language because it is an integral part of the XML
29
1.0 specification. A schema written in this language is commonly referred to as a
DTD. The DTD that follows defines the tags used in the price list XML document.
It specifies four tags (elements) and further specifies which tags may occur (or
are required to occur) in other tags. The DTD also defines the hierarchical
structure of an XML document, including the order in which the tags must occur.
<!ELEMENT priceList (coffee)+>
<!ELEMENT coffee (name, price) >
<!ELEMENT name (#PCDATA) >
<!ELEMENT price (#PCDATA) >
The first line in the example gives the highest level element, priceList,
which means that all the other tags in the document will come between the
<priceList> and </priceList> tags. The first line also says that the priceList
element must contain one or more coffee elements (indicated by the plus sign).
The second line specifies that each coffee element must contain both a name
element and a price element, in that order. The third and fourth lines specify that
the data between the tags <name> and </name> and between <price> and
</price> is character data that should be parsed. The name and price of each
coffee are the actual text that makes up the price list.
Another popular schema language is XML Schema, which is being
developed by the World Wide Web (W3C) consortium. XML Schema is a
significantly more powerful language than DTD, and with its passage into a W3C
Recommendation in May of 2001, its use and implementations have increased.
What Makes XML Portable?
30
A schema gives XML data its portability. The priceList DTD, discussed
previously, is a simple example of a schema. If an application is sent a priceList
document in XML format and has the priceList DTD, it can process the document
according to the rules specified in the DTD. For example, given the priceList
DTD, a parser will know the structure and type of content for any XML document
based on that DTD. If the parser is a validating parser, it will know that the
document is not valid if it contains an element not included in the DTD, such as
the element <tea>, or if the elements are not in the prescribed order, such as
having the price element precede the name element.
Other features also contribute to the popularity of XML as a method for
data interchange. For one thing, it is written in a text format, which is readable by
both human beings and text-editing software. Applications can parse and
process XML documents, and human beings can also read them in case there is
an error in processing. Another feature is that because an XML document does
not include formatting instructions, it can be displayed in various ways. Keeping
data separate from formatting instructions means that the same data can be
published to different media.
XML enables document portability, but it cannot do the job in a vacuum;
that is, parties who use XML must agree to certain conditions. For example, in
addition to agreeing to use XML for communicating, two applications must agree
on the set of elements they will use and what those elements mean. For them to
use Web services, they must also agree on which Web services methods they
will use, what those methods do, and the order in which they are invoked when
31
more than one method is needed. Enterprises have several technologies
available to help satisfy these requirements. They can use DTDs and XML
schemas to describe the valid terms and XML documents they will use in
communicating with each other. Registries provide a means for describing Web
services and their methods. For higher level concepts, enterprises can use
partner agreements and workflow charts and choreographies.
4.4 SOAP
Simple Object Access Protocol is a lightweight protocol intended for
exchanging structured information in a decentralized, distributed environment.
SOAP�s place in the web services technology stack is as a standardized
packaging protocol for the messages shared by the applications. The
specification defines nothing more than a simple XML-based envelope for the
information being transferred, and a set of rules for translating application and
platform-specific data types into XML representations. SOAP's design makes it
suitable for a wide variety of application messaging and integration patterns.
This, for the most part, contributes to its growing popularity. Two major design
goals for SOAP are simplicity and extensibility. SOAP attempts to meet these
goals by omitting, from the messaging framework, features that are often found in
distributed systems.
SOAP is a flavor of XML, which means that everything in SOAP is 100%
XML.
SOAP = XML
32
It uses XML technologies to define an extensible messaging framework
providing 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.
The major goal of SOAP is to be able to invoke remote procedure calls
over the Web. Every SOAP document contains XML and nothing but XML. SOAP
is a way to communicate input parameters, which can be integers, multi-
dimensional arrays, structures, strings, and so on, as XML.
SOAP = XML + RPC
Therefore, a SOAP document is an XML document designed to invoke
methods on remote computers. The original design of SOAP demanded that
HTTP be used to transmit SOAP messages, but the latest round of the
specification opened it up to any protocol, such as FTP or SMTP. However most
of the world will be moving SOAP around over HTTP
SOAP = XML + RPC + HTTP
4.4.1 SOAP and XML
SOAP is XML. That is, SOAP is an application of the XML specification. It
relies heavily on XML standards like XML Schema and XML Namespaces for its
definition and function. XML messaging is where applications exchange
information using XML documents. It provides a flexible way for applications to
communicate, and forms the basis of SOAP. SOAP is a data format � it�s a way
to represent data as text , If you want to send a remote method some input
33
parameters that include a string, an integer and an array, the SOPA specification
tells you what the text in the SOAP message should look like. SOAP exists only
as a specification.All SOAP messages are encoded using XML. A SOAP
application SHOULD include the proper SOAP namespace on all elements and
attributes defined by SOAP in messages that it generates. A SOAP application
MUST be able to process SOAP namespaces in messages that it receives. It
MUST discard messages that have incorrect namespaces and it MAY process
SOAP messages without SOAP namespaces as though they had the correct
4.4.2 SOAP namespaces
The required SOAP Envelope element is the root element of a SOAP
message. It defines the XML document as a SOAP message.Note the use of the
xmlns:soap namespace. It should always have the value of:
http://www.w3.org/2001/12/soap-envelope and it defines the Envelope as a
SOAP Envelope. A SOAP message must always have an Envelope element
associated with the http://www.w3.org/2001/12/soap-envelope namespace . If a
different namespace is used, the application must generate an error and discard
the message.
4.4.3 SOAP Messages
A SOAP message consists of an envelope containing an optional header
and a required body. The header contains blocks of information relevant to how
the message is to be processed. This includes routing and delivery settings,
authentication or authorization assertions, and transaction contexts.
34
The body contains the actual message to be delivered and processed.
Anything that can be expressed in XML syntax can go in the body of a
message.The XML syntax for expressing a SOAP message is based on the
�http://www.w3.org/2001/06/soap-envelope namespace�. This XML namespace
identifier points to an XML Schema that defines the structure of what a SOAP
message looks like.
A SOAP message is an ordinary XML document containing the following
elements:
• A required Envelope element that identifies the XML document as a SOAP
message
• An optional Header element that contains header information
• A required Body element that contains call and response information
• An optional Fault element that provides information about errors that
occurred while processing the message
• All the elements above are declared in the default namespace for the
SOAP envelope: http://www.w3.org/2001/12/soap-envelope and the
default namespace for SOAP encoding and data types is:
http://www.w3.org/2001/12/soap-encoding
The following are some of the important syntax rules in SOAP messaging:
• A SOAP message MUST be encoded using XML
• A SOAP message MUST use the SOAP Envelope namespace
• A SOAP message MUST use the SOAP Encoding namespace
• A SOAP message must NOT contain a DTD reference
35
• A SOAP message must NOT contain XML Processing Instructions
Skeleton SOAP Message
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
4.5 WSDL
Web Services Description Language (WSDL) is an XML format for
describing network services as a set of endpoints operating on messages
containing either document-oriented or procedure-oriented information. In simple
words WSDL is an XML- based language whose goal is to describe webservices
in a computer readable form. The application on reading a WSDL file should
36
know everthing it needs in order to communicate with the WebService
successfully. For example your application needs to know the structure of the
input parameters, which data format the webservice can understand, where the
webservice lives and so on.
As communications protocols and message formats are standardized in
the web community, it becomes increasingly possible and important to be able to
describe the communications in some structured way. WSDL addresses this
need by defining an XML grammar for describing network services as collections
of communication endpoints capable of exchanging messages. WSDL service
definitions provide documentation for distributed systems and serve as a recipe
for automating the details involved in applications communication. A WSDL
document defines services as collections of network endpoints, or ports. In
WSDL, the abstract definition of endpoints and messages is separated from their
concrete network deployment or data format bindings. This allows the reuse of
abstract definitions: messages, which are abstract descriptions of the data being
exchanged, and port types which are abstract collections of operations. The
concrete protocol and data format specifications for a particular port type
constitutes a reusable binding. A port is defined by associating a network
address with a reusable binding, and a collection of ports define a service.
Hence, a WSDL document uses the following elements in the definition of
network services:
• Types� a container for data type definitions using some type system (such
as XSD).
37
• Message� an abstract, typed definition of the data being communicated.
• Operation� an abstract description of an action supported by the service.
• Port Type�an abstract set of operations supported by one or more
endpoints.
• Binding� a concrete protocol and data format specification for a particular
port type.
• Port� a single endpoint defined as a combination of a binding and a
network address.
• Service� a collection of related endpoints.
The operations and messages are described abstractly, and then bound to
a concrete network protocol and message format to define an endpoint. Related
concrete endpoints are combined into abstract endpoints (services). WSDL is
extensible to allow description of endpoints and their messages regardless of
what message formats or network protocols are used to communicate. WSDL is
extensible, which means you can create your own tags to describe whatever data
format you like (like SOAP) and your transfer protocol of choice ( like HTTP). In
fact if the application is using anything besides HTTP and SOAP, then it has to
design its own tags. WSDL exists because its vital. Not describing and not
documenting a webservice is like constructing the webservice in a secret place
and not informing anyone where it is, what is in it and how to access it. The
following are some details that a WSDL document specifies
• Data Types : The data types the method is expecting, such as integers,
strings, arrays etc. These data types are defined inside the
38
<types> element or in an external XML Schema
• Structure of input, output parameters : It specifies the structure, for
example, the SOAP message message may contain
<getPrice>
<symbol>PSFT</symbol>
</getPrice>
OR
<getLastTradePrice>PSFT></getLastTradeprice>
• Input and output parameters : WSDL document must specify as to what is
an input and what is an output. This type of definition is known as an
operation.
• Pairing input and output parameters : WSDL document also defines what
input and output parameters are associated wth each other. These groups
are known as port types.
• Transport protocol and data format : The association of port types with
protocols and data formats is known as binding. Most webservices use the
protocol HTTP and data format as SOAP
• Web Address of the web service : The actual URL address is known as
port. The part of WSDL that defines a port is known as service.
4.6 UDDI
In Simple words UDDI (Universal Description Discovery and Integration )
is nothing but a web-based distributed directory that enables businesses to list
39
themselves on the Internet and discover each other, similar to a traditional phone
book's yellow and white pages.
Given the assumption that WebServices will become popular, businesses
will have several needs such as to:
• Discover each other�s Web Services
• Expose the WebServices to the world in such a waythat other businesses
can find and use
• make the needs and capabilities of WebServices known
There are several things keeping WebServices from becoming widely
deployed. Many existing systems that connect businesses take completely
different and incompatible paths. Moreover businesses have to make large
investments of time and money in order to securely connect their business, and
only businesses that happened to invest in the same technology can
communicate with each other. The UDDI protocol is one of the major building
blocks required for successful Web services. The main purpose of UDDI is to
make WebServices discoverable – that is, to provide a programmatic way for
people to find and use a certain webservice. UDDI creates a standard
interoperable platform that enables companies and applications to quickly, easily,
and dynamically find and use Web services over the Internet. UDDI also allows
operational registries to be maintained for different purposes in different contexts.
UDDI is a cross-industry effort driven by major platform and software providers,
as well as marketplace operators and e-business leaders.Not only does it provide
a way for webservices to be discovered and used, but its also built on
40
open standards. UDDI takes advantage of WorldWide Web Consortium (W3C)
and Internet Engineering Task Force (IETF) standards such as Extensible
Markup Language (XML), and HTTP and Domain Name System (DNS)
protocols. Additionally, cross platform programming features are addressed by
adopting early versions of the proposed Simple Object Access Protocol (SOAP)
known as XML Protocol messaging specifications found at the W3C Web site. All
communication with UDDI is done via SOAP messages over HTTP. The UDDI
protocol is the building block that will enable businesses to quickly, easily and
dynamically find and transact with one another using their preferred applications.
4.6.1 Businesses benefit from UDDI
• Businesses of all sizes can benefit from UDDI, because the specifications
comprehensively addresses problems that limit the growth and synergies
of B2B commerce and Web services.
• The UDDI project is not industry-specific. Any industry, worldwide, offering
products and services can benefit from this open initiative.
• Before the UDDI project, there was no industry-wide, accepted approach
for businesses to reach their customers and partners with information
about their products and Web services. Nor was there a method of how to
integrate into each other's systems and processes.
4.6.2 Problems the UDDI specification can help to solve:
• Making it possible for organizations to quickly discover the right business
from millions currently online
41
• Defining how to enable commerce to be conducted once the preferred
business is discovered
• Immediate benefits of the UDDI project for businesses include:
• Reaching new customers
• Expanding offerings
• Extending market reach
• Increasing access to current customers
• Solving customer-driven need to remove barriers to allow for rapid
participation in the global Internet economy
• Describing their services and business processes programmatically in a
single, open, and secure environment
• Using a set of protocols that enable businesses to invoke services over
the Internet to provide additional value to their preferred customers.
UDDI was created to provide a way for businesses to list not only their
webservices, but also basic business information, like business name, address,
contact info, information about the categories the business is in and technical
information about the webservice. The descriptions of webservices and their
businesses live in a place called the UDDI Business Registry.
A business can register a webservice with the Business Registry ( list the
businesses and what it does, along with the webservice and its interface) which
is called publishing and also find a webservice according to some set of
parameters which is called inquiring.
42
An entry in the UDDI Business registry can be conceptually placed in
three areas :
• White pages : Basic Business information
• Yellow pages : Business and Service classification
• Green pages : Technical and interface information
4.6.3 Registering for UDDI
As the UDDI specification has evolved, this functionality was able to go
online. Registering enables a company to publicly list basic information about
their company and offerings. There will also be the option to list a catalog of
products, services and guidelines for engagement. Registered companies will
then be accessible in searches by potential buyers and marketplaces. As
registrants, integration will be significantly easier and more dynamic for
companies transacting business with each other.
4.6.4 Searching UDDI
As the UDDI specification has evolved, this functionality was able to go
online. Registered companies are accessible in searches by potential buyers and
marketplaces.
43
CHAPTER V
JAX-RPC (JAVA API FOR XML BASED RPC) WEB SERVICES
JAX-RPC stands for Java API for XML-based RPC. It's an API for building
Web services and clients that use remote procedure calls (RPC) and XML. Often
used in a distributed client/server model, an RPC mechanism enables clients to
execute procedures on other systems. In JAX-RPC, a remote procedure call is
represented by an XML-based protocol such as SOAP. The SOAP specification
defines the envelope structure, encoding rules, and convention for representing
remote procedure calls and responses. These calls and responses are
transmitted as SOAP messages (XML files) over HTTP.
Although SOAP messages are complex, the JAX-RPC API hides this
complexity from the application developer. On the server side, the developer
specifies the remote procedures by defining methods in an interface written in the
Java programming language. The developer also codes one or more classes that
implement those methods. Client programs are also easy to code. A client
creates a proxy, a local object representing the service, and then simply invokes
methods on the proxy. With JAX-RPC, the developer does not generate or parse
SOAP messages. It is the JAX-RPC runtime system that converts the API calls
and responses to and from SOAP messages. With JAX-RPC, clients and Web
services have a big advantage--the platform independence of the Java
programming language. In addition, JAX-RPC is not restrictive: a JAX-RPC client
can access a Web service that is not running on the Java platform and vice
44
versa. This flexibility is possible because JAX-RPC uses technologies defined by
the World Wide Web Consortium (W3C): HTTP, SOAP, and the Web Service
Description Language (WSDL). WSDL specifies an XML format for describing a
service as a set of endpoints operating on messages. JAX-RPC makes it easy to
develop Web services and clients because it shields application developers from
the underlying SOAP messages. Instead of writing code to build and parse
SOAP messages, application developers merely implement the service methods
and invoke them from remote clients. The handler processing is hidden from the
JAX-RPC client and service implementation code.
Behind the scenes, JAX-RPC maps types of the Java programming
language to XML/WSDL definitions. For example, JAX-RPC maps the
java.lang.String class to the xsd:string XML data type. Application developers
don't need to know the details of these mappings, but they should be aware that
not every class in the Java 2 Platform, Standard Edition (J2SE) can be used as a
method parameter or return type in JAX-RPC.
5.1 J2SE SDK CLASSES
JAX-RPC supports the following J2SE SDK classes:
java.lang.Boolean
java.lang.Byte
java.lang.Double
java.lang.Float
java.lang.Integer
45
java.lang.Long
java.lang.Short
java.lang.String
java.math.BigDecimal
java.math.BigInteger
java.net.URI
java.util.Calendar
java.util.Date
5.2 Primitives
JAX-RPC supports the following primitive types of the Java programming
language:
Boolean
Byte
double
float
int
long
short
5.3 Arrays
JAX-RPC also supports arrays with members of supported JAX-RPC
types. Examples of supported arrays are int[ ] and String[ ]. Multidimensional
arrays, such as BigDecimal[ ][ ], are also supported.
46
5.4 Value Types
A value type is a class whose state may be passed between a client and
remote service as a method parameter or return value. For example, in an
application for a university library, a client might call a remote procedure with a
value type parameter named Book, a class that contains the fields Title, Author,
and Publisher. To be supported by JAX-RPC, a value type must conform to the
following rules:
• It must have a public default constructor.
• It must not implement (either directly or indirectly) the java.rmi.Remote
interface.
• Its fields must be supported JAX-RPC types.
• The value type may contain public, private, or protected fields.
The field of a value type must meet these requirements:
• A public field cannot be final or transient.
• A non-public field must have corresponding getter and setter methods.
JAX-RPC also supports several implementation classes of the
java.util.Collection interface.
Java.util.Collection Subinterface Implementation Classes
47
List
ArrayList
LinkedList
Stack
Vector
Map
HashMap
Hashtable
Properties
TreeMap
Set
HashSet
TreeSet
1.7 Supported Classes of the Java Collections Framework
5.5 JavaBeans Components
JAX-RPC also supports JavaBeans components, which must conform to
the same set of rules as application classes. In addition, a JavaBeans
component must have a getter and setter method for each bean property. The
type of the bean property must be a supported JAX-RPC type.
48
CHAPTER VI
SKARINGA
Skaringa is an API for Java and XML language binding. It transforms Java
objects into XML documents and back, and can generate XML schema
definitions for a Java class. Typical applications are data exchange, object
persistence, object transformation, and driving XML based presentation layers.
Skaringa is designed for speed and simplicity, supporting a wide range of types.
Its core component is an Object Transformer, which is able to transform Java
objects into XML documents and vice versa.
Typical applications are:
• Data exchange with other applications which produce or consume XML.
• Object persistence to save Java objects between multiple runs of the JVM,
e.g. configuration files.
• Object transformation to transform Java objects of different types using
XSLT.
• Driving XML based presentation layers, for example Apache FOP to
generate PDF.
Skaringa consists of the parts:
• Serializer: Marshalls Java objects into XML documents.
• Deserializer: Creates Java objects from XML documents.
• XML schema generator: Generates XML schema definitions (XSD) from
Java classes. The XML documents created by the serializer can be
49
validated against those schemas.
• Transformer: Transforms Java objects of different types into each other by
using XSLT instructions and provides XML Pre- and Postprocessing.
• It is designed for simplicity, supporting a wide range of types, and speed:
• Simplicity: No code generation or »meta-programming« of definition files
are necessary.
• Supporting a wide range of types: The framework is able to process
complex Java objects including arrays, collections, and maps.
• Speed: The generation and parsing of XML documents is based on
handling of SAX events. The usage of the fast and lightweight SAX-API
results in a short processing time. For example, the complete serialization
and deserialization of an array of 10,000 integers needs about 0.2
seconds with JDK 1.4 running at an AMD Athlon XP 2800+ processor
6.1 Serializable Java types
Skaringa is able to to process complex Java objects, which may have the
the following types of member fields:
All primitive Java types and their wrappers.
• java.lang.String.
• java.util.Date.
• java.math.BigDecimal.
• java.math.BigInteger.
• Arrays.
50
• All Collection types from java.util.
• All Map types from java.util.
• Complex types, which follows this definition.
The components of arrays, collections and maps may be all types of the above
list.
6.2 XML documents
Skaringa can process XML documents which exist as Files, Streams,
Strings, DOM trees and SAX events. More exactly, all kinds of documents that
can be passed into javax.xml.transform.Source or javax.xml.transform.Result
respectively.
6.3 Handling the state of an object
The state of an object is represented by its member variables. The values
of these member variables are saved to the XML document during serialization
and restored during deserialization.
Static and transient fields are not serialized, because they don't represent
the persistent state of an object. Final variables are serialized, but can't be
restored during deserialization. We assume that class definitions don't change
between serialization and deserialization, therefore final variables get their
correct value in this definition.
The developer of a class may define and implement two additional special
functions to get more subtle control over Skaringa's serialization and
deserialization:
51
public Object skaWriteReplace();
If this function exists, it is called before an object is serialized. It may be
used to replace the object by another one, for example by one where secure data
is encrypted or where non-transient fields that should not be persisted are set to
null.
public Object skaReadResolve();
If this function exists, it is called after an object has been deserialized and
all of its non-transient member variables have been restored. This function can
be used to change the deserialized object, for example to compute transient
fields from non-transient fields.Because an object can be serialized more than
once, be careful with modifying the state of the object in skaWriteReplace. It is
guaranteed, that skaReadResolve is called only once during deserialization.
6.4 Using a certain class loader
Skaringa needs to load classes for new objects to be created during
deserialization. By default, the class loader used to load these classes is the
same class loader that has been loaded the Skaringa JAR file.
This can cause problems if different class loaders are used in an
application. For example, web containers (like Tomcat) and EJB containers (like
JBoss) have a hierarchical structure of class loaders. To work around class
loading problems in those environments it is possible to tell Skaringa which class
loader to use to load new classes. This is done by passing the class loader to the
ObjectTransformer with the method setClassLoader.
52
6.5 Properties to customize the XML output
The XML output is optimized for the processing with XML parsers and for
the requirements of deserialization. However, in some cases it may be useful to
make the resulting XML documents more human readable. This can be done by
passing additional properties to the ObjectTransformer via the method
setProperty. We already used this feature in the above example by calling
trans.setProperty(javax.xml.transform.OutputKeys.INDENT, "yes");
to insert extra line feeds into the XML output. People who use german Umlaute
in their strings may want to use another character encoding instead of the default
UTF-8, for example ISO-8859-1:
trans.setProperty(javax.xml.transform.OutputKeys.ENCODING, "ISO-8859-1");
Another important point is the existence of the xsi:type attribute for each
XML element. This attribute is necessary for further deserialization of the XML
document. We already discussed, that the actual type of an object's field may
differ from its declared type. Therefore the actual type of each field is provided
using the xsi:type attribute. This information is also necessary for the members of
collections and maps, because the type of these members is always declared as
java.lang.Object in the Java language.
However, if the Java objects in a concrete application don't make use of
these features or if you don't intend to deserialize the XML documents later, then
adding the xsi:type attribute to each XML element may be unnecessary and
disturbing. In this case, using
trans.setProperty(com.skaringa.javaxml.PropertyKeys.OMIT_XSI_TYPE, "true");
53
will shorten the XML output and enhance its readability dramatically. The XML is
still deserializable in this case, if the actual types of all member fields match their
declared types, and no collections and maps are used (take arrays instead!).
6.6 Field order
The order of the fields in the XML output follows the general rule, that
fields declared in the base class appear before the fields declared in the class
itself.
The fields of a class are not in any particular order. This is no problem in
most cases, where only serialization and deserialization is used. But if the XML
instance is validated against a schema, then field order may cause problems if
schema and instance are generated at different platforms or with different
versions of the JVM.Additionally, there are two possible methods to influence the
field order for those who want more control.
6.7 Lexicographical field order
If the property com.skaringa.javaxml.PropertyKeys.SORT_FIELDS is
passed to the transformer, then the fields declared in one class are serialized in
the lexicographical order of their names.
54
CHAPTER VII
SORCER WEB SERVICES INTEGRATION FRAMEWORK (SWIF)
7.1 Introduction
This section defines the integration framework for SORCER service
requestors as well as WebService clients. The principal focus of this design is to
integrate the RPC WebService technology into the SORCER environment. Since
RPC WebServices technology is protocol based and provides portablility,
interoperability and support for open standards where as Service Oriented
Computing Environment(SORCER) is object based and envisions a Service-to-
Service(S2S) environment , a Jobber with a Web Services Dispatcher is used to
develop an integration framework that allows Protocol-based RPC Web Services
and Object-oriented SORCER service providers to coexist and complement each
other in the same environment.
The SORCER Web Services Integration framework (SWIF) with the
Jobber would allow SORCER Services to be accessed both as RPC
WebServices and SORCER Service Providers for SORCER Service requestors.
The SORCER Web Services Integration Framework also contains a gateway
SWIFServlet which is part of a gateway web service component which enables
RPC Web Service clients to contact both SORCER Providers and RPC Web
Services seamlessly using ServiceContext as the data specification thus
integrating the protocol based web services and clients with object based
SORCER requestors and providers.
55
7.2 Objective / Approach
�RPC Web Services and SORCER service providers can coexist and
complement each other in the same environment�
The approach for this generic framework is split into two parts
• Provide Jobber with a Web Service Dispatcher called
SWIFExertionDispatcher that can route SORCER Service requests to
SORCER Service Providers and route SORCER Service requests to RPC
Web Services
• The gateway component SWIFServlet, a web service gateway which
enables the Web Service client to request services from a SORCER
Service provider as well as from a RPC Web Service.
The main components of the SWIF architecture are the SORCER provider
Jobber with the web service dispatcher SWIFExertionDispatcher and the
gateway SWIFServlet.
The Jobber attends to the requests of the object based SORCER
requestors and has the functionality to direct the calls through the dispatcher
SWIFExertionDispatcher to RPC web services and service the requests for
SORCER providers as well.
The gateway SWIFServlet is part of the gateway web service that attends
to the requests of web service clients and directs the request to the required
SORCER provider or any other RPC web service. The data format specification
is the generic ServiceContext all the way through.
56
7.3 Architecture
The Integration Framework supports this hypothesis by clearly illustrating
appropriate components necessary to integrate RPC WebServices with
SORCER.grid. The design of this framework is such that there exists a generic
SORCER component for all the WebService clients to communicate with
SORCER.grid and a Web Services Dispatcher that SORCER service requestors
to communicate with RPC WebServices. The WebService clients send their
request with the necessary parameters through SWIFCall, which calls upon the
web service gateway SWIFServlet that gets the required SORCER Service
Provider or sends a RPC call to the WebService requested and collects the
results as shown in the Figure 1.8 .
The SORCER Service requestors send their request with the necessary
parameters to the Jobber, which then gets the required SORCER Service
Provider or dispatches a RPC call to the WebService requested and collects the
results. The main components that architects this design is the Web Service
Dispatcher with the Jobber and the web service gateway component,
SWIFServlet. The SWIFServlet is a servlet extended from
com.sun.xml.rpc.server.http.JAXRPCServlet that is generic for RPC WebService
client or SORCER requestor.
The following picture depicts the general system design involved in
building the Integration framework for RPC WebService and SORCER users.
SORCER.grid is a grid network where in a set of service providers are running
continuously and registered with the Jini lookup services.
57
1.8 Integration Framework
WebServices here are RPC-based Webservices which are a collection of
procedures that can be called by a remote client over the Internet. RPC style
websevices and clients use remote procedure calls and XML.
7.4 Design
The generic design of the Integration Framework has been designed to
integrate RPC WebServices to the SORCER.grid network to both access
services from grid and provide RPC WebServices to the grid. This framework
shown in Figures 1.9 and 1.10 basically extends the SOA functionality of
SORCER.grid and JAX-RPC Architecture to perform service oriented computing
with RPC WebService clients.
58
1.9 AirportWeatherRequestor
The SORCER requestor submits a job to the SORCER provider Jobber
after it downloads the proxy of the Jobber from the Jini lookup service.
1.10 SWIFClient
59
The Jobber depending on the job specification submits a job to the
respective SORCER provider or sends the request to RPC web service. The
Jobber collects the result and sends it back to the SORCER requestor
The web service client calls on the web service gateway and provides it
with a ServiceContext. The ServiceContext is serialized and is passed to the
SWIFServlet as a SOAP message over HTTP. The SWIFServlet deserializes the
data into a ServiceContext object, gets the parameters specified in the context,
calls on the requested SORCER provider and then makes a call on a remote web
service specified in the context. All the web service calls here are done as SOAP
messages over HTTP. The resultant ServiceContext is then serialized and sent
as a SOAP response over HTTP back to the web service client. On the client
side the context is deserialized and provided to the web service client.
7.5 Implementation
7.5.1 Technical Architecture
The SWIF architecture has been implemented on SORCER environments
with certain standards to meet the requirements of Service Oriented Architecture
model and web service communication thus enabling integration.
The SWIF technical architecture specifies the underlying blocks of the
framework and also the various technologies that constitute the model and
design. Built on a concrete Java platform, this architecture utilizes the
functionality of various technologies including J2EE, JAX-RPC and Jini to provide
a unified seamless design.
60
1.11 Technical Architecture
The specifications of various technologies were integrated and layered
upon each other to build the technical architecture of the SWIF framework.
Technical Architecture of SWIF framework included building a generic system for
several technologies to work collaboratively and to communicate seamlessly.
7.5.2 Package Diagram
The various functionalities in the framework were categorized and were
packaged into different sections depending up on their usage and deployment.
61
1.12 Package Diagram
The core classes of the SWIF architecture were built on the top of
SORCER classes and were packaged into. The package hierarchies and the
dependencies are shown in the Figure 1.12.
This shows how the technical architectural components are organized in
the framework to use it for validation. This architecture has served to package
the framework and the application into functionality specific packages in the
SORCER environment for better representation and reuse. The functionalities
were categorized and were packaged into different sections based specifically on
their usage and deployment
62
7.5.3 Physical Architecture
The generic design of the SORCER Web services Integration Framework
has been designed to integrate RPC WebServices to the SORCER.grid network
to both access services from grid and provide RPC WebServices to the grid.
1.13 SWIFExertionDispatcher
The main component in this figure above is the Web Services Dispatcher
SWIFExertionDispatcher. The dispatcher was built using the functionality of the
JAX-RPC Call class. This dispatcher has the functionality to invoke RPC calls on
WebServices. The SWIFExertionDispacher uses javax.xml.rpc.Call which has
setter and getter methods like setProperty(), setReturnType(),
setTargetEndpointAddress(), getProperty(), getOperationName() to set the RPC
63
call properties from the WSDL file of the WebService. The process of discovering
a SORCER Service Provider involves the ExertionDispatcher which the Jobber
uses along with the appropriate interface for that service to be discovered.
1.14 SWIF SORCER Providers
The ExertionDispatcher dispatches the exertion to the right provider for
the service using the interface provided and returns the proxy for the service to
the Jobber. The Jobber then invokes the method on the SORCER provider and
collects the result in the form of a ServiceContext.
When a SORCER client submits a job, the Jobber dispatches the job to
the respective dispatcher through the ExertionDispatcher. Depending on whether
the exertion is dropped in space or allocated a cataloger, the dispatcher
downloads the requested proxy from the Jini lookup service and invokes the
64
service to get the result. The SORCER provider performs the necessary
functions taking the ServiceContext as an input and sends back the result as a
ServiceContext,.
Based on the job description and the parameters set in the ServiceContext
the jobber dispatches the job to the SWIFExertionDispatcher which generates a
proxy based on the parameters and invokes a SOAP rpc call on the proxy. The
generated proxy is of the form javax.xml.rpc.Call object, to which parameters are
set ; for eg; Target endpoint address, the encoding style, the namespace of the
web service, the remote method name, the input parameter it takes and its data
type and so on. The method is invoked on the proxy object, the results are
collected from the requested web service and submitted back to the SORCER
client in the form of a ServiceContext.
When a WebService client requests for the service, SWIFCall serializes
the sorcer.core.ServiceContext object wich is the input parameter. This
serialization is done through the skaringa core classes. Skaringa�s
com.skaringa.javaxml.ObjectTransformer serializes the input object and writes it
to a stream. The SWIFCall object creates a SOAP message with the serialized
ServiceContext as a parameter. This request is passed over HTTP to the
gateway as an HTTP SOAP request. The web service gateway component
SWIFServlet, delegates the request to SWIFServletDelegate.
The SWIFServletDelegate extracts the input from the SOAP message and
then using ObjectTransformer deserializes the ServiceContext. The parameters
specified in the ServiceContext are then examined and ServiceProviderAccessor
65
is used to download the right service proxy and invoke the requested method on
the proxy.
1.15 Web service Client
The gateway then collects the resultant ServiceContext and extracts the
output from it. The gateway then invokes an rpc call on the requested web
service by generating a proxy & invoking the requested method on it.
javax.xml.rpc.Call object is used to generate a proxy. The Call object takes in
some parameters to generate a proxy.
The target enpoint address, properties like the SOAP uri property, SOAP
use property, the operation name i.e.; the method name, the encoding style, the
method name, the input parameter for the method and its return data type need
to be specified to the Call object.
66
The process of accessing RPC WebService involves the SWIFCall class
invoking a RPC call on the WebService using the appropriate parameters. For
example, setTargetEndpointAddress() is used to specify the location of the
WebService, setProperty() is used to specify if the operation type of this call is
RPC or Document style, or if the RPC call should use SOAP, the encoding style
used in this RPC call, the data type of the input parameter and so on. The
method setReturnType() is used to specify the data type of the result.
The method with the input parameter is then invoked on the proxy and the
result collected. The invokation takes place in the form of a HTTP SOAP request.
The result is extracted from the SOAP response and inserted into a
ServiceContext which is then serialized using the ObjectTransformer and sent
back as a SOAP message back to WebService client as a HTTP SOAP
response. On the client side the SWIFCall deserializes the result into a
sorcer.core.ServiceContext object. Through the whole framework the requests
from the clients basically goes as a SOAP request using the SOAP protocol
standards and as a HTTP request using the HTTP protocol standards and the
service result is returned back by the same mechanism.
The gateway generates a RPC call with the information provided and
invokes a RPC call on the specified WebService. This request is sent as a SOAP
message over HTTP as a HTTP SOAP request. The gateway receives the
response as a HTTP SOAP response, extracts the result from the SOAP
message and provides the WebService client or the SORCER requestor with the
result.
67
7.6 Validation
The following section describes a WebService application that would
validate the Integration framework designed for SORCER requestors and
WebService clients. This application utilizes the SORCER Web service
Integration Framework both to invoke RPC calls on the RPC WebService as well
as invoke method calls on the SORCER Service Providers.
Validating the framework is carried out as a two fold process which are
described as follows.
• SORCER Requestor : Sorcer Service Requestor in the form of an user
interface AirportWeatherRequestorUI requesting international airport
codes from the SORCER Service Provider, AirportCodesProvider through
the Jobber and the invoking a RPC call using an international airport code
on the Airport Weather WebService. This task is accomplished through
the Jobber object which dispatches jobs to the respective dispatchers,
SWIFExertionDispatcher in case of web service request
• WebService Client : WebService client SWIFClient requesting
international airport codes from the SORCER Service Provider,
AirportCodesProvider and the invoking a RPC call using an international
airport code on the remote WebService Airport Weather. This task is
accomplished through the gateway SWIFServlet which takes care of
serialization and deserialization as well. The SWIFCall object is used for
serialization and deserialization on the client side.
68
7.6.1 SORCER Requestor :
The SORCER Service Provider is the AirportCodesProvider with the
interface AirportRemote. The AirportCodesProvider takes in a string i.e.; the state
name and provides the international airport codes present in that state. The
SORCER requestor here in the form of a user interface
AirportWeatherRequestorUI downloads a Jobber proxy and through the Jobber
dispatches the job to the respective dispatcher,
SpaceSequentialExertionDispatcher in this case.
1.16 AirportWeatherRequestorUI
The dispatcher downloads a proxy of the AirportCodesProvider and
dispatches an exertion to the Provider and receives the international airport
codes in the state specified. An airport code is extracted from the result context
and a Call proxy is generated through the SWIFExertionDispatcher. The
69
SORCER requestor AirportWeatherRequestorUI then through the Jobber
dispatches an RPC call with the international airport code as a parameter and
invokes a RPC call on the AirportWeather WebService available at
http://live.capescience.com/ccx/AirportWeather.
1.17 The Jobber getting the codes from SORCER Provider
The Jobber dispatches this job to the SWIFSequentialDispatcher through
the SWIFExertionDispatcher.
The dispatcher gathers the parameters provided in the context and
creates a proxy of the type javax.xml.rpc.Call and invokes the requested method
on the proxy. Some of the parameters set on Call object are the target endpoint
70
address, the encoding style, the endpoint namespace, method name, the input
parameter and its data type.
1.18 The SORCER Provider providing the codes
The Call object then generates a SOAP message with the method call to
be passed as a SOAP request over HTTP. The Call object requires certain
parameters set like the target endpoint address, the encoding style, the
namespace of the remote web service, the method name, the input parameter,
its data type and so on.
The method is then invoked on the Call proxy with the input parameter.
The SWIFExertionDispatcher then collects the response from the
71
WebService once the AirportWeather WebService sends back the result as a
HTTP SOAP response.
1.19 The AirportWeatherRequestorUI showing the codes
The dispatcher then extracts the result from the SOAP message and
provides it to the SORCER requestor, AirportWeatherRequestorUI, in the form of
a ServiceContext, be it the sky conditions at the airport or the humidity or
temperature.
7.6.2 WebService Client :
The WebService client SWIFClient through the SWIFCall generates a
proxy to call on the SORCER Service Provider AirportCodesProvider using a
parameter set to the ServiceContext passing it the string
�sorcer.provider.airport.AirportRemote� which is the interface of the SORCER
72
Service Provider. SWIFCall serializes the sorcer.core.ServiceContext object
which is the input parameter. This serialization is done through the skaringa core
classes. Skaringa�s com.skaringa.javaxml.ObjectTransformer serializes the input
object and writes it to a file stream.
1.20 The Jobber getting result from remote web service
The contents of the file stream are taken as a string and passed as a
parameter in the generated SOAP request. The SOAP message is created with
the serialized ServiceContext as a string parameter. This request is passed over
HTTP to the gateway SWIFServlet as an HTTP SOAP request. The web service
gateway component SWIFServlet, delegates the request to
73
SWIFServletDelegate. The SWIFServletDelegate extracts the input from the
SOAP message and then using ObjectTransformer deserializes the string
parameter into a ServiceContext object.
1.21 AirportWeatherRequestorUI displaying result
The parameters specified in the ServiceContext are then examined and
ServiceProviderAccessor is used to download the right AirportCodesProvider
proxy and invoke the �codes� method on the proxy. The gateway then collects
the resultant ServiceContext and extracts the output from it.
The gateway then invokes an rpc call on the requested remote Airport
Weather web service by generating a proxy & invoking the requested method on
it. javax.xml.rpc.Call object is used to generate a proxy. The Call object takes in
some parameters to generate a proxy. The target enpoint address is the address
specified by the url http://live.capescience.com/ccx/AirportWeather,
74
capeconnect:AirportWeather:com.capeclear.weatherstation.Station as the body
namespace value, javax.xml.rpc.encodingstyle.namespace.uri as the encoding
style,, the operation name i.e.; getSkyConditions() or getTemperature() or
getLocation(), the input parameter for the method ,extracted from the resultant
context which is the name of a state, the return data type , string need to be
specified to the Call object.
1.22 SWIFServlet gateway Web Service End point
The WebService client SWIFClient gets the AirportWeather WebService
details from the WSDL provided at the location
75
http://live.capescience.com/wsdl/AirportWeather.wsdl. The WebService client
gets details like the data type of the input and the return type, where the endpoint
of the WebService is and so on.
1.23 The WSDL file of the gateway Web service
The getLocation method with the input parameter is then invoked on the
proxy and the result collected. The invokation takes place in the form of a HTTP
SOAP request. The result is extracted from the SOAP response and inserted into
a ServiceContext. The ServiceContext is then serialized using the
ObjectTransformer to a file stream. The contents of the file stream are the
collected as a string and sent back as a SOAP message back to WebService
76
client SWIFClient as a HTTP SOAP response. On the client side the SWIFCall
deserializes the result string into a sorcer.core.ServiceContext object using
skaringa�s ObjectTransformer.
1.24 SWIFClient getting result from SWIFServlet
The result is then extracted from the ServiceContext and provided to the
Web Service Client SWIFClient. Through the whole framework the requests from
the clients basically goes as a SOAP request using the SOAP protocol standards
and as a HTTP request using the HTTP protocol standards and the service result
is returned back by the same mechanism. The Web Service Gateway
SWIFServlet intercepts the call and communicates with requested Web Services.
77
7.6.3 Testing & Results
This entire application has been successfully tested and the results have
proven to be extremely satisfied. The following key points have been noted
during testing.
• The WebService client SWIFClient was successfully able to use the
webservice gateway SWIFServlet to download a proxy of the
AirportCodesProvider and invoke method calls on the proxy passing it a
string, state name, to get the international airport codes in that state.
• The WebService client through Web Service gateway SWIFServlet was
able to invoke the RPC calls on the remote WebService AirportWeather
and get results successfully.
• The SORCER requestor AirportWeatherRequestorUI was able to submit a
job to the Jobber. The Jobber was able to dispatch the job to the
SpaceSequentialDispatcher which was able to download a proxy of the
AirportCodesProvider from the lookup services successfully and invoke
method calls on the proxy to get international airport codes for different
state names.
• The SORCER requestor AirportWeatherRequestor was successfully able
invoke RPC calls on the WebService AirportWeather through the Jobber.
The Jobber was able to dispatch the web service job to the
SWIFExertionDispatcher and get results for different methods provided by
the WebService such as getSkyConditions(), getHumidity() and so on.
78
CHAPTER VIII
FUTURE RESEARCH
The present research was conducted with the Dynamic Invocation
Interface WebService client in mind. There were no stubs involved for RPC calls
on the WebService. The other type of clients involved in the RPC web service
technology are the static stub clients and the dynamic proxy clients. The
SORCER Web service Integration Framework can be further extended to
incorporate Static Stub Clients where stubs are generated before RPC calls are
made, and Dynamic Proxy WebService Clients where stubs are generated during
runtime.
The client can be extended to query the UDDI for the WSDL file and
generate a RPC call based on the parameters specified in the WSDL file during
runtime. In this way the client would not have to specify the parameters to the
RPC call explicitly. The SWIF framework can be further extended to invoke one
way calls on the WebService.
Security has always been foremost important factor for any network
transactions and communications over the network. This Integration framework
though has been tested successfully with a both SORCER requestors and
WebService clients still lacks the secure communication through endpoints and
thus the framework can be further extended to make the communication more
secure.
79
CHAPTER IX
CONCLUSION
SORCER is service centric where as WebServices are protocol based.
With WebServices becoming prominent in today�s Enterprise world, the
integration of WebServices into existing environments is becoming more and
more important. Service Oriented Architecture is a service based or rather object
based architecture and a programming model, a way of thinking about building
software to support all kinds of devices. The conceptual model of SORCER is
generic Service Oriented Architecture and can be implemented on any platform
that supports discovery and join protocols. My research has extended this
Service Oriented Architecture of SORCER to integrate protocol based
WebServices into Service Oriented Computing. This SORCER Web service
Integration framework supports both the WebService clients and SORCER
requestors without any platform barriers. This framework integrates the RPC
WebService technology into SORCER.grid network in such a way that clients can
acces both the SORCER Service Providers as well as WebServices with no
differentiation. Future extensions of this framework will lead us to witness
protocol based WebServices becoming more and more a part of service oriented
environments.
80
GLOSSARY / ACRONYMS
SORCER Service-Oriented Computing Environment.
SOP Service-Oriented Programming
SOA Service-Oriented Architecture
RMI Remote Method Invocation
XML Extensible Markup Language
SOAP Simple Object Access Protocol
WSDL Web Services Description Language
UDDI Universal Discovery Description & Integration
JAX-RPC Java API for XML � RPC
SWIF SORCER Web services Integration Framework
HTTP Hyper Text Transfer Protocol
TCP/IP Transmission Control Protocol/Internet Protocol
81
REFERENCES
[1] FIPER (Federated Intelligent Product Environment) [online] [cited 2002 March
22]. Available at URL: http://www.oai.org/pages/SORCER.html. The Federated Intelligent Product Environment (FIPER) � Project Brief. [Online] 1999 [cited 2002 March 22]. Available at http://www.atp.nist.gov/www/comps/briefs/9901309.htm
[2] Röhl, P.J. & Kolonay, R.M., et al. (2000). Federated Intelligent Product
Environment, American Institute of Aeronautics and Astronautics Inc. [3] Edwards, W.K. (2000). Core Jini, 2nd ed., Prentice Hall, ISBN: 0-13-089408. [4] Oaks, S. & Wong, H. (2000). Jini in a Nutshell, O�Reilly, ISBN:1-56592-759-1. [5] Koch, G. & Loney, K. (1995). Oracle: The Complete Reference, 3rd ed.,
Oracle Press, ISBN: 0-07-882097-9. [6] Grand, M. (1999). Patterns in Java, Volume 1, Wiley, ISBN: 0-471-25841-5 [7] Reese, G. (2000). Database Programming with JDBC and Java, 2nd ed.,
O�Reilly, ISBN: 1-56592-616-1. [8] Jini Architecture Specification. [online] 2000 [cited 2002 March 22]. Available
at URL: http://www.sun.com/jini/specs/jini1_1.pdf. [9] A Collection of Jini Technology Helper Utilities and Services. [Online] 2000
[cited 2002 March 22] Available from URL: http://www.sun.com/jini/specs/collection1_1.pdf.
[10] Zhao, S. & Sobolewski, M. (2001). �Context Model Sharing in the SORCER Environment� (forthcoming) [11] JavaTM Remote Method Invocation (RMI) [online] [cited 2002 March 22]. Available at URL: http://java.sun.com/products/jdk/rmi/ [12] Freeman, E., Hopfer, S., & Arnold, K.(1999), Javaspaces� Principles, Patterns, and Practice, Addison-Wesley, ISBN: 0-201-30955-6. [13] Hunter, J. & Crawford, W. (1998). Java Servlet Programming, O�Reilly, ISBN: 1-56592-391-X. [14] Lapinski, M & Sobolewski, M. (2002). �Managing Notifications in a Federated S2S Environment�.
82
[15] Röhl, P.J., Raymond Kolonay, R.M., Irani, R.K., Soboleweski, M., & Kao, K. A Federated Intelligent Product Environment, AIAA-2000-4902, 8th AIAA/USAF/NASA/ISSMO Symposium on Multidisciplinary Analysis and Optimization, Long Beach, CA, September 6-8, 2000. [16] Federated Intelligent Product Environment. (1999). Technical Proposal to National Institute of Standards and Technology. Ohio Aerospace Institute, General Electric, BFGoodrich, Parker Hannifin, Engineous Software, Ohio University, Stanford University. [17] Web Services Architecture: W3C Working Group Note 11 Feb 2004. Retrieved November 2004 from world wide web consortium website: http://www.w3.org/TR/ws-arch [18] Building Web Services with JAX-RPC. Retrieved November 2004 from Sun Microsystems website: http://java.sun.com/xml/jaxrpc/overview.html [19] WebServices Architectural Patterns: Kevin Mitchell, Agogo Networks, Inc. December 2002. Retrieved November 2004 from Idealliance Enterprises website: http://www.idealliance.org/papers/xml02/dx_xml02/papers/03-02-03/03-02-03.html [20] Dan Livingston (2002) �Advanced SOAP for Web Development �, Prentice Hall PTR, ISBN: 0-13-035655-7 [21] XML and WebServices. Benoit Marchal, April 12 2002. Retrieved December 2004 from Informit website: http://www.informit.com/articles/article.asp?p=29975&redir=1 [22] Foundations of WebServices. Retrieved December 2004 from perfectxml website: http://www.perfectxml.com/WebSvc1.asp [22] Skaringa, API for Java, XML Binding . Retrieved December 2004 from Skaringa website: http://www.skaringa.com [23] Structure of SOAP Message. Retrieved january 2005 from w3schools website:http://www.w3schools.com [24] WebService Architecture: Pavel Kulchenko January 09, 2002. Retrieved january 2005 from O�Rielly web services website: http://webservices.xml.com/pub/a/ws/2002/01/09/soap.html [25] SOAP Specification (Using SOAP for RPC) section 7 of the SOAP 1.1 specification 24 june 2003. Retrieved November 2004 from world wide web consortium website: http://www.w3c.org/TR/SOAP
83
[26] Advantages of Service Oriented programming: Jim Waldo . Retrieved january 2005 from Sun Microsystems website: http://java.sun.com/developer/technicalArticles/jini/protocols.html [27] Advantages of Jini over globus. Retrieved january 2005 from CCLRC e-Science Centre and Grids.ac.uk website : http://tyne.dl.ac.uk/ReDRESS/WebServices/webServices_doc/node11.htm
84
APPENDICES
A. SORCER WEB SERVICES INTEGRATION FRAMEWORK INTERFACES
package sorcer.provider.webservice; import sorcer.core.*; import sorcer.base.*; import sorcer.util.*; import java.rmi.*; public interface AirportWeatherInterface { public ProviderContext temp(ProviderContext context) throws RemoteException; public ProviderContext humid(ProviderContext context) throws RemoteException; public ProviderContext loc(ProviderContext context) throws RemoteException; public ProviderContext wind(ProviderContext context) throws RemoteException; public ProviderContext pressure(ProviderContext context) throws RemoteException; public ProviderContext sky(ProviderContext context) throws RemoteException; public ProviderContext visible(ProviderContext context) throws RemoteException; public ProviderContext getCodes(ProviderContext context) throws RemoteException; }
package sorcer.provider.webservice; import sorcer.core.*; import sorcer.util.*; import java.rmi.*; public interface AirportWeatherRemote extends Remote, AirportWeatherInterface { }
85
package sorcer.provider.airport; import sorcer.core.*; import sorcer.base.*; import sorcer.util.*; import java.rmi.*; public interface AirportInterface { public ProviderContext codes(ProviderContext context) throws RemoteException; }
package sorcer.provider.airport; import sorcer.core.*; import sorcer.util.*; import java.rmi.*; public interface AirportRemote extends Remote, AirportInterface { }
package swifservice; import java.rmi.Remote; import java.rmi.RemoteException; import java.util.*; import sorcer.base.*; public interface SWIFIF extends Remote { public String execute(String s) throws RemoteException; }
86
B. SORCER WEB SERVICES INTEGRATION FRAMEWORK JAVA
DOCUMENTATION
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
sorcer.provider.webservice Interface AirportWeatherInterface All Known Subinterfaces: AirportWeatherRemote All Known Implementing Classes: AirportWeatherProviderImpl
public interface AirportWeatherInterface AirportWeatherInterface is the Provider Inteface contaning methods that allow a SORCER service requestor to submit jobs for SORCER Service Providers as well as remote web services. This Interface contains methods that take in a ProviderContext and based on the parameters in the ProviderContext submits a job to the Jobber that dispatches the job to the requested remote web service through the dispatcher SWIFExertion and to the SORCER Service Provider through SpaceExertionDispatcher. Author: Kiran Masapari
Method Summary sorcer.core.ProviderContext getCodes(sorcer.core.ProviderContext context)
Returns a ProviderContext object that contains the international airport codes in the state that is specified in the input ProviderContext.
sorcer.core.ProviderContext humid(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing humidity at the aiport which the airprt code specfies.
sorcer.core.ProviderContext loc(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing location at the aiport which the airprt code specfies.
87
sorcer.core.ProviderContext pressure(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing pressure at the aiport which the airprt code specfies.
sorcer.core.ProviderContext sky(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing sky conditons at the aiport which the airprt code specfies.
sorcer.core.ProviderContext temp(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing temperature at the aiport which the airprt code specfies.
sorcer.core.ProviderContext visible(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing visiility at the aiport which the airprt code specfies.
sorcer.core.ProviderContext wind(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing wind conditions at the aiport which the airprt code specfies.
Method Detail temp public sorcer.core.ProviderContext temp(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing temperature at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
humid public sorcer.core.ProviderContext humid(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing humidity at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request.
88
Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
loc public sorcer.core.ProviderContext loc(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing location at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
wind public sorcer.core.ProviderContext wind(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing wind conditions at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
pressure public sorcer.core.ProviderContext pressure(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing pressure at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws:
89
java.rmi.RemoteException
sky public sorcer.core.ProviderContext sky(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing sky conditons at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
visible public sorcer.core.ProviderContext visible(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing visiility at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
getCodes public sorcer.core.ProviderContext getCodes(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the international airport codes in the state that is specified in the input ProviderContext. This method submits a job to the jobber which dispatches it to the requested SORCER service provider Parameters: context - a ProviderContext object that contains parameters to call SORCER Service Provider Throws: java.rmi.RemoteException Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
90
Copyright (c) 2004 Texas Tech University, All Rights Reserved. Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
sorcer.provider.webservice Interface AirportWeatherRemote All Superinterfaces: AirportWeatherInterface, java.rmi.Remote All Known Implementing Classes: AirportWeatherProviderImpl
public interface AirportWeatherRemote extends java.rmi.Remote, AirportWeatherInterface AirportWeatherRemote is the remote Provider Inteface contaning methods that allow a SORCER service requestor to submit jobs for SORCER Service Providers as well as remote web services. This Interface contains methods that take in a ProviderContext and based on the parameters in the ProviderContext submits a job to the Jobber that dispatches the job to the requested remote web service through the dispatcher SWIFExertion and to the SORCER Service Provider through SpaceExertionDispatcher. Author: Kiran Masapari
Methods inherited from interface sorcer.provider.webservice.AirportWeatherInterface getCodes, humid, loc, pressure, sky, temp, visible, wind
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
Copyright (c) 2004 Texas Tech University, All Rights Reserved. Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
sorcer.provider.webservice Class AirportWeatherProviderImpl java.lang.Object
91
sorcer.core.provider.ServiceProvider sorcer.core.provider.SorcerProvider sorcer.provider.webservice.AirportWeatherProviderImpl All Implemented Interfaces: net.jini.admin.Administrable, sorcer.core.AdministratableProvider, AirportWeatherInterface, AirportWeatherRemote, com.sun.jini.admin.DestroyAdmin, java.util.EventListener, net.jini.admin.JoinAdmin, sorcer.base.MonitorableServicer, sorcer.base.Provider, net.jini.export.ProxyAccessor, java.rmi.Remote, net.jini.core.constraint.RemoteMethodControl, java.io.Serializable, net.jini.security.proxytrust.ServerProxyTrust, net.jini.lookup.ServiceIDListener, sorcer.base.Servicer, sorcer.util.SORCER
public class AirportWeatherProviderImpl extends sorcer.core.provider.SorcerProvider implements AirportWeatherRemote, sorcer.util.SORCER AirportWeatherProviderImpl is the implementation class of the SORCER Provider Interface sorcer.provider.webservice.AirportWeatherRemote. This class contains methods that take in a ProviderContext and based on the parameters in the ProviderContext submits a job to the Jobber that dispatches the job to the requested remote web service through the dispatcher SWIFExertion and to the SORCER Service Provider through SpaceExertionDispatcher Author: Kiran Masapari See Also: Serialized Form
Nested Class Summary Nested classes inherited from class sorcer.core.provider.SorcerProvider sorcer.core.provider.SorcerProvider.KeepAwake
Field Summary Fields inherited from class sorcer.core.provider.ServiceProvider delegate Fields inherited from interface sorcer.util.SORCER
92
ADD_DATANODE, ADD_DOMAIN, ADD_JOB_TO_SESSION, ADD_LEAFNODE, ADD_SUBDOMAIN, ADD_TASK, ADD_TASK_TO_JOB_SAVEAS, ADD_TASK_TO_JOB_SAVEAS_RUNTIME, APPEND, AS_PROPS, AS_SESSION, ATTRIBUTE_MODIFIED, BGCOLOR, BROKEN_LINK, CATALOG_CONTENT, CATALOGER_EVENT, CLEANUP_SESSION, CMPS, Command, CONTEXT_ATTRIBUTE_VALUES, CONTEXT_ATTRIBUTES, CONTEXT_RESULT, CPS, CREATION_TIME, DATANODE_FLAG, DELETE_CONTEXT_EVT, DELETE_JOB_EVT, DELETE_NOTIFICATIONS, DELETE_SESSION, DELETE_TASK, DELETE_TASK_EVT, DROP_EXERTION, EXCEPTION_IND, EXCEPTIONS, EXERTION_PROVIDER, FALSE, GET, GET_CONTEXT, GET_CONTEXT_NAMES, GET_FT, GET_JOB, GET_JOB_NAME_BY_JOB_ID, GET_JOBDOMAIN, GET_JOBNAMES, GET_NEW_SERVLET_MESSAGES, GET_NOTIFICATIONS_FOR_SESSION, GET_RUNTIME_JOB, GET_RUNTIME_JOBNAMES, GET_SESSIONS_FOR_USER, GET_TASK, GET_TASK_NAME_BY_TASK_ID, GET_TASK_NAMES, GETALL_DOMAIN_SUB, IN_FILE, IN_PATH, IN_SCRIPT, IN_VALUE, IND, IS_NEW, JOB_ID, JOB_NAME, JOB_STATE, JOB_TASK, MAIL_SEP, MAX_LOOKUP_WAIT, MAX_PRIORITY, META_MODIFIED, MIN_PRIORITY, MODIFY_LEAFNODE, MSG_CONTENT, MSG_ID, MSG_SOURCE, MSG_TYPE, NEW_CONTEXT_EVT, NEW_JOB_EVT, NEW_TASK_EVT, NONE, NORMAL_PRIORITY, NOTIFY_EXCEPTION, NOTIFY_FAILURE, NOTIFY_INFORMATION, NOTIFY_WARNING, NOTRUNTIME, NULL, OBJECT_DOMAIN, OBJECT_NAME, OBJECT_OWNER, OBJECT_SCOPE, OBJECT_SUBDOMAIN, Order, OUT_COMMENT, OUT_FILE, OUT_PATH, OUT_SCRIPT, OUT_VALUE, PERSIST_CONTEXT, PERSIST_JOB, PERSIST_SORCER_NAME, PERSIST_SORCER_TYPES, PERSISTENCE_EVENT, POSTPROCESS, PREPROCESS, PRIVATE, PRIVATE_SCOPE, PROCESS, PROVIDER, PROVIDER_CONTEXT, PUBLIC_SCOPE, REGISTER_FOR_NOTIFICATIONS, REMOVE_CONTEXT, REMOVE_DATANODE, REMOVE_JOB, REMOVE_TASK, RENAME_CONTEXT, RENAME_SORCER_NAME, RESUME_JOB, RUNTIME, SAPPEND, SAVE_TASK_AS, SAVEJOB_AS, SAVEJOB_AS_RUNTIME, SCRATCH_CONTEXTIDS, SCRATCH_JOBEXERTIONIDS, SCRATCH_METHODIDS, SCRATCH_TASKEXERTIONIDS, Script, SCRIPT, SELECT, SELF, SERVICE_EXERTION, SOC_BOOLEAN, SOC_CONTEXT_LINK, SOC_DATANODE, SOC_DB_OBJECT, SOC_DOUBLE, SOC_FLOAT, SOC_INTEGER, SOC_LONG, SOC_PRIMITIVE, SOC_SERIALIZABLE, SOC_STRING, SORCER_FOOTER, SORCER_HEADER, SORCER_HOME, SORCER_INTRO, SORCER_TMP_DIR, SPOSTPROCESS, SPREPROCESS, SPROCESS, STEP_JOB, STOP_JOB, STOP_TASK, SUBCONTEXT_CONTROL_CONTEXT_STR, SUSPEND_JOB, SYSTEM_SCOPE, TABLE_NAME, TASK_COMMAND, TASK_ID, TASK_JOB, TASK_NAME, TASK_PROVIDER, TASK_SCRIPT, TRUE, UPDATE_CONTEXT, UPDATE_CONTEXT_EVT, UPDATE_DATANODE, UPDATE_EXERTION, UPDATE_JOB, UPDATE_JOB_EVT, UPDATE_TASK, UPDATE_TASK_EVT
Constructor Summary AirportWeatherProviderImpl(java.lang.String[] args, com.sun.jini.start.LifeCycle lifeCycle) Creates an SORCER service provider proxy
Method Summary sorcer.core.ProviderContext getCodes(sorcer.core.ProviderContext context)
Returns a ProviderContext object that contains the international airport codes in the state that is specified in the input ProviderContext.
93
net.jini.lookup.entry.UIDescriptor getMainUIDescriptor() Returns an UIDescriptor object that is used to bind the service user interface to the Service Provider
java.util.Hashtable getMethodContexts() Returns a Hashtabe with method names mapped to the corresponding context
sorcer.core.ProviderContext humid(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing humidity at the aiport which the airprt code specfies.
void init() Initializes the Provider
void init(sorcer.core.provider.ProviderDelegate delegate) Initializes the Provider
boolean isValidTask() Returns a Booolean value specifying if the service provider's task is valid or not
sorcer.core.ProviderContext loc(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing location at the aiport which the airprt code specfies.
sorcer.core.ProviderContext pressure(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing pressure at the aiport which the airprt code specfies.
sorcer.core.ProviderContext sky(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing sky conditons at the aiport which the airprt code specfies.
sorcer.core.ProviderContext temp(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing temperature at the aiport which the airprt code specfies.
sorcer.core.ProviderContext visible(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing visibilty at the aiport which the airprt code specfies.
sorcer.core.ProviderContext wind(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing wind conditions at the aiport which the airprt code specfies.
94
Methods inherited from class sorcer.core.provider.SorcerProvider addLookupAttributes, addLookupGroups, addLookupLocators, destroy, getAdmin, getConstraints, getGrants, getLookupAttributes, getLookupGroups, getLookupLocators, getProxy, getProxyVerifier, getServiceProxy, grant, grantSupported, init, modifyLookupAttributes, removeLookupGroups, removeLookupLocators, setConstraints, setLookupGroups, setLookupLocators, toString Methods inherited from class sorcer.core.provider.ServiceProvider doJob, doTask, dropJob, dropTask, fireEvent, getAttributes, getDelegate, getDescription, getGroups, getInfo, getLeastSignificantBits, getMostSignificantBits, getProperties, getProperty, getProviderID, getProviderName, getScratchDirectory, getScratchURL, hangup, init, invokeMethod, invokeMethod, isActive, isValidMethod, isValidTask, loadConfiguration, notifyException, notifyException, notifyExceptionWithStackTrace, notifyFailure, notifyFailure, notifyInformation, notifyWarning, processJob, quit, removeScratchDirectory, restore, resume, service, service0, serviceIDNotify, setProperties, startTiming, step, stop, stopTiming, suspend, update Methods inherited from class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait Methods inherited from interface sorcer.base.Provider fireEvent, getAttributes, getDescription, getGroups, getInfo, getProperties, getProperty, getProviderID, getProviderName, hangup, init, invokeMethod, invokeMethod, isValidMethod, isValidTask, notifyException, notifyException, notifyExceptionWithStackTrace, notifyFailure, notifyFailure, notifyInformation, notifyWarning, restore, setProperties, startTiming, stopTiming, update Methods inherited from interface sorcer.base.MonitorableServicer resume, step, stop, suspend Methods inherited from interface sorcer.base.Servicer service
Constructor Detail AirportWeatherProviderImpl public AirportWeatherProviderImpl(java.lang.String[] args, com.sun.jini.start.LifeCycle lifeCycle) throws java.lang.Exception Creates an SORCER service provider proxy
Method Detail init
95
public void init(sorcer.core.provider.ProviderDelegate delegate) Initializes the Provider
init public void init() throws java.rmi.RemoteException Initializes the Provider Specified by: init in interface sorcer.base.Provider Throws: java.rmi.RemoteException
temp public sorcer.core.ProviderContext temp(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing temperature at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Specified by: temp in interface AirportWeatherInterface Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
humid public sorcer.core.ProviderContext humid(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing humidity at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Specified by: humid in interface AirportWeatherInterface Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
loc public sorcer.core.ProviderContext loc(sorcer.core.ProviderContext context) throws java.rmi.RemoteException
96
Returns a ProviderContext object that contains the string representing location at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Specified by: loc in interface AirportWeatherInterface Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
wind public sorcer.core.ProviderContext wind(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing wind conditions at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Specified by: wind in interface AirportWeatherInterface Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
pressure public sorcer.core.ProviderContext pressure(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing pressure at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Specified by: pressure in interface AirportWeatherInterface Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
sky
97
public sorcer.core.ProviderContext sky(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing sky conditons at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Specified by: sky in interface AirportWeatherInterface Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
visible public sorcer.core.ProviderContext visible(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing visibilty at the aiport which the airprt code specfies. This method submits a job to the jobber which dispatches it to the requested remote web service through a dispatcher called SWIFFExertionDispatcher by generating a SOAP request. Specified by: visible in interface AirportWeatherInterface Parameters: context - a ProviderContext object that contains parameters to call remote web service Throws: java.rmi.RemoteException
getMethodContexts public java.util.Hashtable getMethodContexts() Returns a Hashtabe with method names mapped to the corresponding context Specified by: getMethodContexts in interface sorcer.base.Provider
getMainUIDescriptor public net.jini.lookup.entry.UIDescriptor getMainUIDescriptor() Returns an UIDescriptor object that is used to bind the service user interface to the Service Provider Specified by: getMainUIDescriptor in interface sorcer.base.Provider
getCodes public sorcer.core.ProviderContext
98
getCodes(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the international airport codes in the state that is specified in the input ProviderContext. This method submits a job to the jobber which dispatches it to the requested SORCER service provider Specified by: getCodes in interface AirportWeatherInterface Parameters: context - a ProviderContext object that contains parameters to call SORCER Service Provider Throws: java.rmi.RemoteException
isValidTask public boolean isValidTask() Returns a Booolean value specifying if the service provider's task is valid or not
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
Copyright (c) 2004 Texas Tech University, All Rights Reserved.
99
Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
sorcer.provider.webservice Class AirportWeatherRequestorUI java.lang.Object java.awt.Component java.awt.Container java.awt.Window java.awt.Frame javax.swing.JFrame sorcer.provider.webservice.AirportWeatherRequestorUI All Implemented Interfaces: javax.accessibility.Accessible, java.awt.event.ActionListener, java.util.EventListener, java.awt.image.ImageObserver, java.awt.MenuContainer, javax.swing.RootPaneContainer, java.io.Serializable, javax.swing.WindowConstants
public class AirportWeatherRequestorUI extends javax.swing.JFrame implements java.awt.event.ActionListener AirportWeatherRequestorUI provides the service user interface for the SORCER service requestor to submit SORCER service jobs to both SORCER serice Providers as well as RPC web services. Author: Kiran Masapari See Also: Serialized Form
Nested Class Summary Nested classes inherited from class javax.swing.JFrame javax.swing.JFrame.AccessibleJFrame Nested classes inherited from class java.awt.Frame java.awt.Frame.AccessibleAWTFrame Nested classes inherited from class java.awt.Window java.awt.Window.AccessibleAWTWindow
100
Nested classes inherited from class java.awt.Container java.awt.Container.AccessibleAWTContainer Nested classes inherited from class java.awt.Component java.awt.Component.AccessibleAWTComponent, java.awt.Component.BltBufferStrategy, java.awt.Component.FlipBufferStrategy
Field Summary Fields inherited from class javax.swing.JFrame accessibleContext, EXIT_ON_CLOSE, rootPane, rootPaneCheckingEnabled Fields inherited from class java.awt.Frame CROSSHAIR_CURSOR, DEFAULT_CURSOR, E_RESIZE_CURSOR, HAND_CURSOR, ICONIFIED, MAXIMIZED_BOTH, MAXIMIZED_HORIZ, MAXIMIZED_VERT, MOVE_CURSOR, N_RESIZE_CURSOR, NE_RESIZE_CURSOR, NORMAL, NW_RESIZE_CURSOR, S_RESIZE_CURSOR, SE_RESIZE_CURSOR, SW_RESIZE_CURSOR, TEXT_CURSOR, W_RESIZE_CURSOR, WAIT_CURSOR Fields inherited from class java.awt.Component BOTTOM_ALIGNMENT, CENTER_ALIGNMENT, LEFT_ALIGNMENT, RIGHT_ALIGNMENT, TOP_ALIGNMENT Fields inherited from interface javax.swing.WindowConstants DISPOSE_ON_CLOSE, DO_NOTHING_ON_CLOSE, HIDE_ON_CLOSE Fields inherited from interface java.awt.image.ImageObserver ABORT, ALLBITS, ERROR, FRAMEBITS, HEIGHT, PROPERTIES, SOMEBITS, WIDTH
Constructor Summary AirportWeatherRequestorUI(java.lang.Object obj) The constructor creates a proxy of the service provider object, creates and shows the sevice user interface
Method Summary void actionPerformed(java.awt.event.ActionEvent e)
Invoked when an action occurs
101
static void main(java.lang.String[] args) The main program for the AirportWeatherRequestorUI class
Methods inherited from class javax.swing.JFrame addImpl, createRootPane, frameInit, getAccessibleContext, getContentPane, getDefaultCloseOperation, getGlassPane, getJMenuBar, getLayeredPane, getRootPane, isDefaultLookAndFeelDecorated, isRootPaneCheckingEnabled, paramString, processWindowEvent, remove, setContentPane, setDefaultCloseOperation, setDefaultLookAndFeelDecorated, setGlassPane, setJMenuBar, setLayeredPane, setLayout, setRootPane, setRootPaneCheckingEnabled, update Methods inherited from class java.awt.Frame addNotify, finalize, getCursorType, getExtendedState, getFrames, getIconImage, getMaximizedBounds, getMenuBar, getState, getTitle, isResizable, isUndecorated, remove, removeNotify, setCursor, setExtendedState, setIconImage, setMaximizedBounds, setMenuBar, setResizable, setState, setTitle, setUndecorated Methods inherited from class java.awt.Window addPropertyChangeListener, addPropertyChangeListener, addWindowFocusListener, addWindowListener, addWindowStateListener, applyResourceBundle, applyResourceBundle, createBufferStrategy, createBufferStrategy, dispose, getBufferStrategy, getFocusableWindowState, getFocusCycleRootAncestor, getFocusOwner, getFocusTraversalKeys, getGraphicsConfiguration, getInputContext, getListeners, getLocale, getMostRecentFocusOwner, getOwnedWindows, getOwner, getToolkit, getWarningString, getWindowFocusListeners, getWindowListeners, getWindowStateListeners, hide, isActive, isFocusableWindow, isFocusCycleRoot, isFocused, isShowing, pack, postEvent, processEvent, processWindowFocusEvent, processWindowStateEvent, removeWindowFocusListener, removeWindowListener, removeWindowStateListener, setCursor, setFocusableWindowState, setFocusCycleRoot, setLocationRelativeTo, show, toBack, toFront Methods inherited from class java.awt.Container add, add, add, add, add, addContainerListener, applyComponentOrientation, areFocusTraversalKeysSet, countComponents, deliverEvent, doLayout, findComponentAt, findComponentAt, getAlignmentX, getAlignmentY, getComponent, getComponentAt, getComponentAt, getComponentCount, getComponents, getContainerListeners, getFocusTraversalPolicy, getInsets, getLayout, getMaximumSize, getMinimumSize, getPreferredSize, insets, invalidate, isAncestorOf, isFocusCycleRoot, isFocusTraversalPolicySet, layout, list, list, locate, minimumSize, paint, paintComponents, preferredSize, print, printComponents, processContainerEvent, remove, removeAll, removeContainerListener, setFocusTraversalKeys, setFocusTraversalPolicy, setFont, transferFocusBackward, transferFocusDownCycle, validate, validateTree Methods inherited from class java.awt.Component
102
action, add, addComponentListener, addFocusListener, addHierarchyBoundsListener, addHierarchyListener, addInputMethodListener, addKeyListener, addMouseListener, addMouseMotionListener, addMouseWheelListener, bounds, checkImage, checkImage, coalesceEvents, contains, contains, createImage, createImage, createVolatileImage, createVolatileImage, disable, disableEvents, dispatchEvent, enable, enable, enableEvents, enableInputMethods, firePropertyChange, firePropertyChange, firePropertyChange, getBackground, getBounds, getBounds, getColorModel, getComponentListeners, getComponentOrientation, getCursor, getDropTarget, getFocusListeners, getFocusTraversalKeysEnabled, getFont, getFontMetrics, getForeground, getGraphics, getHeight, getHierarchyBoundsListeners, getHierarchyListeners, getIgnoreRepaint, getInputMethodListeners, getInputMethodRequests, getKeyListeners, getLocation, getLocation, getLocationOnScreen, getMouseListeners, getMouseMotionListeners, getMouseWheelListeners, getName, getParent, getPeer, getPropertyChangeListeners, getPropertyChangeListeners, getSize, getSize, getTreeLock, getWidth, getX, getY, gotFocus, handleEvent, hasFocus, imageUpdate, inside, isBackgroundSet, isCursorSet, isDisplayable, isDoubleBuffered, isEnabled, isFocusable, isFocusOwner, isFocusTraversable, isFontSet, isForegroundSet, isLightweight, isOpaque, isValid, isVisible, keyDown, keyUp, list, list, list, location, lostFocus, mouseDown, mouseDrag, mouseEnter, mouseExit, mouseMove, mouseUp, move, nextFocus, paintAll, prepareImage, prepareImage, printAll, processComponentEvent, processFocusEvent, processHierarchyBoundsEvent, processHierarchyEvent, processInputMethodEvent, processKeyEvent, processMouseEvent, processMouseMotionEvent, processMouseWheelEvent, removeComponentListener, removeFocusListener, removeHierarchyBoundsListener, removeHierarchyListener, removeInputMethodListener, removeKeyListener, removeMouseListener, removeMouseMotionListener, removeMouseWheelListener, removePropertyChangeListener, removePropertyChangeListener, repaint, repaint, repaint, repaint, requestFocus, requestFocus, requestFocusInWindow, requestFocusInWindow, reshape, resize, resize, setBackground, setBounds, setBounds, setComponentOrientation, setDropTarget, setEnabled, setFocusable, setFocusTraversalKeysEnabled, setForeground, setIgnoreRepaint, setLocale, setLocation, setLocation, setName, setSize, setSize, setVisible, show, size, toString, transferFocus, transferFocusUpCycle Methods inherited from class java.lang.Object clone, equals, getClass, hashCode, notify, notifyAll, wait, wait, wait Methods inherited from interface java.awt.MenuContainer getFont, postEvent
Constructor Detail AirportWeatherRequestorUI public AirportWeatherRequestorUI(java.lang.Object obj) The constructor creates a proxy of the service provider object, creates and shows the sevice user interface
Method Detail main public static void main(java.lang.String[] args) The main program for the AirportWeatherRequestorUI class
103
actionPerformed public void actionPerformed(java.awt.event.ActionEvent e) Invoked when an action occurs Specified by: actionPerformed in interface java.awt.event.ActionListener
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
Copyright (c) 2004 Texas Tech University, All Rights Reserved.
104
Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
sorcer.provider.airport Interface AirportInterface All Known Subinterfaces: AirportRemote All Known Implementing Classes: AirportProviderImpl
public interface AirportInterface AirportInterface is the Provider Inteface contaning methods that provides a SORCER service requestor with the internatonal airport codes for a sting specifying a state name. This Interface contains the codes method that take in a ProviderContext and based on the parameter in the ProviderContext provides the service requestor or the web service client with international airport codes the requested state
Method Summary sorcer.core.ProviderContext codes(sorcer.core.ProviderContext context)
Returns a ProviderContext object that contains the international airport codes in the state that is specified in the input ProviderContext.
Method Detail codes public sorcer.core.ProviderContext codes(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the international airport codes in the state that is specified in the input ProviderContext. Throws: java.rmi.RemoteException
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
Copyright (c) 2004 Texas Tech University, All Rights Reserved.
105
Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
sorcer.provider.airport Interface AirportRemote All Superinterfaces: AirportInterface, java.rmi.Remote All Known Implementing Classes: AirportProviderImpl
public interface AirportRemote extends java.rmi.Remote, AirportInterface AirportInterface is the Provider remote Inteface contaning methods that provides a SORCER service requestor with the internatonal airport codes for a sting specifying a state name. This Interface contains the codes method that take in a ProviderContext and based on the parameter in the ProviderContext provides the service requestor or the web service client with international airport codes the requested state
Methods inherited from interface sorcer.provider.airport.AirportInterface codes
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
Copyright (c) 2004 Texas Tech University, All Rights Reserved.
106
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
sorcer.provider.airport Class AirportProviderImpl java.lang.Object sorcer.core.provider.ServiceProvider sorcer.core.provider.SorcerProvider sorcer.provider.airport.AirportProviderImpl All Implemented Interfaces: net.jini.admin.Administrable, sorcer.core.AdministratableProvider, AirportInterface, AirportRemote, com.sun.jini.admin.DestroyAdmin, java.util.EventListener, net.jini.admin.JoinAdmin, sorcer.base.MonitorableServicer, sorcer.base.Provider, net.jini.export.ProxyAccessor, java.rmi.Remote, net.jini.core.constraint.RemoteMethodControl, java.io.Serializable, net.jini.security.proxytrust.ServerProxyTrust, net.jini.lookup.ServiceIDListener, sorcer.base.Servicer, sorcer.util.SORCER
public class AirportProviderImpl extends sorcer.core.provider.SorcerProvider implements AirportRemote, sorcer.util.SORCER AirportProviderImpl is the implementation class of the SORCER Provider Interface sorcer.provider.airport.AirportRemote. This Interface contains the codes method that take in a ProviderContext and based on the parameter in the ProviderContext provides the service requestor or the web service client with international airport codes the requested state See Also: Serialized Form
Nested Class Summary Nested classes inherited from class sorcer.core.provider.SorcerProvider sorcer.core.provider.SorcerProvider.KeepAwake
Field Summary Fields inherited from class sorcer.core.provider.ServiceProvider delegate
107
Fields inherited from interface sorcer.util.SORCER ADD_DATANODE, ADD_DOMAIN, ADD_JOB_TO_SESSION, ADD_LEAFNODE, ADD_SUBDOMAIN, ADD_TASK, ADD_TASK_TO_JOB_SAVEAS, ADD_TASK_TO_JOB_SAVEAS_RUNTIME, APPEND, AS_PROPS, AS_SESSION, ATTRIBUTE_MODIFIED, BGCOLOR, BROKEN_LINK, CATALOG_CONTENT, CATALOGER_EVENT, CLEANUP_SESSION, CMPS, Command, CONTEXT_ATTRIBUTE_VALUES, CONTEXT_ATTRIBUTES, CONTEXT_RESULT, CPS, CREATION_TIME, DATANODE_FLAG, DELETE_CONTEXT_EVT, DELETE_JOB_EVT, DELETE_NOTIFICATIONS, DELETE_SESSION, DELETE_TASK, DELETE_TASK_EVT, DROP_EXERTION, EXCEPTION_IND, EXCEPTIONS, EXERTION_PROVIDER, FALSE, GET, GET_CONTEXT, GET_CONTEXT_NAMES, GET_FT, GET_JOB, GET_JOB_NAME_BY_JOB_ID, GET_JOBDOMAIN, GET_JOBNAMES, GET_NEW_SERVLET_MESSAGES, GET_NOTIFICATIONS_FOR_SESSION, GET_RUNTIME_JOB, GET_RUNTIME_JOBNAMES, GET_SESSIONS_FOR_USER, GET_TASK, GET_TASK_NAME_BY_TASK_ID, GET_TASK_NAMES, GETALL_DOMAIN_SUB, IN_FILE, IN_PATH, IN_SCRIPT, IN_VALUE, IND, IS_NEW, JOB_ID, JOB_NAME, JOB_STATE, JOB_TASK, MAIL_SEP, MAX_LOOKUP_WAIT, MAX_PRIORITY, META_MODIFIED, MIN_PRIORITY, MODIFY_LEAFNODE, MSG_CONTENT, MSG_ID, MSG_SOURCE, MSG_TYPE, NEW_CONTEXT_EVT, NEW_JOB_EVT, NEW_TASK_EVT, NONE, NORMAL_PRIORITY, NOTIFY_EXCEPTION, NOTIFY_FAILURE, NOTIFY_INFORMATION, NOTIFY_WARNING, NOTRUNTIME, NULL, OBJECT_DOMAIN, OBJECT_NAME, OBJECT_OWNER, OBJECT_SCOPE, OBJECT_SUBDOMAIN, Order, OUT_COMMENT, OUT_FILE, OUT_PATH, OUT_SCRIPT, OUT_VALUE, PERSIST_CONTEXT, PERSIST_JOB, PERSIST_SORCER_NAME, PERSIST_SORCER_TYPES, PERSISTENCE_EVENT, POSTPROCESS, PREPROCESS, PRIVATE, PRIVATE_SCOPE, PROCESS, PROVIDER, PROVIDER_CONTEXT, PUBLIC_SCOPE, REGISTER_FOR_NOTIFICATIONS, REMOVE_CONTEXT, REMOVE_DATANODE, REMOVE_JOB, REMOVE_TASK, RENAME_CONTEXT, RENAME_SORCER_NAME, RESUME_JOB, RUNTIME, SAPPEND, SAVE_TASK_AS, SAVEJOB_AS, SAVEJOB_AS_RUNTIME, SCRATCH_CONTEXTIDS, SCRATCH_JOBEXERTIONIDS, SCRATCH_METHODIDS, SCRATCH_TASKEXERTIONIDS, Script, SCRIPT, SELECT, SELF, SERVICE_EXERTION, SOC_BOOLEAN, SOC_CONTEXT_LINK, SOC_DATANODE, SOC_DB_OBJECT, SOC_DOUBLE, SOC_FLOAT, SOC_INTEGER, SOC_LONG, SOC_PRIMITIVE, SOC_SERIALIZABLE, SOC_STRING, SORCER_FOOTER, SORCER_HEADER, SORCER_HOME, SORCER_INTRO, SORCER_TMP_DIR, SPOSTPROCESS, SPREPROCESS, SPROCESS, STEP_JOB, STOP_JOB, STOP_TASK, SUBCONTEXT_CONTROL_CONTEXT_STR, SUSPEND_JOB, SYSTEM_SCOPE, TABLE_NAME, TASK_COMMAND, TASK_ID, TASK_JOB, TASK_NAME, TASK_PROVIDER, TASK_SCRIPT, TRUE, UPDATE_CONTEXT, UPDATE_CONTEXT_EVT, UPDATE_DATANODE, UPDATE_EXERTION, UPDATE_JOB, UPDATE_JOB_EVT, UPDATE_TASK, UPDATE_TASK_EVT
Constructor Summary AirportProviderImpl(java.lang.String[] args, com.sun.jini.start.LifeCycle lifeCycle) Creates an SORCER service provider proxy
Method Summary
108
sorcer.core.ProviderContext codes(sorcer.core.ProviderContext context) Returns a ProviderContext object that contains the string representing humidity at the aiport which the airprt code specfies.
java.util.Hashtable getMethodContexts() Returns a Hashtabe with method names mapped to the corresponding context
void init() Initializes the Provider
void init(sorcer.core.provider.ProviderDelegate delegate) Initializes the Provider
boolean isValidTask() Returns a Booolean value specifying if the service provider's task is valid or not
Methods inherited from class sorcer.core.provider.SorcerProvider addLookupAttributes, addLookupGroups, addLookupLocators, destroy, getAdmin, getConstraints, getGrants, getLookupAttributes, getLookupGroups, getLookupLocators, getProxy, getProxyVerifier, getServiceProxy, grant, grantSupported, init, modifyLookupAttributes, removeLookupGroups, removeLookupLocators, setConstraints, setLookupGroups, setLookupLocators, toString Methods inherited from class sorcer.core.provider.ServiceProvider doJob, doTask, dropJob, dropTask, fireEvent, getAttributes, getDelegate, getDescription, getGroups, getInfo, getLeastSignificantBits, getMainUIDescriptor, getMostSignificantBits, getProperties, getProperty, getProviderID, getProviderName, getScratchDirectory, getScratchURL, hangup, init, invokeMethod, invokeMethod, isActive, isValidMethod, isValidTask, loadConfiguration, notifyException, notifyException, notifyExceptionWithStackTrace, notifyFailure, notifyFailure, notifyInformation, notifyWarning, processJob, quit, removeScratchDirectory, restore, resume, service, service0, serviceIDNotify, setProperties, startTiming, step, stop, stopTiming, suspend, update Methods inherited from class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait Methods inherited from interface sorcer.base.Provider fireEvent, getAttributes, getDescription, getGroups, getInfo, getMainUIDescriptor, getProperties, getProperty, getProviderID, getProviderName, hangup, init, invokeMethod, invokeMethod, isValidMethod, isValidTask, notifyException, notifyException, notifyExceptionWithStackTrace, notifyFailure, notifyFailure, notifyInformation, notifyWarning, restore, setProperties, startTiming, stopTiming, update Methods inherited from interface sorcer.base.MonitorableServicer
109
resume, step, stop, suspend Methods inherited from interface sorcer.base.Servicer service
Constructor Detail AirportProviderImpl public AirportProviderImpl(java.lang.String[] args, com.sun.jini.start.LifeCycle lifeCycle) throws java.lang.Exception Creates an SORCER service provider proxy
Method Detail init public void init(sorcer.core.provider.ProviderDelegate delegate) Initializes the Provider
init public void init() throws java.rmi.RemoteException Initializes the Provider Specified by: init in interface sorcer.base.Provider Throws: java.rmi.RemoteException
codes public sorcer.core.ProviderContext codes(sorcer.core.ProviderContext context) throws java.rmi.RemoteException Returns a ProviderContext object that contains the string representing humidity at the aiport which the airprt code specfies. Specified by: codes in interface AirportInterface Throws: java.rmi.RemoteException
getMethodContexts public java.util.Hashtable getMethodContexts() Returns a Hashtabe with method names mapped to the corresponding context Specified by: getMethodContexts in interface sorcer.base.Provider
isValidTask public boolean isValidTask() Returns a Booolean value specifying if the service provider's task is valid or not
110
Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
Copyright (c) 2004 Texas Tech University, All Rights Reserved. Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
swifservice Interface SWIFIF All Superinterfaces: java.rmi.Remote All Known Implementing Classes: SWIFImpl
public interface SWIFIF extends java.rmi.Remote SWIFIF is Inteface representing the remote web service gateway for SORCER service requestors and rpc web service clients.
Method Summary java.lang.String execute(java.lang.String s)
The execute method routes requests to SORCER Providers as well as RPC web services
Method Detail execute public java.lang.String execute(java.lang.String s) throws java.rmi.RemoteException The execute method routes requests to SORCER Providers as well as RPC web services Throws: java.rmi.RemoteException
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
Copyright (c) 2005 Texas Tech University, All Rights Reserved.
111
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
swifservice Class SWIFImpl java.lang.Object swifservice.SWIFImpl All Implemented Interfaces: java.rmi.Remote, SWIFIF
public class SWIFImpl extends java.lang.Object implements SWIFIF SWIFImpl is the implementation class of the remote gateway web service SWIFIF. This class contains the execute method that routes requests to SORCER Providers as well as RPC web services
Constructor Summary SWIFImpl()
Method Summary java.lang.String execute(java.lang.String context)
The execute method routes requests to SORCER Providers as well as RPC web services
Methods inherited from class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
Constructor Detail SWIFImpl public SWIFImpl()
Method Detail execute public java.lang.String execute(java.lang.String context) The execute method routes requests to SORCER Providers as well as RPC web services
112
Specified by: execute in interface SWIFIF
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
Copyright (c) 2005 Texas Tech University, All Rights Reserved.
113
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
swifservice Class SWIFServlet java.lang.Object javax.servlet.GenericServlet javax.servlet.http.HttpServlet com.sun.xml.rpc.server.http.JAXRPCServlet swifservice.SWIFServlet All Implemented Interfaces: java.io.Serializable, javax.servlet.Servlet, javax.servlet.ServletConfig
public class SWIFServlet extends com.sun.xml.rpc.server.http.JAXRPCServlet Represents the Servlet that handles the RPC web service clients requests and routes the requests to the SORCER Service Providers as well as requested RPC web services See Also: Serialized Form
Field Summary protected com.sun.xml.rpc.server.http.ServletDelegate
delegate Represents the Servlet delegate object
static java.lang.String JAXRPC_RI_PROPERTY_PUBLISH_MODEL String representing the parameter defining object of type com.sun.xml.rpc.server.http.publishModel
static java.lang.String JAXRPC_RI_PROPERTY_PUBLISH_STATUS_PAGE String representing the parameter defining object of type com.sun.xml.rpc.server.http.publishStatusPage
static java.lang.String JAXRPC_RI_PROPERTY_PUBLISH_WSDL String representing the parameter defining object of type com.sun.xml.rpc.server.http.publishWSDL
static java.lang.String JAXRPC_RI_RUNTIME_INFO String representing the parameter defining object of type com.sun.xml.rpc.server.http.info
114
Constructor Summary SWIFServlet()
Method Summary void destroy()
Destroys the SWIFServlet protected void
doGet(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Delegates to SWIFServletDelagate doGet
protected void
doPost(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Delegates to SWIFServletDelagate doPost
void init(javax.servlet.ServletConfig servletConfig) Initializes the SWIFServlet
Methods inherited from class javax.servlet.http.HttpServlet doDelete, doHead, doOptions, doPut, doTrace, getLastModified, service, service Methods inherited from class javax.servlet.GenericServlet getInitParameter, getInitParameterNames, getServletConfig, getServletContext, getServletInfo, getServletName, init, log, log Methods inherited from class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
Field Detail delegate protected com.sun.xml.rpc.server.http.ServletDelegate delegate Represents the Servlet delegate object
JAXRPC_RI_RUNTIME_INFO public static final java.lang.String JAXRPC_RI_RUNTIME_INFO String representing the parameter defining object of type com.sun.xml.rpc.server.http.info See Also: Constant Field Values
JAXRPC_RI_PROPERTY_PUBLISH_WSDL
115
public static final java.lang.String JAXRPC_RI_PROPERTY_PUBLISH_WSDL String representing the parameter defining object of type com.sun.xml.rpc.server.http.publishWSDL See Also: Constant Field Values
JAXRPC_RI_PROPERTY_PUBLISH_MODEL public static final java.lang.String JAXRPC_RI_PROPERTY_PUBLISH_MODEL String representing the parameter defining object of type com.sun.xml.rpc.server.http.publishModel See Also: Constant Field Values
JAXRPC_RI_PROPERTY_PUBLISH_STATUS_PAGE public static final java.lang.String JAXRPC_RI_PROPERTY_PUBLISH_STATUS_PAGE String representing the parameter defining object of type com.sun.xml.rpc.server.http.publishStatusPage See Also: Constant Field Values
Constructor Detail SWIFServlet public SWIFServlet()
Method Detail init public void init(javax.servlet.ServletConfig servletConfig) throws javax.servlet.ServletException Initializes the SWIFServlet Throws: javax.servlet.ServletException
destroy public void destroy() Destroys the SWIFServlet
doPost protected void doPost(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) throws javax.servlet.ServletException Delegates to SWIFServletDelagate doPost Throws: javax.servlet.ServletException
doGet
116
protected void doGet(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) throws javax.servlet.ServletException Delegates to SWIFServletDelagate doGet Throws: javax.servlet.ServletException
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
Copyright (c) 2005 Texas Tech University, All Rights Reserved.
117
Package Class Use Tree Deprecated Index Help PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
swifservice Class SWIFServletDelegate java.lang.Object com.sun.xml.rpc.server.http.JAXRPCServletDelegate swifservice.SWIFServletDelegate All Implemented Interfaces: com.sun.xml.rpc.server.http.ServletDelegate
public class SWIFServletDelegate extends com.sun.xml.rpc.server.http.JAXRPCServletDelegate The SWIFServletDelegate acts a delegate for the SWIFServlet and handles RPC web service clients requests, routing them to SORCER Service providers as well as requested RPC web service
Constructor Summary SWIFServletDelegate()
Methods inherited from class com.sun.xml.rpc.server.http.JAXRPCServletDelegate Methods inherited from class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
Constructor Detail SWIFServletDelegate public SWIFServletDelegate()
118
Method Detail init public void init(javax.servlet.ServletConfig servletConfig) throws javax.servlet.ServletException
Method Summary
protected static void copyStream(java.io.InputStream istream, java.io.OutputStream ostream) Copies the bytes from inputstream to outputstream
void destroy() Destroys the SWIFServletDelegate
void doGet(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Routes RPC web service client requests to SORCER Service Providers and RPC web services
void doPost(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) Routes RPC web service client requests to SORCER Service Providers and RPC web services
protected com.sun.xml.rpc.server.http.RuntimeEndpointInfo
getEndpointFor(javax.servlet.http.HttpServletRequest request) Returns an object of type RuntimeEndpointInfo that contains the endpoint of the requested RPC web service from the HttpServletRequest object
protected static javax.xml.soap.MimeHeaders
getHeaders(javax.servlet.http.HttpServletRequest req) Returns an object of type MimeHeaders that contain the headers from the HttpServletRequest object
protected com.sun.xml.rpc.util.localization.Localizer
getLocalizerFor(javax.servlet.ServletRequest request) Returns an object of type Localizer
protected java.lang.String getValidPathForEndpoint(com.sun.xml.rpc.server.http.RuntimeEndpointInfo info) Returns a string representing the endpoint of the RPC web service from the RuntimeEndpointInfo object
void init(javax.servlet.ServletConfig servletConfig) Initializes the SWIFServletDelegate
protected static void putHeaders(javax.xml.soap.MimeHeaders headers, javax.servlet.http.HttpServletResponse res) Modifies headers of the HttpServletResponse
protected static byte[] readFully(java.io.InputStream istream) Returns the bytes from the InputStream
protected void registerEndpointUrlPattern(com.sun.xml.rpc.server.http.RuntimeEndpointInfo info) Adds the endpoints url pattern to the path
protected void writeNotFoundErrorPage(com.sun.xml.rpc.util.localization.Localizer localizer, javax.servlet.http.HttpServletResponse response, java.lang.String message) Displays the "404 Not Found" Error page
protected void writeReply(javax.servlet.http.HttpServletResponse resp, com.sun.xml.rpc.soap.message.SOAPMessageContext messageContext) Writes the SOAP Message reply to the HttpServletResponse's OutputStream
119
Initializes the SWIFServletDelegate Throws: javax.servlet.ServletException
destroy public void destroy() Destroys the SWIFServletDelegate
doGet public void doGet(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) throws javax.servlet.ServletException Routes RPC web service client requests to SORCER Service Providers and RPC web services Throws: javax.servlet.ServletException
doPost public void doPost(javax.servlet.http.HttpServletRequest request, javax.servlet.http.HttpServletResponse response) throws javax.servlet.ServletException Routes RPC web service client requests to SORCER Service Providers and RPC web services Throws: javax.servlet.ServletException
writeReply protected void writeReply(javax.servlet.http.HttpServletResponse resp, com.sun.xml.rpc.soap.message.SOAPMessageContext messageContext) throws javax.xml.soap.SOAPException, java.io.IOException Writes the SOAP Message reply to the HttpServletResponse's OutputStream Throws: javax.xml.soap.SOAPException java.io.IOException
writeNotFoundErrorPage protected void writeNotFoundErrorPage(com.sun.xml.rpc.util.localization.Localizer localizer, javax.servlet.http.HttpServletResponse response, java.lang.String message) throws java.io.IOException Displays the "404 Not Found" Error page Throws: java.io.IOException
120
getHeaders protected static javax.xml.soap.MimeHeaders getHeaders(javax.servlet.http.HttpServletRequest req) Returns an object of type MimeHeaders that contain the headers from the HttpServletRequest object
putHeaders protected static void putHeaders(javax.xml.soap.MimeHeaders headers, javax.servlet.http.HttpServletResponse res) Modifies headers of the HttpServletResponse
readFully protected static byte[] readFully(java.io.InputStream istream) throws java.io.IOException Returns the bytes from the InputStream Throws: java.io.IOException
registerEndpointUrlPattern protected void registerEndpointUrlPattern(com.sun.xml.rpc.server.http.RuntimeEndpointInfo info) Adds the endpoints url pattern to the path
getValidPathForEndpoint protected java.lang.String getValidPathForEndpoint(com.sun.xml.rpc.server.http.RuntimeEndpointInfo info) Returns a string representing the endpoint of the RPC web service from the RuntimeEndpointInfo object
getEndpointFor protected com.sun.xml.rpc.server.http.RuntimeEndpointInfo getEndpointFor(javax.servlet.http.HttpServletRequest request) Returns an object of type RuntimeEndpointInfo that contains the endpoint of the requested RPC web service from the HttpServletRequest object
getLocalizerFor protected com.sun.xml.rpc.util.localization.Localizer getLocalizerFor(javax.servlet.ServletRequest request) Returns an object of type Localizer
copyStream protected static void copyStream(java.io.InputStream istream, java.io.OutputStream ostream) throws java.io.IOException Copies the bytes from inputstream to outputstream
121
Throws: java.io.IOException
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
Copyright (c) 2005 Texas Tech University, All Rights Reserved.
122
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
client Class SWIFClient java.lang.Object client.SWIFClient
public class SWIFClient extends java.lang.Object RPC web service client requesting SORCER service as well as RPC web service
Constructor Summary SWIFClient()
Method Summary static void main(java.lang.String[] args)
The main program of the SWIFClient class Methods inherited from class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
Constructor Detail SWIFClient public SWIFClient()
Method Detail main public static void main(java.lang.String[] args) The main program of the SWIFClient class
Package Class Use Tree Deprecated Index Help
PREV CLASS NEXT CLASS FRAMES NO FRAMES All Classes All Classes SUMMARY: NESTED | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD
Copyright (c) 2005 Texas Tech University, All Rights Reserved
PERMISSION TO COPY
In presenting this thesis in partial fulfillment of the requirements for a master�s
degree at Texas Tech University or Texas Tech University Health Sciences Center, I
agree that the Library and my major department shall make it freely available for research
purposes. Permission to copy this thesis for scholarly purposes may be granted by the
Director of the Library or my major professor. It is understood that any copying or
publication of this thesis for financial gain shall not be allowed without my further
written permission and that any user may be liable for copyright infringement.
Agree (Permission is granted.)
_____KIRAN MANOAH MASAPARI______________ ___5/2/2005_______ Student Signature Date Disagree (Permission is not granted.) _______________________________________________ _________________ Student Signature Date .
