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

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 Application – runs externally to Fispace “B2B App” – runs within B2B module – This is convenient enough for a short name

4. Virtualization / Contexts B2B Apps – Executes common business logic within a (collaboration) context – Can think of different contexts as being different virtual-apps Can also be relevant for (hosted, as-a-service) applications Suggestion: (connects with next slides) – Each app and B2BApp can have a list of virtual ids. By default, they start with a single virtual id – These virtual ids should be managed by (role) - the app developer / business architect / someone else? – For B2B App; part of the correlation key must be the virtual id (but there may be additional fields used too)

5. Registration Capability Type: defines request & response message types (can have nulls for feeds) B2B Apps and Applications: indicate capability types provided / consumed (for services need to explicitly indicate whether they consume or provide the service). These define new Capability (Provider) instances (must include here some sort of an app id; for service providers and data consumers must include a URL) MessageEndPoint: a pair.

6. Contract A contract indicates an agreement between (virtual) apps / B2B apps to share data and services – i.e., establishes consumer/producer relationships, where each is identified by a MessageEndPoint Contracts are queryable; e.g., an app developer / a virtual app / b2b app should be able to find all contracts where it consumes a specific capability type. This enables, for example, to query for prices, make a decision, and then invoke a service from one provider amongst many

7. Communications Messages must contain the sender’s end point and may contain one or more receiver end points Messages which don’t specify receiver end points are sent to all relevant, contracted end points Consumers should not know about each other: when Fispace sends a message to a consumer it will remove all other consumer end-points from that message Messages can only be sent to contracted or “publicly accessible” end points

8. Example I have created a B2B App to handle shipping For different collaborations I establish different virtual ids Within a collaboration all of my MessageEndPoint instances will have the same virtual id. I will establish Contracts using these instances. I can connect specific MessageEndPoint instances with other apps / b2b apps, for example, to provide data to an analytics service

9. Business Process Template? Defines capability types and cardinalities (e.g., should there be a single provider of a service or can there be multiple), may indicate certain capability types as being optional I’m not 100% clear on why it’s needed once we identify virtual instances and contracts. Shouldn’t capability types and cardinalities be part of registration already? Note: a virtual b2b app controls 1 or more collaborations; but it can participate in additional collaborations that are defined by other b2b apps. Thus, a message doesn’t exist in the context of a single “business process”; it may be produced by one process, but consumed by several others. Thus, I’m not clear on why we need the extra “business process” abstraction.