SERVICE ORIENTED ARCHITECTURE unit IV

8/3/2019 SERVICE ORIENTED ARCHITECTURE unit IV

1/79

UNIT IV

Based On

Service-Oriented Architecture: Concepts,

Technology, and Design

By Thomas Erl


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.


3/79

Common SOA platform layers

Relationship between SOA layers and technologies


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.


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.


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.


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/79

may be executed prior to the endpoint being contacted by an incoming

message.


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


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


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


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.


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


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


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


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.


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).


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


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:


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).


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:


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.


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.


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.


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


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.


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


28/79


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


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


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)


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):


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.


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.


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


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.


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.)


37/79

BusinessLifeCycleManager, which allows the client to modify theinformation in a registry by either saving it (updating it) or deleting it.


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


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.


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


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


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


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


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


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


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


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


47/79

CREATING WEB FORM

Click on File Menu->New->WebSite


48/79


49/79


50/79


51/79


52/79


53/79


54/79


55/79


56/79

THE FORM THAT IS IMPLEMENTED ALONG WITH CONTROLS


57/79


58/79


59/79


60/79

HelloWorld.aspx


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


62/79

The following is from data binding and Radiobutton List

Enter Name:

Choose Your Company:

This is to demonstrate server side scripting


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

{


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();

}

}


65/79


66/79


67/79


68/79


69/79


70/79


71/79


72/79


73/79


74/79


75/79


76/79


77/79


78/79

Code added


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

SERVICE ORIENTED ARCHITECTURE unit IV

Documents

Transcript of SERVICE ORIENTED ARCHITECTURE unit IV