Supply Chain Management System - Cadair

normalpetsSoftware and s/w Development

Nov 4, 2013 (3 years and 10 months ago)

142 views

1






1.
Introduction




1.1
Aim and Objectives



The purpose of this dissertation

is to develop a supply chain management
application based on SOA (Service Oriented Architecture) and investigate

and the best approach

use
d in developing SOA application





This supply chain management application is simple and scalable.

New services can easily be implemented and added into the system.




The research involves:




Investigate the best approach in developing SOA application such as

SOA application
using BPEL and SOA application using a traditional
approach



Investigate BPEL language, Oracle database, and various J2EE
technologies



Find the proper tools and application servers in developing SOA
application

such as Oracle SOA Suite, Oracle JDeveloper 10
g, Oracle
BPEL Process Manager, and NetBeans IDE6.1



Investigate JSF (Java Server Faces) used in developing User Interface



Design and develop a simple supply chain management application



Compare and evaluate the approaches in developing SOA application
incl
uding strengths and weaknesses from both approaches.



1.2
Scope of work


The main objective of this project is to develop a simple supply chain management
application. Therefore, this application does not show the application in a real life
scenario and i
t only can meet minimum requirements indentified in this project in order
to reduce the complexities of the system. This simple supply chain management avoids
developing many components. In addition,
there are
some
securities

requirements need to
be consid
ered.













2









1.3
Arrangement and Contents





Here is a summary of these chapters and how they work together.

In Chapte
r 1 explains the aim
, scope of

work,
and
arrangement of the projects, i
n the

Chapter 2 shows the software methodo
logy in developing supply chain management
application Chapter 3

provides a developer the concept of SOA, the BPEL language, and
Web Service, so that the developer can have a good understanding of SOA application
design and
development and in the Chapter 4

explains what Enterprise Java Bean is, type
of EJBs, and learns how to develop a JAX
-
WS web service with a basic example. If you
are an experienced java developer, so you might sk
ip this chapter. Next, Chapter 5

provides the concept of Java

Server Faces
Technology and some important components
such managed
-
bean and navigation in building server
-
side user

interfaces. And then,
Chapter 6

provides some reasons that why communication between web services and a
web service itself need to be secured and some ex
amples in settin
g up a secure channel.
Chapter 7

represents the structure of supply chain management
system,

overall
requirements,
use case diagram, The Value List Handler pattern that is used, sequence
diagram and some details of each web service working
together in the system then
Chapter 8 explains detailed design and some coding, and Chapter 9 show the table of
testing results

how to set up an environment in developing the app
lication. Chapter 10
application demonstration

followed
by Chapter 11 provides

tools used in the project, how
to run the application, next Chapter 12 explains why changes the approach, and Chapter
13
provides crit
ical evaluation and conclusions, finally chapter 14 Bibliography and
Appendix A, B, C, D, E
























3








2.
Software development methodology




Software development methodology is a framework that is applied to plan, and
control the software process of an information system. There are a wide range of
frameworks evolved over the years. Each methodolog
y is best suited to specific kinds of
projects. These approaches are:

[
26
]




Waterfall model

This model is a sequential development
process;

it begins with customer
specification of requirements and progress through planning, designing,
coding, testing, ma
intenance and deploy
ment. It is appropriate when the

r
equirements of a problem are well understood
.




Increme
n
tal model

This model supports the iterative and incremental development, which the
various parts of the system are developed at different times and

integrated as
they are completed.



Spiral model

This model is suitable for large, expensive and complicated projects



Agile model (Extreme Programming)


This model
is suitable for ongoing changes to requirements. They believe that
adaptab
ility to changing requirements anytime during project life is more realistic than
defining all requirements at the beginning of a project. The model also involves
developers doing pair
-
programming.


2.1
My approach



After I studied the specific nature o
f my project, I decided to choose an
incremental model as a main software development approach in this project due to the
following reasons:



It is not necessary to obtain complete requirements at the beginning of this
project, since the nature of this comp
lete project consists of many small
projects working together as a string of services in an SOA application.

As a

result, only basic requirements are addressed, buy many
supplementary features (some known, others unknown) remain
undelivered.



I was only on
e developer who worked on this project.



This project is a small
project;

it is no
t large, and complicated
.







4








It is essential to reduce inherent
project risk by breaking a project into
smaller segments and provide more requirements such as more com
plex
user interface or security consideration
s

during the development process.



Each service can be compared to one increment.



Each service is implemented at different time and some services needed to
be integrated before adding a new service into the sys
tem. The service is
also tested in different time.



The requir
e
ments are

easily changes and there are

a lot of re
-
designs and
integration tests.



The project gets more and more complex
and the design is often changed.


2.2 The incremental m
odel





Figure
1

t
he incremental Model


The first increment




At the beginning
, the system has
only basic requirements
, for instance,



A

simple retail

service
system
can fulfill

requests from custom
ers through a web browser.


The simple JSF web application a
nd a simple retail service were developed in this
increment with a simple user interface. The user only can place an order with the
limitation of number of product provided.









5







T
he second increment


In this increment, the system a
dded more service
s into the system, such as

FirstWarehouse service including integration tests between services.



T
he third increment


In this increment,
is to change user interface in order to make user interface
more flexible and scalab
le.
For example, in the first increment the user only can place an
order with the limitatio
n of number of product.


The

fourth increment, the security requirements needs to be considered and there is a re
-
design, and more functions
and more services are i
mplemented including testing.



































6





2.3
P
roject plan


NO.


Task Name


Duration


Date

1

Project Preliminary study

(SOA)


15 days


15/6/2008

2

Proposal


7 days



22/6/2008


3

Investigating SOA con
cept
and SOA development
approach


15 days


5/7/2008

4

Research and Choose what kind of application that is
suitable using SOA and web service technologies


15 days


19/7/2008

5

Design a simple
supply chain management application


7 days


26/7/2008

6

Investigate BPEL language and implement a simple
BPEL

business process including web services

Using NetBean IDE 6.1


30 days


26/8/2008

7

Investigate the proper tools in developing SOA
application JDeveloper and NetBeans IDE 6.1

15 days

10/9/2008

8

I
nvestigate Oracle SOA suite and BPEL process
manager and Oracle database

30 days

10/10/2008

9

Develop a BPEL process using Oracle technologies


7 days

17/10/2008

10

Integrating user interface with a BPEL process


7 days

24/10/2008

11

Problems and Soluti
ons, change the approach


7 days

1/11/2008

12

Investigate a new approach to develop SOA application


7 days

8/11/2008

13

Investigate JSF (Java Server Faces)

15 days

22/11/2008

14

Implementation ( start from scratch) Retailer service

15 days

22/11/2008

15

Implementation a web application

15 days

22/12/2008


16

Implement and integrate between both applications


7 days

29
/12
/2008

17

Testing / Integration Test/ Bug Fix


7 days

5/1
/200
9

18

Design and implement FirstWarehouse


7 days

12/1
/200
9

19

Implem
ent and integrate a Retailer Web service and

FirstWarehouse service


7 days

19/1
/200
9

20

Testing/Integration Test/Bug Fix

7

days

26/1
/200
9

22

Implement and integrate a Retailer Web service and

SecondWarehouse service

7

days

2/2
/200
9

23

Testing /Integra
tion

Test
/ Documentati
o
n

3
days

5/
2/200
9

24

Bug Fix


3

days

8/2
/200
9

25

Investigate security requirements in a supply chain
management application


3

days

11/2
/200
9

26

Investigate security technologies in j2EE and web
services


3

days

14/2
/200
9

27

Add

some securities and problems


3

days

17/2
/200
9

28

Redesign User Interface


7

days

24/2
/200
9

29

Documentation

29

days

23/2
/200
9

30

Bug Fix/Testing

7

days

23/3
/200
9

31

Completion of Project

7 days

30/3
/200
9



7







Summarize


Accordi
ng to the project pla
n table, th
e project plan is divided into 10

stages


1.

Project Preliminary study (SOA) and proposal

2.

Investigate SOA concept and SOA development

3.

SOA development using BPEL , JDeveloper, BPEL process manager, Oracle
Database

4.

Problems and Solutions

5.

Change the a
pproach and start from scratch

6.

Design and implement a supply chain management application

7.

Testing /Integration Test/ Bug Fix/ Document

8.

Redesign / User Interface/ add more functions/ services

9.

Documentation

10.

Completion of project


It can be clearly seen that
I spent a large amount of time investigating SOA approach,

development tools, BPEL language at the first part of this project. Then I found the
problems and changed the approach in developing a supply chain management
application based on SOA so that I wa
s able to complete the project.


























8







3. Concept of SOA and Web Service




3.1
Service Oriented Architecture

(SOA)











Figure
2
. A Service
-
Oriented Architecture



A service
-
oriented architecture

[18]

is an architect
ural approach supporting loosely
coupled services to enable business flexibility. SOA consists of a collec
tion of business
servi
ces in a network such the world
-
wide
-
web.




A service
offers a business function
with a well
-
defined interface. T
he service is
self
-
contained and does not
depend on other services
such as Loan Processing Service
,

that
processes the loan application. The many services can work together in a coordinated
way such as supply chain management system based on SOA. Multiple services are u
sed
to satisfy a more complicated business requirement.


SOA is not a new
architecture;

it has been around for y
ears related to the integration
,
development, and maintenance of complex enterprise applications. The use of SOA
approach is to improve and ext
end the flexibility of integration methods

(EAI) and
distributed architecture and reusability of existing applications.


The characteristic that makes SOA different from other architecture is loose coupling.
This means that the way a client communicates
with the service does not depend on the
implementation of the service. The client does not need to know what language the
service is coded or what platform the service runs on.

But what is new is the web service based on SOA.
A web service is a service
c
ommunicating with client through a s
et of protocols and technologies in an interoperable,
technology
-
agnostic manner. Hence web services are well
-
suited as the basis for a
service
-
oriented environment and most often implemented with web services.



9







3.
2
Why SOA


There are many good reasons to take an SOA approach.

[23]





Reusability

Developers can bring code implemented for existing applications and expose it as a web
service, then reuse it to meet new business requirements. This leads to reduce the
de
velopment cost and time.




Interoperability

The clients and services in service oriented environment communicate each other no
matter what platform they run on and which language used to implement services.




Scalability

S
ervices in SOA are loosely coupled
,
thus
it easy to enlarge applications using these
services
. That because there are few dependencies between the requesting application and
the services it uses.



Flexibility

Because SOA services are loosely
coupled,
they are more flexible than
tightly
-
cou
pled
applications. The components of an application are not tightly bound to each other. This
makes it easy to change the application in order to meet new business requirements.
The
loosely
-
coupled, asynchrono
us nature of services in a SOA
make
s

applicatio
n flexible.



Location transparency

Location transparency is another main characteristic of SOA architecture. A service
implementation can be moved from location to location without client’s knowledge. This
increases service availability and performance.























10








3.3
SOA, Web Services and BPEL



SOA
[27]

describes the communication pattern between services, functions and
their operations. The service itself and interactions between services are defined using a
description language such a
s web service description language (WSDL). Each interaction
is loosely
-
coupled. Thus, web service technology is main foundation of developing SOA
application. This project focuses on orchestration of a supply chain management. By the
definition, orchestrat
ion illustrates how web services can interact with each other at the
message level including the business logic.



A
ccording to research,

BPEL is a language for specifying with web services.
Hence BPEL is main important component used in developing SOA app
lication.


To have a good understanding in developing a SOA application, it is important to
know details of using BPEL and it will be presented in details on the topic Business
Process.




3.4
SOA design and Development




To build a SOA application, f
irst of all, a developer needs to break out the
different pieces of business logic into services.


The service can be:



Defined by well
-
published interfaces.



Loosely coupled



Entities encapsulating reusable business functions


In a SOA application
, services

communicate with each other using different message
exchange patterns

(
one
-
way, synchronous and asynchronous)



To implement SOA application

[24]





Identify the different units of business logic and units of work to be
performed



The functionality
of the units of work is described in term of
services by implementing stateful or stateless service.



Identify the main infrastructure services, which each service needs
to use.



Define the major pieces of common functionality, if any, between
the various se
rvices. Make sure that the common functionality is
described as a reusable service.




The different pieces of functionality is exposed as a service in
terms of operations such as web service




Describe events that services would be producing or
consuming
.




B
uild workflows to enab
le service choreograph


11







3.5

Business Processes

BPEL



BPEL [
18
]

(Business Process Execution Language) has become one of the most
important language for

developing SOA application. It
is a language used for
composition, orchestrati
on, and coordination of web services.
It offers rich functions to
manage the behavior of business processes. BPEL also introduces a new concept into
application development.

Developers can do programming in the large rather than do
programming in the small

using traditional approach. This BPEL concept allows
developers to create business processes quickly by only defining in which services will
be invoked. This make
s

applications become more flexible to the changes in business
processes.


Developing Busi
ness Processes with BPEL



Business processes are processes that compose a collection of services. A
business is described in BPEL.


In a typical scenario, the BPEL business process receives a request from client.
To fulfill the request, the BPEL process
will invokes the involved web services and
responses to the caller. In the process, a developer requires to specify relations between
several web services. These relations are called partner links.


Furthermore, BPEL provides conditional behavior. For ex
ample, a developer can
construct loops, declare variables, copy and assign values.

To understand how BPEL works, a developer needs to understand the concepts first.



BPEL Concepts




A BPEL process is made up of steps. Each step is called an
activity. Activities
represent basic constructs and used for common tasks such as



Invoking other web services, using <invoke>



Waiting for the client to invoke the business process using <receive>



Generating a response , using <reply>



Manipulating data vari
able, using <assign>



Terminating the entire process, using <terminate>


In addition, the interface of new BPEL web service uses a set of port types, which
it offers operations like any other web services.


To make the BPEL concepts clear
, l
ets look at a B
PEL business process Example of a
simple supply chain management.






12







BPEL Business Process Example
(A simple business supply chain management)







Figure 3

BPEL process for business supply chain management




I have defined a simple business process for business supply chain
management. Lets consider the business process. When client make a request to the
business process, first the process will receive the request using the receive activity

(
no

shown in diagram). Then the process will invoke a retailer service using the invoke
activity to ask for catalog products. After that the retailer service sends the response back
to the process using the reply activity (not shown in the diagram). And the r
esponse is
passed to the client. Next the client submit
s

the quantity of products, the new request is
sent to the process and the request is fulfilled by
the retailer service. The retailer first
needs to check stock level to see whether warehouseA has enou
gh products or not enough
by invoking the invoke activity

(for warehouseA). The response returns the response
using the receive activity. If the warehouseA can not fulfill the request, the warehouseB
will be invoked by the invoke activity

(for warehouseB).

The response is returned from
warehouse B to the process, finally the process pass
es

this response to client and the
process ends.


13








3.6
Web Service Overview






A web service is
a remote application, which is accessed by clients using
XML
-
based pro
tocols such

as Simple Object Access Protoco
l

(SOAP) and data is
transmitted over internet protocols such as Http.
It has its interfaces described using Web
Service
Definition Language (WSDL) file
[7]




Web services use Internet technology for system inte
roperability, which is
supported by almost every technology vendor (Microsoft, IBM, BEA, Sun Microsy
stems,
Oracle, HP, and others). Web services also offer a way for applications to expose their
functionality over a network, regardless of implementation la
nguages, platforms.

Not
only can web services help an enterprise to enlarge business offerings, improve the
efficiency of business processing. Web Services Technolog
y has been increasingly
adopted
, since it can cut down operational costs by allowing organi
zations to extend and
reuse their existing system functionality.













3.7

Benefits of Web Services




R
eus
ab
i
li
ty

Web

services play a big role in improving software reusability in organizations. Web
services can wrap

legacy application, databases,

and objects
then expose them as services.
In addition, web services are built on interoperable and ubiquitous standard.




Fre
edom of choice

Web services standards have created a huge marketplace for tools, products, and
technologies. Organizations have a wide range of options to select configurations that
best meet their requirements. Furthermore, developers can boost their prod
uctivity rather
than using their own solutions. They have a chance to choose from a market of
application components.



Support more client types

Since web services offer interoperability, there are more choices in supporting more
client types regardless of
the platform: Java or Microsoft or it can be based even on a
wireless platform.



Interoperability in a heterogeneous environment

Web services allow different distributed services to run across different software
platforms and architectures and web service
s also can be implemented in different
languages.




Location Transparency

A client can find a service and does need to care where the service is located. Thus, an
organization is able to move services to different machines. Developers also can move
code fro
m one platform to another.


14









3.8

SOAP


For Web services, the protocol that is used called SOAP.
Soap is a distributed
object protocol based on XML. It is defined by its own XML schema

and depended on
XML namespaces.


SOAP Message Structure











Figure

4

SOAP Message Structure


Example of soap message


<?xml version='1.0' ?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap
-
envelope">


<env:Header>


<m:reservation xmlns:m="http://tr
avelcompany.example.org/reservation"


env:role="http://www.w3.org/2003/05/soap
-
envelope/role/next"


env:mustUnderstand="true">


<m:reference>uuid:093a2da1
-
q345
-
739r
-
ba5d
-
pqff98fe8j7d</m:reference>


<m:dateAndTime>2001
-
11
-
29T13:20:00
.000
-
05:00</m:dateAndTime>


</m:reservation>


<n:passenger xmlns:n="http://mycompany.example.com/employees"


env:role="http://www.w3.org/2003/05/soap
-
envelope/role/next"


env:mustUnderstand="true">


<n:name>Åke Jógvan Øyvind</n:name>


</n:passenger>


</env:Header>


<env:Body>


<p:itinerary


xmlns:p="http://travelcompany.example.org/reservation/travel">


<p:departure>




15











<p:departing>New York</p:departing>


<p:arriving>Los Angeles</p:arriving>


<p:departureDa
te>2001
-
12
-
14</p:departureDate>


<p:departureTime>late afternoon</p:departureTime>


<p:seatPreference>aisle</p:seatPreference>


</p:departure>


<p:return>


<p:departing>Los Angeles</p:departing>


<p:arriving>New York</p:arriving>


<
p:departureDate>2001
-
12
-
20</p:departureDate>


<p:departureTime>mid
-
morning</p:departureTime>


<p:seatPreference/>


</p:return>


</p:itinerary>


<q:lodging


xmlns:q="http://travelcompany.example.org/reservation/hotels">


<q:preference>none</
q:preference>


</q:lodging>


</env:Body>

</env:Envelope>




A SOAP message

is a XML document containing
The optional <Header>
element, The mandatory <Body> element, and envelope element.


The envelope element




This element acts like a container for the

body element and header element.
The envelop element is used to indicate the start and the end of the message to the
receiver. When the receiver find the </Envelope> tag, it understand that the message has
ended.





The <Header> element [2]



It is optio
nal element and has to be located at the first immediate child
element of the envelope element. It is used for holding infrastructure data such as security
data, transaction data, routing information.








16









The Body element




The body contains t
he actual message such as a complete
purchase order
sent from the consumer to provider. The message can be RPC style describing details
about procedure and parameters.


The Fault element




This element is embedded in
the body and is
used to carry error a
nd status
information within a SOAP message
. It indicates a problem while processing the message.
Such a message is called a SOAP fault. Proble
ms can be application
-
specific (
username
not f
ound) or system issues such as
the problem of finding a host name.


This fault element has two subelements

1.

A mandatory fault

code element
,
showing

the common errors.

2.

A mandatory fault

string element, giving a human
-
readable explanation of errors.


3.9

WSDL (Web Services Description Language)








Figure 5

shows
WSDL document: a conceptual representation



17









Sample WSDL document [18]



<definitions name="EndorsementSearch"
targetNamespace="http://namespaces.snowboard
-
info.com"
xmlns:es="http:
//www.snowboard
-
info.com/EndorsementSearch.wsdl"
xmlns:esxsd="http://schemas.snowboard
-
info.com/EndorsementSearch.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/" >

<!
--

omitted types section with content mo
del schema info
--
>


<message name="GetEndorsingBoarderRequest"> <part name="body"
element="esxsd:GetEndorsingBoarder"/> </message>

<message name="GetEndorsingBoarderResponse"> <part name="body" e e
element="esxsd:GetEndorsingBoarderResponse"/> <
/message>

<portType name="GetEndorsingBoarderPortType">


<operation name="GetEndorsingBoarder">


<input message="es:GetEndorsingBoarderRequest"/>


<output message="es:GetEndorsingBoarderResponse"/>


<fault message="es:GetEndorsingBoarderFa
ult"/>


</operation>

</portType> <binding name="EndorsementSearchSoapBinding"
type="es:GetEndorsingBoarderPortType">


<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>


<operation name="GetEndorsingBoarder
">


<soap:operation


soapAction="http://www.snowboard
-
info.com/EndorsementSearch"/>



<input>


<soap:body use="literal" namespace="http://schemas.snowboard
-
info.com/EndorsementSearch.xsd"/>


</input>


<output> <soap:body
use="literal" namespace="http://schemas.snowboard
-
info.com/EndorsementSearch.xsd"/>

</output>


18








<fault> <soap:body use="literal" namespace="http://schemas.snowboard
-
info.com/EndorsementSearch.xsd"/>

</fault>

</operation>

</binding>


<service name
="EndorsementSearchService"> <documentation>snowboarding
-
info.com
Endorsement Service</documentation>


<port name="GetEndorsingBoarderPort"

binding="es:EndorsementSearchSoapBinding">

<soap:address location="http://www.snowboard
-
info.com/EndorsementSearc
h"/>
</port>

</service>

</definitions>



In WSDL, there are three

elements describing all abstract definitions of the Web
Service interface.

1.

Types
:
contains the language
-
independent data type definitions

using XML schema

the key structure of t
he types element is


<definitions
>


<types>



<xsd:schema../>


</types>

</definitions>


There are two elements of type MathInput (Add, Subtract) and two elements of type
MathOutput (AddResponse, SubtractResponse).


<definitions


xml
ns="http://schemas.xmlsoap.org/wsdl/"


xmlns:xs="http://www.w3.org/2001/XMLSchema"


xmlns:y="http://example.org/math/"


xmlns:ns="http://example.org/math/types/"


targetNamespace="http://example.org/math/"

>



19










<types>


<xs:schema


targetNamespace="http://example.org/math/types/"


xmlns="http://example.org/math/types/"


>


<xs:complexType name="MathInput">


<xs:sequence>


<xs:element name="x" type="xs:double"/>


<xs:element name="y" type="xs:double"/>



</xs:sequence>


</xs:complexType>


<xs:complexType name="MathOutput">


<xs:sequence>


<xs:element name="result" type="xs:double"/>


</xs:sequence>


</xs:complexType>


<xs:element name="Add" type="MathInput"/>


<
xs:element name="AddResponse" type="MathOutput"/>


<xs:element name="Subtract" type="MathInput"/>


<xs:element name="SubtractResponse" type="MathOutput"/>


</xs:schema>


</types>


...

</definitions>



3.
messages
:

can serve as the input and o
utput parameters for the service
.

The content of a message depends on the interaction between the consumer and the
service. For instance, if you define an RPC style service, the message parts is represented
by listing parameters.


<definitions


xmlns="h
ttp://schemas.xmlsoap.org/wsdl/"


xmlns:xs="http://www.w3.org/2001/XMLSchema"


xmlns:y="http://example.org/math/"


xmlns:ns="http://example.org/math/types/"


targetNamespace="http://example.org/math/"

>


...


<message name="AddMessage">


<
part name="parameter" element="ns:Add"/>


</message>



20








<message name="AddResponseMessage">


<part name="parameter" element="ns:AddResponse"/>


</message>


<message name="SubtractMessage">


<part name="parameter" element="ns:Subtract"
/>


</message>


<message name="SubtractResponseMessage">


<part name="parameter" element="ns:SubtractResponse"/>


</message>


...

</definitions>


3.

portTypes
: represents operation name, input, and output parameters.

The portType describes a set
of webservice operations
. Each operation consists of input
element,output element,and also a fault element.

An input element represents the type of soap message that a client should send to the web
service. An output element describes the type of soap mess
age that a client expects to get
back.


There are two styles of web services messaging: request
-
response and one
-
way.

Request
-
response messaging requires an input element, an output element, and an
optional fault element.


The following request
-
response m
essaging:



<portType name="MathInterface">


<operation name="Add">


<input message="y:AddMessage"/>


<output message="y:AddResponseMessage"/>


</operation>


</portType>

In addition, one
-
way message style contains only an i
nput element, but no output element
and fault element.



Bindings
:
describes the

concrete details of a portType, the type of encoding
used to send and receive messages, and protocol that SOAP messages are carried.

The
key structure of a binding element is

shown below

<binding name="MathSoapHttpBinding" type="y:MathInterface">


<soap:binding style="document"


transport="http://schemas.xmlsoap.org/soap/http"/>


<operation name="Add">


<soap:operation


soapAct
ion="http://example.org/math/#Add"/>


<input>


<soap:body use="literal"/>




21








</input>


<output>


<soap:body use="literal"/>


</output>


</operation>


...


</binding>


Services:
desc
ribes a group of ports or endpoints.

In the port element,there is the address details showing where the service is located.



<service name="MathService">


<port name="MathEndpoint" binding="y:MathSoapHttpBinding">


<soap:address



location="http://localhost/math/math.asmx"/>


</port>


</service>




























22







4.1
Enterprise Bean



An Enterprise

java bean [
2]

is a key server
-
side component used for distributed
applications. It provides a standard model fo
r implementing server components
representing business process. Such as purchasing order, inventory process. Furthermore,
these distributed component
s

do not have to reside on the same server, they can res
ide in
wherever it is suitable in order to reduce l
atency or maximize reliability.



Benefits of Enterprise Beans



EJB architecture increases the productivity of application developers by

automating the use of complex infrastructure services such as transaction management
and security authorizat
ion.

While developing distributed ap
plication, developers only
need

to focus on business logic rather than transaction and security issues. In addition
,
EJB supports
scalability;

it accommodates a growing number of users.



4.2
Type of EJBs



Enterprise ja
va bean comes in two different types



Session beans


Session bean is used to manage business process or perform tasks for clients.

A session
bean is not persistent and data is not mapped and stored into a database. Session beans
work with entity beans and
other resources to control interactions of beans. They manage
tasks and resources but they don not represent data.

In addition, a stateless session bean does not maintain state from one method invocation
to the next. It does not care what other requests
have gone or followed.

More importantly, a stateless session bean can be implemented as a web service and it is
used in this Supply chain management system.




Entity beans

Entity beans represent business objects and are mapped to tables in a relation data
base.

These entity beans objects can be allocated, and sent across the network. They are
persistent, have primary keys and can have relationships with ot
her entity beans.



4.3
Using JAX
-
WS




JAX
-
WS is a fundamental technology for developing web service
s and
clients. JAX
-
WS is designed to take place o
f JA
-
RPC, thus it can simplify

the creation of
web service.

In addition, the JAX
-
WS specification offers an extensive set of
annotations and these annotations make web services a lot easier to implement.

Developers only needs to add two annotations @WebService and @WebMethod to
transform a statless EJB into a web service.


23








Reason to implement a JAX
-
WS web service

[22]




JAX
-
WS 2.0 fully supports the java architecture for XML binding

(jaxb)
specificat
ion and jaxb offers a way to bind a xml schema to a
representation in java code. This is easy for developers to integrate xml
data and processing functions in applications without knowing much
about xml.




JAX
-
WS model is robust because developers can use
additional
annotations to customize the mapping from java to xml schema or
WSDL and map Web Service operation names to meaningful names in
the WSDL file.




Since JAX
-
RPC is not evolving , the future of web service is JAX
-
WS



The @WebService annotation



@
javax.jws.WebService is main annotation used to specify that the class is a web
service. This annotation has to be placed on the stateless session bean class so as to
expose it as a web service. There are some key attributes that developers should know:



Th
e name() attribute is the name of the web service



The wsdlLocation() attribute defines the URL of the WSDL document
representing this web service.


The @WebMethod annotation





@javax.jws.WebMethod is another key annotation used to define an operation of

web service. Every method in java class is transformed to operations of web service by
adding @javax.jws.WebMethod.
There

are some key attributes that developers should
know:




The operationName() attribute is used to define the WSDL operation. If
it is no
t specified, the java method is used.






.







24







For example,


import javax.ejb.Stateless;

import javax.jws.WebService;


@Stateless

@WebService(name =”TravelAgent”)

public class TravelAgentBean{





@WebMethod(operationName= “Reserve”)




Public St
ring makeReservation(){




}

}



The Service Endpoint Interface



A service endpoint interface is a java interface declaring the methods
that a client
can invoke on the service.
A
JAX
-
WS client can use the @javax.xml.ws.WebServiceRef
annotation to referenc
e a service endpoint interface directly.


For example,




@WebServiceRef(wsdlLocation
=
"http://localhost:8090/ProductItemsBSBeanService/ProductItemsBSBean?wsdl")






















25








5.1
JSF Overview




Java

Server Faces Technology (JSF) [1] is a s
erver
-
side user interface framework,
which simplifies the creation of java web applications. It offers a set of APIs for
representing UI components, state management, event handling, input validation, and
internationalization support. Furthermore, it also
provides custom tag libraries for
expressing UI components in a JSP Page in order to wire up components to server
-
side
objects.





Figure 6

High
-
level Overview of the JSF framework



The primary benefits of Java

Server Faces Tech
nology

[2]




Ease
-
of
-
Use


JSF framework is based on Model
-
View
-
Con
troller architecture (MVC),
offer
ing

a clean separation between presentation and business logic

This facilitates each member in a development team to focus on his or her own
piece
of development process. For instance, page authors who specialize in graphic design
can design look and feel of web application using the Java Server Faces tag libraries.
This leads to a division of labor and brings a rapid development cycle.



Stan
dardization

JSF technology is a standard framework for constructing a server
-
side
user interface application. It is being developed through the Java Community Process
under JSR
-
127. Many respected tools vendors are committed to
supporting JSF
technology in

their tools.





26










Device Independency


JSF technology is flexible and maintainable. It defines component
functionality in extensible UI component classes, and allows component developers
to extend the component classes to produce their own component t
ag libraries for
specific clients.



Java Server Faces Application



A typical JSF application comprises the following:




A set of JSF pages, which is a JSP page that has JSF tags. It uses custom tags to
express the user interface components.



A set of back
ing beans, which are javabeans components, expose properties and
functions for UI components on the page



A configuration file ,which is faces
-
config.xml file



It could be a set of custom objects implemented by the web developer such as

custom components, v
alidators, converters, or listeners.



In JavaServer Faces development, the application code is written in beans and the design
is in web pages. First, look at beans


5.2 Managed
-
Beans



Bean is a class that exposes properties and events. In a bean class,
properties can
be any attribute of a bean such as a name, a type, and methods for getting and setting the
property value. Bean is used when a developer need to wire up java classes with web
pages or configuration files.


For instance, in this UserBean cla
ss, there are two properties, name and password.




Public class UserBean{



public String getName(){…}



public void setName(String newValue){…..}



public String getPassword(){……..}



public void setPassword(String newValue){….}


}








27






In

addition, UserBean instance needs to be configured in the face
-
config.xml file:



<managed
-
bean>



<managed
-
bean
-
name>user </managed
-
bean
-
name>


<managed
-
bean
-
class>com.corejsf.UserBean</managed
-
bean
-
class>


<
managed
-
bean
-
scope>session</managed
-
bean
-
scope>


</managed
-
bean>



This above means the object named User is created in com.corejsf.UserBean and it is
alive for the duration of the session for all requests that stem from the same client.



When

looking in the User design code,





<h:inputSecret value=”{user.password}”/>

This input filed reads and updates the password property of the user bean. The beans are
produced according to the managed
-
bean elements in the configuration file.



JSF pages



In typical JSF pages, it mostly starts with the tag library declarations



<%@ taglib uri=”http://java.sun.com/jsf/core” prefix=”f” %>


<%@ taglib uri=”http://java.sun.com/jsf/html” prefix=”h” %>


<f:view>



<h:form id=”helloForm1”>




</h
:form>


</f:view>


The first tag is the core tag that is independent of the redering technology and the
second tag is the HTML tags that creates HTML
-
specific markup and is followed by the
view tag. All JavaServer Faces component tags need to be

inside this view tag.



5.3
Navigation


Navigation is a set of rules, which tell the JSF application that which page needs
to be displayed next after the button in the form has been submitted.

In this example, when the user clicks the login button,the
page is changed from
the index.jsp page to welcome.jsp page.








28







<navigation
-
rule>


<from
-
view
-
id>/index.jsp</from
-
view
-
id>


<navigation
-
case>



<from
-
outcome>login</from
-
outcome>



<to
-
view
-
id>/welcome.jsp</to
-
view
-
id>


<
/navigation
-
case>

</navigation
-
rule>


In the from
-
outcome tag, the value login matches the action attribute of the command
button of the index.jsp page


<h:commandButton value=”Login” action=”login”/>




5.4
JSF TAGS



There are a number of important JSF

tags used in this web application

An example from List.jsp



<f:view>


<head>


<meta http
-
equiv="Content
-
Type" content="text/html; charset=UTF
-
8" />


<!
--

We use the url tag to make sure the correct path is found for the re
source
--
>


<c:url value="/styles.css" var="stylesUrl"/>


<!
--

The out tag will convert the expression language statement into text that is


used as the href value
--
>


<link href='<c:out value="${stylesUrl}
"/>' rel="stylesheet"
type="text/css"/>


<title>


<h:outputText value="#{msgs.ProductItemDetailsTitlepage}"/>


</title>


</head>


<body>


<center>


<h:graphicImage value="/images/banner.jpg"/>


<h:form>



<center>





<h:commandLink value="TV" action="tv"/> |


<h:commandLink value="Camera" action="camera"/> |


<h:commandLink value="MP3" action="mp3"/> |


<h:commandLink value="LAPTOP" acti
on="laptop"/> |


<h:commandLink value="Mobile phone" action="phone"/> |


</center>





29








<h:outputText value="#{msgs.ProductItemDetailsTitlepage}"
styleClass="emphasis"/>


<h:panelGroup rendered="#{Brow
seProduct.itemcount > 0 }">


<!
--

Display the Items n..m of pages list. Note the use of parameters
--
>


<h:outputFormat value="#{msgs.pagePreviousNext}">


<f:param value="#{BrowseProduct.firstItem + 1}"/>



<f:param value="#{BrowseProduct.lastItem}"/>


<f:param value="#{BrowseProduct.itemcount}"/>


</h:outputFormat>


<h:outputText value=" "/>


<h:commandLink action="#{BrowseProduct.prev}"



value="#{msgs.previous} #{BrowseProduct.pageSize}"


rendered="#{BrowseProduct.firstItem >= BrowseProduct.pageSize}"/>


<h:outputText value=" "/>


<h:commandLink action="#{BrowseProduc
t.next}"


value="#{msgs.next} #{BrowseProduct.pageSize}"


rendered="#{BrowseProduct.lastItem + BrowseProduct.pageSize <=
BrowseProduct.itemcount}"/>


<h:outputText value=" "/>





<h:commandLink action="#{BrowseProduct.next}"


value="#{msgs.remaining} #{BrowseProduct.itemcount
-

BrowseProduct.lastItem}"


rendered="#{BrowseProduct.lastItem < BrowseProduct.itemcount &&
Browse
Product.lastItem + BrowseProduct.pageSize > BrowseProduct.itemcount}"/>


<br />


<!
--

We now display the data
--
>


<h:dataTable value='#{BrowseProduct.items}' var='item'


styleClass="evenRow"
headerClass="columnHeader"


columnClasses="evenRow,oddRow">


<h:column headerClass="columnHeader">


<h:graphicImage url="#{item.imageurl}"/>


</h:column>







<h:column headerClass="columnHeader">


<f:facet name="header">


<h:outputText value="#{msgs.productHeader}"/>


</f:facet>


<h:out
putText value="#{item.productnumber}"/>


</h:column>






30








<h:column headerClass="columnHeader">


<f:facet name="header">


<h:outputText value="#{msgs.nameHeader}"/>



</f:facet>


<h:outputText value="#{item.productname}"/>


</h:column>


<h:column headerClass="columnHeader">


<f:facet name="header">


<h:outputText value="#{msgs.category
Header}"/>


</f:facet>


<h:outputText value="#{item.category}"/>


</h:column>






<h:column headerClass="columnHeader">


<f:facet name="header">



<h:outputText value="#{msgs.priceHeader}"/>


</f:facet>


<h:outputText value="#{item.price}"/>


</h:column>




<h:column headerClass="columnHeader">


<f:f
acet name="header">


<h:outputText value="Show details"/>


</f:facet>


<center>


<h:commandLink value="#{msgs.show}"
action="#{BrowseProduct.detailSet}">


<f:param name="currentPro
ductItem
"
value="#{item.productid}"/>


</h:commandLink>


</center>


</h:column>


</h:dataTable>


</h:panelGroup>


</h:form>


</center>

</f:view>










31







Displaying Text and Image
s



These are three basic tags used to display text and images




h:outputText

This tag produces text and a developer can specify

many attributes attached to it.
For
example, converter, id, rendered, styleClass, value


<h:outputText value="#{msgs.Pr
oductItemDetailsTitlepage}"/>





The value from Message.properties file will be accessed and displayed by using
outputText.




h:graphicImage

This tag helps to generate an image



<h:graphicImage value="/images/banner.jpg"/>



h:outputFo
rmat

This

tag is used for displaying output with parameters specified in the body of the
tag


For example,



<h:outputFormat value=”{0} is{1} high”>




<f:param value=”This building” />




<f:param value=”very”/>


</h:outputFormat>


Links




h:c
ommandLink


The h:commandLink tag produces an HTML anchor element that acts like a
submit button.

<h:commandLink value="TV" action="tv"/>

















32








Passing data from User interface to the server




The f:param tag


Using this tag, a develo
per can attach a parameter to a component. More
interestingly, the f:param tag perform differently depending on the type of
component attached.

For instance, you use h:outputFormat , JSF uses the value of parameters to fill in
placeholders, such as {0}, {
1}. If you use f:param tag with a command
component such as h:commandLink. JSF will pass the parameter’s value to the
server as a request parameter.

An example is shown below:


<h:commandLink action="#{OrderController.add}"
value="#{msgs.addToCart}">



<f:param name="currentProductItem"
value="#{BrowseProduct.productItem.productid}" />


<f:param name="currentNumberItem"
value="#{BrowseProduct.productItem.productnumber}" />


<f:param name="currentNameItem"
value="#{BrowsePr
oduct.productItem.productname}" />


</h:commandLink>


PanelGroup




h:panelGroup is often used with h:panelGrid. The role of panelGroup is
to group
two or more components
,

therefore they can be treated as one component.

For instance, you gr
oup an input field and error message together:



<h:panelGrid column=”2”>



<h:panelGroup>




<h:inputText id=”name” value=”#{user.name}”>


<h:message for=”name” />



</h:panelGroup>


</h:panelGrid>













33






Data Tables



h:dataTable tag


Java Server Faces offers a powerful tag called h:dataTable used for creating Tables
while iterating the data from a backing bean. This tag can iterate over the collection or
array of values.


While h:dataTabl
e iterates, it create each item in the list and the name of the item
is specified with h:dataTable’s attribute.




<h:dataTable value='#{BrowseProduct.items}' var='item'


styleClass="evenRow" headerClass="c
olumnHeader"


columnClasses="evenRow,oddRow">


<h:column headerClass="columnHeader">


<h:graphicImage url="#{item.imageurl}"/>


</h:column>







<h:column headerClass="columnHeader">


<f:facet name="header">


<h:outputText value="#{msgs.productHeader}"/>


</f:facet>


<h:outputText value=
"#{item.productnumber}"/>


</h:column>


</h:dataTable>


From the example above,


h:dataTable iterates through the collection called items and each item is populated
in each column. h:dataTable also provides useful attribu
te specifying CSS

classes such as columnClasses ,which is list of CSS classes for columns, headerClass
that is CSS class for the table header.





















34






5.5
Using Standard Converters




Java Server Faces library, which is
in the javax.faces.convert package, provides a
set of Converters, for examples [21]




NumberConverter


This converter is attached to the text field and tells to format the current value
with at least two digits after the decimal point:




<h:
inputText value=”#{payment.amount}”>




<f:convertNumber minFractionDigits=”2”/>


</h:inputText>




DataTimeConverter




<h:outputText value=”#{payment.amount}”>




<f:convertDateTime patte
rn=”MM/yyyy”/>


</h:outputText>


In addition, other standard converts can be used in three ways:



Ensure that the component using the converter has its value bound
to a backing bean property of the same type as the converter



Add the
converter to the component tag by using converted
attribute.



Using converter by class or its ID using the converter attribute



Conversion Errors







When conversion errors occur, they can be seen by adding h:message
tags when using converters such
as


<h:inputText id=”amount” label=”#{msgs.amount}”


value =”#{payment.amount}”/>


<h:message for=”amount”/>


Using
Standard Validators




When using the standard validators, developers do not need to imp
lement
any code to perform validation. They only can attach the standard validator tag inside a
tag representing a component of type UInput and provide the necessary constraints.




<h:inputText id=”card” value=”#{payment.card}”>




<f:validateLength minim
um=”13”/>


</h:inputText>


When the text field is submitted, the validator checks that the string contains at least 13
characters. If the validation fails, validators produce error messages.


35








5.6
Programming with Custom Convert
ers and Validators



By definition, a converter is a class converting between strings and object. When
developers want to use a converter, they need to write the Converter interface

There are two methods:
[6]



Object getAsObject(FacesContext context, UIComp
onent component,
String newValue)


This method is used when a string is sent from the client such as in a text field.



String getAsString(FacesContext context, UIComponent component,
Object value)


This method converts an object into a string
and is shown in the client interface.


One good example that uses customer conversion is Credit card converter.


Specify custom converters




First a developer adds <converter> tag in faces.config.xml file and specifies
converter using a ID. For instanc
e, the developer uses the ID com.corejsf.CreditCard for
credit card converter.



<converter>



<converter
-
id> com.corejsf.CreditCard</converter
-
id>



<converter
-
class>com.corejsf.CreditCardConverter</converter
-
class>


</converter>


The develope
r implements a Payment Bean that has a property type CreditCard


public class PaymentBean{




private CreditCard card=new CreditCard(“”);


}



Then developer can use the f:converter tag and specify the converter ID:



<h:inputText value=”#{payment.card}”>



<f:converter converterId=” com.corejsf.CreditCard”/>


</h:inputText>


Specify custom validators



Like custom converters, when a developer wants to use validator, the developer
needs to implement the javax.faces.validator.Validator interface a
nd register that
validator in a configuration file faces
-
config.xml. If validation fails, it generates a
FacesMessage describing the error.




36









If (validation fails){



FacesMessage message=….;



Message.setSeverity(FacesMessage.SEVERITY_ERROR);



Thr
ow new ValidatorException(message);



}


Specify Custom Validators




In the configuration file,


<validator>



<validator
-
id> com.corejsf.CreditCard</validator
-
id>


<validator
-
class>com.corejsf.CreditCardValidator</validat
or
-
class



</validator>



and then you can use custom validators with the f:validator tag

For instance,




<h:inputText id=”card” value=”#{payment.card}” required=”true”>



<f:converter converterId=”com.corejsf.CreditCard”/>



<f:validator val
idatorId=”com.corejsf.CreditCard”/>


<h:inputText>





















37







6.1
J2EE Platform Security Model



Security on the j2EE platforms is mainly declarative and is specified externally
from the application code. Security mechanisms used is expressed
in a configuration file
called a deployment descriptor in an application. The main advantage of defining security
declaratively is that it is easy for developers to change these settings to match their
security policy.


In addition, j2EE security model, i
t provides a collection of security services to its
application and clients such as authorization, authentication mechanisms, and digital
certificates.

Let take a look in more detail at the j2EE security services provided


6.2
Web Tier Authentication



J2
EE web containers provides three different authentication mechanisms [7]




HTTP basic authentication

The username and password are used in this mechanism obtained from the web client





























These two values are attached in the HTTP headers and are managed at the transport
layer sent to the web server.



Form
-
based authenticati
on

Developers create a form for receiving username and password and use this form to
transmit the information to the web container.



HTTPS mutual authentication

The client and the server employ digital certificates to establish their identity over a
secure
channel using SSL (Secure Sockets Layer)


6.3
EJB Tier Authentication



The EJB containers provide the ability to handle authentication between a client
and a web service endpoint implemented by an enterprise bean.



Web Service Security



In

J2EE web services scenarios, they have some security requirements that need
to implement between a client and a service. In addition, it is important that when a client
makes a request to a service, then web service endpoints can securely access other J2E
E
components such as entity beans, databases. As the service processes the client request,
service endpoints might need to interact with other web services in a secure manner.


Moreover, a secure web service includes more than securing initial interaction
between the client and the service. Developers also need to consider web service
endpoint’s subsequent interactions with other components. This means that whole
channel should be secure.



38








6.4
Security for Web Service Interactions





The J2EE platfo
rm has supported WS
-
I Basic Profile 1.0 specifications for secure
interoperable web service interactions. This specification involves the transport layer of
HTTPS to be combined with other mechanisms for basic and mutual authentication.


The j2EE platform

offers web tier and EJB tier endpoints with similar security
mechanisms for web services.


Since the main requirement for a secure web service are authentication and setting
up a secure SSL channel for interaction and security can be applied to web servic
es at
both transport
-
level and the message
-
level. Hence, let’s examine how to secure at
transport layer first.



6.4.1
Transport
-
Level Security



Secure Socket Layer

(SSL) [10] is a popular standard for establishing a secure
connection between web browser
s and web servers. In the SSL connection, data will be
encrypted before being sent and is decrypted on the receipt. Therefore, this SSL
mechanism is essential that web services should have for security reasons. SSL addresses
the following important securit
y considerations.




Authentication

[7]:
In a secure connection, the server will require
a set of credentials from the browser in the form of a username, password or a digital
certificate to verify that a claimed identity is genuine. In addition, the service

might have
to access a set of components and resource such as enterprise beans (EJB), web service
endpoints, and databases. Thus, the components and resources might need to prove their
identity to the service.



Confidentiality:

This SSL mechanism ensures
that the data from
the client to the server can not be viewed and intercepted by the third parties. The
message content is encrypted and is still confidential.



Integrity:

SSL helps guarantee that data will not be altered in
transit by the third party.














39









In addition, j2EE platform provides authentication mechanism in establishing an
HTTPS connection for Web service.




The server
authenticates itself to clients

,
by setting up SSL and
make its certificate available.




The client applies basic
authentication over SSL connection.



Mutual authentication is there are two certificates sent from the
server and the client so that both parties can authenticate to each
other.


Since a web service can be developed in the web tier and EJB tier, t
he secure
mechanisms are different in details when defining declarative settings in the deployment
descriptor file.


For web tier endpoint, a developer can indicate that the developer is setting up
SSL by defining all settings in the web.xml deployment des
criptor. This setting enforces
an SSL interaction between the client and a web service endpoint.




An example of a web.xml application deployment desc
riptor that specifies that
SSL
be used:


For example,


<web
-
app>


<security
-
constraint>



<web
-
resource
-
collection>


<web
-
resource
-
name>retailService</web
-
resource
-
name>



<url
-
pattern> /mywebservice</url
-
pattern>



<http
-
method> GET</http
-
method>



<http
-
method> POST</http
-
method>


</web
-
res
ource
-
collection>



<user
-
data
-
constraint>



<transport
-
guarantee> CONFIDENTIAL</transport
-
guarantee>



</user
-
data
-
constraint>


</security
-
constraint>


</web
-
app>


A user data constraint specifies a transport guarantee (<transport
-
guarantee> in th
e
deployment descriptor. The options for transport
-
guarantee include CONFIDENTIAL,
INTEGRAL, or NONE.







40






The strength of the required protection is defined by the value of the transport guarantee.




Specify CONFIDENTIAL when the application requires
that data be sent in order
to prevent other entities from motoring the contents of the transmission.



Specify INTEGRAL when the application requires that data be sent between
client and server in a way that it can not be changed in transit.



Specify NONE th
is means that the container must accept the constrained requests
on any connection.



Setting up SSL for EJB tier endpoints varies according to the particular
application server. For instance, in glassfish application server, a developer defines all
secur
ity settings in sun
-
ejb
-
jar.xml deployment descriptor.

There are two kinds of authentication employed in EJB: SSL server authentication and
SSL mutual authentication.



6.4.2
SSL Mutual authentication


In this case, both the client and the serv
er verify the identity of each other by checking
certificates in mutual truststores.

For SSL mutual authentication, you need to specify the <login
-
config> element to
CLIENT
-
CERT. You also need to specify the <transport
-
gurantee> element to