SOAP: The 'S' stands for simple (not really)

One of several great motivations for that approach is that you want the power to refactor the database later without being limited by the fact that you have seven applications from seven different divisions of the company all hooked up to a single schema design. You want to be able to moderate through a business logic layer.

Many businesses wind up in this situation by chance, and then have a very painful journey out of the casual schema they created when they were a small business into something which matches their larger business.

Unfortunately, IMO, supplying a good answer to that question is the 'northwest passage' of software development.

I've spent years at it on and off. I can create such a layer, but the solutions I've come up with are unwieldy from the perspective of the business layer programmer, which is an inadequate solution.

--

If I have another attempt, I'll try to create something which would look to the observer quite a lot like visual basic, but where instead of constructing a Windows forms, you're constructing a state, which consists of a set of forms and a variable store.

The datatypes for the fields would be something like this:

    Readonly
    Boolean
    Text (untyped)
    SingleSelect (conceptually like html dropdown)
    MultiSelect (like checkbox)
    ExposeObject (the object is tagged, client
         can bookmark these these objects in its
         session)
    ReferenceSocket (the socket indicates the tags it
         accepts, exposes compatible tags, connection point
         for bookmarked objects with compatible tags)
    Link (like html link)
    Action (like html submit button)

A client API then migrates this with a query language that navigates the states. An example of a dumb session that knows nothing of the app to which it's connecting, and which is rendering a UI on the fly:

    # Remote application knows nothing
    list all
    # It gets back a description of the current state, 'login'

    # Remote application logs in to session
    assert form is login
    set username wizard_2
    set password whatever
    action login
    list all
    # Remote application has control again

    # Remote application wants to know what operations are available
    assert form is portal
    list actions

    # Remote application decides it wants to go to person
    assert form is portal
    link "manage person"
    list actions

    # Remote app decides to add a person
    assert form is "manage person"
    link new
    list all
    # Shows fields and actions

    assert mode is new
    set firstname Wiz
    set lastname Ard
    set age 40
    select male from singleselect 
    action save
    # Application throws an exception with details

    # Client app
    assert mode is new
    set data_of_birth 08081971
    action save
    list form

Just as SQL is a flexible language for a relational model, this language is a flexible language for an interactive state graph. A client progrmamer who know the state mapping of the app could write tighter instructions than this.

That client app can be anything: desktop app, unit test framework, web app, direct rpc over http.

Conceptually the situation of states, objects and actions is very similar to a text adventure, but I'd been working on it for years before I realised this.

Every time the state progresses from one to the next, it keeps a copy of the previous state in memory.

This logic layer has the database underneath it. The DB is now abstracted away from the user-facing application. Major benefits of this approach:

- You can design the application with almost no concern to user interface. Then you can create a streamlined user interface later that leverages the correct business logic. You can separate the costing for both projects. That's how I came to the problem. It would revolutionise software consulting.

- You can wrap a dumb client interface around the engine. Want your entire business logic exposed to the web, securely? Or RPC? Or mobile? Or for the blind? Done, with literally zero extra effort.

- If we had a relational database that had version numbers for its internal state (think git model), you could write applications that could unwind and rewind. Takes a lot of memory, but you could store the states in a nosql database.

--

OK. I'll try to answer your question now with the best I know of current techniques. Things using current technology that somewhat address the question you asked:

- Filter all chat with the database through stored procedures. Problems with this: (1) non-stateful, you don't have the user's application session; (2) stored procedure languages are a pain to work with. This is the sort of solution you'll find most often in large organisations because you can hire a single known skillset (DBA) who knows both stored procedures and schemas. It's awful but it works.

- Put a HTTP layer between the database and the application. Do all interaction with the database through this. In the payload that users send in they could (1) name the action they want to do such as create person and (2) supply the arguments they should send in for that business case. Basically, here you're doing stored procedures but in language of your choice. Latency is higher than with real stored procedures.

- Have a rule that all application programmers integrate with the application using Apache Cayenne or Hibernate or something similar as an object-relational modeler, in a strongly-typed language. Insist on use of Data Access Object pattern (see Fowler) for any original entrypoint to the object graph. Now when you refactor your database, regenerate your schema, and use the static typing checking in Java to rapidly adjust your application to the changed schema. You'd need to get all client apps to do this, but it's a lot more rapid than if you've got application users using SQL.

"Flavour of the month" might be a bit harsh. It certainly is popular these days, so it's not wholly inappropriate. But it's worth noting JSON/REST is popular with, and largely because of, people who've learned the painful lessons of earlier messes like SOAP.

It's not (just) a hot new thing used by new faces who've never really known any other way.

Seriously? I'm actually surprised that anyone would find SOAP complex. I see it as incredibly simplistic to implement. Are you really saying you avoid web services because you don't understand SOAP? I've done them in both .NET and Java many times.

mmmm, I'd be very wary of doing this. This kinda of "data" or "infrastructure" level service often devolves into a service that can accept SQL or lands up exposing the oddities of the DB anyway. Because they are low-level they also tend to be very chatty and performance goes right out the window. They probably should be an anti-pattern.

If you image a pyramid of service types:

Business Process

Business Operation

Component

Infrastructure/Data

Then you want to shoot for building "Business Operation" type services. These give you the maximum reuse in an enterprise as they encapsulate a useful atom of business functionality. They hide the complexity of an enterprise's IT systems from consumers and typically use semantics that are business not IT system specific. For example CreateOrder, CreateCustomer etc...

Component services are the other useful one. Typically used to wrap a system with web services. This eases integration and allows for aggregation of these services into Business Operation services.

For instance the CreateCustomer service above might call CreateCustomer in System A, RegisterMember in System BB and write a record into a the Users table of System C (sometimes its impossible/cheaper not to use web services).

As for as the consumer (the helpdesk app, the self service portal etc.) is concerned they just created a Customer within the business and they don't need to know anything about Systems A, B and C.

I once worked at a company that had a platform named "Occam". While I was learning the system, I asked someone who had been there for a long time if they had chosen that name ironically. He didn't think it was funny.