Session Focus: SBR Core Services Update

1
Session FocusSBR Core Services Update
Session outcome Gaining an up-to-date
understanding of the Core Services technical
design, particularly the approaches to web
services and the Software Development Kit.
2
Agenda

• Core Services Update, comprising
• Web Services
• Software Development Kit
• Validation

3
Session focusoverview of granularity options
Session outcome Gaining a better understanding
of three web service granularity options
4
Questions

• What experience have you had with web services?
• What is your preferred approach to web services?
• Single web service per report? (Options 1 3)
• One web service to lodge all reports? (Option 2)

5
What is a web service?
According to the W3C a Web service is a software
system designed to support interoperable
machine-to-machine interaction over a network. It
has an interface that is described in a
machine-processable format such as WSDL.
6
What is web service granularity?

• Web Service granularity is a relative measure of
  how broad a required piece of functionality must
  be in order to address the need at hand. Fine
  grained services address small units of
  functionality, course grained encapsulate large
  chunks of capability. Getting the balance right
  is the art of SOA there are guidelines.

7
SBR design option 1
Fine grain web service with fined grained message
schema

• In this alternative, each reporting business
  service is realised by a separate web service.
  For example, there will be separate web services
  for TFNDec, CompanyTaxReturn and QLDPayrollTax.
  Additionally, the reporting taxonomy for each of
  these web services is fully exposed in the WSDL.

8
SBR design option 1

• Advantages
• Able to define messages, operations and quality
  of services specific to the requirements of the
  form / report
• Aligns with how transactional web services are
  generally developed
• Software Development tools are able to use the
  WSDL to automatically generate service code
• Provides a clear identification for Software
  Developers as the report being submitted is
  identified as the web service being invoked

9
SBR design option 1

• Disadvantages
• Require software developer to manage a number of
  WSDLs i.e. every report that is implemented
  will require a WSDL to be consumed. New reports
  and new versions will also need new WSDLs

10
SBR design option 1

• Disadvantages
• A tight coupling exists between the web service
  and the reporting taxonomy. If there is a
  breaking change in the taxonomy then a new
  versions of the WSDL would need to be consumed
  and old versions maintained
• Not generally aligned with document based web
  services as parsing through additional XML in
  soap message reduces performance

11
SBR design option 2
Coarse grained web service with coarse grained
message schema

• In this alternative, a coarse-grained web
  service, LodgeReport is reused to realise each
  reporting business service. Operations on the
  coarse-grained services would be identified based
  on service requirements such as
• batching
• quality of service
• the need for an accompanying attachment
• combinations of the above

12
SBR design option 2

• For example the following services and associated
  WSDLs could be identified for the generic
  requirement of lodging a report
• lodge report
• lodge report in batch
• lodge report with high security quality of
  service
• lodge report with minimal security quality of
  service

13
SBR design option 2

• Advantages
• Fewer WSDL compared to Option 1, therefore
  requiring less maintenance to the Software
  Developer
• As the taxonomy is hidden in the WSDL message
  schemas payload, changes to taxonomies will not
  require a new WSDL

14
SBR design option 2

• Advantages
• Shields developers from complexity and the need
  to test functionality every time a new report is
  introduced
• Changes are confined to report definition only
  and not web service or its definition

15
SBR design option 2

• Disadvantages
• To take a generic service approach, there needs
  to be sufficient analysis that determines overall
  granularity
• Goes against the intent of the WSDL completely
  descirbing the service as document aspects are
  treated as opaque. As a result the details on how
  to create an instance document needs to be
  provided as separate information

16
SBR design option 2

• Disadvantages
• If different reporting arrangements require
  different quality of services there may be a need
  for additional services the number of services
  will thus increase

17
SBR design option 3

• In this alternative, a fine-grained web service
  is realised for each reporting lodgement business
  service, similar to option 1
• However, these web services will use a
  coarse-grained message schemas

18
SBR design option 3

• Advantages
• Same advantages as listed for option 1 except
  for Software Developers ability to use the WSDL
  to enable the service is depleted as the message
  definition in a generic blob
• WSDL is not impacted by a breaking change in the
  related reporting taxonomy

19
SBR design option 3

• Disadvantages
• A number of services are required (one per
  report). The developers will need to consume a
  large number of services on a regular basis as
  SBR is implements new reports
• As the message definition within the WSDL is
  generic then this information will be provided
  via word documents which will need to be
  maintained and managed as new versions are
  released

20
Core Servicesoverview of software developers kit
Session outcome Gaining a better understanding
of content of the SBR software developers kit
21
Executive summary

• Software developer (SWD) perceptions on software
  development Kit (SDK) characteristics have been
  provided through workshops to date
• SBR program is dependent on SWDs to support their
  SBR aware applications. There needs to be
• SWDs buy-in of the proposed SDK
• business buy-in of provided user experience

22
Executive summary

• Options are
• providing basic SBR support via documentation,
  tutorial, samples and testing facilities (as per
  TFN Dec User implementation guide)
• full function bolt-on SDK application
• a componentised, mix-and-match SDK solution, with
  flexibility to
• prioritise the delivery of SDK components
• choose between basic versus full functionality
• to help SWDs to make their software XBRL aware.

23
Option 1 Providing basic SBR support only

• Information and implementation guides
• Web Services
• WSDL Semantics
• Web Services Profiles
• Interoperability standards
• Reference Code
• Taxonomy and sample instance documents
• Testing guidelines and facilities
• Does not provide an API or GUI for use by SWDs

24
Option 2 - Packaged DTS- aware SDK Application

• SDK provides everything as a packaged application
• SDK provides GUIs and APIs required by SWDs
• Includes mapping tools, instance document
  creation, validation, report lodgement
• Minimises SWD effort and involvement in SDK
  development process
• Focus on data integration between financial
  application and SDK application
• SDK application treated as a bolt on
• Discoverable Taxonomy Set

25
Option 3 - Componentised DTS-aware SDK

• SDK provided as a set of discrete components
• Also includes mapping, Instance Document
  creation, validation, and lodgement components
• SWDs can mix and match application and SDK
  components
• Integrate SDK with native application components
• User deals with one application

26
Option 3 - Componentised DTS-aware SDK

• Close working required between SBR and SWDs
• More opportunity for SWDs to influence SDK
• More effort for SWDs
• More opportunity to make Software applications
  XBRL aware
• Components delivered with a set of APIs

27
Recommended Option

• Recommendations are
• Select option 3
• Agree on functionality required ranging from
  basic to full function
• Set implementation priorities and capabilities
  needed

28
Recommended Option

• Continue to work with SWDs
• Further refine implementation priorities and
  capabilities needed
• Establish an SDK community group, or CoE
• Investigate options for COTS
• Potentially consider alternatives such as
  server-side XBRL only, or SDK build time XBRL
  only

29
Option 3 Components
30
Option 3 Solution Overview
31
Application Capability Considerations

• Existing applications may already provide some
  capabilities required by the SDK out-of-the-box
  (OOB), such as
• Data connectors eg. Product-specific DB connector
• Data transformation/mapping components for
  generating OOB reports
• Report viewing components for viewing OOB reports
• Identity management for controlling end user
  access

32
Application Capability Considerations

• The SDK needs to enable integration with such
  capabilities to
• Minimise impacts on end-user experience
• Minimise duplication and complexity for SWDs

33
XBRL COTS Package Capability Considerations

• XBRL COTS packages provide a subset of the SDK
  capabilities, such as
• Data connectors eg. XML files
• Data transformation/mapping
• XBRL processing
• XBRL editing
• XBRL validation
• XBRL report viewing
• Buy vs build considerations for these capabilities

34
SWD vs End-user Data Mapping Considerations

• Data transformation/mapping capability is
  required by both SWDs and business end-users
• Build time (for SWD)
• SWDs select subset of SBR reports to be supported
  by their application
• SWDs create mappings between standard application
  data and selected reports
• Runtime (for end-user)
• Business users create mappings between
  business-specific chart of accounts and supported
  reports
• Similar to the way some financial applications
  currently support BAS reporting

35
SBR Client Implementation Considerations

• Option 3 provides a reference implementation of
  SDK components
• SWDs can choose to use the SDK in different ways
• Integrate reference implementation of a component
  within their application
• Build a new application component aligned with
  reference implementation
• Reuse an existing application component aligned
  with reference implementation
• Rely on external/manual processing for some
  components eg. SBR messaging

36
Validation

• Question
• Is the current approach to validation, as
  outlined in this presentation, suitable?

37
Validation Types
38
Where Can Validation Occur
39
Questions

• Is the current approach to validation, as
  outlined in this presentation, suitable?

40
Next Steps

• What experience have you had with web services?
• Which is your preferred approach to web services?
• Which SDK components do you see as a priority?
• Do you wish to join a working group to validate
  the design for the components of the SDK?
• Is the current approach to validation, as
  outlined in this presentation, suitable?

41
Feedback

• Please provide your feedback, including
  nomination for the SDK working group, by 05 Nov
  2008, to either
• Email sbr_at_treasury.gov.au
• An electronic version of the SDK prioritisation
  form will be available on http//www.sbr.gov.au

42
(No Transcript)