I'm currently developing this 'off-line', so there is no website at all. Regarding the functionality, i'm focussing on the following items, ordered by priority
1: Full envelop compliancy (user messages and signal messages)
2: Soap one-way MEP (one way push)
4: Reliable messaging for this mep
5: One way pull
6: Reliable messaging for this mep
7: Request response MEP
8: Reliable messaging for this MEP
After this basic functionality, I'll look into storing partner profiles, agreements etc. So on this part I am open to any requirements (I prefere to use LDAP though on the technical level) Only after this, I'll pay attention to persistent security aspects (signing etc)
Reliability is the challenge, since there are two competing standards for it, both under OASIS (????? admired and hated by me cause of their flexibility. Speed ok, TWO protocols.... stupid) Maybe JBossWS will include one, I personally have a preference to use the SUN version, WS-Reliability)
Ah, this is what I was hoping for: More synergies than divergence.
The basic functionality for the platform I envision has, at its root, a "hub and spoke" mentality. In my view, this can readily be adapted to a bus architecture, as I've come to understand ESB:
1. Trading Partner Management (maintenance of each endpoint's profile, including such things as formatting, security, transport). This could include entities as well as applications.
2. User Management (maintenance of each participant's profile, including security, level of access, etc.).
3. Routing (this capability can, especially as an ESB, involve routing intra-enterprise, as well as inter-enterprise). This would include application-specific adapters, enabling tight coupling with an entities' processing environment.
4. Transformation (each Trading Partner can have a "flavor" of "standard", according to their specific requirement). This portion of the functionality (as I see it today) must have the greatest level of flexibility to accommodate any-to-any, many-to-many endpoints. An "endpoint" might not necessarily be an "end", but an interim step. ESB design accommodates this nicely.
5. Tracking (each authorized user of the platform would have the ability of monitoring individual batch, message, transaction [pick your level of granularity] "in flight", that is, from point of delivery to the platform to point of delivery to desired recipient/application).
6. Security (I suspect JBoss AS/ESB provide most of what is required here, even to the message/transaction/batch level).
This is what comes to mind, but makes a fair outline for a more fleshed-out functional spec.