Low Level Design
Low Level Design
Low Level Design
Version No.:
Date:
Project Name:
Project Code:
<Address>
Revision History
Version No
Date
Prepared by /
Modified by
Significant Changes
1.
Glossary
Abbreviation
Description
Page 2 of 13
Table Of Contents
1
Introduction ....................................................................................................................................... 5
1.1
Identification ............................................................................................................................. 5
1.2
1.3
3.2
3.3
3.4
3.3.2
Variables..................................................................................................................... 7
3.3.3
3.3.4
Event/ Message Flow Diagram (as applicable) .......... Error! Bookmark not defined.
3.4.2
Event / Message Structure (as applicable) ................ Error! Bookmark not defined.
3.4.3
3.5
3.6
3.7
Configuration .................................................................................................................................. 11
4.1
3.3.1
4.1.2
4.2
4.3
4.4
Customization ................................................................................................................................. 12
5.1
5.2
Assumptions ................................................................................................................................... 12
Dependencies ................................................................................................................................. 12
Page 3 of 13
Annexures ....................................................................................................................................... 13
Page 4 of 13
1 Introduction
1.1 Identification
Project Name
Document Name
Document Version No.
2 Design Overview
The Business Process workflow used in our system can be broken down into three tiers:1) The Client Tier with the HTML and the messages that are interchanged
2) The middle tier which comprises of service mix and the Server with the business logic
3) The Back end tier with the database.
Client tier
Middle Tier
Web layer
Integration
BPM
mySQL
Hibernate
HTML
JSP
Page 5 of 13
3 Design Description
3.1 Business Process workflow
Our scenario and workflow design call for our workflow to interface with the following
hypothetical and actual components and applications:
The WorkFlow client used by the HCS, and Government Employee, and the normal user
accessing through the web interface.
The Hibernate component that provides database access and update and change of data.
Server-side components, such as servlets, in the front-end Web application with which the
customer interacts
A back-end reporting application
An e-mail client to which a confirmation message may be sent
A message passing architecture implemented using service-mix
Page 6 of 13
3.3.2 Variables
3.3.3 Transformation Rules
3.3.4 Transformer Classes (as applicable)
Thus, to communicate with many of the external and even internal components in our
workflows, we will need to compose and send XML messages to either a Worklist client user, or
an external or internal topic or queue. XML elements and attributes correspond to workflow
variables for which values are provided at run time. We use outgoing XML documents in the
sample workflows for the following purposes:
To substitute for the XML document which would be sent by a front-end Web application to
trigger the new-individual registration application
To request the government to provide the result of the search performed
Services
search_person: Gov HCS
input: Query
output: set of person_Data
Business Logic
Search on the database to get the personal data. Receive the search
parameter, send the search result.
Used By:
Government Clerk
Variables
personID
The diagram above demonstrates how to represent in the UML a service that exposes a
set of interfaces. By separating the notion of a service which is an actual software entity
that exists at some identified end point from the interfaces which are a specification of
some set of behavior we gain the flexibility to reuse common interfaces across a
Page 7 of 13
The diagram above demonstrates how the abstract Message structure is used, that
the Journal Content Request message is a specialization that includes an element
from the Journal Content Domain.
As an example, given SOAP 1.2 and a simple UMLXML serialization we could expect
to see the following request message in XML. Also note that the constraint {signed} in
the model results in the generation of an XML
Soap
<env:Envelope xmlns:env="http://www.w3.org/2002/12/soap-envelope">
<env:Header>
...
</env:Header>
<env:Body>
<m:SearchRequest xmlns:m="http://dit.unitn.it/schema/jrnlcnt">
<m:PersonIdentifier>
<m:Person id>. . .</m: Person id >
</m:PersonIdentifier>
<sig:Signature xmlns:sig="http://www.w3.org/2000/02/xmldsig#">
</sig:Signature>
</m:JournalContentRequest>
</env:Body>
</env:Envelope>
Deploy WSDL
<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="Searchperson" provider="java:RPC">
<parameter name="className" value="server.Searchperson.getdata"/>
<parameter name="allowedMethods" value="*"/>
Page 8 of 13
</service>
</deployment>
Publish service
deploy.batAxis_Lib is the path of axis.jar
set Axis_Lib=D:\workspace\test\WEB-INF\lib
set Java_Cmd=java -Djava.ext.dirs=%Axis_Lib%
set Axis_Servlet=http://localhost:8080/test/servlet/AxisServlet
%Java_Cmd% org.apache.axis.client.AdminClient -l%Axis_Servlet% deploy.wsdd
it is important to separate out the structures that define a message passed in orout of a
service action and the domain content that is used as the content of the message. The
following diagram demonstrates this separation.
This allows us to separate information about the instance of a message from the
content in the message, so for example the same content might be sent to two different
end points but have different associated message-level information included. This
separation also allows the definition of properties that are to be consumed by the HCSGov-System aware end-point but not necessarily by the end-user of consumer of the
content. This separation also allows us to adhere to a common layered approach to the
architecture that clearly defines the content relevant to each layer in a simple model as
shown below.
Page 9 of 13
Page 10 of 13
4 Configuration
4.1 Adapter / Connector Configuration
4.1.1 Adapter / Connector Name
4.1.2 Adapter / Connector Details (as applicable)
Page 11 of 13
5 Customization
5.1 Application (as applicable)
Serial no
Interface
identified
Available out-ofthe-box in
application
Application module to
be used
% customization
required
Connector / Adaptor
to be Used
% Customization
Required
Interface
Identified
6 Assumptions
7 Dependencies
Page 12 of 13
Page 13 of 13