Transcript Open-edi - Norsk Regnesentral

An Open-EDI prototype based on UML,
CORBA and Java
Lesson learned
Presented at ISO/IEC SC32 WG1 Ottawa
22. September 1998
Per Myrseth
[email protected]
Norwegian Computer Center
www.nr.no
1
Target: Formal specification and
automatic system generation
An old idea within system developement, but so far
successful only under very limited circumstances.
How we tried to reach our target
 Used ”state-of-the-art” FDT toolkit. Rational Rose and
UML notation
 Used ”state-of-the-art” technology, Corba and Java for
implementation
Slide 2
Norsk Regnesentral
Norwegian Computing Center
Model in UML
customer :
Customer
subscription_c :
Subscription_C
NR : Net
OwnerRegistry
NR : Net
OwnerRegistry
subscription_n :
Subscription_N
locateNetOwner (in Address)
Role
(from open-edi)
NetOwner
Role (in string)
Customer
newSubscription (subscription_c)
S_NetOwner
1
1
S_Customer
Role (in string)
Subscription
/N_Sub scription
/C_Sub scription
0..1
N_Subscriptions
C_Subscriptions
confirmSubscription (subscription_n)
bind (subscription_n, role_id)
*
Subscription_N
changeCustom er( )
Subscription_C
0..1
1
/Sub scription
meterReading( )
confirmSubscription( )
Message sequence diagram
(+State diagram)
Objectmodel
FSV
BOV
Slide 3
Norsk Regnesentral
Norwegian Computing Center
From model to usable code
UML model
Open
EDI
framework
State
diagrams
Clientspecific
code
Message
sequence
diagrams
Class
diagrams
IDL code
generation
Scenario
generation
CORBA
interface
definitions
Java code
generation
Scenario
drivers &
utilities
Specific
operations,
interfacing,
etc.
Scenario
skeleton
Slide 4
Object
ORB
interfaces interfacing
code
Norsk Regnesentral
Norwegian Computing Center
The structure in a CORBA/Javaapplication
User-written code
Client code
Generated code
Built-in code
Server code
Server skeleton
Stubs
Holders/helpers
Object adapter
OrbixWeb ORB
Slide 5
Norsk Regnesentral
Norwegian Computing Center
Modeling Open-EDI scenarios with
Rational Rose and using UML notation
Some findings:
 Rational Rose is primarily designed for use in software
development projects, not to model BOV.
 Several objects could act in concert to implement a
single role.
 All actions must take place in concrete objects, where
each is always executed on a specified host computer
and under the control/responsibility, and on behalf of
precisely one real-world actor.
Slide 6
Norsk Regnesentral
Norwegian Computing Center
FDT’s for asyncronous versus
syncronous system integration
Having in mind that an EDI message counterpart within
distributed object systems is the method call.
At what time do we have to choose asyncronous versus
syncronous integration?
 Reference model level (Open-EDI, eCo, Zackman)
 FTD level
 Design level
 SW implementation tool
Slide 7
Norsk Regnesentral
Norwegian Computing Center
Message modeling versus state modeling
Difference between:
 Message modeling
 State modelling of agents/programs to act upon data in
objects
 Type of error handling
 Security issues
Signature on messages versus callable objects
Encryption on messages versus restricted access to objects
Slide 8
Norsk Regnesentral
Norwegian Computing Center
”Information exchange” in a distributed
object model, 1
Use reference to objects
 Count on partner’s systems to be available at all time
 Use version handling on objects
Slide 9
Norsk Regnesentral
Norwegian Computing Center
”Information exchange” in a distributed
object model, 2
Copied or cloned
 What about the methods, they are not platform
independent and can’t be copied?
 Could all involved actors use the same method libraries?
 What about deep versus shallow copying?
 Java: Coping objects by value, data, state and methods
The idea of an object is that it should be viewed as a whole
in the context it belongs. Copy by value is not in line with
this idea.
Slide 10
Norsk Regnesentral
Norwegian Computing Center
Points of interest for evaluating FDT’s and
variations of implementations
In a ”live” business transaction:
 Where/what is the scenario state?
 What/where are the scenario attributes?
 How is a scenario initiated?
 When does a role die?
End of scenario
End of business relation with partner
 Error handling? Where is it modeled?
 Security issues? Where is it modeled?
Digital signatures, encryption, access controll
Slide 11
Norsk Regnesentral
Norwegian Computing Center
What to do versus how to do it
Reference
models
What to do
OeDT
UML
Abstract
Concrete
FSV
FDT
Framework’s
Library’s
Compiled
Software
How to do it
Slide 12
Norsk Regnesentral
Norwegian Computing Center
Comments
To have automatic code generation I believe that:
A FDT’s expression power has to be equal to the
expression power to the target abstration level
Open-edi reference model serves as a good
vocabulary for a very complex field, made up by
simple parts
UML descriptions is interchangable by using
XMI, XML Metadata Interchange.
Norsk Regnesentral
Slide 13
Norwegian Computing Center