4.2 Abstract Design
4.2.4 Protocol Manipulation Layering Method
In the following section, an application service, or in an applied case a geo-data service, is one which has the ability to handle sector specific formats and may merge information. A business service covers transaction aspects like price, ordering and delivery.
The OGC Web Map Server (WMS) is a good example of an application service. The Web Pricing & Ordering Service (WPOS) (see 5.2.2) is an example of a business service.
The service name WPOS is here introduced for a better understanding and can be considered here as an abstract component.
A solution to separate application and business data streams comes from introducing the method of protocol manipulation layer methodology. Each protocol layer covers its specific aspects then encodes and packs the lower protocol into its layer data stream from the client to the server.
WMS-Service WM-Client
WMS-Client
WMS-Serv. WMS Serv.
03.06.2003
Figure 22 Separation of application data and business data streams with the protocol manipulation layering method
Figure 23, Figure 24 and Figure 25 show the approach in a graphical manner and from different points of view with the applied example of the Web Mapping Service (WMS) as an application-, a WPOS for a business- and an AAA for a security service.
Figure 23 Protocol Manipulation Layering methodology from a vertical point of view
The connection between the application geo-data client and its service are defined by a URL (1a), which can be configured in a general manner. The URL is the only general parameter involved in the application data stream. In the business case the application target URL of its service is reconfigured to an emulating business client (2a). The business client accepts the request and the parameter list.
Business Protocol Application Protocol
Roland M. Wagner
Figure 24 The Protocol Manipulation Layering Methodology from a sequence point of view
The application request can be decoded and analyzed from the business client. In the following steps the business client sends a request to the business server for price models or prices until an order is set-up with an accepted price as a contract by a purchaser. In this case, the business service unpacks the application request, decodes the application request, recalculates the price for security reasons and sends it to the target application service (2c). Only the application service has the ability to create or to integrate the requested data for the application client. This data stream will be routed back (2d) via the business protocol (2e) and presented to the application client as requested (2f). All transactions are tracked and analyzed for further accounting within the business layer.
It is important to mention that each protocol layer may manipulate an embedded request and a response. Therefore it is not a simple orthogonal layering.
4.2.4.1 Protocol Manipulation Layering Methodology in a cascaded Case
The “Protocol Manipulation Layering” methodology also supports cascading. The principle of cascading was illustrated in Figure 21. Figure 25 shows this mechanism in a cascaded case. A company B provides geo-data integration as a product, but buys different data sets from company C and D. A technical geo-data request from a WMS Client of company A will be transferred to the WPOS Client of its company (2a). The business client asks the business service of company B, e.g. for a price model.
WPOS-Client
WMS-Client WPOS-Server WMS-Server
WMS Request
WMS Request Pricing
Pricing
WMS Response WMS
Response
Ordering
Delivery
2e
Client Service
2a
2b
2f
2b 2c
2d
03.06.2003
Figure 25 This general approach can be used to cover business aspects without interfering with the data stream between specialized application services
For business requests, which do not need an application request, e.g. GetCapabilities, the business service of company B separates the business request into two requests and bypasses (see I in Figure 26) the application integration service to the business service of company C and D.
Figure 26 Protocol Layering in a cascaded Case: Bypass business requests (I) and business-application interacting requests (II)
For business requests, which require the embedded geo-data request (see II in Figure 26), the original request will be separated. The geo-data request will be unpacked and
Company D WPOS-Client
WPOS-Client
WPOS-Service WMS-Service WMS-Client
WMS-Client
WPOS-Service WMS-Service WPOS-Service
WMS-Service
Company B Company A
Company C
WPOS-Client WPOS-Service
WMS-Service WMS-Client
Company B
I II
Company D Company C
Company A
Roland M. Wagner send to the geo-data service, e.g. WMS. This application component has the
know-how to understand and to separate the application requests. But the URL of separated back-office request is configured to target the client of the same business. The client may have manipulated each application request and packed it into a back-office business request.
For these business responses, which do not require an application response, e.g. get a price, the application service of company B will receive an application protocol error message. Finally the new back-office business requests can be sent out to the services of company C and D.
4.2.4.2 Façades Service
The approach of the protocol manipulation layering method with its façades has the important advantage of combining different data streams without interference on the one hand but with full manipulation access on the other. This approach makes it possible to design many “service” services: one service designed to support another.
The business case with the WPOS is a good example for this class of services.
Figure 27 Enhanced WPOS with external Façade Service
But these façades have the obvious disadvantage of being “application” protocol specific. Each protocol may have several versions. Some protocols are “known”, which means that they are standardized and accepted by large communities. Some protocols are “un-known”. In the long term, a large number of protocols may need a general
Publish WPOS-Server WMS-Server
WMS Request Pricing
WMS Response
Service 2b
2c
2d
Web Registry Service
Façade Service
GetWPOSFaçadeService (OGC, WMS, v 1.1.0)
WPOSFaçadeService URL
translateRequest
03.06.2003
solution for this handling of façades. An approach is described in this thesis as an abstract design.
The most important function of a façade is to translate parameter values from a specific application protocol to the abstract XCPF parameter. Therefore these façades can be considered as enhanced translation tables. In some experimental implementations, all needed translation functionalities could be expressed with XSL. From a general point of view, this translation functionality could be separated from the WPOS into a “WPOS Façade Service”, without significant effort. This service should be registered with each supported technical geo-data protocol and version in a Registry Service. Figure 27, which enhances Figure 25, explains the workflow sequentially.
This approach is very typical for new service architectures. The advantage is that workload can be shared, which reduces maintenance costs. In this concept the Façade Service may be set-up and maintained by e.g. a WPOS software producer. Unknown protocols or new versions of geo-data services could be stored by this service. But other service providers may offer other Façade Service instances. Other geo-data service software producers may set up Façade Service instances for their own proprietary geo-services. The last scenario opens a far-reaching perspective in a spatial data infrastructure. New services or new versions of services can be introduced seamlessly.
Roland M. Wagner