SOA-based development of applications is quite common today. However, lacking suitable APIs to develop them, developers often find it difficult to adopt an SOA-based approach. With introduction of Service Component Architecture (SCA) and Service Data Objects (SDO), it has become simpler and more powerful for developers to develop SOA applications.
Service Component Architecture
SCA is a specification which describes a model for building applications and systems using SOA. It provides a platform through which SOA can be easily implemented to design new/existing applications and also simplifies the integration of applications which are SOA compliant.
SCA requires business logic code implementation to be based on components, which exposes its functionality through service-oriented interfaces and consumes functionality provided by other components through their service-oriented interfaces. Under this architecture, we first implement the functionalities into components, which may use other services, and later assemble these components to build the desired application by designing the flow of components to achieve the desired business logic. Moreover, SCA provides the ability to represent business logic as a reusable component so that it can be integrated into other SCA-compliant applications.
SCA separates the implementation logic from the business logic (i.e. a developer at business level only needs to design the flow of components) and there is no need to worry about the implementation details of the components. Implementation logic for services can be written in any of the given languages: Java, PHP, C++, COBOL, BPEL, XSLT, and also SQL and XQuery. Also security, transaction and reliable messaging are handled declaratively and separated from the implementation code.
Service Data Objects
SDO is all about accessing heterogeneous data uniformly. It essentially simplifies the data model and abstracts data based on an SOA model. It offers:
- simplification of data model
- data abstraction based on an SOA model
- unification of data application development
- support for integration with XML
SDO is a framework which not only abstracts data from its sources. but is also extensible and can be integrated with new data and its sources. It allows to access from multiple data sources like relational databases, XML, Web Services, etc.
At the architecture level, SDO represents all data in the form of graphs using Data Mediator Services (DMS). SDO clients (or objects) operate only on these data graphs and do not deal with original data sources or formats (which might be persisted or even serialized). Changes in graphs are automatically written back to data sources. Hence, under the model of "disconnected data graphs," it separates data source and data handler. It also provides a metadata API to handle graphs and data model.
ERP Use Case for SCA using SDO
The Figure 1 shows the various components that make an ERP application. The components (except client) form the server components. The server can be classified under two broad categories. They are:
- Business-oriented components
- Support-oriented components
The business-oriented components purely provide the core business functionality like AP, AR, inventory management, GL, banking, etc. of a business application. The support-oriented components are the ones that provide additional features like notifications, user authentication, business reporting, data access, proxy, etc.
ERP and SCA
Let's discuss the "Reporting Service" support-oriented component in detail. The Reporting Service component provides the functionality for generating reports for business components like GL or inventory. The Reporting Service component generates a report based on an XML template to define the look and feel of the components. It has three components:
- Layout and displaying logic
- Object mapping API
- Rendering API
Layout and displaying logic
It provides an entry point for using the Reporting Service component by other modules. The main objective of this component is to fetch data and set properties specific to layout and elements. The following are kind of services it offers:
- Page – Defines paging in a report.
- Style – Text (e.g. font size, font face, wrapping, etc.) and Image (scale, crop, etc.) style settings for the elements to be written to the report.
- Positioning – Calculation of actual positioning of the elements in a page, relative positioning to other elements of the report.
- Interacts with the databases in order to fetch actual data.
- Miscellaneous tasks like formula and parameter deduction, grouping data, etc.
The layout and display logic uses the services of both the rendering API and object mapping API to generate a report.
The object mapping API is a programming interface for XML template documents. It defines the way an XML document can be accessed and manipulated. The objective is to provide a standard programming interface to a wide variety of applications. It is designed to be used with any programming language and any operating system. With this, a user can create an XML template document, navigate its structure and add, modify or delete its elements.
Any XML parser can be used to load an XML document into the memory. When the document is loaded, its information can be retrieved and manipulated by the object mapping API. This represents a tree view of the template. The object graph generated by this API is used by the layout and display logic component to access the elements of the template.
Rendering API
The rendering API is a programming interface for contexts. It defines the way a context can be accessed. The API can be used in the creation of, writing to and destroying of contexts. The objective is to provide a generic programming interface (context independent) for accessing different context rendering APIs (like HTML, PDF or CSV). With this, a user can create, write and release contexts without actually knowing the actual context-related API. For example, if the report output has to be in PDF format then user just needs to use this generic wrapper, which in turn routes the request to the PDF-rendering API.
ERP and SDO
Each request made by a client to server is called a transaction. During an initial transaction, the server fetches all the data and caches it with the proxy (client and server) as an entity graph, which is a collection of entities. Each entity is similar to a row. An entity, apart from the data, is associated with metadata, which allows it to be introspected for information about data types, data relations and data constraints.
The entity graph keeps track of the modifications, new additions and deletions made to it. At the end of the transaction, the metadata API, which is associated to metadata, will automatically generate a query based on the modifications. The client proxy then sends this query to server proxy, which in turn updates its local entity graph. Then the server proxy publishes these modifications to all the clients registered for that event. The conflicts during updating at the server side are resolved based on time stamps. At a predefined interval, the changes at the server cache are replicated to the data store through a data access adapter (which provides access to the data store). The next time a request is made by a client, the proxies serve the request from its local entity graph.
Technology independence from a developer perspective
As can be seen in Fig. 1, each module/component in the server is an technologically independent component. For example, the reporting service component can be developed using any technology as long as it provides a standard interfaces to external components. So when a developer is implementing any component which uses Reporting Service component, it just requires knowing about the standard interfaces provided.
About the authors
Vijaya Bhaskar Peddinti is a Software Engineer with Web Services Centre of Excellence in SET Labs, Infosys Technologies Ltd. in Hyderabad, India. His experience has been in product development of various sizes based on SCA. He can be reached at vijayabhaskar_p01@infosys.com.
Shaurabh Bharti is a Junior Research Associate at Software Engineering and Technology Labs, Infosys Technologies Ltd. He works with Web Services and SOA Center of Excellence. His current research interests include Semantic Web and SOA, Web Ssrvice standards and contextual collaboration. He can be contacted at Shaurabh_Bharti@infosys.com.
Mohit Chawla is a software engineer with the Web Services Center of Excellence at Infosys Technologies Ltd.. His primary area of interest is SOA, with specific focus on Web services implementations on various platforms. He has also actively participated in publishing in leading international conferences. He can be reached at mohit_chawla@infosys.com.
