Browser Based Full Client Continued
The Pharm2Phork package supplies:
- Peer Group Creation and Selection
- Graphical Workflow Creation
- EAN.UCC Membership Services
- Connectivity to Public Networks.
- Document Production and Translation.
- Industry Standard Messaging Formats.
- Built in RDF Data Store.
- Mapping to Extract Existing Data to RDF.
- Indexing of Text Documents emails etc.
- Confirmation Requests and Receipts by SMS, Email, Web.
- One./Two way Authentication via Tokens.
- LDAP Connectivity.
- Data Encryption.
- And much more
The Pharm2Phork system is a bit different from other, more conventional client server based platforms, in that each user is potentially both a client and a server. Each node consumes certian services and may, in turn, provide additional services. We form groups of trading partners, create transactions and then create and register event messages in real time, to build a record of these events as our transactions progress throughout the supply chain.
If we are alone in using the system, we enter our transaction and since we are not receiving any information from other partners, provide the event data ourselves. We may wish to use the document service to produce shipping documentation, recode the items in industry standard codes, or send the data electronically via email or SMS to the next member of our supply chain.
If we have a group of users in the same supply chain, information on events are transferred automagically from node to node, building up supply chain events and providing a complete history of activities throughout our chain. We can share documents between each other, photographs, sound recordings, whatever, while the whole time we are able to control who sees what, where and when. If , in the future, a partner requires the activity data, this can be made available manually ,or electronically, through a public service such as EPC Global, ebXML or RosettaNet.
With little overhead, we can use industry standard coding when conducting our business, without changing our internal systems. We can share information with others during the course of processing our transactions, provide services to each other and help others to get important data into our system in a timely fashion, with little additional effort or costs on the part of the individual actors. We are effectively streamlining our logistics, securing our data and complying with the regulations both today and in the future, easily, all while saving time and money.
The most important aspect to us, the developers of the system, is that each individual maintains possession and tight control over the use of his/her own data. We pass around messages that tell us what events have occurred, but the underlying meaning is held by the originators of the event and the creator of the transaction. We can take an event, use it as a starting point for our own transaction (Nested Transaction), process the items and send an event to the group. The additional data we store about our participation is ours, private, unless we wish to share it . We are still able to trace the activity, by either our own transaction reference, or by that of the original message. We are building up a distributed database of all activity around the main transaction.
