IRS XML MessagingSchemas

22-September-2004

2

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

3

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

4

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)

5

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

6

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

7

ELDM Subject Area: Taxpayer Assets

8

Sample Message Format Implementation

AssetOwnership.xsd

AssetSeizure.xsd

PartyAsset.xsd

9

Sample Schemas

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

AssetValuation.xsdThis is the complex type “Asset Valuation” definition.Notice how it also includes it direct children.

10

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:

1.the functionality/business logic that is performed by a service supplying application

• The business logic inside a service is independent of the message

2.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 DataBy Pat Helland, Microsoft Corporation

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

11

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:

1.Request Message formats

2.Response Message formats

A sample instant document is shown on the following slide.

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

12

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

13

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?