Breaking the Code of Web Services
Platform- and language-independent, web services were invented to provide interoperability between applications running on disparate systems. When applied to accessing data in real time from back-end systems, the advantages of a web services-based approach over traditional methodologies are substantial, specifically in terms of platform independence, true integration, and extensive re-use of components and services.
This is a method with advantages that reach far beyond those of traditional approaches when properly leveraged.
So, with the promises come the hype, and with the hype, come the questions. In the last few years, many CIOs have been faced with answering the question: So, whats our web service strategy?
IT organizations, especially in service, information and consumer sectors have been implementing web services and service-oriented architecture (SOA). In a recent report, Gartner predicted that by the end of 2007, approximately 25% of global 2000 will have employed an external web service in a strategic application.
As strong a promise as web services holds, many CIOs are still in the development phase of putting together a strategy for their company. In industry sectors such as manufacturing, financial services, healthcare, and chemicals, the value of an SOA approach is starting to be recognized.
However, these industries are laden with complex and legacy systems that require more sophisticated uses of these strategic applications. There is a greater need for interoperability with different organizations within the enterprise and a wide variety of specifications for end user access.
For example, when it comes to providing real-time access to a complex system like SAP, a web services approach can enable bi-directional integration. This means organizations can gain the ability to automate business processes across SAP and other applicationssuch as providing remote order entry capabilities to a mobile device-equipped sales force.
In short, web services provide a powerful way of avoiding the pitfalls that plague traditional data access methodologies. But, to gain full advantages, web services still have to be harnessed properly. And, to do this, IT must be able to deal with an architecture that presents a challenging code.
The Code Barrier
Functionality in contemporary web applications is typically modularized into discrete business objects or services, which abstract the application layer from direct interaction with the data layer. The advantage is the application itself does not need to be redesigned every time the underlying data structure is changed, so long as the business object or service is adjusted to maintain its expected behavior.
This allows better isolation of code-maintenance tasks and therefore allows development teams to scale to take on more complex projects in a more efficient way.
However, the overall architecture of these applications remains complex, with three interdependent levels of code. Each piece of application functionality must know how to talk to a corresponding business object or service.
Each business object or service is a development effort in its own right. Finally, the business objects or services must know how to address the applications underlying physical data source.
The contemporary approach is limited in that application functionality remains dependent on the objects, services and data that it was intended to be used with. This means the original application architects must correctly anticipate at design-time exactly the business functionality that will be needed.
If they are not completely correct in their planning, or if business needs change over time, code must be adjusted or new code created for new business objects and new application functionality to leverage them.
Contemporary web service approaches can deliver tremendous value, but organizations with complex and multiple back-end systems face substantial programming costs and delays in implementing these methodologies.
Fortunately, an innovative approach that unlocks the interdependency of different levels of the code can provide a more effective SOA strategy for these types of organizations
Schema independent architecture (SIA) is a fundamentally different design approach which eliminates the need to foresee all possible business requirements at the time of designing an application.
Experience has shown that it is almost impossible to completely understand how a business process should be automated prior to actually seeing it run in an automated state. There are always unforeseen wrinkles to the theoretical process.
Business needs are constantly changing, so even if there was a perfect process, it would have a relatively short shelf-life before becoming stale or obsolete. SIA eliminates the issue of where a process is going to be at a particular point in time and, instead, puts the focus on how to dynamically orchestrate business processeseven as they continue to evolve.
SIA achieves this by eliminating any pre-assumed dependency between the application and the data model. The application assumes nothing about the underlying data model.
Instead, a logical data schema intervenes above the physical data source. The schema is administered via a visual wizard, which allows the schema to dynamically discover and validate against the underling physical data model.
As new data elements, relationships or rules are needed, they are designed within the visual schema wizard, and re-validated back to the physical database underneath.
Jenny Peng is the VP of Engineering at Saratoga Systems, a global CRM company. Ms. Peng brings over 14 years of experience in software development and programming and has a proven track record of achievements in directing projects and staff in fast-paced, results-driven environments.