Service Orinted Analysis

SERVICE ORINTED ANALYSIS

PRE-REQUISITE DISCUSSION

Service-oriented analysis establishes a formal analysis process completed jointly by business analysts and technology architects. Service modeling, a sub-process of service-oriented analysis, produces conceptual service definitions called imodeling processes result in the gradual creation of a service inventory blueprint.

DERIVING BUSINESS SERVICES

With the detailed example explain about the entity- centric business layer. Case Study This is only TLS's second service-oriented solution.

The first was created to establish an external interface with their accounting system via a B2B environment.

That solution was built according to the top-down delivery strategy and therefore resulted in a collection of entity-centric business services.

Architects involved with the service design for this new Timesheet Submission application are pretty confident that the new set of services in no way overlaps with the existing ones.

However, because the B2B solution was built by a completely different project team, they agree that it is worth the effort to review existing services before commencing with the design process.

Their investigation reveals that the following entity-centric business services were delivered as part of the B2B project: Accounts Payable Service, Purchase Order Service, Ledger Service, and Vendor Profile Service

STEP 1..

The Employee Service candidate. Step2.

The existing inventory of TLS services. project architects then conclude that no overlap exists, which gives them the green light to proceed with the design of the Employee Service. TLS invested in creating a standardized XML data representation architecture (for their accounting environment only) some time ago. As a result, an inventory of entity-centric XSD schemas representing accounting-related information sets already exists.

At first, this appears to make this step rather simple. However, upon closer study, it is discovered that the existing XSD schema is very large and complex. After some discussion, TLS architects decidefor better or for worsethat they will not use the existing schema with this service at this point.

Instead, they opt to derive a lightweight (but still fully compliant) version of the schema to accommodate the simple processing requirements of the Employee Service.

They begin by identifying the kinds of data that will need to be exchanged to fulfill the processing requirements of the "Get weekly hours limit" operation candidate. They end up defining two complex types: one containing the search criteria required for the request message received by the Employee Service and another containing the query results returned by the service.

The types are deliberately named so that they are associated with the respective messages. These two types then constitute the new Employee.xsd schema file.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 

targetNamespace=         "http://www.xmltc.com/tls/employee/schema/accounting/">

<xsd:element name="EmployeeHoursRequestType">  <xsd:complexType>

<xsd:sequence>    <xsd:element name="ID" type="xsd:integer"/>   </xsd:sequence>

</xsd:complexType>     </xsd:element>   <xsd:element name="EmployeeHoursResponseType">

<xsd:complexType>      <xsd:sequence>    <xsd:element name="ID"       

type="xsd:integer"/>      <xsd:element name="WeeklyHoursLimit" 

type="xsd:short"/>        </xsd:sequence>   </xsd:complexType>   </xsd:element>

</xsd:schema>                                 

Example 15.2. The EmployeeHistory schema, with a different targetNamespace to identify its distinct origin. <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

targetNamespace=         "http://www.xmltc.com/tls/employee/schema/hr/">       <xsd:element

name="EmployeeUpdateHistoryRequestType"> <xsd:complexType>      <xsd:sequence>

<xsd:element name="ID" type="xsd:integer"/>   <xsd:element name="Comment"

type="xsd:string"/>       </xsd:sequence>   </xsd:complexType>   </xsd:element>

<xsd:element name="EmployeeUpdateHistoryResponseType">     <xsd:complexType>

<xsd:sequence>    <xsd:element name="ResponseCode"        type="xsd:byte"/>

</xsd:sequence>   </xsd:complexType>     </xsd:element> </xsd:schema>        

To promote reusability and to allow for each schema file to be maintained separately from the WSDL, the XSD schema import statement is used to pull the contents of both schemas into the Employee Service WSDL types construct.

The WSDL types construct being populated by imported schemas. <types>      <xsd:schema

targetNamespace=         "http://www.xmltc.com/tls/employee/schema/">  <xsd:import

namespace=                   "http://www.xmltc.com/tls/employee/schema/accounting/"

schemaLocation="Employee.xsd"/> <xsd:import         namespace=

"http://www.xmltc.com/tls/employee/schema/hr/" schemaLocation="EmployeeHistory.xsd"/> </xsd:schema> </types>

The TLS architects decide on the following operations names: GetEmployeeWeeklyHoursLimit and UpdateEmployeeHistory

They subsequently proceed to define the remaining parts of the abstract definition, namely the message, and portType constructs.

Example 15.4. The message and portType parts of the Employee Service definition that implement the abstract definition details of the two service operations. <message name="getEmployeeWeeklyHoursRequestMessage"> <part name="RequestParameter" element="act:EmployeeHoursRequestType"

WSDL BASICS

CONTENTS:

WSDL stands for Web Services Description Language.

WSDL is a language for describing web services and how to access them.

WSDL is written in XML.

WSDL stands for Web Services Description Language

WSDL is written in XML

WSDL is an XML document

WSDL is used to describe Web services

WSDL is also used to locate Web services

WSDL is a W3C recommendation

WSDL stands for Web Services Description Language.

WSDL is a document written in XML. The document describes a Web service. It specifies the location of the service and the operations (or methods) the service exposes.

he WSDL Document Structure

A WSDL document describes a web service using these major elements:

Element      Description

<types>      A container for data type definitions used by the web service

<message>  A typed definition of the data being communicated

<portType>         A set of operations supported by one or more endpoints

<binding>   A protocol and data format specification for a particular port type

The main structure of a WSDL document looks like this: <definitions>

<types>

data type definitions........

</types>

<message>

definition of the data being communicated....

</message>

<portType>

set of operations......

</portType>

<binding>

protocol and data format specification....

</binding>

</definitions>

SOAP BASICS:

A WSDL document can also contain other elements, like extension elements, and a service element that makes it possible to group together the definitions of several web services in one single WSDL document.

WSDL Ports

The <portType> element is the most important WSDL element.

It describes a web service, the operations that can be performed, and the messages that are involved.

The <portType> element can be compared to a function library (or a module, or a class) in a traditional programming language.

WSDL Messages

The <message> element defines the data elements of an operation.

Each message can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language.

WSDL Types

The <types> element defines the data types that are used by the web service.

For maximum platform neutrality, WSDL uses XML Schema syntax to define data types. WSDL Bindings

The <binding> element defines the data format and protocol for each port type. WSDL Example

This is a simplified fraction of a WSDL document: <message name="getTermRequest">

<part name="term" type="xs:string"/> </message>

<message name="getTermResponse"> <part name="value" type="xs:string"/>

</message>

<portType name="glossaryTerms"> <operation name="getTerm">

<input message="getTermRequest"/> <output message="getTermResponse"/> </operation>

</portType>

The TLS architect in charge of the Employee Service design decides to make adjustments to the abstract service interface to apply current design standards. Specifically, naming conventions are incorporated to standardize operation names

The revised Employee Service operation names.

Example

The two operation constructs with new, standardized names. <operation name="GetWeeklyHoursLimit">

<input message="tns:getWeeklyHoursRequestMessage"/> <output message="tns:getWeeklyHoursResponseMessage"/>

</operation>

<operation name="UpdateHistory">

<input message="tns:updateHistoryRequestMessage"/> <output message="tns:updateHistoryResponseMessage"/> </operation>

As explained in the Apply naming standards guideline, the use of naming standards provides native support for intrinsic interoperability, a key contemporary SOA characteristic.

If entirely new tasks are defined, then they can be incorporated by new operations that follow the same design standards as the existing ones.

If new functional requirements are identified that relate to existing operations, then a common method of extending these operations is to add input and output values.

This allows an operation to receive and transmit a range of message combinations. Care must be taken, though, to not overly complicate operations for the sake of potential reusability.

It often is advisable to subject any new proposed functionality to a separate analysis process. Also, while it is desirable and recommended to produce entity-centric services that are completely self-sufficient at managing data associated with the corresponding entity domain, there is a key practical consideration that should be factored in.

SOA COMPOSITION GUIDELINES

Service composability is a design principle, applied within the service-orientation design paradigm, which encourages the design of services that can be reused in multiple solutions that are themselves made up of composed services. The ability of the service to be recomposed is ideally independent of the size and complexity of the service composition.

This principle is directly responsible for the agility promised by SOA as it promotes composing new solutions by reusing existing services.

ENTITY-CENTRIC BUSINESS SERVICE DESIGN (A STEP-BY-STEP PROCESS):

Entity-centric business services represent the one service layer that is the least influenced by others. Its purpose is to accurately represent corresponding data entities defined within an organization's business models.

These services are strictly solution- and business process-agnostic, built for reuse by any application that needs to access or manage information associated with a particular entity.

atomically in relation to other service layers, it is beneficial to design entity-centric business services prior to others. This establishes an abstract service layer around which process and underlying application logic can be positioned.

APPLICATION SERVICE DESIGN – TASKCENTRIC BUSINESS SERVICE DESIGN

project architects then conclude that no overlap exists, which gives them the green light to proceed with the design of the Employee Service. TLS invested in creating a standardized XML data representation architecture (for their accounting environment only) some time ago. As a result, an inventory of entity-centric XSD schemas representing accounting-related information sets already exists. At first, this appears to make this step rather simple. However, upon closer study, it is discovered that the existing XSD schema is very large and complex. After some discussion, TLS architects decidefor better or for worsethat they will not use the existing schema with this service at this point. Instead, they opt to derive a lightweight (but still fully compliant) version of the chema to accommodate the simple processing requirements of the Employee Service. They begin by identifying the kinds of data that will need to be exchanged to fulfill the processing requirements of the "Get weekly hours limit" operation candidate. They end up defining two complex types: one containing the search criteria required for the request message received by the Employee Service and another containing the query results returned by the service. The types are deliberately named so that they are associated with the respective messages. These two types then constitute the new Employee.xsd schema file.

SIGNIFICANCE

The SOA is important because without this no service can be provided to the user easy and efficiently

APPLICATION AREA:

The service oriented architecture is used in all the web oriented service application in internet.