"Every Web 2.0 company is ultimately a database company." Tim O'Reilly
Embedded systems should expose web service interfaces. That web service should be secure or not. That web service should be on a private network or not.
The first generation enterprise interfaces to embedded systems are about cleaning up messes. We got rid of the protocol gunk by moving things to TCP/IP. TCP/IP allows normal routers to pass traffic to and from embedded systems. TCP/IP enables generic service monitors to watch the traffic going to and from an embedded system. We have normalized the lower level functions of the network. That step got us ready for first generation web services.
The first generation web services for embedded systems are about Plain Old XML (POX). First generation web services for Enterprise systems are also about POX. Although we have standardized the serialization strategies, and moved towar4d stateless connections, we are still using the old API (Application Programming Interface) model, requiring the enterprise programmer to have a deep knowledge of the underlying system and its processes.
Even though first generation web services now use an asynchronous protocol (TCP/IP), they are still used to make what are essentially synchronous calls to remote state engines. Do this now. Write information to this register now. Do exactly what I say, when I say it.
First generation web services are characterized by the REST (Representational State Transfer) style of development. REST development uses the 4 verbs of HTTP (POST, GET, PUT and DELETE) to do all programming. Today most enterprise interactions have not grown up into true service oriented architectures (SOA), but are instead procedure-oriented programs connected by URIs. They do no support concurrency, they do not support long-running process. They assume that all calls originated inside the firewall, if not inside the data center, and they therefore use only the simplest concepts of security.
To grow up, web services will have to move beyond simple CRUD (CREATE, READ, UPDATE, DELETE) and into more abstract interactions. But how is a database anything beyond CRUD? Well modern enterprise databases defend their data. They will not let you add records that violate referential integrity. Some records cannot be deleted by certain people. Other records automatically create detailed change logs whenever they are updated. The database is charged with the mission of maintaining referential integrity, and your CRUD is subordinate to that.
I worked a couple years ago with a web programmer who used the latest development tools to work with back-end databases. He would query the tables he wanted from the database first thing in the morning, and manage all changes using his in-memory datasets throughout the day. He felt pretty good that he was using databases at last. But of course, he wasn’t. He had concurrency problem. He had referential integrity problems. He was not using the database, merely writing to it.
If every Web 2.0 Company is ultimately a database company, does it follow that every Web Service 2.0 is ultimately a database interaction? Does it mean that the processes that generate the database, and that the database controls, should be unreachable except through the database? That database should be responsible for all sorts of data, and process integrity issues, just as a mature database is responsible for authorization and auditing functions.