The application collaboration is a trend in application development that is gaining momentum. There are several forces pushing it forward:

  • Streamline enterprise information systems. Enterprises use application collaboration to eliminate application and infrastructure redundancies. It lowers the development and maintenance cost and increases the flexibility of the information systems.
  • Create new business opportunities by exposing data and services to other applications. For example Amazon enables users to browse their collection of books and buy books. They also provide interface for applications to do the same. It enables third party applications to check whether certain book is available on Amazon and promote it on their site. The objective is to empower the applications with the same capabilities that are available to users.

Application collaboration in its broadest sense means that applications are capable of sharing software artifacts: data objects, operations, presentation components. It provides applications with capabilities to expose and consume software artifacts.
Application collaboration is based on the notion that some artifacts will be implemented remotely instead of locally. There might be a debate whether the application should be aware which artifacts are implemented remotely. In my opinion application collaboration should be completely transparent, allowing architects to move software artifacts around and optimize enterprise information systems. The price of the transparency is that application collaboration capabilities need to match the ones available to locally implemented artifacts.

In this article we will discuss the basic capabilities that are needed for each software artifact and how they can be implemented with different architectural approaches to application collaboration.

Software Artifacts:
Data objects

  • Get a list of data objects – all or subset by passing search criteria
  • Select data object by key or search criteria
  • Create new data object
  • Insert new data object
  • Update existing data object
  • Delete single data object or collection of objects
  • Query a collection of data objects and apply aggregation.

Operations (instance of programming logic)

  • Execute operation – developers may pass 0-may input parameters and receive a result or 0-many output parameters

Presentation Components (reusable instance of presentation functionality)

  • Create reusable presentation components that can be deployed within applications.
  • Deploy presentation components within applications – makes all URIs within the presentation component application specific. Developers customize presentation components during the deployment and wire their component model to the application context.
  • Presentation components should process all requests generated by their presentation – avoid external dependencies. They return actions to the application, which determines where to go next.

The industry has developed several architectural approaches for application collaboration. Next we will discuss how those approaches support application collaboration.

Service Oriented Architecture (SOA)
SOA is based on the concept of service and the ability of applications to make remote procedure call (RPC) to other applications in platform independent way. Most of the SOA implementations use SOAP Web Services. WSDL is used to define the interface of the remote service.

Sharing data objects with SOA
Since SOA is based on the concept of remote procedure call, the access to all data objects is implemented through custom interfaces. Developers need to explicitly define and implement all methods for data object access: get/search/create/insert/update/delete… The interface is exposed to other applications as WSDL.
The implementation of data object access with SOA is like providing access to database through custom interface for each database table. It does not matter how many methods you will define. The interface will always limit developers compared with the flexibility of the SQL language. In addition you need to write all the data access functionality that is otherwise implemented by the database engine.

Sharing operations with SOA
Sharing operations (data transformation) with SOA is easy. Developers organize related operations into custom interfaces and expose them to other applications as WSDL.

Sharing presentation components with SOA
SOA approach to sharing of presentation functionality is defined by Web Services for Remote Portlets (WSRP) specification. It enables applications to interact with remote presentation components (portlets) through web service interface.

Resource Oriented Architecture (ROA)
ROA is based on the concept of web resource (uniquely identified by URI) and the ability of applications to access and update the representational state of that resource. It follows the RESTful architectural style. ROA is always implemented over HTTP protocol.

Sharing data objects with ROA
REST has simplified the access and manipulation of data objects. Each data object is uniquely identified by URI. Developers use GET, POST, PUT and DELETE HTTP verbs to implement CRUD functionality related to the data object. Request parameters are used to pass search criteria when needed. It eliminates the need to define custom interfaces for data object access (like SOA). The representational state of the object is sent back in XML, JSON, etc. format requested by the client.
While REST saves you the effort of specifying custom interfaces, developers still need to implement the implicit data object interface defined by HTTP verbs and request parameters. They do that by mapping URI templates to custom code. Back to the database paradigm, developers write all the data access functionality that is otherwise implemented by the database engine.
Other considerations to keep in mind when using REST:

  • Data object URIs are absolute. Some planning is required to ensure that applications are not created with absolute URIs and can run in multiple environments like: development, testing, production.
  • Search criteria are limited – allow passing object attribute names and matching values like the following:
  • http://mysite.com/customers?last-name=’Smith’&first-name=’John’.
    The only available operation is equal. The implementation of more advanced search criteria will require additional conventions between ROA client and the server.

  • There is no standard way to query data objects exposed over REST.
  • More advanced object model is needed to support updates of database objects. The implementation of optimistic concurrency requires REST server to know the original values retrieved by the client. Additional information like DB keys, timestamp value, etc. may need to be attached to the data objects as well. That requires the client and server implementations to agree on the data object model that is exchanged.
  • Transaction capabilities are needed, if the client is allowed to send multiple data object updates that are part of the same client transaction.
  • Representational state of the data object does not have provisions for returning application level exceptions if the request failed. Instead it will return HTTP error.

REST provides simple approach to sharing of data object and can be used successfully with data that are either read-only or can ignore the concurrency issues. More sophisticated access requires building additional capabilities on top of REST.

Sharing operations with ROA
REST enables developers to assign unique URI to operations and execute them by passing operation parameters as request parameters. The result of the operation is returned to the client as representational state of the URI. REST has the following limitations:

  • Operation URIs are absolute, which raises the same concerns that were discussed for data objects.
  • The custom code processing the operation request will need to deal with serialization/deserialization of the operation parameters and operation result.
  • Representational state of the operation does not have provisions for returning application level exceptions if the request failed. Instead it will return HTTP error.

REST will work well for most of the operations. To stay compliant with REST developers should avoid operations that return output parameters.

Sharing presentation functionality with ROA
REST enables retrieval of HTML representational state of any URI, which is the foundation of WWW. It is intended for direct interaction with the application functionality or static pages. REST does not support directly the sharing of presentation functionality as defined above. Such functionality needs to be developed on top of REST.

Transparent Application Collaboration (TAC)
TAC is comprehensive solution for application collaboration. Instead of generalizing shared artifacts to a single concept like service (everything is a service) or web resource (everything is a web resource), TAC recognizes the differences between artifact types. It defines separate interface for each software artifact type, reflecting the functionality needed by developers to interact with it.
TAC simplifies application collaboration by eliminating the need of:

  • Custom interfaces (like SOA)
  • URI hierarchy (like ROA)
  • Custom code associated with shared artifacts

It defines the following interfaces:

  • Data Object Service – provide access to the repository of data objects exposed to other applications
  • Operation Service – enable execution of the operations exposed to other applications
  • Presentation Component Service – enable interaction with the presentation components exposed to other applications

The implementations of TAC consist of client and server components that hide completely the remoteness of the software artifact. Any application may be a client and server of shared artifacts at the same time. TAC clients may also access software artifacts exposed as SOA services or ROA web resources.

Sharing data objects with TAC
Data Object Service is used to access and manipulate the repository of shared data objects. Objects are organized in groups by objectId. The server component of Data Object Service is assigned to fixed application URI. All object requests go to the same application URI.
TAC automates the access to shared data objects for the client and server application. It does not require custom interfaces. TAC server component implements the data access functionality without any custom code.
Below we discuss the main differences between TAC and REST implementation of shared data objects:

  • TAC repository of data objects is flat, just like relational database. Each object is identified by objectId (similar to DB table name) and object key (similar to primary key). In REST the same object may be referenced through different URIs. For example:
  • http://mysite.com/address/456
    http://mysite.com/customer/123/home-address

    TAC retrieves the address object with the following request:
    http://mysite.com/object-processor?operation-name=’get-object’&object-id=’address’&object-key=’456’
    It is more verbose compared to REST request, but allows developers to specify the operation that is applied to the object. In the second example the home address is retrieved with the customer object, so it will not require another remote call. Developers can access objects directly from the Data Object Service using the objectId or through the hierarchy of other objects.

  • Applications access data objects through local object Ids. The client component maps those Ids into remote application and objectId. Developers need to change the mapping when switching between environments like: development, testing and production.
  • Data Object Services provides generic object search capabilities. Developers create search criteria by using operations from the Operation Service and entity expressions. Entity expressions enable direct access to any attribute or entity within the data object graph.
  • Examples of object search criteria:
    string.begin-with (value-1=$last-name, value-2=’S’)
    string.equal(value-1=$home-address.zip-code, value-2=’11111’)

  • Data Object Service provides generic capabilities to query collections of data objects. Query definitions may be provided in XML file or created dynamically by the applications.
  • An example of XML defined query: 
    <query-config query-name=”person-account” query-object-id=”com.shipka.backend.person.PersonData”>
            <attributes>
                    <attribute name=”person-last-name” object-type=”java.lang.String” source-entity-attribute=”lastName” order-by=”yes” group-by=”yes” />
                    <attribute name=”person-fist-name” object-type=”java.lang.String” source-entity-attribute=”firstName” order-by=”yes” group-by=”yes” />
                    <attribute name=”person-middle-name” object-type=”java.lang.String” source-entity-attribute=”middleName” order-by=”yes” group-by=”yes” />
                    <attribute name=”bank-name” object-type=”java.lang.String” source-entity-attribute=”personAccounts.bank-name” group-by=”yes” />
                    <attribute name=”account-balance” object-type=”java.lang.String” source-entity-attribute=”personAccounts.account-balance” aggregate-operation=”float.add” />
            </attributes>
    </query-config>

    The query defines the object collection that is queried and aggregates the account balances of persons for each bank. The result is ordered by last-name, first-name, middle-name.

  • Client and server components implement object model that supports change tracking and transactions. The server component may attach server specific data (like DB keys, timestamp and other DB columns) to each object. The client sends back data objects along with change tracking and server specific information. It enables the server component to implement correctly optimistic concurrency for any updates.
  • Data object requests that fail at the server return stacktrace of the exception instead of expected objects.

TAC provides rich interface for access and manipulation of remote objects. It is well-suited for integration of enterprise applications. Companies may use TAC to expose data object interface on top of relational database (without writing any custom code) and prevent other applications from accessing the database directly.

Sharing operations with TAC
TAC provides standard interface (Operation Service) for executing operations at the Operation Repository in platform-independent way. It means that all data object parameters are exchanged in XML format. Each operation is uniquely identified by operationId. Developers execute operations by making requests to the Operation Service and passing operationId and input parameters. They get back the operation result and output parameters. If the operation fails, developers receive back the stacktrace of the exception.
The server component of Operation Service is assigned to fixed application URI, so all operation requests go to the same URI. The client and server components handle the serialization/ deserialization of operation parameters and result.

Sharing presentation components with TAC
TAC provides standard interface (Presentation Component Service) for interacting with presentation components at the Presentation Component Repository in platform-independent way. Each presentation component is uniquely identified by presentationId. Applications interact with presentation components through Presentation Component Interface.
The server component of Presentation Component Service is assigned to fixed application URI, so all presentation component requests go to the same URI. Following rules apply to the integration of presentation components:

  • Shared presentation functionality runs within the context of the main application.
    • Users work with the main application only and do not access collaborating applications directly. It resolves any firewall issues, since collaborating applications do not need to be directly accessible by the users. The main application mediates and tunnels all requests to shared presentation components.
    • Main application communicates the URI prefix of shared presentation component. It enables shared presentation component to generate URIs within the context of main application instead of collaborating application.
    • User session at the main application is kept alive regardless of whether the user is interacting with locally implemented or shared presentation functionality.
    • Main application can customize shared presentation components.
  • Shared presentation components process all requests generated by their presentation. They return actions to the main applications, which decides where to go next.
  • Shared presentation components extends the user session of the main application. It ensures that the sessions at collaborating applications should not expire until the main application user session expires. Why?
    • Shared presentation components may store user session data locally instead of relying upon the main application to provide all required data with every request. It is especially important when sharing workflow-type of presentation functionality. The extended sessions facilitate loose coupling, since the main application does not need to know the data model of the shared presentation components.
    • Main application should be able to access data objects stored at the user session of collaborating applications. It simplifies the contract between the main application and shared presentation components. The main application needs to know only which object to retrieve when certain exit point is reached.
  • Shared presentation components are developed without any knowledge of the applications that will integrate the functionality and do not rely upon any services provided by those applications.

j

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s