COFIQ addresses the toughest SOA challenges
SOA is indeed an architecture style with some challenges.
While many thought it was simply a matter of implementing an enterprise service bus and waiting for improved business agility to magically appear time has learned that SOA is not a matter of technology but primarily a matter of organisational competence of creating the right set of services and actually using and governing them. These challenges can be seen as the price to pay for the advantages of SOA; improved business agility.
COFIQ provides just the tool for use by that competence. Get your SOA act together!
- Contract First Development. There used to be two camps: the code-first camp that defended leaving the service contract to the developer using a webservice to meet interfacing demands of a particular application. And the contract-first camp defending the importance of producing a set of interoperable services positioned for use by multiple (including future) applications. While code-first is much easier to manage as it allows autonomous projects, contract-first is the only way to achieve the benefts of SOA: increasing agility. Contract-last amounts to more point-to-point interfacing. There is no free lunch... contract-first needs a central body responsible for defining service contracts. COFIQ is firmly in the contract-first camp and has the tool for such a body. Be it a freelancer playing that role for several customers, a team within a single organisation or a true standards body.
- Interoperability. Developing an interoperable set of services instead of JABOWS 'just a bunch of webservices'. Interoperability is achieved by using a single vocabulary for your messages; a shared data model. Each COFIQ model contains a single vocabulary.
- Change Impact Analysis and Version Control. While stable service contracts are the goal it is a fact of life that changes will occur. Some changes in the shared data model will lead to new service contracts that are not backward compatible with services using the data model before the change. Meaning existing service contracts need to be checked for compatibility issues everytime changes to the data model are made. COFIQ using versioning at the lowest level possible; this way the impact of data model changes is minimized. Services no longer backward compatible are marked as 'obsolete'. This may trigger the introduction of a new version of the service.
- Service Consumer Administration. Changes to service contracts that are not in use may be applied without problems, when they are in use and no longer compatible with the latest version of the service, the service consumers need to be migrated to the new version. This requires an administration of service usage. Services in use are locked to prevent any changes. Consumers of obsolete services can be changed to use the new version of the service. COFIQ administrates service consuming applications and composite services.
- WSDL/XSD/JSON-HYPER-SCHEMA readability/maintainability. While a WSDL form of service contract is essential for automated processing by development- and test-tools they are very hard to read for humans. COFIQ uses a repository for service contracts used to generate WSDL's for tool-input and PDF's for human readers. COFIQ users don't have to manipulate any WSDL's or associated XSD's. They enter data in the repository in a very simple way and generate PDF's for human readers, including developers, and WSDL's for tool consumption, completely in line with each other. COFIQ can also generate JSON HYPER SCHEMA's from the same repository information. JSON HYPER SCHEMA may be easier to read than WSDL, but managing a central vocabulary for them is no less severe. COFIQ keeps them all in sync with your vocabulary and determines change impact with the push of a button.
- Service Portfolio Boundaries. Organizational boundaries are no longer a fixed given; there may be acquisitions or split offs, temporary partners may come aboard to leave at a certain point etc. it is better to define a portfolio of services for a specific capability of which an organization may provide several. COFIQ uses models containing one data model together with services defined in terms of that data model. The user is free to define a model for each capability or define a single model for the complete organization.
COFIQ implements the following process steps. Of course it allows incremental development and in practice steps will be performed interatively.
Look and Feel
Nothing fancy, straight forward data entry. The intelligency is below the surface. Making cumbersome XML manipulation and performing backward compatibility checks a thing of the past!
Every COFIQ account gets a free example model to demonstrate the power of COFIQ and play with. Below you'll find examples of the output of that model:
Another example to show that COFIQ can handle technical API's as well as API's for administrative applications.
It is very loosely based on Philips Hue API, which was crowned as the best 'Internet of Things' API.
With COFIQ you can define a winning API for your own 'things'. This example shows the power of using REST messages
combining URI and Body message parts to achieve optimum easy of use for your app developers. To be absolutely clear
this is not meant to interact with Philips Hue, it is meant to develop your own API for your 'Internet of Things'
devices. These examples demonstrate the value of COFIQ, just imagine what it would mean to manually
maintain this in a guaranteed consistent way. COFIQ does this for you!
- Example vocabulary - PDF report
- CashManagementServiceV1 - PDF
- CashManagementServiceV1 - WSDL
- CashManagementServiceV1 - JSON HYPER SCHEMA
Here's the vocabulary, PDF service report and a more traditional SOAP .wsdl file.
All from a single service definition as entered in the COFIQ repository.
- Domotica Lighting API V1 - JSON HYPER SCHEMA
- Domotica Lighting API Vocabulary - PDF report
- Domotica Lighting API V1 - PDF
- Domotica Lighting API V1 - WSDL