# Presentation: 249788

## IRS XML MessagingSchemas22-September-2004

## Why are we talking about “Messaging Schemas”?

**IRS has a need to exchange data**
- Batch processing
- Transaction based processing
- With external partners
**The IRS Enterprise Architecture is moving towards a Service Oriented Architecture (SOA)**
- Application integration is achieved through loosely coupled, message-based services

## Why did we make the decision to use XML?

**The Federal Enterprise Architecture proscribes XML as the data transport technique. **
**XML is portable between heterogeneous platforms because it is a standard, self-describing, text-based format. **
**Caveat:  Use XML – when practical**
- XML is not the only interface standard for services
- Not all/some batch processes may not benefit from XML

**Notes:**
Inter-application, intra-application and batch data transfers must be considered. Like any technology decision, the use of XML must be appropriate to the business requirements driving the decision-making process.

## So what should the XML data look like?

**Data in messages must be defined in a way that is understandable to both the consumer and the provider of the service.**
**Data in messages should be in a common language.**
**Integrate an appropriate level of Business Rules in XML schemas**
**All XML will adhere to the IRS XML Standards and Guidelines as outlined in Enterprise Data Standards and Guidelines (EDSG)**

## What decisions were made regarding messaging schemas?

**The canonical form of data throughout the IRS for OLTP purposes is defined in the IRS Enterprise Logical Data Model (ELDM) **
- Complete model of IRS business data
**Data message schemas will not be lower than the data class level as defined by ELDM.**
- Build standard XML schemas to store ELDM definition
- Payloads must conform to the XML definitions associated with ELDM classes.
- Integrate reference data with XML elements, just as they relate to ELDM classes and attributes
**Data interchange services will provide authoritative data based on specifications provided by the IRS Enterprise Data Management Office (EDMO).**

## What exactly did we do?

**Write one schema for each ELDM data class.**
- ELDM data classes are defined as complex types
- ELDM data class attributes are defined as simple types
- These simple types are included as elements in the class complex type definition
- Each of these are optional (minOccurs = 0) except for primary key attributes
**For relationships between ELDM data classes:**
- Child schemas are “included” in the parent schema
- Child classes become elements in the parent class’s complex type definition
**Subtypes of ELDM classes are represented in choice tags**

## ELDM Subject Area: Taxpayer Assets

## Sample Message Format Implementation

**Sample Message Format Implementation**

**AssetOwnership.xsd**

**AssetSeizure.xsd**

**PartyAsset.xsd**

**Notes:**
In this subject area of the ELDM (“Taxpayer Assets”), we have developed a schema for each logical table.

Then for those logical tables that are “parents” of dependent classes, we have included the child classes as elements within the parent class schema.

This process for defining schemas keeps the schemas at a parent-child level only – and can be cascaded upwards. 

In this case, the class “Asset Ownership” has three dependent classes – Asset Ownership Status, Lien Priority and Asset Collateral Agreement.  So the Asset Ownership schema includes these child class schemas.

Also notice that the class “Party Asset” is the parent of “Asset Ownership” – so by merely including the next lowest level schema, technically we can also access the children of Asset Ownership.

## Sample Schemas

**PartyAsset.xsd**
- This schema includes the “Asset Valuation” schema and includes the element defined in that schema as part of the “Party Asset” complex type.

**AssetValuation.xsd**
- This is the complex type “Asset Valuation” definition.
*Notice how it also includes it direct children.*

## How does “Messaging” fit in a “SOA”?

**Services are independent pieces of code and data that perform a specified business purpose.**
**Services are made up of:**
- the * ****functionality/business logic*** that is performed by a service supplying application
- The business logic inside a service is independent of the message
- the ***interface definition*** for the service
- This defines the standard _messages_  used to invoke the service and to send back service responses.

*Source:  Data on the Outside vs. Data on the Inside;  An Examination of the Impact of Service Oriented Architectures on Data*
*By Pat Helland, Microsoft Corporation*

**“****The only way into and out of a service are through messages”**

## Service Definition/Interface

- <xsd:include schemaLocation=“PartyAsset.xsd"/>
- <xsd:element name=“RequestAssetValuation">
- 	<xsd:element name=“PartyAsset" type="PartyAsset"/>
- </xsd:element>
- <xsd:element name=“RespondAssetValuation">
- 	<xsd:element name=“PartyAsset" type="PartyAsset"/>
- 	<xsd:element name="ErrorCode" type="string"
- 		minOccurs="0" maxOccurs="unbounded“/>
- </xsd:element>

- This is how we are using the standard ELDM defined schemas

- This is the request.
- It is asking for the ELDM “PartyAsset” as input.  More details on this is provided on the following slides.

- This is the response.
- In this case, we will respond with the “PartyAsset” and its related “AssetValuation” and zero-or-more error codes.

**Services interfaces are made up of:**
- Request Message formats
- Response Message formats

**A sample instant document is shown on the following slide.**

**A sample schema for these message formats is defined below...**

## Sample Messages

- <xsd:include schemaLocation=“PartyAsset.xsd"/>
- <xsd:element name=“RequestAssetValuation">
- 	<xsd:element name=“PartyAsset" type="PartyAsset"/>
- </xsd:element>
- <xsd:element name=“RespondAssetValuation">
- 	<xsd:element name=“PartyAsset" type="PartyAsset"/>
- 	<xsd:element name="ErrorCode" type="string"
- 		minOccurs="0" maxOccurs="unbounded“/>
- </xsd:element>

- <RequestAssetValuation>
- 	<PartyAsset>
- 		<TaxpayerAssetSequenceNum>123456</TaxpayerAssetSequenceNum>
- 	</PartyAsset>
- </RequestAssetValuation>

- <RespondAssetValuation>
- 	<PartyAsset>
- 		<TaxpayerAssetSequenceNum>123456</TaxpayerAssetSequenceNum>
- 		<AssetValuation>
- 			<AssetValuationSequenceNum>234</AssetValuationSequenceNum>
- 			<AssetValueBasisTypeCd>TR</AssetValueBasisTypeCd>
- 			<AssetValuationDeterminationDt>
- 				10-Sep-2004
- 			</AssetValuationDeterminationDt>
- 			<AssetValuationValueAmt>2500.00</AssetValuationValueAmt>
- 			<AssetValuationAppraisalMethodDescriptionTxt>
- 				Description of the Valuation
- 			</AssetValuationAppraisalMethodDescriptionTxt>
- 		</AssetValuation>
- 		<ErrorCode>XXX</ErrorCode>
- 	</PartyAsset>
- </RespondAssetValuation>

**Request Message**

**Response Message**

## Wrap-Up

**On-Going Challenges**
- Schema maintenance as the ELDM evolves
- Version Control
- Impact Analysis
- Schema management and stewardship
- How best to handle reference data
**Feedback ?**
- What about our policy of defining schemas at the class level?
- What about how we built the schemas using simple and complex types?