1/22 FP6-511678ORCHESTRA Open Architecture and Spatial Data Infrastructure for Risk ManagementIntegrated ProjectPriority 2.3.2.9 Improving Risk ManagementWP3.4 – OA Service Specifications Specification of the Format Conversion Service Revision [1.7 / 2.2.2]
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
8/6/2019 Format Conversion Service Specification v1.7-EIG
Specification of the Format Conversion Service – Table of Contents
6/22
8.1.2 Cooperation and Cascading between Service Instances ..........................................................19 9 Appendix A: Abstract Test Suite (normative)............................................................................................21 10 Appendix B: UML Models (normative) ......................................................................................................22
10.1 XMI Model ......................................................................................................................................22
8/6/2019 Format Conversion Service Specification v1.7-EIG
Specification of the Format Conversion Service – Tables and Diagrams
7/22
Tables
Table 1: Summary of operation........................................................................................................................13 Table 2: Referenced OA Types .......................................................................................................................15
Table 3: Specification of the convert Operation...............................................................................................16 Table 4: Sections of the service specific capabilities.......................................................................................17 Table 5 Attributes of the service specific capabilities of section availableOrdinaryConversions .................... 18
Diagrams
Diagram 1: Class Diagram of the Format Conversion Service........................................................................10 Diagram 2: Class Diagram of the Format Conversion Interface......................................................................13
Diagram 3 Format Conversion Service specific capabilities............................................................................ 17
8/6/2019 Format Conversion Service Specification v1.7-EIG
Specification of the Format Conversion Service – Conventions
9/22
2 Conventions
2.1 Abbreviations
The abbreviations used in this document are defined in chapter 3.1 of the Reference Model for theORCHESTRA Architecture Version 2.0 (RM-OA).
2.2 Terms and definitions
Terms and definitions necessary for understanding this document are defined in chapter 3.2 of the RM-OA Glossary.
2.3 UML Notation
All diagrams that appear in this specification are presented using the Unified Modelling Language(UML) version 2.0 as the conceptual schema language.
2.4 Conformance
2.4.1 Conformance to the OMM
This abstract service specification is specified according to the rules of the ORCHESTRA Service Meta-model (OMM-Service) and follows the rules for ORCHESTRA Services as described in chapter 9.2 ofthe RM-OA.
The extended service capabilities are be modelled according to the RM-OA rules for OAS-MI.
2.4.2 Conformance of Implementation Specifications
Conformance of Implementation Specifications to this Abstract Specification shall be checked using allthe relevant tests and rules specified or referenced in Appendix A: Abstract Test Suite (normative).
8/6/2019 Format Conversion Service Specification v1.7-EIG
Specification of the Format Conversion Service – Overview and Architecture Outline
10/22
3 Overview and Architecture Outline
3.1 Role and Scope of the Format Conversion Service
The Format Conversion Service allows the conversion of data given in one format to the correspondingdata given in another format. Each conversion between a pair of formats requires a conversion algo-rithm.
The problem we face is how two organisations are able to exchange their documents without caringabout the format the other side uses. This is the reason why the “Format Conversion Service” isneeded. It allows the conversion from one document type (MS-Word, OpenDocument, pdf, …) to an-other one in order to easily exchange documents between different organisations. Data could be textbased, like a word document or a pdf, or it could be binary data like JPEG or WMF.
3.2 Service Interface Specification Summary
This service type specification of the Format Conversion Service is comprised of the following interfacethat is defined in separate interface type specification:
• The Service Capabilities Interface Type
The following interface is specified as integral part of this service in chapter 6:
Specification of the Format Conversion Service – Context of the Format Conversion Service
11/22
4 Context of the Format Conversion Service
4.1 Relations to Standards
The way used to specify the format or type is established according to MIME (RFC 2387), a list ofavailable types is maintained at IANA.
The MIME-standard is available as RFC 2387 at:
http://www.ietf.org/rfc/rfc2387.txt
See for available types at:
http://www.iana.org/assignments/media-types/
Depending on the requirements of actual applications, the resulting implementation of the Format Con-version Service can adopt different standards. These might be file formats for pictures, e.g.:
• Portable Network Graphics (PNG) [W3C-PNG: http://www.w3.org/TR/PNG/ and ISO/IEC15948:2003]
• JPEG (lossy and lossless: ITU-T T.81, ISO/IEC IS 10918-1; extensions: ITU-T T.84)
• JPEG-LS (lossless: ITU-T T.87, ISO/IEC IS 14495-1)
• JBIG (black and white: ITU-T T.82, ISO/IEC IS 11544-1)
• JPEG-2000 (evolved from JPEG/JPEG-LS: ITU-T T.800, ISO/IEC IS 15444-1; extensions: ITU-T T.801)
• a list of picture file formats may be found at:http://en.wikipedia.org/wiki/Graphics_file_format_summary
• a converter from “ArcView Shapefile” to SVG is available under the terms of the LGPL at:http://www.carto.net/papers/svg/utils/shp2svg/
Standard file formats for textual documents might be:
• RTF (various Microsoft™ specifications)
• OpenDocument (OASIS Open Document Format for Office Applications; ISO/IEC DIS 26300)
•
Microsoft™ Word documents• …
The Format Conversion Service currently does not qualify for the contribution to a standard.
4.2 Relations to ongoing Initiatives and related Projects
The Format Conversion Service has no immediate relation to ongoing projects.
4.3 Relations to ORCHESTRA Application Schemas
The Format Conversion Interface Type Specification that is specified as integral part of this ServiceType Specification uses Basic and OA Types that are defined in the package OAS/Basic Types,
OAS/OA Types and OAS-MI/OA-MI Types of the Information Viewpoint.
8/6/2019 Format Conversion Service Specification v1.7-EIG
Specification of the Format Conversion Service – Context of the Format Conversion Service
12/22
The Format Conversion Interface Type Specification that is specified as integral part of this ServiceType Specification defines new parameter types.
• These parameter types are defined the in the package OAS/OA Types/«Application Schema»Format Conversion Service Exceptions, OAS/OA Types/ «Application Schema» Format Con-
version Service Types of the Information Viewpoint.
4.4 Relations to other ORCHESTRA Service Specifications
The interaction with the Document Access Service is a possible relation to the OA Service. The modeof interaction is to be defined in the respective service’s specification.
8/6/2019 Format Conversion Service Specification v1.7-EIG
Specification of the Format Conversion Service – Requirements
13/22
5 Requirements
5.1 Security Requirements
The Format Conversion Service has no requirements beyond the scope of the Authentication and Au-thorisation Service.
5.2 Reliability Requirements
• The question about the technical possibility of a certain conversion will be answerable using thegetCapabilities operation. If a certain possible conversion will deliver the expected result is adifferent question.
• Consider the conversion of a document given in the format with the mime-type “text/html” thathas to be converted to “text/plain”. Sloppy spoken the conversion includes parsing the html-document, stripping the html-tags and finally produce a reasonable formatted text-file. But find-
ing an algorithm which performs reasonable formatting for an arbitrary html-document is quitehard. Consider the following algorithm: Replace every html-tag with a single space. This willsatisfy our requirement converting from “text/html” to “text/plain” but will lead to a huge andhardly readable text. Of course there are many better approaches to do that conversion but thebasic problem becomes clear. Two “text/html” to “text/plain” conversion-adapters may be fairlydifferent. Their use has to be considered in the context of their purpose to really ensure ameaningful outcome.
6 Specification of the Format Conversion Interface
Specification of the Format Conversion Service – Specification of the convert Operation
15/22
OA_UnsupportedSchema E OA Types/Exception Types No
OA_SyncOperationUnsupported E OA Types/Exception Types No
OA_OperationFailure E OA Types/Exception Types No
OA_AsyncOperationUnsupported E OA Types/Exception Types No
OA_AbortNotPossible E OA Types/Exception Types No
OA_InvalidStat E OA Types/Exception Types No
Table 2: Referenced OA Types
6.2 Specification of the Operations
6.2.1 Specification of the convert Operation
The mandatory convert operation converts data. This data is provided via an input-file, the format of theinput-file is specified via a parameter, and the same applies for the output-file.
Specification of the Format Conversion Service – OA_UnknownMimeTypeException
16/22
OA_InvalidParameterValue Operation request contains an invalid pa-rameter value. Return the name of theparameter with invalid value.
OA_MissingParameterValue Operation request does not include a pa-rameter value. Return the name of themissing parameter
OA_NoApplicableCode No other basic or service-specific excep-tion type applies.
OA_InternalErrorA problem occurred in the runtime envi-ronment (e.g. out of memory)
OA_UnknownMimeTypeExceptionIn case a format specified as one of theparameters is not known to this serviceinstance.
OA_InvalidInputFileException The specified input-file in not valid. Pos-sible reasons are: not found, or the for-mat does not comply to the specified one.
OA_ConversionNotSupportedExceptionThe conversion between the specified in-put-format and the output-format is notsupported.
Table 3: Specification of the convert Operation
6.3 Specification of Parameter Types
This interface specification defines the OA Types
These new OA Types will become part of the OAS “OA Types”.
This interface specification does not define any new OT Types.
This interface specification does not introduce any new non-ORCHESTRA Types.
6.3.1 OA_UnknownMimeTypeException
In case a format specified as one of the parameters is not known to this service instance.
6.3.2 OA_InvalidInputFileException
If the specified input-file in not valid, the possible reason are: not found, or the format does not complywith the specified one.
6.3.3 OA_ConversionNotSupportedException
The conversion between the specified input-format and the output-format is not supported by this in-stance of the Format Conversion Service.
8/6/2019 Format Conversion Service Specification v1.7-EIG
Specification of the Format Conversion Service – Specification of Parameter Types
17/22
7 Specification of extended Service Capabilities
As part of ORCHESTRA D3.3.2 a meta-information schema for services is defined acting as a default
OAS-MI for service capabilities. OA_MI_CapabilitiesDocument includes both the common capabilitiesand the service specific capabilities. While the common capabilities are defined in the specification ofthe Service Capabilities Interface, the specific capabilities have to be specialized in each service speci-fication.
cd Format Conversion Serv ice Capabilities
OA_MI_Service_SpecificCapabilities
«type»
OA_FormatConv ersionCapabilities
list
+ avail able OrdinaryConversions: OA_ConversionIn formation
«type»
OA_MI_FCS_SpecificCapabilities
+ isLossy: Boo lean
«type»
OA_ConversionInformation
+ input: OA_MimeT ype
+ output: OA_MimeT ype
Specialisation/decoration
with "isLossy",
"isAdapterChain" and so
on needs to be rethought.
Diagram 3 Format Conversion Service specific capabilities
The schema for service specific capabilities defined here is explicitly divided into the following schemasections:
Section Name Section Contents
availableOrdinaryConversions List of conversions that can be done with using a single conversion algorithm. Each ConversionInformation object represents a single conversion by specifying an input and an output mime type.
Table 4: Sections of the service specific capabilities
8/6/2019 Format Conversion Service Specification v1.7-EIG
Specification of the Format Conversion Service – Specification of Parameter Types
18/22
Name Data Type Description Multiplicity and Use
Input OA_MimeType The input format of the data
1 / mandatory
output OA_MimeType The output format of the data
1 / mandatory
isLossy Boolean
Since some conver- sions can degrade the quality of the given data, this operation indicates whether a conversion uses at least one lossy con- version adapter.
1 / mandatory
Table 5 Attributes of the service specific capabilities of section availableOrdinaryConversions
8/6/2019 Format Conversion Service Specification v1.7-EIG
In the current specifications only files are considered. Maybe support is needed also for streamed inputand output. e.g. one company has a video in one format (consider a very large file) and wants to con-vert in another format for immediate display. Considering the current specifications, at the beginning thevideo has to be uploaded to your service, then converted (in its entirety), and then to be sent back. Thisprocedure can take a lot of time for huge file sizes. To improve the efficiency a streamed input and out-put may be considered. If streamed I/O is possible depends on the source- and target-format on theone hand and on the chosen target-platform.
8.1.2 Cooperation and Cascading between Service Instances
In the context of the Format Conversion Service the following question has raised.
Consider a service has multiple instances in an OSN. Instances of services can each have different ca-pabilities. In the case of the Format Conversion Service, each instance can support different conver-sions. The question is now, what the capabilities of each service are?
The capabilities supported by the current instance or the union of the capabilities of all instances?
The same question can be asked for the conversion itself.
In the first case another question raises. How does a user locate the correct service instance for histask? A possible solution could be to use a catalogue service to find an appropriate instance.
In the second case service instances would have to cooperate. The service instance of the service re-quest (getCapabilities, conversion) would figure out the correct service instance and delegate the re-quest to an appropriate instance without any involvement of the service requestor.
The service cooperation is not intended to make any catalogue service obsolete. This approach is
based on the assumption that a communication between two service instances can be very effectivesince they know their own structure very well and thus additional meta-information is not required todelegate any request.
Surely, there are more approaches to handle this scenario. In the following a few others will be drafted.
Precondition:
There are multiple service instances for a certain service.
Requirement:
The distribution of the service (multiple service instances) should be invisible to the service client.
Examples:
Services:• Format Conversion Service (FCS)
o What if the current service instance does not support the requested conversion but anotherinstance does?
• Document Access Service (DAS)o What if there are multiple DAS instances?
How to find a certain document? How to find the instance having a certain document?
Possible Solutions:1. A service client has to contact the proper service having the needed capability.
The problem of finding the correct instance is the service client’s problem.
Discussion:
8/6/2019 Format Conversion Service Specification v1.7-EIG
Of course, this in not really a solution! Every client would have to solve this problem if it occurs.There would be no reusability at all.
2. A service client always contacts a catalogue service to determine services offering the format-conversion in question.
Possible hits may be different Format Conversion Service instances and service-chains (possi-ble defined and annotated by the Service Chain Access Service).3. A service client may direct the request to any service instance.
A “broker” locates all registered services, checks their capabilities and chooses a proper in-stance.It delegates the service request to the found instance and redirects the result to the service re-questor.Such a broker would make use of Catalogue Services containing service-descriptions especiallyof Format Conversion Services and a Service Chain Access Service.
8/6/2019 Format Conversion Service Specification v1.7-EIG
Specification of the Format Conversion Service – Appendix A: Abstract Test Suite (normative)
21/22
9 Appendix A: Abstract Test Suite (normative)
When creating an implementation specification of the Format Conversion Service, the “Rules for Im-
plementation Specifications of ORCHESTRA Services” defined in chapter 9.2.2.3 and the “Rules for theService Mapping to a given Platform” of the RM-OA shall be obeyed.
In addition, the following tests shall be performed to ensure conformance of an implementation specifi-cation to the platform-independent specification of the Format Conversion Service:
1. Syntactical Conformance
• Are all mandatory operations present?
• Are all mandatory parameters present?
• Are the operation signatures correct?
• Are there any new operations or parameters?
2. Semantical Conformance• Is the behaviour of the operation still the same?
Additional conformance checks that are specifically to the Format Conversion Service are not required.
8/6/2019 Format Conversion Service Specification v1.7-EIG
The XMI Model contains all parameters required by this service including those data types and excep-tions inherited or reused from other interface and service specifications.