©Kabira Technologies Inc, 2001 May 7-9, 2001 Westward Look Resort Tucson, Arizona SMUG 2001 Execution in UML

©Kabira Technologies Inc, 2001

May 7-9, 2001

Westward Look Resort

Tucson, Arizona

SMUG 2001 Execution in UML


Michael M. LeeV.P of Application Engineering


<Insert interesting and provocative talk title here before going to SMUG-2001>

Michael M. LeeV.P of Application Engineering

Automated Bridging to

Third Party Packages


Recursive Design 101

Requirements

Implementations


Domains of Different Technologies

MaterialHandling Process

AlarmHandling

GenericEquipmentHandling

OperatorInterface

Corba-BasedEquipment

Drivers

Java-BasedPlant

Maintenance

• You need to use a 3rd party software package (a.k.a. COTS, legacy software, realized domain) as a service?

• You need to expose your system as a service to another system?

But What Happens When

Straightforward approach with homogeneous, OOA domains


Bridging to 3rd Party Packages



Drivers

• The ability of the client domain to drive requirements on the service domain is limited.– totally limited if service is fixed

– partially limited if it isn’t fixed

• The implementation mechanisms can be dictated by the service.– Corba, Java

– execution paradigms (transactions, multi versus single threaded, synch/asynch)


The Question for Code Generation

executableprocess

standard compiler

technology

conventionalcompiler and

linker

object-oriented models Model Compiler

ModelCode

System Software

Architecture Run Time

Implementation Platform

TranslationRules

Design Patterns

Frameworks

TranslationRules

Design PatternsFrameworks

Run TimeLibraries

ModelTranslator

Source Compilerand linker

source code

Software Architecture

Design

Software Architecture

Design

ApplicationLogic

ApplicationLogic

?3rd Party Packages


Interfaces to 3rd Party Packages

• Language based API’s– Java– C++– C

• Specification based API’s– Corba– DCOM

Interfaces to 3rd party packages are typicallydefined in one of two basic ways:


One Approach

CodeGeneration

InterfaceDefinition

Model Based Wrapper

Native Client Interface

to Service


Drivers


Model Based Wrapper


to Service

model basedinterface

OOA model


Implications


Drivers


Model Based Wrapper


to Service

• The client deals directly with the level of abstraction presented by the 3rd party package.

• Good: nothing “between” package and client

• Bad: may be a conceptual gap between client and service

Let’s look at some examples...


Corba Client Adapter (a.k.a. Bridge)

CodeGeneration

IDL

Model Based Wrapper

ORBInterface

Logic

Development

Client App Engine CCA EngineCORBA Server

ORB

ObjectSwitchObjectSwitch

Deployment

Client “sees” CORBA service as if it were modeled in OOA


The Development Process

Design CenterDesign Center

IDL

CCA Component

Application model

Obj

ectS

witc

hN

ode

CCA Engine

Client ApplicationEngine

Built from application model + CCA component

Design CenterDesign Center““wrapping”wrapping”

CCA Component

unpack/deploy

Step 1. Create CCA Component by “wrapping” IDL

Step 2. Use Component + your model to build engine

Engine Component

CORBAServer

CORBAServer


Basic Operation

• Obtain stringified IOR (strIOR)• Declare and create object of wrapped type, proxy object

declare componentName::MyModule::MyInterface mi;

create mi values (m_stringifiedIOR:strIOR);

• If the IDL contained user exceptions, the client can catch them in try…catch blocks.

CCA Engine

CORBA Server

ORB

ObjectSwitchShared Memoryproxy object

miproxy object

mi


Java Client Adapter (a.k.a. Bridge)

Development

CodeGeneration

Javaclient

routines

Model Based Wrapper

Java ClientRoutines

Java VM

Deployment

Client Engine JCA Engine Java application


The client “sees” the Java serviceas if it were modeled in OOA.


Nothing New Here




IDL

CCA Component

Application model

Ob

ject

Sw

itc

hN

od

e

CCA Engine

Client ApplicationEngine

Built from application model + CCA component

Design CenterDesign Center“wrapping”“wrapping”

CCA Component

unpack/deploy

Step 1. Create CCA Component by “wrapping” IDL


Engine Component

CORBAServer

CORBAServer


Basic Operation

• Obtain stringified IOR (strIOR )

• Declare and create object of wrapped type, proxy objectdeclare componentName ::MyModule ::MyInterface mi;

create mi values (m_stringifiedIOR:strIOR );

• If the IDL contained user exceptions, the client can catch themin try…catch blocks.

CCA Engine

CORBA Server

ORB

ObjectSwitchShared Memoryproxy object

miproxy object

mi

The approach to Java is basically the same as Corba.


Another Exchange Standard: XML

• eXtended Markup Language• Specifies structure and contents for a

“document” (DTD/Schema) • Does not specify communication protocol as

Corba and Java do.Service

Actication

HTTPService

XMLService

COVAD


XSA Adapter (a.k.a. Bridge)

The client “sees” the XML documentas if it were modeled in OOA.

Deployment

XSA EngineProtocolEngine


Client Engine

XML

Development

CodeGeneration

XMLSchema

Model Based Wrapper

3rd PartyDOM

Service

import/export documents of

defined schema


XSA Service Component

• Each XML Schema you wrap results in a distinct XSA Service component

• The XSA Service component contains a hierarchy of entities and interfaces that facilitate conversion of data between XML and object attributes

• The key object in the generated object hierarchy is the “root” object


XML Schema

XSA Service component

root entity

- XMLString

exportToXML()

setXMLString()




XMLSchema

XSA Service Component

Client model

Obj

ectS

witc

hN

ode

XSA Service Engine

XSA clientEngine

Built from Client model + XSA Service

component

Design CenterDesign Center““wrapping”wrapping”

XSA Servicecomponent

unpack/deploy

Step 1. Create XSA Component from XML schema


XSA client component


Sending an XML Document



Client Engine

XML

• The client engine creates the objects it needs for an XML document from the entities defined in the XSA Service Engine and assigns values as desired.

• The Client then calls the exportToXML() operation in the root object of the document.

• An XML string of the document is returned which is then sent out using the protocol engine.


Receiving an XML Document



Client Engine

XML

• The client engine acquires an XML document (a string) using the protocol engine. A document root object is created.

• The setXMLString() operation of the root object of the document is invoked with the XML document as an input.

• The objects necessary to contain the information in the XML document are created and initialized.


One Approach

Code

Generation

Interface

Definition

Model Based Wrapper

Native

Client Interfaceto Service


Drivers


Model Based Wrapper


to Service

model based

interface

OOA model

• Wrapped non OOA functionality in OOA.

• Used code/model generation technology.

• Exposed an OOA interface to existing service functionality.

• Built up the domain chart as the technology (RD) dictates.

Summary: Bridging to 3rd Party Software


Supplementary Slides


Extinsible CodeGen Architecture

Plu

g In

Ser

vice

Model Repository

Import/Export

Model Auditor

System Builder

Model Compiler

AL Interpreter

Adapter-1

Adapter-N

. . .

DC Server

DC GUIClient

DC CMDClient

CorePlug Ins

AdapterPlug Ins• Persistence• Corba• SNMP• others...

Basis forExtensibleDC Services• Register/List/Search• Project Mgmt• Property Mgmt• Commands/Results

CorbaORB

Built with ObjectSwitch!

Documents

©Kabira Technologies Inc, 2001 May 7-9, 2001 Westward Look Resort Tucson, Arizona SMUG 2001 Execution in UML