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
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 AssetOwnership.xsd AssetSeizure.xsd PartyAsset.xsd
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...