eCommerce Management Facility - Functionality

[ddegroff]

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)
3: Errorhandling
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.

Dave

[ddegroff]

http://www.ehealthconnect.net/ehc/JBossESB-MX.pdf

This description offers more detail about the proposed JBESB-based message exchange facility.

Any thoughts/comments/suggestions/concerns are gratefully accepted.

Dave DeGroff

[jplenhart]

Hi Dave,

Looks great. I was wondering what type of proposed frameworks are to be used when decrypting and validating messages. Perhaps something like SAML or XMLDS? Or obviously anything the user wants by implementing some interfaces - none the less seems like this could tie into JBoss AS.

Thanks,

Jason

[ddegroff]

Thanks, Jason.

Three levels of response to your query about security and validation:

1. Security is something that I would propose track closely with developments from Scott Stark's group. It appears that, from a JB-AS perspective, those folk have this issue nailed.

2. Encryption/Decryption is a separate matter, as the payload of data within JBESB-MX should have the option of using "good old" PKI for encrypt/decrypt/non-repudiation. As you suggest, the door should/would be left open for the user to incorporate the organization's tool of choice (PGP, SAML, XMLDS).

3. Validation is a more content/context oriented operation, requiring (in my view) the Data Transformation (JBESB-XL) to apply standards and user-authored rules to the data payload to validate its structure and content.

As to tying in with JBoss AS, my purpose for publishing this proposed infrastructure at this early date is to ensure that nothing is out of line with JBoss' roadmap.

Dave

[jplenhart]

Hi Dave,

This may have already been discussed but are the Maintenance and Designer Services going to be Eclipse Plugins? Or simply a web based SEAM type of application? Seems like this would really be cool to work on - especially the Process stuff as it begins to approach a type of 4th generation language ... or to this effect.

Thanks,

Jason

[ddegroff]

Well, you know what they say about "like minds"...

The subject has not previously been discussed, but yes, Maintenance and Designer services are to be considered Eclipse plugins.

Seam may be a "phase two" consideration, but initially Eclipse is the way to go.

As far as working on these apps., I will be proposing design specifications to the lead on JBESB-Data Transformation as soon as these specs. are complete. I surely don't want this track to get out of sync with Tom's thinking...

Dave

[jplenhart]

Hi,

I am wondering what you all think of the overlap (or lack thereof) with jBPM. In a sense they are representing a flow or process graphically, much of the time as a medium of design to bridge the gap between business analyst and developer.

Perhaps some of these tools show overlap in the context of getting closer to a 4GL - where you can graphically start routing messages and introduce some logic along the way - seems like it would be close to what jBPM is doing but instead of messages they are using process instances.

Any thoughts?

[daniel.brum]

jBPM has some interesting capabilities that we intend to take advantage of internaly inside JBoss ESB once we get to that stage. It's definetely on the road map.