8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
1/79
UNIT IV
Based On
Service-Oriented Architecture: Concepts,
Technology, and Design
By Thomas Erl
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
2/79
SOA platform basics
Basic platform building blocks
The realization of a software program puts forth some basic requirements,mainly:
We need a development environment with which to program andassemble the software program. This environment must provide us
with a development tool that supports a programming language.
We need a runtime for which we will be designing our software. We need APIs that expose features and functions offered by the
runtime so that we can build our software program to interact with and
take advantage of these features and functions.
Finally, we need an operating system on which to deploy the runtime,APIs, and the software program. The operating system interfaces withthe underlying hardware and likely will provide additional services
that can be used by the software program.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
3/79
Common SOA platform layers
Relationship between SOA layers and technologies
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
4/79
The Web Technology layer needs to provide support for the first-generation Web services technology set to enable us to build a
primitive SOA.
The Web Technology layer needs to provide support for WS-*specifications for us to fulfill some of the contemporary SOA
characteristics.
The Web Technology layer needs to provide a means of assemblingand implementing its technology support into Web services.
The Component Technology layer needs to support encapsulation byWeb services.
The Runtime layer needs to be capable of hosting components andWeb services.
The Runtime layer needs to provide a series of APIs in support ofcomponents and Web services.
The APIs layer needs to provide functions that support thedevelopment and processing of components and Web services
technologies.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
5/79
Fundamental service technology architecture Service processing tasks Service providers are commonly expected to perform the following
tasks:
Supply a public interface (WSDL definition) that allows it to beaccessed and invoked by a service requestor.
Receive a SOAP message sent to it by a service requestor. Process the header blocks within the SOAP message. Validate and parse the payload of the SOAP message.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
6/79
Transform the message payload contents into a different format. Encapsulate business processing logic that will do something
with the received SOAP message contents.
Assemble a SOAP message containing the response to theoriginal request SOAP message from the service requestor.
Transform the contents of the message back into the formatexpected by the service requestor.
Transmit the response SOAP message back to the servicerequestor.
Service providers are designed to facilitate service requestors. A servicerequestor can be any piece of software capable of communicating with a
service provider. Service requestors are commonly expected to:
Contain business processing logic that calls a service provider for aparticular reason.
Interpret (and possibly discover) a service provider's WSDL definition. Assemble a SOAP request message (including any required headers) in
compliance with the service provider WSDL definition.
Transform the contents of the SOAP message so that they comply withthe format expected by the service provider.
Transmit the SOAP request message to the service provider. Receive a SOAP response message from the service provider. Validate and parse the payload of the SOAP response message received
by the service provider.
Transform the SOAP payload into a different format. Process SOAP header blocks within the message.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
7/79
The grouping of the WSDL with other metadata documents (such as policies and
schemas) and classify them collectively as the endpoint
The endpoint is not located in front of the service message processing logic.Instead, it is wedged within the message processing logic block because
some of the runtime components that comprise the message processing logic
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
8/79
may be executed prior to the endpoint being contacted by an incoming
message.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
9/79
The primary difference between how service logic is used in requestors andproviders is related to the role of business logic. The business logic part of a
service requestor is responsible for initiating an activity (and the resultingSOAP message exchange), whereas the business logic within a service provider
responds to an already initiated activity.
The figure shows some common processing layers represented by the message
processing logic of a service provider. Among these layers are tasks, such as
header processing, that are generic and applied to all service providers. Validation
or transformation tasks, on the other hand, may involve service-specific XSD
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
10/79
schemas and XSLT stylesheets and therefore may be considered exclusive to the
service provider
Although the message processing logic for service requestors and serviceproviders may be similar, there is an important implementation-level
difference. The service provider supplies an endpoint that expresses an
interface and associated constraints with which all service requestors must
comply.
Vendor platforms accomplish this by supporting the creation of proxycomponents.
Proxies accept method calls issued from the regular vendor platform components
that contain the service requestor business logic. The proxies then use vendor
runtime services to translate these method calls and associated parameters into
SOAP request messages. When the SOAP request is transmitted, the proxy is
further able to receive the corresponding SOAP response from the service
provider. It then performs the same type of translation, but in reverse
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
11/79
Although the message processing logic for service requestors and serviceproviders may be similar, there is an important implementation-level
difference. The service provider supplies an endpoint that expresses an
interface and associated constraints with which all service requestors must
comply.
Vendor platforms accomplish this by supporting the creation of proxycomponents.
Proxies accept method calls issued from the regular vendor platformcomponents that contain the service requestor business logic. The proxies
then use vendor runtime services to translate these method calls and
associated parameters into SOAP request messages. When the SOAP request
is transmitted, the proxy is further able to receive the corresponding SOAP
response from the service provider. It then performs the same type oftranslation, but in reverse.
Business logic
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
12/79
Business logic can exist as a standalone component, housing theintelligence required to either invoke a service provider as part of a
business activity or to respond to a request in order to participate in
such an activity.
As an independent unit of logic, it is free to act in different roles. Thefigure shows a unit of business logic being encapsulated as part of a
service provider but also acting as a service requestor
If units of business logic exist as physically separate components, thesame business logic can be encapsulated by different service
providers.
Because units of business logic can exist in their native distributedcomponent format, they also can interact with other components that
may not necessarily be part of the SOA.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
13/79
Service agents
A type of software program commonly found within the message processing
logic of SOA platforms is the service agent. Its primary role is to perform some
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
14/79
form of automated processing prior to the transmission and receipt of SOAP
messages. As such, service agents are a form of intermediary service.
Service agents usually address cross-cutting concerns, providing genericfunctions to alleviate the processing responsibilities of core Web servicelogic. Examples of the types of tasks performed by service agents include:
SOAP header processing filtering (based on SOAP header or payload content) authentication and content-based validation logging and auditing routing
Vendor platforms The next two sections consist of the following sub-sections through
which each platform is discussed:
Architecture components
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
15/79
Runtime environments Programming languages APIs Service providers Service requestors Service agents Platform extensions
SOA support in J2EE
Platform overview The Java 2 Platform is a development and runtime environment based
on the Java programming language. It is a standardized platform that
is supported by many vendors that provide development tools, server
runtimes, and middleware products for the creation and deployment of
Java solutions.
The Java 2 Platform is divided into three major development andruntime platforms, each addressing a different type of solution.
The Java 2 Platform Standard Edition (J2SE) is designed tosupport the creation of desktop applications
The Micro Edition (J2ME) is geared toward applications thatrun on mobile devices.
The Java 2 Platform Enterprise Edition (J2EE) is one of the two primaryplatforms currently being used to develop enterprise solutions using Webservices.
The Java 2 Platform Enterprise Edition (J2EE) is built to support large-scale,
distributed solutions. J2EE has been in existence for over five years and has been
used extensively to build traditional n-tier applications with and without Web
technologies
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
16/79
The Servlets + EJBs and Web + EJB Container layers (as well as theJAX-RPC Runtime) relate to the Web and Component Technology
layers established earlier in the SOA platform basics section. They do
not map cleanly to these layers because to what extent component and
Web technology is incorporated is largely dependent on how a vendorchooses to implement this part of a J2EE architecture.
The components shown in Figure 18.13 inter-relate with other parts of theoverall J2EE environment (as shown in Figure 18.14) to provide a platform
capable of realizing SOA.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
17/79
Three of the more significant specifications that pertain to SOA are listedhere:
Java 2 Platform Enterprise Edition Specification This importantspecification establishes the distributed J2EE component architecture
and provides foundation standards that J2EE product vendors are
required to fulfill in order to claim J2EE compliance.
Java API for XML-based RPC (JAX-RPC) This document defines theJAX-RPC environment and associated core APIs. It also establishes
the Service Endpoint Model used to realize the JAX-RPC Service
Endpoint, one of the primary types of J2EE Web services (explained
later).
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
18/79
Web Services for J2EE The specification that defines the vanilla J2EEservice architecture and clearly lays out what parts of the service
environment can be built by the developer, implemented in a vendor-
specific manner, and which parts must be delivered according to J2EE
standards.
Architecture components
J2EE solutions inherently are distributed and therefore componentized. Thefollowing types of components can be used to build J2EE Web applications:
Java Server Pages (JSPs) Dynamically generated Web pages hostedby the Web server. JSPs exist as text files comprised of code
interspersed with HTML.
Struts An extension to J2EE that allows for the development of Webapplications with sophisticated user-interfaces and navigation.
Java Servlets These components also reside on the Web server and areused to process HTTP request and response exchanges. Unlike JSPs,
servlets are compiled programs.
Enterprise JavaBeans (EJBs) The business components that performthe bulk of the processing within enterprise solution environments.They are deployed on dedicated application servers and can therefore
leverage middleware features, such as transaction support.
While the first two components are of more relevance to establishing thepresentation layer of a service-oriented solution, the latter two commonly are
used to realize Web services.
Runtime environments
The J2EE environment relies on a foundation Java runtime to process thecore Java parts of any J2EE solution. In support of Web services, J2EE
provides additional runtime layers that, in turn, supply additional Web
services specific APIs (explained later). Most notable is the JAX-RPC
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
19/79
runtime, which establishes fundamental services, including support for
SOAP communication and WSDL processing.
Additionally, implementations of J2EE supply two types of componentcontainers that provide hosting environments geared toward Web services-centric applications that are generally EJB or servlet-based.
EJB container This container is designed specifically to host EJBcomponents, and it provides a series of enterprise-level services that
can be used collectively by EJBs participating in the distributed
execution of a business task.
Examples of these services include transaction management,concurrency management, operation-level security, and object
pooling.
Web container A Web container can be considered an extension to aWeb server and is used to host Java Web applications consisting of
JSP or Java servlet components. Web containers provide runtime
services geared toward the processing of JSP requests and servlet
instances
Programming languages
The Java 2 Platform Enterprise Edition is centered around the Javaprogramming language. Different vendors offer proprietary
development products that provide an environment in which the
standard Java language can be used to build Web services.
SOA support in J2EEAPIs
Java API for XML Processing (JAXP) This API is used to process XMLdocument content using a number of available parsers. Both Document
Object Model (DOM) and Simple API for XML (SAX) compliant models
are supported, as well as the ability to transform and validate XML
documents using XSLT stylesheets and XSD schemas. Example packages
include:
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
20/79
javax.xml.parsersA package containing classes for different vendor-specific DOM and SAX parsers.
org.w3c.dom and org.xml.sax These packages expose the industrystandard DOM and SAX document models.
javax.xml.transform A package providing classes that exposeXSLT transformation functions.
Java API for XML-based RPC (JAX-RPC) The most established andpopular SOAP processing API, supporting both RPC-literal and document-
literal request-response exchanges and one-way transmissions. Example
packages that support this API include:
javax.xml.rpc & javax.xml.rpc.server These packages contain aseries of core functions for the JAX-RPC API
javax.xml.rpc.handler & javax.xml. rpc.handler.soap APIfunctions for runtime message handlers are provided by these
collections of classes. (Handlers are discussed shortly in the Service
agents section.)
javax.xml.soap & javax.xml.rpc.soap API functions for processingSOAP message content and bindings.
SOA support in J2EE
Java API for XML Registries (JAXR) An API that offers a standardinterface for accessing business and service registries. Originally developed
for ebXML directories, JAXR now includes support for UDDI.
javax.xml.registry A series of registry access functions that supportthe JAXR API.
javax.xml.registry.infomodel Classes that represent objects within aregistry.
Java API for XML Messaging (JAXM) An asynchronous, document-styleSOAP messaging API that can be used for one-way and broadcast message
transmissions (but can still facilitate synchronous exchanges as well).
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
21/79
SOAP with Attachments API for Java (SAAJ) Provides an APIspecifically for managing SOAP messages requiring attachments. The SAAJ
API is an implementation of the SOAP with Attachments (SwA)
specification.
Java Architecture for XML Binding API (JAXB) This API provides ameans of generating Java classes from XSD schemas and further abstracting
XML-level development.
Java Message Service API (JMS) A Java-centric messaging protocol used for
traditional messaging middleware solutions and providing reliable delivery
features not found in typical HTTP communication
Service providers As previously mentioned, J2EE Web services are typically implemented as
servlets or EJB components. Each option is suitable to meet different
requirements but also results in different deployment configurations, as
explained here:
JAX-RPC Service Endpoint When building Web services for usewithin a Web container, a JAX-RPC Service Endpoint is developed
that frequently is implemented as a servlet by the underlying Webcontainer logic.
EJB Service Endpoint The alternative is to expose an EJB as a Webservice through an EJB Service Endpoint. This approach is
appropriate when wanting to encapsulate existing legacy logic or
when runtime features only available within an EJB container are
required. To build an EJB Service Endpoint requires that the
underlying EJB component be a specific type of EJB called a Stateless
Session Bean.
A key part of either service architecture is an underlying model that definesits implementation, called the Port Component Model which establishes a
series of components that comprise the implementation of a J2EE service
provider, including:
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
22/79
Service Endpoint Interface (SEI) A Java-based interpretation of theWSDL definition that is required to follow the JAX-RPC WSDL-to-
Java mapping rules to ensure consistent representation.
Service Implementation Bean A class that is built by a developer tohouse the custom business logic of a Web service. The Service
Implementation Bean can be implemented as an EJB Endpoint
(Stateless Session Bean) or a JAX-RPC Endpoint (servlet).
For an EJB Endpoint, it is referred to as an EJB ServiceImplementation Bean and therefore resides in the EJB
container.
For the JAX-RPC Endpoint, it is called a JAX-RPC ServiceImplementation Bean and is deployed in the Web container.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
23/79
Service requestors
The JAX-RPC API also can be used to develop service requestors. Itprovides the ability to create three types of client proxies, as explained
here:
Generated stub The generated stub (or just "stub") is the mostcommon form of service client. It is auto-generated by the JAX-RPC
compiler (at design time) by consuming the service provider WSDL,
and producing a Java-equivalent proxy component. Specifically, the
compiler creates a Java remote interface for every WSDL portType
which exposes methods that mirror WSDL operations. It further
creates a stub based on the WSDL port and binding constructs. The
result is a proxy component that can be invoked as any other Java
component. JAX-RPC takes care of translating communication
between the proxy and the requesting business logic component into
SOAP messages transmitted to and received from the service provider
represented by the WSDL.
Dynamic proxy and dynamic invocation interface Two variationsof the generated stub are also supported.
The dynamic proxy is similar in concept, except that the actualstub is not created until its methods are invoked at runtime.
Secondly, the dynamic invocation interface bypasses the needfor a physical stub altogether and allows for fully dynamic
interaction between a Java component and a WSDL definition
at runtime.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
24/79
Service agents
Vendor implementations of J2EE platforms often employ numerous serviceagents to perform a variety of runtime filtering, processing, and routing
tasks. A common example is the use of service agents to process SOAP
headers.
To support SOAP header processing, the JAX-RPC API allows for thecreation of specialized service agents called handlers (Figure 18.17)runtime
filters that exist as extensions to the J2EE container environments. Handlers
can process SOAP header blocks for messages sent by J2EE service
requestors or for messages received by EJB Endpoints and JAX-RPC
Service Endpoints.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
25/79
Multiple handlers can be used to process different header blocks in the sameSOAP message. In this case the handlers are chained in a predetermined
sequence (appropriately called a handler chain).
Platform extensions Different vendors that implement and build around the J2EE platform offer
various platform extensions in the form of SDKs that extend their
development tool offering. The technologies supported by these toolkits,
when sufficiently mature, can further support contemporary SOA. Following
are two examples of currently available platform extensions.
IBM Emerging Technologies Toolkit A collection of extensions thatprovide prototype implementations of a number of fundamental WS-*
extensions, including WS-Addressing, WS-ReliableMessaging, WS-
MetadataExchange, and WS-Resource Framework.
Java Web Services Developer Pack A toolkit that includes both WS-* support as well as the introduction of new Java APIs. Examples of
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
26/79
the types of extensions provided include WS-Security (along with
XML-Signature), and WS-I Attachments.
Primitive SOA support
Service encapsulation The distributed nature of the J2EE platform allows for the creation of
independent units of processing logic through Enterprise Java Beans
or servlets. EJBs or servlets can contain small or large amounts of
application logic and can be composed so that individual units
comprise the processing requirements of a specific business task or an
entire solution.
Both EJBs and servlets can be encapsulated using Web services. Thisturns them into EJB and JAX-RPC Service Endpoints, respectively.
The underlying business logic of an endpoint can further compose and
interact with non-endpoint EJB and servlet components. As a result,
well-defined services can be created in support of SOA.
Loose coupling The use of interfaces within the J2EE platform allows for the
abstraction of metadata from a component's actual logic. When
complemented with an open or proprietary messaging technology,
loose coupling can be realized. EJB and JAX-RPC Endpoints further
establish a standard WSDL definition, supported by J2EE HTTP and
SOAP runtime services. Therefore, loose coupling is a characteristic
that can be achieved in support of SOA.
Messaging Prior to the acceptance of Web services, the J2EE platform supported
messaging via the JMS standard, allowing for the exchange of
messages between both servlets and EJB components. With the arrival
of Web services support, the JAX-RPC API provides the means of
enabling SOAP messaging over HTTP.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
27/79
Also worth noting is the availability of the SOAP over JMS extension,which supports the delivery of SOAP messages via the JMS protocol
as an alternative to HTTP. The primary benefit here is that this
approach to data exchange leverages the reliability features provided
by the JMS framework. Within SOA this extension can be used by thebusiness logic of a Web service, allowing SOAP messages to be
passed through from the message process logic (which generally will
rely on HTTP as the transport protocol). Either way, the J2EE
platform provides the required messaging support for primitive SOA.
SOA support in J2EE - Support for service-orientation principles
Autonomy For a service to be fully autonomous, it must be able to
independently govern the processing of its underlying
application logic. A high level of autonomy is more easily
achieved when building Web services that do not need to
encapsulate legacy logic. JAX-RPC Service Endpoints exist
as standalone servlets deployed within the Web container and
are generally built in support of newer SOA environments.
It may therefore be easier for JAX-RPC Service Endpoints toretain complete autonomy, especially when they are only
required to execute a small amount of business logic.
EJB Service Endpoints are required to exist asStateless Session Beans, which supports autonomy
within the immediate endpoint logic.
However, because EJB Service Endpoints are morelikely to represent existing legacy logic retaining a high
level of autonomy can be challenging.
Reusability
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
28/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
29/79
Note that even if JAXR is used to represent a UDDI registry, it doesso by exposing an interface that differs from the standard UDDI API.
(For example, a UDDI Business-Entity is a JAXR Organization, and a
UDDI BusinessService is a JAXR Service.)
SOA support in J2EE - Contemporary SOA support
Based on open standards The Web services subset of the J2EE platform supports industry
standard Web services specifications, including WSDL, SOAP, and
UDDI. Support for the WS-I Basic Profile also has been provided.
Supports vendor diversity Adherence to the vanilla J2EE API standards has allowed for a
diverse vendor marketplace to emerge. Java application logic can be
developed with one tool and then ported over to another. Similarly,
Java components can be designed for deployment mobility across
different J2EE server products.
Further, by designing services to be WS-I Basic Profile compliant,vendor diversity beyond J2EE platforms is supported.
Intrinsically interoperable Interoperability is, to a large extent, a quality deliberately designed
into a Web service. Aside from service interface design
characteristics, conformance to industry-standard Web services
specifications is critical to achieving interoperable SOAs, especially
when interoperability is required across enterprise domains.As of
version 1.1, the JAX-RPC API is fully capable of creating WS-I Basic
Profile-compliant Web services.
Promotes federation Strategically positioned services coupled with adapters that expose
legacy application logic can establish a degree of federation. Building
an integration architecture with custom business services and legacy
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
30/79
wrapper services can be achieved using basic J2EE APIs and features.
Supplementing such an architecture with an orchestration server
further increases the potential of unifying and standardizing integrated
logic. J2EE Connector Architecture (JCA), is a structured, adapter-
centric integration architecture through which resource adapters areused to bridge gaps between J2EE platforms and other environments.
As with JMS, JCA is traditionally centered around the use of
proprietary messaging protocols and platform-specific adapters.
Architecturally composable Given the modular nature of supporting API packages and classes and
the choice of service-specific containers, the J2EE platform is
intrinsically composable. This allows solution designers to use onlythe parts of the platform required for a particular application.
Extensibility As with any service-oriented solution, those based on the J2EE
platform can be designed with services that support the notion of
future extensibility. This comes down to fundamental design
characteristics that impose conventions and structure on the service
interface level. While still achieving extensibility within the vendorenvironment, proprietary extensions can limit the portability and
openness of Java solutions.
Supports service-oriented business modeling There is no inherent support for service-oriented business modeling
within J2EE.This is primarily because the concept of orchestration is
not a native part of the J2EE platform. Instead, orchestration services
and design tools are provided by vendors to supplement the J2EE
Web services development and runtime environment. Service-oriented
business modeling and the service layers can therefore be created with
the right vendor tools.
Logic-level abstraction
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
31/79
JAX-RPC Service Endpoints and EJB Service Endpoints can bedesigned into service layers that abstract application-specific or
reusable logic. Further, entire J2EE solutions can be exposed through
these types of services, when appropriate.
Depending on the vendor server platform used, some limitations may be
encountered when building service compositions that require message-level
security measures. These limitations may inhibit the extent of feasible logic-level
abstraction
Organizational agility and enterprise-wide loose coupling The creation of these service layers is possible with the help of a
vendor-specific orchestration server. Although the orchestration
offering is proprietary, the fact that other Web services are J2EE
standardized further promotes an aspect of agility realized through the
vendor diverse nature of the J2EE marketplace.
For example, if a vendor server platform is not satisfying currentbusiness needs and requires replacement, application, entity-centric,
and task-centric services likely will be sufficiently mobile so that they
can be used in the replacement environment. The orchestration logic
may or may not be portable, depending on whether a commonorchestration language, such as WS-BPEL, was used to express the
process logic.
To attain a state where business and technology domains of anenterprise are loosely coupled and achieve full, two-way agility,
requires the fulfillment of a number of contemporary SOA
characteristics. The J2EE platform provides a foundation upon which
to build a standardized and extensible SOA. Enterprise features
offered by vendor platforms need to be incorporated to add layers ontop of this foundation necessary to driving service-orientation across
the enterprise.
Java API for XML-based web services (JAX-WS)
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
32/79
JAX-WS stands for Java API for XML Web Services. JAX-WS isa technology for building web services and clients that
communicate using XML. JAX-WS allows developers to write
message-oriented as well as RPC-oriented web services. In JAX-WS, a remote procedure call is represented by an XML-based
protocol such as SOAP. The SOAP specification defines the
envelope structure, encoding rules, and conventions 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-WS API hides this complexity from the applicationdeveloper.
On the server side, the developer specifies the remoteprocedures 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 theservice) and then simply invokes methods on the proxy. With
JAX-WS, the developer does not generate or parse SOAP
messages. It is the JAX-WS runtime system that converts the
API calls and responses to and from SOAP messages.
With JAX-WS, clients and web services have a big advantage: theplatform independence of the Java programming language. Inaddition, JAX-WS is not restrictive: a JAX-WS client can access a
web service that is not running on the Java platform, and vice
versa. This flexibility is possible because JAX-WS uses
technologies defined by the World Wide Web Consortium (W3C):
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
33/79
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.
Java architecture for XML binding (JAXB)
The JavaArchitecture for XML Binding (JAXB) provides a fast and
convenient way to bind between XML schemas and Java
representations, making it easy for Java developers to incorporate XML
data and processing functions in Java applications. As part of this
process, JAXB provides methods for unmarshalling XML instance
documents into Java content trees, and then marshalling Java content
trees back into XML instance documents. JAXB also provides a way
generate XML schema from Java objects
A JAXB implementation consists of the following architecturalcomponents:
schema compiler: binds a source schema to a set of schemaderived program elements. The binding is described by an XML-
based binding language.
schema generator: maps a set of existing program elements to aderived schema. The mapping is described by program annotations.
binding runtime framework: provides unmarshalling (reading) andmarshalling (writing) operations for accessing, manipulating and
validating XML content using either schema-derived or existing
program elements.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
34/79
Take steps from The general steps in the JAXB data binding process are:
1. Generate classes. An XML schema is used as input to the JAXB bindingcompiler to generate JAXB classes based on that schema.
2. Compile classes. All of the generated classes, source files, and applicationcode must be compiled.
3. Unmarshal. XML documents written according to the constraints in thesource schema are unmarshalled by the JAXB binding framework. Note that
JAXB also supports unmarshalling XML data from sources other than
files/documents, such as DOM nodes, string buffers, SAX Sources, and so
forth.
4. Generate content tree. The unmarshalling process generates a content treeof data objects instantiated from the generated JAXB classes; this content
5. Validate (optional). The unmarshalling process optionally involvesvalidation of the source XML documents before generating the content tree.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
35/79
Note that if you modify the content tree in Step 6, below, you can also usethe JAXB Validate operation to validate the changes before marshalling the
content back to an XML document.
6. Process content. The client application can modify the XML datarepresented by the Java content tree by means of interfaces generated by the
binding compiler.
7. Marshal. The processed content tree is marshalled out to one or moreXML output documents. The content may be validated before marshalling.
Java API for XML Registries (JAXR)
The Java API for XML Registries (JAXR) provides a uniform and standardJava API for accessing various kinds of XML registries. After providing a
brief overview of JAXR, this chapter describes how to implement a JAXR
client to publish an organization and its web services to a registry and to
query a registry to find organizations and services. Finally, it explains how
to run the examples provided with this tutorial and offers links to more
information on JAXR.
Java API fThe high-level architecture of JAXR
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
36/79
The high-level architecture of JAXR consists of the following parts: A JAXR client: This is a client program that uses the JAXR API to
access a business registry via a JAXR provider.
A JAXR provider: This is an implementation of the JAXR API thatprovides access to a specific registry provider or to a class of registry
providers that are based on a common specification.
A JAXR provider implements two main packages: javax.xml.registry, which consists of the API interfaces and classes
that define the registry access interface.
javax.xml.registry.infomodel, which consists of interfaces that definethe information model for JAXR. These interfaces define the types of
objects that reside in a registry and how they relate to each other. The
basic interface in this package is the RegistryObject interface. Its
subinterfaces include Organization, Service, and ServiceBinding.
Java API for XML Registries (JAXR)
The most basic interfaces in the javax.xml.registry package are Connection. The Connection interface represents a client session with
a registry provider. The client must create a connection with the
JAXR provider in order to use a registry.
RegistryService. The client obtains a RegistryService object from itsconnection. The RegistryService object in turn enables the client to
obtain the interfaces it uses to access the registry.
The primary interfaces, also part of the javax.xml.registry package, are BusinessQueryManager, which allows the client to search a registry
for information in accordance with the javax.xml.registry.infomodel
interfaces. An optional interface, DeclarativeQueryManager, allows
the client to use SQL syntax for queries. (The implementation of
JAXR in the Application Server does not implement
DeclarativeQueryManager.)
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
37/79
BusinessLifeCycleManager, which allows the client to modify theinformation in a registry by either saving it (updating it) or deleting it.
Java API for XML Registries (JAXR)
When an error occurs, JAXR API methods throw a JAXRException or oneof its subclasses.Many methods in the JAXR API use a Collection object as
an argument or a returned value. Using a Collection object allows operations
on several registry objects at a time. Figure 61 illustrates the architecture of
JAXR. In the Application Server, a JAXR client uses the capability level 0
interfaces of the JAXR API to access the JAXR provider. The JAXR
provider in turn accesses a registry. The Application Server supplies a JAXR
provider for UDDI registries.
Java API for XML based RPC (JAX-RPC)
Purpose of the JAX-RPC Optional Package
The Java API for XML-Based RPC (JAX-RPC) is an implementationof Remote Procedure Call (RPC) technology in the Java language,
and is part of the Java 2, Enterprise Edition (J2EE) platform. The
JAX-RPC optional package subset, provided with the J2ME Web
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
38/79
Services Reference Implementation, is a scaled-down version of JAX-
RPC specifically tailored to the J2ME platform.
The J2ME JAX-RPC subset allows Java developers to create portableweb services clients that can easily exchange data between clients andback-end servers. Using XML and the Simple Object Access Protocol
(SOAP), JAX-RPC allows developers to dispatch Remote Procedure
Calls (RPC) to web services running on a different machine, a
different network, or in a different language. Using RPC, developers
can call methods on remote objects as easily as they can call them on
local objects.
Contents of the JAX-RPC Optional Package
The J2ME Web Services Reference Implementation JAX-RPCOptional Package contains three parts:
JAX-RPC Subset APIs - the Java APIs used to develop a specificimplementation of a web service. For more information, see The
JAX-RPC API Subset.
Remote Method Invocation (RMI) APIs - Java classes included withthe J2ME Web Services Reference Implementation to satisfy
dependencies of JAX-RPC on CLDC-based platforms.
A Java Web Services-specific Service Provider Interface (SPI) -enables stubs to be portable and compatible across varying
implementations of the Java Web Services Specification.
Web Services Interoperability Technologies (WSIT)
What is WSIT?Sun is working closely with Microsoft to ensure interoperability of web
services enterprise technologies such as message optimization, reliable
messaging, and security. The initial release of WSIT is a product of this joint
effort. WSIT is an implementation of a number of open web services
specifications to support enterprise features.
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
39/79
In addition to message optimization, reliable messaging, and
security,WSIT includes a bootstrapping and configuration technology.
Figure 11 shows the underlying services that were implemented for each
technology.
Message Optimization Technology
A primary function of web services applications is to share data among
applications over the Internet. The data shared can vary in format and include large
binary payloads, such as documents, images, music files, and so on. When large
binary objects are encoded into XML format for inclusion in SOAP messages,
even larger files are produced. When a web service processes and transmits these
large files over the network, the performance of the web service application and
the network are negatively affected. In the worst case scenario the effects are asfollows:
The performance of the web service application degrades to a point that it is no
longer useful.
The network gets bogged down with more traffic than the allotted bandwidth can
handle.
One way to deal with this problem is to encode the binary objects so as to
optimize both the SOAP application processing time and the bandwidth required to
transmit the SOAP message over the network. In short, XML needs to be
optimized for web services. This is the exactly what the Message Optimization
technology does. It ensures that web services messages are transmitted over the
Internet in the most efficient manner. Sun recommends that you use message
optimization if your web service client or web service endpoint will be required to
process binary encoded XML documents larger than 1KB.
Reliable Messaging Technology
Reliable Messaging is a Quality of Service (QoS) technology for building
more reliable web services. Reliability is measured by a systems ability to deliver
messages from point A to point B without error. The primary purpose of Reliable
Messaging is to ensure the delivery of application messages to web service
endpoints. The Reliable Messaging technology can also be used to implement
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
40/79
session management. A unique message sequence is created for each client-side
proxy and the lifetime of the sequence identifier coincides with the lifetime of the
proxy. Therefore, each message sequence can be viewed as a session and can be
used to implement session management.
You should consider using reliable messaging if the web service is
experiencing the following types of problems:
Communication failures are occurring that result in the network being unavailable
or connections being dropped
Application messages are being lost in transit
Application messages are arriving at their destination out of order and ordered
delivery is a requirement
To help decide whether or not to use reliable messaging, weigh thefollowing advantages and disadvantages:
Enabling reliable messaging ensures that messages are deliveredexactly once from the source to the destination and, if the ordered-
delivery option is enabled, ensures that messages are delivered in
order.
Enabling reliable messaging causes a degradation of web serviceperformance, especially if the ordered delivery option is enabled.
Non-reliable messaging clients cannot interoperate with web servicesthat have reliable messaging enabled.
Security Technology
Until now, web services have relied on transport-based security such
as SSL to provide point-to-point security. WSIT implements WS-Security soas to provide interoperable message content integrity and confidentiality,
even when messages pass through intermediary nodes before reaching their
destination endpoint. WS-Security as provided by WSIT is in addition to
existing transport-level security, which may still be used. WSIT also
enhances security by implementing WS-Secure Conversation, which enables
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
41/79
a consumer and provider to establish a shared security context when a
multiple-message-exchange sequence is first initiated. Subsequent messages
use derived session keys that increase the overall security while reducing the
security processing overhead for each message.
Further, WSIT implements two additional features to improve security inweb services:
Web Services Security PolicyEnables web services to use securityassertions to clearly represent security preferences and requirements
for web service endpoints.
Web Services TrustEnables web service applications to useSOAP messages to request security tokens that can then be used to
establish trusted communications between a client and a web service.
WSIT implements these features in such a way as to ensure that web servicebinding security requirements, as defined in the WSDL file, can interoperate
with and be consumed by WSIT and WCF endpoints.
SOA support in .NET
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
42/79
The .NET framework is a proprietary solution runtime anddevelopment platform designed for use with Windows operating
systems and server products. The .NET platform can be used to
deliver a variety of applications, ranging from desktop and mobile
systems to distributed Web solutions and Web services.
A primary part of .NET relevant to SOA is the ASP.NETenvironment, used to deliver the Web Technology layer within SOA
(and further supplemented by the Web Services Enhancements (WSE)
extension).
Common Language Runtime The Common Language Runtime (CLR) is a special run time environment
that provides the underlying infrastructure for Microsoft's .NET framework.
This runtime is where the source code of an application is compiled into an
intermediate language called CIL (Common Intermediate Language),
originally known as MSIL (Microsoft Intermediate Language). When the
program is then run, the CIL code is translated into the native code of the
operating system using a just-in-time (JIT) compiler.
This intermediate language is used to keep the environment platform-neutraland as a result, supports all .NET languages such as C# or VB.NET
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
43/79
Common Language Runtime
There are several key advantages to employing Common Language Runtimeand CIL listed below which are broken down into general advantages and
application related advantages.
General advantages Note: Much of the general advantages are taken from Microsofts
paper on CLR. The rest is from the Common Language Runtime
Architecture paper from Microsoft.
Portability Using an intermediate language instead of compiling straight to native
code requires n + m translators instead of n*m translators to
implement it in n languages on m platforms.
Security
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
44/79
The high level intermediate code is more ready for deployment andruntime enforcement of security and typing constraints than just low-
level binaries used in other languages.
Interoperability
Every major .NET language supports CLR and all get compiled toCIL. In that intermediate language, implementation of services such
as security and garbage collection are the same. This allows one
library or application of one .NET language to inherit
implementations from classes written in another .NET language. This
cuts down on the redundant code developers would have to write to
make a system work in multiple languages, allowing for multi-
language system designs and implementations.
Additionally, to keep full component interoperability, the runtime
incorporates all metadata into the component package itself, essentially
making it self-describing. As a result, no separate packages or metadata files
need to be kept in sync at all times with the compilation and the executable.
Flexibility Combining high level intermediate level code with metadata enables
the construction of (typesafe) metaprogramming such as reflection
and dynamic code generation.
Application related advantages The listed features or advantages are as of .NET 4.0
Automated Garbage Collection Support for explicitly free threading, which allows for the creation of
multi-threaded, scalable applications.
Support for uniform exception handling
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
45/79
Use of delegate functions instead of function pointers for increasedtype safety and security.
ASP .NET Web Forms
Web Forms are based on ASP.NET Working with Web Forms is similar to working with Windows Forms. But
the difference is that we will create Web pages with Web forms that will be
accessible by a Web browser.
Web Forms are Web pages that serve as the user interface for a Webapplication
. A Web Forms page presents information to the user in any browser orclient device and implements application logic using server-side code.
Web Forms are based on the System.Web.UI.Page class. There are three critical points
Web pages can have both web forms and web controls All processing is done on the server [ You can have client side
processing with scripting language but that is not a part of ASP.NET]
If you use ASP web control, what the browser sees is just HTML codeWEB FORM EVENTS
Forms are event driven and event describe the idea that something happened A event is generated when a user clicks a button or selects a list box or
otherwise interacts with the user interface
The method that responds to the event is called event handler in C# code andassociated with the control in the HTML page through control properties
ASP.NET event handler returns void and takes two parameters Object raising the event
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
46/79
Event Argument [ information specific to the event ] Web Application handle events on the server and therefore require a round
trip
ASP.NET supports a limited number of events like button click and textchange
POST BACK vs NON POST BACK EVENTS
Post Back events are those that cause forms to be posted back to the serverimmediately
This event sends the page to server for processing. This causes thepage a round-trip to the server.
These events include click type events like button type events Non Post Back events are those not posted back to the server immediately ,
instead these are cached by the control until the next time a post back event
occurs
STATE
The Web application state is the current value of all the controls andvariables for the current user in the current session
A web is inherently a stateless environment A stateless server is a server that treats each request as an independent
transaction that is unrelated to any previous request
ASP.NET Page Handling
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
47/79
CREATING WEB FORM
Click on File Menu->New->WebSite
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
48/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
49/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
50/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
51/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
52/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
53/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
54/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
55/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
56/79
THE FORM THAT IS IMPLEMENTED ALONG WITH CONTROLS
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
57/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
58/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
59/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
60/79
HelloWorld.aspx
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
61/79
Untitled Page
The following is to show printing data and date from DateTime
object
HelloWorld. Today the time is
The following is to show usage of controls i.e RadioButton
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
62/79
The following is from data binding and Radiobutton List
Enter Name:
Choose Your Company:
This is to demonstrate server side scripting
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
63/79
HelloWorld_aspx.cs
using System;
using System.Configuration;
using System.Data;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
public partial class HelloWorld_aspx : System.Web.UI.Page
{
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
64/79
protected void Page_Load(object sender, EventArgs e)
{
}
protected void btnOrder_Click(object sender, EventArgs e)
{
lblMsg.Text = "Thank You " + txtName.Text.Trim() + ".You
Chose " + rblShippers.SelectedItem.Text.ToString() + "whose ID is " +
rblShippers.SelectedIndex.ToString();
}
}
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
65/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
66/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
67/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
68/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
69/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
70/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
71/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
72/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
73/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
74/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
75/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
76/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
77/79
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
78/79
Code added
8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV
79/79
Web Services Enhancements (WSE)
Web Services Enhancements for Microsoft .NET (WSE) is a .NET
class library for building Web services using the latest Web services protocols,
including WS-Security, WS-SecureConversation, WS-Trust, and WS-Addressing.
WSE allows you to add these capabilities at design time using code or at
d l t ti th h th f li fil
Top Related