The alternative is an enormous array of protocols. Every protocol slightly different than the other but also quite common. Some protocols are data-driven like XML, while other protocols are more function- or action-driven like HTTP. EDI, HTML, HTTP, XML, SOAP, .NET, the list goes on and on. All of these protocols require a contract between client and server or otherwise a contract to be discovered and complied with dynamically.
Agents can change this. Rather than thinking about agents as "mobile pieces of code", we could think about agents as "mobile, adaptive pieces of code that maintain a conversation". I'm basing this on Java for example, where it's easy to serialize a Java class with its data and transport it over a network. The agents are all sent to the same port without exception, because it is no longer the port that controls behaviour or is entitled to particular functionality, it is the message and request that is inside the agent, which is actually executed within the host environment.
The agent may request information (browsing) or make a request to purchase a particular article. It can give away information about its host environment like HTTP does in some sense, but it can also travel around further for other information that may be required before the action can be completed.
Consider a credit card transaction. An agent could be sent off to buy item "15-XA-01" from a particular online-shop. The agent is sent off along with credit card details and shipping address in its pocket. The agent is executed and requests the item to be purchased and sent off to the address. In return, it hands over the credit card details to the environment, which needs to specifically ask for it. If the environment also asks for an email address or phone number, the agent needs to travel back to the originating host, where it requests the user for the extra information. The agent then returns and continues its conversation.
Rather than creating "software interfaces", I think it's worth to consider "data-objects" that are versioning. For instance, an environment could ask for "v3.0 of Master CC", which is version 3 of the Master Credit Card details, a specific format. Or it could give the list of acceptable payments and ask the user how it wants to pay. Anything is possible. The actual conversation can be based on very basic, old "text adventure" parsing protocols:
- A: Buy "XA-01-05"
- B: Accept "{v3.0 Master CC, v2.0 Visa CC, cash}" ( "{...}" being the contents of a Java object )
- A: Use "{v3.0 of Master CC}"
- B: Get "Shipping Address"
- A: Use "{shipping_address}"
- B: Get "Email Of Host"
- A: Please forward to {Host}
- A: Request "Email of Host" for transaction "YYY" to "Buy XA-01-05"
- ( C shows message to user, who accepts )
- C: Use "Email of Host"
- A: Please forward to {address_of_destination}
Just some initial ideas there, in practice there will be a big gap to be filled in the capabilities of the agent and its parsing capabilities, not to mention security! Plus how can it be proven that something was actually bought in a court of law, etc? Cryptography can help here and there, but only to some extent.
What I wish to pursue is "some means" where the endless "integration" of protocols can be avoided altogether. A space in which integration is the addition of a couple of parsing statements or requests, rather than burying layer of layer on additional "plumbing" on top of one another. Business rules with the above are potentially easier.
You should also see in the above that it requires standardisation of data-classes. Properly versioned, I see this as a benefit, because once the data is common, libraries can be written once to do the parsing and validation only once, rather than each entity having to do this "in their own way".
Many benefits over current integration practices... Let's see how this follows in the space.
Posts
2 comments:
I say.. have a look at http://www.tryllian.nl/ for mobile (java) agents... including a open development kit
Intriguing. Downloaded the code and examples and looks like an interesting framework to use. I'll have to take a deeper look how much flexibility the ADK offers.
I worked on an OS workflow solution before that offered very high flexibility in system integration between systems, but did not offer much of anything else. I'm going to do some investigation on how maybe those ideas can be integrated using the ADK.
Post a Comment