1. Capability Model & B2B – Draft for Discussion IBM Research – Haifa Moti Nisenson

2. Goals Sharing data should be possible between applications and between collaborations – 1 to Many: e.g. provide a feed of data to all/some consumers. New consumers can join without needing to know about previous consumers – Many to Many: many parties come together to collaborate – Extend over time; my collaboration creates a data feed and I want that to feed into a new collaboration It should be possible to dynamically choose the best provider of a service Minimal changes from current implementation

3. Definitions Data Provider / Consumer – provides/receives a feed of messages of a specific type Service Provider / Consumer – provides/calls a synchronous request-response service Fispace App – runs externally to Fispace “B2B App” – runs within B2B module – This is convenient enough for a short name – Contains within it several collaboration definitions – Collaboration instances are instantiated at runtime, based on incoming messages

4. Current State Capability Type: defines request & response message types (can have nulls) Capability is the registration of a FiSpace App as a Service Provider or a Data Consumer; in other words they get a request of a certain type, and if the Capability Type has a response, they should provide the response

5. Current State - Business Process Business Process Template defines participating Capability Types Instantitation is a Business Process with specific Capability instances and an Id. Business Process Template lines up with a Collaboration definition inside B2B Current Gap: a single B2B App could potentially have several Collaborations defined

6. Current State – Messages Have a Type Specify a business process id Previously had a capability id field – This has been removed as Fispace apps “shouldn’t” need to know others capability ids – But… when signing a contract (instantiating a business process) they DO need to know others capability ids – Also, prevents re-using message types for different needs. E.g., define 2 messages, one for all customers and one for premium customers. Same format, but when Fispace App sends it could have indicated by using different capability types which one it is.

7. Issues Need to include a business process id in messages: – Fispace App needs to know all the business processes it participates in; it may also need to send the same message data multiple times – Can’t share data across B2B Apps or between collaborations without “leaving” Fispace No “B2B App” identified – can’t have different collaborations working over the same data without defining 1 very large business process template (which impacts maintenance) Message issues (previous slide)

8. Questions Should a Fispace App be able to know who provided it some data – whether it be a business process or some other Fispace App? Definitely for a business process; this is because the Fispace App may decide to send additional messages back to a specific business process Maybe yes for some other Fispace App but maybe no (decide in Future)

9. Suggestions B2B App need to be defined; this has an id, and is a collection of business process templates. Thus business processes should also have the b2bAppId in them. – This id should be used in EPM and BCM to determine context Messages should include a capability type id field (indicating their own capability type)

10. Message Routing – Incoming from Fispace App Lookup based on App Id, Message Capability Type the business processes that could receive the message – This means at the contract level, that the Fispace App should indicate it wants the B2B App/business process to handle that capability type for it If the message specifies business process ids, then filter those ids with the result from the lookup. Otherwise, use all the ids from the lookup It should add the following data to the message (or to a wrapper) and send to B2B: b2bAppId, bptId and bpId – These 3 ids are used for internal routing and as part of correlation keys

11. Message Routing – Outgoing from B2B The message contains a capability type The message contains a sending business process id The message may contain capabilities – If it does the message is sent to those capabilities (SDI should verify a contract between the B2B App / business process and those capabilities). The message sent shouldn’t include the capability ids What about business process to business process communications? (FUTURE) – Could handle similarly… have contracts based on capability type between business processes