1	B2B търговия
2	Необходими предпоставки за B2B Гарантиране на интероперативност между участващите софтуерни системи – използват се middleware платформи, с които се преодоляват разликите между хардуера и оперативните среди (напр. CORBA). Поддръжка на кохерентност на системите – необходима е стандартизирана лексика, така че различните информационни системи да могат да се разбират помежду си. Гъвкавост - софтуерните системи трябва да могат гъвкаво да се адаптират към нови ситуации и търговски взаимоотношения и без модификация на първичния код и прекъсване на оперирането си. Управление на работни потоци – търговските транзакции включват освен обмен на данни, така също и вътрешни процеси и бизнес-правила на участниците. Те трябва да се управляват от един организационен процес, който е на по-високо абстрактно ниво.
3
4	EDI (Electronic Data Interchange)
5	EDI (Electronic Data Interchange) EDI - електронен обмен на структурирана бизнес-информация между търговски партньори; данните са в предварително дефиниран чрез специфицирани структури формат; стандартните формати позволяват интерпретиране на информацията, независимо от приложението и операционната система; изпращащият и получаващият съобщението, се нуждаят от EDI софтуер за конвертиране на данните в и от EDI формат.
6	EDI комуникация между бизнес партньори EDI софтуера конвертира подходящо данните от вътрешно-фирмения формат на организация А във формат, отговарящ на приетите стандарти между две организации; EDI данните се предават чрез взаимно договорени електронни методи за комуникация;
7	EDIFACT (EDI For Administration Commerce and Transport) EDIFACT предоставя международно приети стандартни формати за бизнес документи; структурата на документите е сложна поради необходимостта да предвидят различни възможности; дефинирани са отделни подмножества на EDIFACT, които определят различни стандарти, предназначени за специфични индустрии; съобщенията се разработват, контролират, регистрират и публикуват под контрола на Обединените Нации.
8	UN/EDIFACT съобщения задават модели на данни за различни сектори от икономиката; структурата на UN/EDIFACT съобщение е йерархична; при една транзакция могат да се предадат едно или повече съобщения; всяко съобщение съдържа сегменти, които от своя страна съдържат прости или съставни елементи с данни;
9	UN/EDIFACT съобщения два вида сегменти – потребителски сегменти и служебни сегменти; сегментите, елементите в сегментите и елементите в съставните елементи са в строго определена последователност; отделните сегменти и прости елементи се разделят посредством разделители; достъпа до елементите се осъществява чрез позицията и/или идентификаторите им.
10	Структура на UN/EDIFACT съобщение
11	Служебни сегменти Служебните сегменти са UNA, UNB, UNZ, UNG, UNE, UNH и UNT. Те съдържат елементи със служебни данни, като: изпращач на транзакцията; типове синтактични правила; дата на изпращане; други специфични данни, необходими за транзакцията.
12	Сегменти с потребителски данни съдържанието им е извън обхвата на UN/EDIFACT стандарта за синтаксис на съобщението; съдържат елементи с потребителски данни (напр. количества, цени, имена, места и др.); имената на сегментите с потребителски данни не трябва да започват с “UN”, тъй като този низ е резервиран за служебните сегменти.
13	Информационен модел на класическите EDI - системи независим е от вида на използваната техника; включва обикновено три независими модула, които взаимодействат помежду си посредством стандартизирани интерфейси.
14	Модули на класическа EDI - система Вътрешно-фирмена информационна система - информационнa системa, създаващa и поддържащa бази данни на локално ниво, както и инструменти за подготовка на документи на основата на съществуващи международни стандарти. EDI-стандартна система - този модул включва стандартни програмни средства (обикновено специализирани конвертиращи програми) за преобразуване на данните от вътрешно-фирмен формат в някои от възможните EDI-формати и обратно. Комуникационна система - модул, осъществяващ глобалната комуникация между отделните партньори. В EDI не са дефинирани никакви изисквания към комуникацията. Това прави стандарта по-широко приложим.
15	”Kласически” EDI модел
16	Интерфейси – два вида интерфейси към вътрешно-фирмените системи - обикновено това са специализирани редактори или предпроцесори. Те разполагат с информация за структурата на конкретната база данни и на тази основа създават необходимата формална среда за конкретната работа на конвертиращия софтуер; интерфейси към комуникационния модул - едни от най-сложните интерфейси. Трудностите са свързани предимно с голямото разнообразие на използваните комуникационни протоколи.
17	Пример за търговски процес, който обхваща 4 роли: всеки отделен трансфер отговаря на определено EDI-съобщение
18	Характерни особености на B2B търговията При търговските транзакции участват предимно софтуерни компоненти – хората участват предимно като конфигуратори или контрольори на автоматизирани процеси. Различните търговски правила на променящи се партньори определят вида и начина за обмен на взаимни услуги. Стандартизация е необходима не само на ниво комуникация, а също така на ниво търговски процеси, както и за общо използваната терминология.
19	Интеграция на фирми
20	Бизнес обекти представят търговски обекти – напр. таблица на валутни курсове, склад, главна книга и др. обекти са; в смисъла на обектно-ориентирания подход това означава, че: данните могат да се капсулират; бизнес-логиката може да се представи като методи; за всички обекти единни концепции – класове; независими са от технологични платформи; могат да бъдат произволно разпределяни; възможност за стандартизиране.
21	Продукти и стандарти за конструиране на комплексни приложения от бизнес обекти Java Beans; Enterprise Java Beans; CORBA; BOCA - много мощна и комплексна рамка, която дефинира поведението и интерфейсите на бизнес-обекти; San-Francisco-Framework – обектно-ориентирана рамка на IBM; много други.
22	BOCA BOCA - Business Object Component Architecture; CORBA - базирана архитектура; опит да се представят постоянно променящите се търговски процеси така, че да е възможна кооперация извън границите на отделните фирми.
23	Business Object Facility (BOF) предлага една платформа за моделиране и работа на бизнес-обекти; платформата доставя само механизми за управление и описание на бизнес-обекти; самите бизнес-обекти се конфигурират, когато се разработват конкретни приложения.
24	Два вида бизнес - обекти Common Business Objects (CBO) – разработени са и се доставят като рамкови структури от софтуерни фирми като IBM, Oracle и др. В рамките на BOCA тези обекти са стандартизирани и не могат да бъдат променяни. Specific Business Objects (SBO) – разработват се от потребителите според техните индивидуални потребности. Могат да бъдат специфицирани спрямо производителя (IBM, Oracle,…), функционалността (финанси, производство, управление на документи,...), потребителите.
25	Архитектура на BOCA
26	Бизнес – обекти: CORBA-обекти са, т.е. могат да бъдат идентифицирани и използвани в мрежата през един ORB; представят проблеми или процеси в определена търговска област; пример за бизнес-обекти: договори, клиенти, отдели, продукти, проекти.
27	Бизнес – обекти: притежават еднозначен идентификатор, посредством който могат да бъдат свързвани на определени места; не могат да бъдат копирани, а само премествани (идентификаторите не могат да бъдат дублирани); чрез идентификаторите си могат да бъдат направени персистентни и съхранявани и търсени в БД; имат съпоставени типове, които определят атрибутите, методите, събитията, ролите и т.н., които може да притежават обектите; могат да наследяват свойства и поведение.
28	Зависими типове обектите на зависимите типове не могат да се идентифицират еднозначно; обектите от зависими типове се използват само във връзка с други бизнес-обекти; съществуват стандартизирани зависими типове, напр. валути, цветове, мерки и т.н. Пример: атрибутите на бизнес-обектите са от зависими типове.
29	Свойства на бизнес-обект
30	Параметри на свойствата на бизнес-обект подпомагат детайлизирането на спецификациите на бизнес-обектите; задават специфични за конкретен случай правила и ограничения, без да е необходимо да се променя обекта и неговите методи.
31
32	Домейни от бизнес-обекти
33	За управление на бизнес-обекти от един и същи тип се използват typmanager-и. Те служат за: създаване на инстанции на обектите; съхраняване и премахване на обектите от БД; управление на общия брой на обектите; освобождаване на паметта от неизползвани обекти.
34	CDL (Component Definition Language)
35	CDL (Component Definition Language) разширение на IDL, дефинирано като формат за обмен и език за спецификация на бизнес – обектите; с помощта на CDL градивните елементи на BOF могат да бъдат синтактично и семантично коректно интегрирани.
36
37	При стандартизацията на CDL са приети различни съществуващи концепции от други езици CDL-граматиката е супермножество на IDL; използва се ODL (Object Definition Language) на ODMG (Object Database Management Group) – за улесняване на адаптирането на средствата за обектно моделиране; синтаксисът за дефиниране на изрази – от Java; спецификация на условия и заявки – от OMG OCL (Object Contraint Language);
38