Home » Language IDEs » ServerTools (WTP) » EMF, WSDL and SOAP
| EMF, WSDL and SOAP [message #212409] |
Wed, 16 April 2008 08:41  |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040402080601090203000403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
As mentioned in a previous post, I'm working on generating a web services
description language (WSDL) file, from an EMF model of the services. The idea is
to model the domain and related services as a "standard" object-oriented model,
and let EMF and my generator handle all the XML and WSDL encoding stuff. I
thought I'd share the current design with you all, so I can get comments before
I put too much effort into the code. Sorry if this really should be sent to
another newsgroup...
First some words about WSDL (as far as I understand). A WSDL file is typically
composed of several elements:
- An XML schema part, which defines and/or imports type definitions. This
essentially defines how domain objects (types) are described using XML. EMF
already has tools for generating XML schemas for Ecore models (export a genmodel
as XML schema).
- A "port type" part. A port type is similar to an interface, in that it defines
a set of abstract operations. Each operation in turn defines the input and
output by means of the (structure of) the messages that are exchanged. The
messages refer to the types (and elements) defined in the XML schema part
(explicitly defined or imported).
- A binding part, which defines how the operations of a port type actually are
implemented. Implemented means what communication protocol is used (and how) to
exchange the relevant messages for invoking operations.
- A service part, which defines where (server address) a set of bindings are
handled.
My current design is as follows:
The domain model is modeled in the usual way, as an Ecore model with classes,
references and attributes, e.g. in a domain.ecore. The services models is
modeled in its own model, e.g. domain-services, with references to the domain
model, using the Load resource... trick. I've chosen to split the models in this
way for two reasons: 1) These two models should be in their own packages, so
they get separate namespaces. 2) It is easier to invoke the generator (an IFile
action) if the services are in their own file.
The services model has three kinds of classes:
- A "port type" class is a class marked as interface (and abstract). Such a
class contains operations only. A port type class is mapped to a WSDL port type.
- A "binding" class is a class that is a subclass of a single port type class.
Such a class contains the same operations as the port type class, but may omit
the parameters. The operations are (just) used as placeholders for annotations,
which are used to include information of the protocols used by the binding.
- A "service" class is a class that is a subclass of a set of binding classes.
It is also a placeholder for annotations that add protocol information. A
service class is mapped to a WSDL service.
I've attached three files, for illustrating the design:
- phonebook.ecore may be used for generating a corresponding xsd file.
- phonebook-services.ecore is used by my generator for generating the WSDL file.
- phonebook-services.wsdl is the desired/resulting WSDL file. BTW, this file has
a reference to a Ecore.xsd file in the same folder. This file can be found on
the org.eclipse.xsd plugin, I think.
Note that I haven't tried generating SOAP requests based on this design, yet.
I'm currently focusing on making the modeling feel natural. It may be changed if
I find out it is difficult (cumbersome) to generate the corresponding SOAP
requests, using EMF current XML support.
Hallvard
--------------040402080601090203000403
Content-Type: text/xml;
name="phonebook.ecore"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="phonebook.ecore"
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="phonebook"
nsURI="http:///phonebook.ecore" nsPrefix="pb">
<eClassifiers xsi:type="ecore:EClass" name="Person" eSuperTypes="#//PhoneNumbers">
<eStructuralFeatures xsi:type="ecore:EReference" name="personData" eType="#//PersonData"
containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Book">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="bid" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
iD="true"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="persons" upperBound="-1"
eType="#//Person" containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="PhoneNumber">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="role" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="type" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="data" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="PhoneNumbers">
<eStructuralFeatures xsi:type="ecore:EReference" name="phoneNumbers" upperBound="-1"
eType="#//PhoneNumber" containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Persons">
<eStructuralFeatures xsi:type="ecore:EReference" name="personData" upperBound="-1"
eType="#//PersonData"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="PersonData">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="pid" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
iD="true"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
</ecore:EPackage>
--------------040402080601090203000403
Content-Type: text/xml;
name="phonebook-services.wsdl"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="phonebook-services.wsdl"
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iQVNDSUkiPz4NCjx3c2Rs OmRlZmluaXRp
b25zIHhtaTp2ZXJzaW9uPSIyLjAiIHhtbG5zOnhtaT0iaHR0cDovL3d3dy5v bWcub3JnL1hN
SSIgeG1sbnM6WE1MU2NoZW1hPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hN TFNjaGVtYSIg
eG1sbnM6ZWNvcmU9Imh0dHA6Ly93d3cuZWNsaXBzZS5vcmcvZW1mLzIwMDIv RWNvcmUiIHht
bG5zOnBiPSJodHRwOi8vL3Bob25lYm9vay5lY29yZSIgeG1sbnM6cGJzPSJo dHRwOi8vL3Bo
b25lYm9vay9zZXJ2aWNlcy5lY29yZSIgeG1sbnM6c29hcD0iaHR0cDovL3Nj aGVtYXMueG1s
c29hcC5vcmcvc29hcC8iIHhtbG5zOndzZGw9Imh0dHA6Ly9zY2hlbWFzLnht bHNvYXAub3Jn
L3dzZGwvIiB0YXJnZXROYW1lc3BhY2U9Imh0dHA6Ly8vcGhvbmVib29rL3Nl cnZpY2VzLmVj
b3JlIj4NCiAgPHdzZGw6dHlwZXM+DQogICAgPFhNTFNjaGVtYTpzY2hlbWEg dGFyZ2V0TmFt
ZXNwYWNlPSJodHRwOi8vL3Bob25lYm9vay9zZXJ2aWNlcy5lY29yZSI+DQog ICAgICA8WE1M
U2NoZW1hOmltcG9ydCBuYW1lc3BhY2U9Imh0dHA6Ly93d3cuZWNsaXBzZS5v cmcvZW1mLzIw
MDIvRWNvcmUiIHNjaGVtYUxvY2F0aW9uPSJFY29yZS54c2QiLz4NCiAgICAg IDxYTUxTY2hl
bWE6aW1wb3J0IG5hbWVzcGFjZT0iaHR0cDovLy9waG9uZWJvb2suZWNvcmUi IHNjaGVtYUxv
Y2F0aW9uPSJwaG9uZWJvb2sueHNkIi8+DQogICAgICA8WE1MU2NoZW1hOmVs ZW1lbnQgbmFt
ZT0ibWFueUVTdHJpbmciPg0KICAgICAgICA8WE1MU2NoZW1hOmNvbXBsZXhU eXBlPg0KICAg
ICAgICAgIDxYTUxTY2hlbWE6c2VxdWVuY2U+DQogICAgICAgICAgICA8WE1M U2NoZW1hOmVs
ZW1lbnQgbWluT2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIgbmFt ZT0iRVN0cmlu
ZyIgdHlwZT0iZWNvcmU6RVN0cmluZyIvPjwvWE1MU2NoZW1hOnNlcXVlbmNl PjwvWE1MU2No
ZW1hOmNvbXBsZXhUeXBlPjwvWE1MU2NoZW1hOmVsZW1lbnQ+PC9YTUxTY2hl bWE6c2NoZW1h
Pg0KICA8L3dzZGw6dHlwZXM+DQogIDx3c2RsOm1lc3NhZ2UgbmFtZT0iYWRk UGVyc29uU29h
cEluIj4NCiAgICA8d3NkbDpwYXJ0IG5hbWU9ImJvb2siIHR5cGU9ImVjb3Jl OkVTdHJpbmci
Lz4NCiAgICA8d3NkbDpwYXJ0IG5hbWU9Im5hbWUiIHR5cGU9ImVjb3JlOkVT dHJpbmciLz4N
CiAgPC93c2RsOm1lc3NhZ2U+DQogIDx3c2RsOm1lc3NhZ2UgbmFtZT0iYWRk UGVyc29uU29h
cE91dCI+DQogICAgPHdzZGw6cGFydCBuYW1lPSJ2YWx1ZSIgdHlwZT0iZWNv cmU6RVN0cmlu
ZyIvPg0KICA8L3dzZGw6bWVzc2FnZT4NCiAgPHdzZGw6bWVzc2FnZSBuYW1l PSJzZXRQaG9u
ZU51bWJlclNvYXBJbiI+DQogICAgPHdzZGw6cGFydCBuYW1lPSJib29rIiB0 eXBlPSJlY29y
ZTpFU3RyaW5nIi8+DQogICAgPHdzZGw6cGFydCBuYW1lPSJwZXJzb24iIHR5 cGU9ImVjb3Jl
OkVTdHJpbmciLz4NCiAgICA8d3NkbDpwYXJ0IG5hbWU9Im51bWJlciIgdHlw ZT0icGI6UGhv
bmVOdW1iZXIiLz4NCiAgPC93c2RsOm1lc3NhZ2U+DQogIDx3c2RsOm1lc3Nh Z2UgbmFtZT0i
c2V0UGhvbmVOdW1iZXJTb2FwT3V0Ij4NCiAgICA8d3NkbDpwYXJ0IG5hbWU9 InZhbHVlIiB0
eXBlPSJlY29yZTpFQm9vbGVhbiIvPg0KICA8L3dzZGw6bWVzc2FnZT4NCiAg PHdzZGw6bWVz
c2FnZSBuYW1lPSJnZXRQaG9uZU51bWJlclNvYXBJbiI+DQogICAgPHdzZGw6 cGFydCBuYW1l
PSJib29rIiB0eXBlPSJlY29yZTpFU3RyaW5nIi8+DQogICAgPHdzZGw6cGFy dCBuYW1lPSJw
ZXJzb24iIHR5cGU9ImVjb3JlOkVTdHJpbmciLz4NCiAgICA8d3NkbDpwYXJ0 IG5hbWU9InJv
bGUiIHR5cGU9ImVjb3JlOkVTdHJpbmciLz4NCiAgPC93c2RsOm1lc3NhZ2U+ DQogIDx3c2Rs
Om1lc3NhZ2UgbmFtZT0iZ2V0UGhvbmVOdW1iZXJTb2FwT3V0Ij4NCiAgICA8 d3NkbDpwYXJ0
IG5hbWU9InZhbHVlIiB0eXBlPSJlY29yZTpFU3RyaW5nIi8+DQogIDwvd3Nk bDptZXNzYWdl
Pg0KICA8d3NkbDptZXNzYWdlIG5hbWU9ImdldEFsbFBob25lTnVtYmVyc1Nv YXBJbiI+DQog
ICAgPHdzZGw6cGFydCBuYW1lPSJib29rIiB0eXBlPSJlY29yZTpFU3RyaW5n Ii8+DQogICAg
PHdzZGw6cGFydCBuYW1lPSJwZXJzb24iIHR5cGU9ImVjb3JlOkVTdHJpbmci Lz4NCiAgICA8
d3NkbDpwYXJ0IG5hbWU9InJvbGUiIHR5cGU9ImVjb3JlOkVTdHJpbmciLz4N CiAgPC93c2Rs
Om1lc3NhZ2U+DQogIDx3c2RsOm1lc3NhZ2UgbmFtZT0iZ2V0QWxsUGhvbmVO dW1iZXJzU29h
cE91dCI+DQogICAgPHdzZGw6cGFydCBuYW1lPSJ2YWx1ZSIgdHlwZT0icGI6 UGhvbmVOdW1i
ZXJzIi8+DQogIDwvd3NkbDptZXNzYWdlPg0KICA8d3NkbDptZXNzYWdlIG5h bWU9ImdldEFs
bFBlcnNvbnNTb2FwSW4iPg0KICAgIDx3c2RsOnBhcnQgbmFtZT0iYm9vayIg dHlwZT0iZWNv
cmU6RVN0cmluZyIvPg0KICA8L3dzZGw6bWVzc2FnZT4NCiAgPHdzZGw6bWVz c2FnZSBuYW1l
PSJnZXRBbGxQZXJzb25zU29hcE91dCI+DQogICAgPHdzZGw6cGFydCBuYW1l PSJ2YWx1ZSIg
dHlwZT0icGI6UGVyc29ucyIvPg0KICA8L3dzZGw6bWVzc2FnZT4NCiAgPHdz ZGw6bWVzc2Fn
ZSBuYW1lPSJmaW5kUGVyc29uc1NvYXBJbiI+DQogICAgPHdzZGw6cGFydCBu YW1lPSJib29r
IiB0eXBlPSJlY29yZTpFU3RyaW5nIi8+DQogICAgPHdzZGw6cGFydCBuYW1l PSJxdWVyaWVz
IiBlbGVtZW50PSJwYnM6bWFueUVTdHJpbmciLz4NCiAgPC93c2RsOm1lc3Nh Z2U+DQogIDx3
c2RsOm1lc3NhZ2UgbmFtZT0iZmluZFBlcnNvbnNTb2FwT3V0Ij4NCiAgICA8 d3NkbDpwYXJ0
IG5hbWU9InZhbHVlIiB0eXBlPSJwYjpQZXJzb25zIi8+DQogIDwvd3NkbDpt ZXNzYWdlPg0K
ICA8d3NkbDpwb3J0VHlwZSBuYW1lPSJJUGhvbmVCb29rIj4NCiAgICA8d3Nk bDpvcGVyYXRp
b24gbmFtZT0iYWRkUGVyc29uIj4NCiAgICAgIDx3c2RsOmlucHV0IG1lc3Nh Z2U9InBiczph
ZGRQZXJzb25Tb2FwSW4iLz4NCiAgICAgIDx3c2RsOm91dHB1dCBtZXNzYWdl PSJwYnM6YWRk
UGVyc29uU29hcE91dCIvPg0KICAgIDwvd3NkbDpvcGVyYXRpb24+DQogICAg PHdzZGw6b3Bl
cmF0aW9uIG5hbWU9InNldFBob25lTnVtYmVyIj4NCiAgICAgIDx3c2RsOmlu cHV0IG1lc3Nh
Z2U9InBiczpzZXRQaG9uZU51bWJlclNvYXBJbiIvPg0KICAgICAgPHdzZGw6 b3V0cHV0IG1l
c3NhZ2U9InBiczpzZXRQaG9uZU51bWJlclNvYXBPdXQiLz4NCiAgICA8L3dz ZGw6b3BlcmF0
aW9uPg0KICAgIDx3c2RsOm9wZXJhdGlvbiBuYW1lPSJnZXRQaG9uZU51bWJl ciI+DQogICAg
ICA8d3NkbDppbnB1dCBtZXNzYWdlPSJwYnM6Z2V0UGhvbmVOdW1iZXJTb2Fw SW4iLz4NCiAg
ICAgIDx3c2RsOm91dHB1dCBtZXNzYWdlPSJwYnM6Z2V0UGhvbmVOdW1iZXJT b2FwT3V0Ii8+
DQogICAgPC93c2RsOm9wZXJhdGlvbj4NCiAgICA8d3NkbDpvcGVyYXRpb24g bmFtZT0iZ2V0
QWxsUGhvbmVOdW1iZXJzIj4NCiAgICAgIDx3c2RsOmlucHV0IG1lc3NhZ2U9 InBiczpnZXRB
bGxQaG9uZU51bWJlcnNTb2FwSW4iLz4NCiAgICAgIDx3c2RsOm91dHB1dCBt ZXNzYWdlPSJw
YnM6Z2V0QWxsUGhvbmVOdW1iZXJzU29hcE91dCIvPg0KICAgIDwvd3NkbDpv cGVyYXRpb24+
DQogICAgPHdzZGw6b3BlcmF0aW9uIG5hbWU9ImdldEFsbFBlcnNvbnMiPg0K ICAgICAgPHdz
ZGw6aW5wdXQgbWVzc2FnZT0icGJzOmdldEFsbFBlcnNvbnNTb2FwSW4iLz4N CiAgICAgIDx3
c2RsOm91dHB1dCBtZXNzYWdlPSJwYnM6Z2V0QWxsUGVyc29uc1NvYXBPdXQi Lz4NCiAgICA8
L3dzZGw6b3BlcmF0aW9uPg0KICAgIDx3c2RsOm9wZXJhdGlvbiBuYW1lPSJm aW5kUGVyc29u
cyI+DQogICAgICA8d3NkbDppbnB1dCBtZXNzYWdlPSJwYnM6ZmluZFBlcnNv bnNTb2FwSW4i
Lz4NCiAgICAgIDx3c2RsOm91dHB1dCBtZXNzYWdlPSJwYnM6ZmluZFBlcnNv bnNTb2FwT3V0
Ii8+DQogICAgPC93c2RsOm9wZXJhdGlvbj4NCiAgPC93c2RsOnBvcnRUeXBl Pg0KICA8d3Nk
bDpiaW5kaW5nIG5hbWU9IlBob25lQm9va0ltcGwiIHR5cGU9InBiczpJUGhv bmVCb29rIj4N
CiAgICA8c29hcDpiaW5kaW5nIHRyYW5zcG9ydD0iaHR0cDovL3NjaGVtYXMu eG1sc29hcC5v
cmcvc29hcC9odHRwIi8+DQogICAgPHdzZGw6b3BlcmF0aW9uIG5hbWU9ImFk ZFBlcnNvbiI+
DQogICAgICA8d3NkbDppbnB1dD4NCiAgICAgICAgPHNvYXA6aGVhZGVyLz4N CiAgICAgICAg
PHNvYXA6Ym9keSB1c2U9ImxpdGVyYWwiLz4NCiAgICAgIDwvd3NkbDppbnB1 dD4NCiAgICAg
IDx3c2RsOm91dHB1dD4NCiAgICAgICAgPHNvYXA6aGVhZGVyLz4NCiAgICAg ICAgPHNvYXA6
Ym9keSB1c2U9ImxpdGVyYWwiLz4NCiAgICAgIDwvd3NkbDpvdXRwdXQ+DQog ICAgPC93c2Rs
Om9wZXJhdGlvbj4NCiAgICA8d3NkbDpvcGVyYXRpb24gbmFtZT0ic2V0UGhv bmVOdW1iZXIi
Pg0KICAgICAgPHdzZGw6aW5wdXQ+DQogICAgICAgIDxzb2FwOmhlYWRlci8+ DQogICAgICAg
IDxzb2FwOmJvZHkgdXNlPSJsaXRlcmFsIi8+DQogICAgICA8L3dzZGw6aW5w dXQ+DQogICAg
ICA8d3NkbDpvdXRwdXQ+DQogICAgICAgIDxzb2FwOmhlYWRlci8+DQogICAg ICAgIDxzb2Fw
OmJvZHkgdXNlPSJsaXRlcmFsIi8+DQogICAgICA8L3dzZGw6b3V0cHV0Pg0K ICAgIDwvd3Nk
bDpvcGVyYXRpb24+DQogICAgPHdzZGw6b3BlcmF0aW9uIG5hbWU9ImdldFBo b25lTnVtYmVy
Ij4NCiAgICAgIDx3c2RsOmlucHV0Pg0KICAgICAgICA8c29hcDpoZWFkZXIv Pg0KICAgICAg
ICA8c29hcDpib2R5IHVzZT0ibGl0ZXJhbCIvPg0KICAgICAgPC93c2RsOmlu cHV0Pg0KICAg
ICAgPHdzZGw6b3V0cHV0Pg0KICAgICAgICA8c29hcDpoZWFkZXIvPg0KICAg ICAgICA8c29h
cDpib2R5IHVzZT0ibGl0ZXJhbCIvPg0KICAgICAgPC93c2RsOm91dHB1dD4N CiAgICA8L3dz
ZGw6b3BlcmF0aW9uPg0KICAgIDx3c2RsOm9wZXJhdGlvbiBuYW1lPSJnZXRB bGxQaG9uZU51
bWJlcnMiPg0KICAgICAgPHdzZGw6aW5wdXQ+DQogICAgICAgIDxzb2FwOmhl YWRlci8+DQog
ICAgICAgIDxzb2FwOmJvZHkgdXNlPSJsaXRlcmFsIi8+DQogICAgICA8L3dz ZGw6aW5wdXQ+
DQogICAgICA8d3NkbDpvdXRwdXQ+DQogICAgICAgIDxzb2FwOmhlYWRlci8+ DQogICAgICAg
IDxzb2FwOmJvZHkgdXNlPSJsaXRlcmFsIi8+DQogICAgICA8L3dzZGw6b3V0 cHV0Pg0KICAg
IDwvd3NkbDpvcGVyYXRpb24+DQogICAgPHdzZGw6b3BlcmF0aW9uIG5hbWU9 ImdldEFsbFBl
cnNvbnMiPg0KICAgICAgPHdzZGw6aW5wdXQ+DQogICAgICAgIDxzb2FwOmhl YWRlci8+DQog
ICAgICAgIDxzb2FwOmJvZHkgdXNlPSJsaXRlcmFsIi8+DQogICAgICA8L3dz ZGw6aW5wdXQ+
DQogICAgICA8d3NkbDpvdXRwdXQ+DQogICAgICAgIDxzb2FwOmhlYWRlci8+ DQogICAgICAg
IDxzb2FwOmJvZHkgdXNlPSJsaXRlcmFsIi8+DQogICAgICA8L3dzZGw6b3V0 cHV0Pg0KICAg
IDwvd3NkbDpvcGVyYXRpb24+DQogICAgPHdzZGw6b3BlcmF0aW9uIG5hbWU9 ImZpbmRQZXJz
b25zIj4NCiAgICAgIDx3c2RsOmlucHV0Pg0KICAgICAgICA8c29hcDpoZWFk ZXIvPg0KICAg
ICAgICA8c29hcDpib2R5IHVzZT0ibGl0ZXJhbCIvPg0KICAgICAgPC93c2Rs OmlucHV0Pg0K
ICAgICAgPHdzZGw6b3V0cHV0Pg0KICAgICAgICA8c29hcDpoZWFkZXIvPg0K ICAgICAgICA8
c29hcDpib2R5IHVzZT0ibGl0ZXJhbCIvPg0KICAgICAgPC93c2RsOm91dHB1 dD4NCiAgICA8
L3dzZGw6b3BlcmF0aW9uPg0KICA8L3dzZGw6YmluZGluZz4NCiAgPHdzZGw6 c2VydmljZSBu
YW1lPSJQaG9uZUJvb2tTZXJ2aWNlIj4NCiAgICA8d3NkbDpwb3J0IG5hbWU9 IklQaG9uZUJv
b2siIGJpbmRpbmc9InBiczpQaG9uZUJvb2tJbXBsIj4NCiAgICAgIDxzb2Fw OmFkZHJlc3Mg
bG9jYXRpb249Imh0dHA6Ly9leGFtcGxlLmNvbS8iLz4NCiAgICA8L3dzZGw6 cG9ydD4NCiAg
PC93c2RsOnNlcnZpY2U+DQo8L3dzZGw6ZGVmaW5pdGlvbnM+
--------------040402080601090203000403
Content-Type: text/xml;
name="phonebook-services.ecore"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="phonebook-services.ecore"
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="services"
nsURI="http:///phonebook/services.ecore" nsPrefix="pbs">
<eClassifiers xsi:type="ecore:EClass" name="IPhoneBook" abstract="true" interface="true">
<eOperations name="addPerson" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString">
<eParameters name="book" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eParameters name="name" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eOperations>
<eOperations name="setPhoneNumber" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean">
<eParameters name="book" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eParameters name="person" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eParameters name="number" eType="ecore:EClass phonebook.ecore#//PhoneNumber"/>
</eOperations>
<eOperations name="getPhoneNumber" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString">
<eParameters name="book" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eParameters name="person" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eParameters name="role" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eOperations>
<eOperations name="getAllPhoneNumbers" eType="ecore:EClass phonebook.ecore#//PhoneNumbers">
<eParameters name="book" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eParameters name="person" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eParameters name="role" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eOperations>
<eOperations name="getAllPersons" eType="ecore:EClass phonebook.ecore#//Persons">
<eParameters name="book" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eOperations>
<eOperations name="findPersons" eType="ecore:EClass phonebook.ecore#//Persons">
<eParameters name="book" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eParameters name="queries" upperBound="-1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eOperations>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="PhoneBookImpl" eSuperTypes="#//IPhoneBook">
<eAnnotations source="no.hal.soap">
<details key="binding/@transport" value="http://schemas.xmlsoap.org/soap/http"/>
<details key="body/@use" value="literal"/>
</eAnnotations>
<eOperations name="addPerson" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eOperations name="setPhoneNumber" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean"/>
<eOperations name="getPhoneNumber" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eOperations name="getAllPhoneNumbers" eType="ecore:EClass phonebook.ecore#//PhoneNumbers"/>
<eOperations name="getAllPersons" eType="ecore:EClass phonebook.ecore#//Persons"/>
<eOperations name="findPersons" eType="ecore:EClass phonebook.ecore#//Persons"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="PhoneBookService" eSuperTypes="#//PhoneBookImpl"/>
</ecore:EPackage>
--------------040402080601090203000403--
|
|
|
| Re: EMF, WSDL and SOAP [message #212410 is a reply to message #212409] |
Wed, 16 April 2008 11:54  |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hallvard,
Comments below.
Hallvard Trætteberg wrote:
> Hi,
>
> As mentioned in a previous post, I'm working on generating a web
> services description language (WSDL) file, from an EMF model of the
> services.
Cool.
> The idea is to model the domain and related services as a "standard"
> object-oriented model, and let EMF and my generator handle all the XML
> and WSDL encoding stuff.
Which is all complex crap that a real busy programmer would rather not
precious spend time on.
> I thought I'd share the current design with you all, so I can get
> comments before I put too much effort into the code. Sorry if this
> really should be sent to another newsgroup...
It sounds like folks on both groups are likely to be interested.
>
> First some words about WSDL (as far as I understand). A WSDL file is
> typically composed of several elements:
> - An XML schema part, which defines and/or imports type definitions.
> This essentially defines how domain objects (types) are described
> using XML. EMF already has tools for generating XML schemas for Ecore
> models (export a genmodel as XML schema).
Yes, I think EcoreSchemaBuilder is pretty good. It's designed to be
able to round trip Ecore -> XSD -> Ecore... XSD -> Ecore -> XSD isn't
generally a perfect round trip, but of course if you have a schema
already, there's not much need to generate one.
> - A "port type" part. A port type is similar to an interface, in that
> it defines a set of abstract operations. Each operation in turn
> defines the input and output by means of the (structure of) the
> messages that are exchanged.
Sounds a lot like an EClass with EOperations, doesn't it...
> The messages refer to the types (and elements) defined in the XML
> schema part (explicitly defined or imported).
Sounds like more EClasses with features typed by other EClasses and
EDataTypes...
> - A binding part, which defines how the operations of a port type
> actually are implemented. Implemented means what communication
> protocol is used (and how) to exchange the relevant messages for
> invoking operations.
I suppose this could be used to declaratively define the EOperation
bodies that are generated...
>
> - A service part, which defines where (server address) a set of
> bindings are handled.
I guess the generated code would use this to communicate with a specific
address.
>
> My current design is as follows:
>
> The domain model is modeled in the usual way, as an Ecore model with
> classes, references and attributes, e.g. in a domain.ecore. The
> services models is modeled in its own model, e.g. domain-services,
> with references to the domain model, using the Load resource... trick.
> I've chosen to split the models in this way for two reasons: 1) These
> two models should be in their own packages, so they get separate
> namespaces. 2) It is easier to invoke the generator (an IFile action)
> if the services are in their own file.
I hope Thiago soon starts to do something active in CVS with
http://wiki.eclipse.org/Servus. I imagine it's possible to use Ecore
itself to model the services part, using EAnnotations to identity things
that are acting as messages and services....
>
> The services model has three kinds of classes:
You mean actual EClasses here?
> - A "port type" class is a class marked as interface (and abstract).
> Such a class contains operations only. A port type class is mapped to
> a WSDL port type.
> - A "binding" class is a class that is a subclass of a single port
> type class. Such a class contains the same operations as the port type
> class, but may omit the parameters.
So there's no operation overloading issues with WSDL...
> The operations are (just) used as placeholders for annotations, which
> are used to include information of the protocols used by the binding.
> - A "service" class is a class that is a subclass of a set of binding
> classes. It is also a placeholder for annotations that add protocol
> information. A service class is mapped to a WSDL service.
This all seems like quite a clean simple mapping.
>
> I've attached three files, for illustrating the design:
> - phonebook.ecore may be used for generating a corresponding xsd file.
> - phonebook-services.ecore is used by my generator for generating the
> WSDL file.
> - phonebook-services.wsdl is the desired/resulting WSDL file. BTW,
> this file has a reference to a Ecore.xsd file in the same folder. This
> file can be found on the org.eclipse.xsd plugin, I think.
It's in platform:/plugin/org.eclipse.emf.ecore/model/Ecore.xsd. Note
that if your Ecore model uses types from the XMLTypePackage, i.e.,
XMLTypePackage.Literals.STRING, instead of
EcorePackage.Literals.ESTRING, the the XML Schema you generate will use
XML Schema built-in types instead of needing to refer to Ecore.xsd.
This will make your examples seem prettier for the w3c-centric folks...
>
> Note that I haven't tried generating SOAP requests based on this
> design, yet. I'm currently focusing on making the modeling feel
> natural. It may be changed if I find out it is difficult (cumbersome)
> to generate the corresponding SOAP requests, using EMF current XML
> support.
This seems all very nice to me. Very cool stuff! This work does relate
very closely to Servus. I wonder if you'd be interested in hosting this
work at Eclipse perhaps as part of the Servus component?
>
> Hallvard
|
|
| |
| Re: EMF, WSDL and SOAP [message #212427 is a reply to message #212410] |
Wed, 16 April 2008 21:34 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Ed Merks wrote:
> Hallvard,
>
>> The idea is to model the domain and related services as a "standard"
>> object-oriented model, and let EMF and my generator handle all the XML
>> and WSDL encoding stuff.
> Which is all complex crap that a real busy programmer would rather not
> precious spend time on.
That's one way of putting it :-)
>> - A "port type" part. A port type is similar to an interface, ...
> Sounds a lot like an EClass with EOperations, doesn't it...
You've already guessed it all...
> I suppose this could be used to declaratively define the EOperation
> bodies that are generated...
I'm not trying to generate more than the WSDL file. There's already tools that
can generate stubs for both the client and server, based on WSDL. Of course,
with more information in the service model, more of the implementation code may
be generated, too.
>> The services model has three kinds of classes:
> You mean actual EClasses here?
Of course, as you see in the example models.
> So there's no operation overloading issues with WSDL...
I think overloading is allowed, using names of input and output messages to
differentiate between them. I haven't a real understanding of this, yet, so I
have to look into this problem later.
> This all seems like quite a clean simple mapping.
The goal is twofold: 1) define a way of using Ecore that feels natural and
simple and 2) to keep the mapping simple, so I don't invent a new language that
needs a lot of complex tools. I assume it will grow big enough, when the
shortcomings and weaknesses are identified.
> It's in platform:/plugin/org.eclipse.emf.ecore/model/Ecore.xsd. Note
> that if your Ecore model uses types from the XMLTypePackage, i.e.,
> XMLTypePackage.Literals.STRING, instead of
I found XMLType.ecore in the same plugin. You mean to e.g. replace EString with
String? I notice there are two of each type (name) in the type dropdown, do you
know why?
> This seems all very nice to me. Very cool stuff! This work does relate
> very closely to Servus. I wonder if you'd be interested in hosting this
> work at Eclipse perhaps as part of the Servus component?
Fine with me. Whatever makes it most useful. What should I do?
Hallvard
|
|
|
| Re: EMF, WSDL and SOAP [message #212430 is a reply to message #212427] |
Wed, 16 April 2008 23:23 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hallvard,
When Thiago becomes active in May, I'll get him to follow up on this
thread to contact you.
Hallvard Trætteberg wrote:
> Ed Merks wrote:
>> Hallvard,
>>
>>> The idea is to model the domain and related services as a "standard"
>>> object-oriented model, and let EMF and my generator handle all the
>>> XML and WSDL encoding stuff.
>> Which is all complex crap that a real busy programmer would rather
>> not precious spend time on.
>
> That's one way of putting it :-)
>
>>> - A "port type" part. A port type is similar to an interface, ...
>> Sounds a lot like an EClass with EOperations, doesn't it...
>
> You've already guessed it all...
>
>> I suppose this could be used to declaratively define the EOperation
>> bodies that are generated...
>
> I'm not trying to generate more than the WSDL file. There's already
> tools that can generate stubs for both the client and server, based on
> WSDL. Of course, with more information in the service model, more of
> the implementation code may be generated, too.
>
>>> The services model has three kinds of classes:
>> You mean actual EClasses here?
>
> Of course, as you see in the example models.
>
> > So there's no operation overloading issues with WSDL...
>
> I think overloading is allowed, using names of input and output
> messages to differentiate between them. I haven't a real understanding
> of this, yet, so I have to look into this problem later.
>
>> This all seems like quite a clean simple mapping.
>
> The goal is twofold: 1) define a way of using Ecore that feels natural
> and simple and 2) to keep the mapping simple, so I don't invent a new
> language that needs a lot of complex tools. I assume it will grow big
> enough, when the shortcomings and weaknesses are identified.
>
>> It's in platform:/plugin/org.eclipse.emf.ecore/model/Ecore.xsd. Note
>> that if your Ecore model uses types from the XMLTypePackage, i.e.,
>> XMLTypePackage.Literals.STRING, instead of
>
> I found XMLType.ecore in the same plugin. You mean to e.g. replace
> EString with String? I notice there are two of each type (name) in the
> type dropdown, do you know why?
>
>> This seems all very nice to me. Very cool stuff! This work does
>> relate very closely to Servus. I wonder if you'd be interested in
>> hosting this work at Eclipse perhaps as part of the Servus component?
>
> Fine with me. Whatever makes it most useful. What should I do?
>
> Hallvard
|
|
|
| Re: EMF, WSDL and SOAP [message #212434 is a reply to message #212409] |
Thu, 17 April 2008 01:41 |
| Eclipse User |
|
|
|
Originally posted by: ttonelli.uwaterloo.ca
Hi Hallvard,
nice to know that somebody is interested in the same things I am! We are
actually working on the same task: I am also implementing a mapping
between WSDL and Ecore models which is similar to yours. Let me explain
the differences of our approaches and give my opinion on those
differences so that we can discuss what are the best options.
The main similarity is that we both want to generate separate models for
the data and services. What you call "domain", I call simply "data
model" and I also use standard EMF tools to generate Ecore/XSD for it.
The service model is what I call "servus models" (in the plural because
I create a model for each targetNamespace in the WSDL) and they encode
basically the same information that you have in the WSDL.
The two main differences I see are:
1) when designing the service model I am also taking into consideration
WSDL 2.0. There are some small differences between WSDL 1.1 and WSDL 2.0
that go beyond renaming PortType to interface. For example, in WSDL 2.0
it is possible to declare "generic bindings" which don't apply
specifically to a certain interface (PortType). So, when creating the
mappings, I am also thinking about those issues.
2) the problem I see with the way your mapping works is that it
resembles too much the WSDL. I am trying to avoid that because of the
following reasons:
i) if I just want a nice interface to manipulate the WSDL with its own
abstractions (interfaces, bindings, services, etc), I can use WTP
editors for that, and
ii) imagine the other way around, generating WSDL from an existing Ecore
model: you already have a model with a certain EClass with some
operations and you want to expose them as Web Services. Using your
mapping you would have to create two other EClasses (which ones depend
if your already existing class will be the service, binding or
interfaces) and put them in an inheritance relationship. Furthermore,
you have many repetition of information (the operations for example, are
repeated in the interface and the binding).
I solved this situation in my mapping by using annotations. First, I
define a metamodel (another ecore model) with "Servus Annotations",
which are similar to JAX-WS annotations (with things like WebService,
WebBinding, etc). Second, I map a PortType to an EClass with the
corresponding EOperations. The remaining information is basically
encoded in annotations to this EClass and its EOperations (there are
some weird cases when I might want to do some sub-classing, but I will
omit details for now). This way I can model my service thinking about
the operations it has (and the operation's parameters). Then, if all I
want is to use default things (like SOAP, Doc/Literal, etc), I just
annotate the EClass with WebEndpoint giving the http address as
parameter and the mapping will be able to generate WSDL with all the
defaults. The same way, if my WSDL has only default things, the
generated service model will look very simple (because I omit
annotations that are defaults).
What do you think about this approach? Does it suit your needs?
About development. I have a WSDL to Ecore mapping almost working.
Because I am trying to do something very generic, that works for every
crazy thing people might do in WSDLs, it took me some time to think
about how to deal with all namespaces, imports, input/output patterns,
etc. However, I believe I will have a first working version on CVS by
the end of this week (Sunday). The next step will be to implement the
Ecore to WSDL mapping, but I cannot promise to have it done before May.
Note that with these mappings implemented, we can map WSDLv1 <-> Ecore
models (data + service), but we cannot do much with the artifacts. Of
course we could generate the java classes for the data model and a
server skeleton from the service EClass, but the next step would be to
implement the generation of client stubs and also a reliable data
binding (so that we can pass EObjects as parameters/return types).
That's what I will be doing this summer.
Sorry for the long email and I would appreciate to hear your opinion.
Cheers,
Thiago
Hallvard Trætteberg wrote:
> Hi,
>
> As mentioned in a previous post, I'm working on generating a web
> services description language (WSDL) file, from an EMF model of the
> services. The idea is to model the domain and related services as a
> "standard" object-oriented model, and let EMF and my generator handle
> all the XML and WSDL encoding stuff. I thought I'd share the current
> design with you all, so I can get comments before I put too much effort
> into the code. Sorry if this really should be sent to another newsgroup...
>
> First some words about WSDL (as far as I understand). A WSDL file is
> typically composed of several elements:
> - An XML schema part, which defines and/or imports type definitions.
> This essentially defines how domain objects (types) are described using
> XML. EMF already has tools for generating XML schemas for Ecore models
> (export a genmodel as XML schema).
> - A "port type" part. A port type is similar to an interface, in that it
> defines a set of abstract operations. Each operation in turn defines the
> input and output by means of the (structure of) the messages that are
> exchanged. The messages refer to the types (and elements) defined in the
> XML schema part (explicitly defined or imported).
> - A binding part, which defines how the operations of a port type
> actually are implemented. Implemented means what communication protocol
> is used (and how) to exchange the relevant messages for invoking
> operations.
> - A service part, which defines where (server address) a set of bindings
> are handled.
>
> My current design is as follows:
>
> The domain model is modeled in the usual way, as an Ecore model with
> classes, references and attributes, e.g. in a domain.ecore. The services
> models is modeled in its own model, e.g. domain-services, with
> references to the domain model, using the Load resource... trick. I've
> chosen to split the models in this way for two reasons: 1) These two
> models should be in their own packages, so they get separate namespaces.
> 2) It is easier to invoke the generator (an IFile action) if the
> services are in their own file.
>
> The services model has three kinds of classes:
> - A "port type" class is a class marked as interface (and abstract).
> Such a class contains operations only. A port type class is mapped to a
> WSDL port type.
> - A "binding" class is a class that is a subclass of a single port type
> class. Such a class contains the same operations as the port type class,
> but may omit the parameters. The operations are (just) used as
> placeholders for annotations, which are used to include information of
> the protocols used by the binding.
> - A "service" class is a class that is a subclass of a set of binding
> classes. It is also a placeholder for annotations that add protocol
> information. A service class is mapped to a WSDL service.
>
> I've attached three files, for illustrating the design:
> - phonebook.ecore may be used for generating a corresponding xsd file.
> - phonebook-services.ecore is used by my generator for generating the
> WSDL file.
> - phonebook-services.wsdl is the desired/resulting WSDL file. BTW, this
> file has a reference to a Ecore.xsd file in the same folder. This file
> can be found on the org.eclipse.xsd plugin, I think.
>
> Note that I haven't tried generating SOAP requests based on this design,
> yet. I'm currently focusing on making the modeling feel natural. It may
> be changed if I find out it is difficult (cumbersome) to generate the
> corresponding SOAP requests, using EMF current XML support.
>
> Hallvard
>
|
|
|
| Re: EMF, WSDL and SOAP [message #212439 is a reply to message #212434] |
Thu, 17 April 2008 08:53 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Thank you for taking time to explain your approach. You have a broader goal and
a more generic approach than I have. But as you say, we are both interested in
the same thing. You have a lot more knowledge about this than I have, and to
some extent that explains why my approach is more narrow: I want to try to
handle simple cases first, to learn more about the general issues and problems.
Hopefully, by increasing my understanding, I can be of more help to you and the
community.
BTW, I'm doing this in the context of user interface modeling (see
http://www.idi.ntnu.no/~hal/research) and BPM with Intalio's tools. What they
lack is 1) user interface modeling, which is my main field of research, and 2)
architecture and tools for server-based data management. Both Servus and CDO
seems to be relevant for the latter.
You'll find more comments below:
Thiago Tonelli Bartolomei wrote:
>
> The two main differences I see are:
>
> 1) when designing the service model I am also taking into consideration WSDL 2.0.
I've just started understanding some simple WSDL examples, which I guess are
WSDL 1.1, and have not considered WSDL 2.0.
> 2) the problem I see with the way your mapping works is that it
> resembles too much the WSDL.
Yes, I tried to make a natural mapping from WSDL to Ecore: PortTypes are
interfaces and Bindings are implementations. The result has the content of a
WSDL with the look and feel of Ecore :-)
> I solved this situation in my mapping by using annotations. First, I
> define a metamodel (another ecore model) with "Servus Annotations",
> which are similar to JAX-WS annotations (with things like WebService,
> WebBinding, etc). Second, I map a PortType to an EClass with the
> corresponding EOperations. The remaining information is basically
> encoded in annotations to this EClass and its EOperations
Do you think it is correct to say that you "weave" the Binding information into
the PortType, as annotations?
I think the most important point is having an explicit service interface, since
the data model is generally not suitable for this. In my mental model, a service
is a new kind of object, of which there is usually few instances, managing the
"real" objects. E.g. instead of an operation Book.remove(Person) you have
BookService.removePerson(Book, Person). The set of operations exposed by the
service is based on the real objects', but need to be designed differently (e.g.
more information hiding).
In your approach, you avoid having an explicit Binding EClass, which is good,
since this can be considered a WSDL artifact and not very interesting conceptually.
> What do you think about this approach? Does it suit your needs?
Yes! I think it's fairly easy to simplify my approach to work in the same way,
after having yours explained :-)
> About development. I have a WSDL to Ecore mapping almost working.
> Because I am trying to do something very generic, that works for every
> crazy thing people might do in WSDLs, it took me some time to think
> about how to deal with all namespaces, imports, input/output patterns,
> etc. However, I believe I will have a first working version on CVS by
> the end of this week (Sunday).
I would guess the WSDL to Ecore mapping is the most difficult one, meaning
you've come pretty far!
> The next step will be to implement the
> Ecore to WSDL mapping, but I cannot promise to have it done before May.
Do you think I can be of any help, if I could get a deep enough understanding of
WSDL 1.1/2.0 and your approach? Would it be possible for you to remodel my
example with your approach? This would let me get a better understanding of
yours, I think.
> Note that with these mappings implemented, we can map WSDLv1 <-> Ecore
> models (data + service), but we cannot do much with the artifacts. Of
> course we could generate the java classes for the data model and a
> server skeleton from the service EClass, but the next step would be to
> implement the generation of client stubs and also a reliable data
> binding (so that we can pass EObjects as parameters/return types).
> That's what I will be doing this summer.
Yes, the actual implementation of the data model's logic remains. As mentioned
above, the service interface is often based on the data model's. E.g. sometimes
service.removePerson(book, person) is just a wrapper for book.remove(person). Do
you think OCL could have role here, for describing the service logic?
Concerning databinding: In my mental model, the server/service manages a set of
connected resources, that provides a context for the messages sent to and from
the service. When sending e.g. a Person as a parameter, you can either model it
as a Person's id parameter (a string), and look it up manually, or model it as a
Person, and actually send the URI fragment for the Person in a Resource. The
latter is more elegant, but requires more of the framework. I think if this is
done correctly, EMF will handle most if not all of the details. In my
understanding, this is CDO's approach (?), although it uses its own connection
mechanism (net4j?) instead of SOAP messaging.
We may need is an Ecore model of (a) SOAP (message), so we can build messages as
EObjects (structures) and just serialize them, letting EMF's XML support handle
all the details. In the context of BPMN, it is important to know the actual XML
(serialization) format used, since a BPMN model only support XML as data, which
in our approach equals serialized EObject structures.
A side note: I've been planning to use Javascript and e4x for a quick and dirty
solution for both the client and server side, as described in
http://www.ibm.com/developerworks/webservices/library/ws-aja x1/ and
..../ws-ajax2/. Since I'm already using Javascript this may provide a quick and
flexible solution.
Hallvard
|
|
|
| Re: EMF, WSDL and SOAP [message #212475 is a reply to message #212439] |
Fri, 18 April 2008 03:20 |
| Eclipse User |
|
|
|
Originally posted by: ttonelli.uwaterloo.ca
Hi Hallvard,
Hallvard Trætteberg wrote:
> Thank you for taking time to explain your approach. You have a broader
> goal and a more generic approach than I have. But as you say, we are
> both interested in the same thing. You have a lot more knowledge about
> this than I have, and to some extent that explains why my approach is
> more narrow: I want to try to handle simple cases first, to learn more
> about the general issues and problems. Hopefully, by increasing my
> understanding, I can be of more help to you and the community.
>
> BTW, I'm doing this in the context of user interface modeling (see
> http://www.idi.ntnu.no/~hal/research) and BPM with Intalio's tools. What
> they lack is 1) user interface modeling, which is my main field of
> research, and 2) architecture and tools for server-based data
> management. Both Servus and CDO seems to be relevant for the latter.
>
nice. I have to take a closer look at Intalio, seems interesting.
> You'll find more comments below:
>
> Thiago Tonelli Bartolomei wrote:
>>
>> The two main differences I see are:
>>
>> 1) when designing the service model I am also taking into
>> consideration WSDL 2.0.
>
> I've just started understanding some simple WSDL examples, which I guess
> are WSDL 1.1, and have not considered WSDL 2.0.
>
Yes, most of people are still using WSDL 1.1, but at some point they
will probably migrate to WSDL 2.0.
>> 2) the problem I see with the way your mapping works is that it
>> resembles too much the WSDL.
>
> Yes, I tried to make a natural mapping from WSDL to Ecore: PortTypes are
> interfaces and Bindings are implementations. The result has the content
> of a WSDL with the look and feel of Ecore :-)
>
>> I solved this situation in my mapping by using annotations. First, I
>> define a metamodel (another ecore model) with "Servus Annotations",
>> which are similar to JAX-WS annotations (with things like WebService,
>> WebBinding, etc). Second, I map a PortType to an EClass with the
>> corresponding EOperations. The remaining information is basically
>> encoded in annotations to this EClass and its EOperations
>
> Do you think it is correct to say that you "weave" the Binding
> information into the PortType, as annotations?
>
You can call it "weaving" when I am automatically generating the Ecore
models from the WSDL. But if I have the models and I want to expose web
services, I would prefer "decorating the model" instead ;-)
> I think the most important point is having an explicit service
> interface, since the data model is generally not suitable for this. In
> my mental model, a service is a new kind of object, of which there is
> usually few instances, managing the "real" objects. E.g. instead of an
> operation Book.remove(Person) you have BookService.removePerson(Book,
> Person). The set of operations exposed by the service is based on the
> real objects', but need to be designed differently (e.g. more
> information hiding).
>
Agree. That's what the service models are for.
> In your approach, you avoid having an explicit Binding EClass, which is
> good, since this can be considered a WSDL artifact and not very
> interesting conceptually.
>
>> What do you think about this approach? Does it suit your needs?
>
> Yes! I think it's fairly easy to simplify my approach to work in the
> same way, after having yours explained :-)
>
>> About development. I have a WSDL to Ecore mapping almost working.
>> Because I am trying to do something very generic, that works for every
>> crazy thing people might do in WSDLs, it took me some time to think
>> about how to deal with all namespaces, imports, input/output patterns,
>> etc. However, I believe I will have a first working version on CVS by
>> the end of this week (Sunday).
>
> I would guess the WSDL to Ecore mapping is the most difficult one,
> meaning you've come pretty far!
>
This is a though part, but I am not sure that this is the most
complicated one. I still think that making the serialization work
properly for all possible cases of SOAP binding will also be hard (and I
will start with the WS-I profile only).
>> The next step will be to implement the
>> Ecore to WSDL mapping, but I cannot promise to have it done before May.
>
> Do you think I can be of any help, if I could get a deep enough
> understanding of WSDL 1.1/2.0 and your approach? Would it be possible
> for you to remodel my example with your approach? This would let me get
> a better understanding of yours, I think.
>
Let me just finish some details of my implementation and I will apply it
on your example. I noticed that you haven't sent the phonebook.xsd file,
but I generated that from you Ecore models and I think it will work
properly.
>> Note that with these mappings implemented, we can map WSDLv1 <-> Ecore
>> models (data + service), but we cannot do much with the artifacts. Of
>> course we could generate the java classes for the data model and a
>> server skeleton from the service EClass, but the next step would be to
>> implement the generation of client stubs and also a reliable data
>> binding (so that we can pass EObjects as parameters/return types).
>> That's what I will be doing this summer.
>
> Yes, the actual implementation of the data model's logic remains. As
> mentioned above, the service interface is often based on the data
> model's. E.g. sometimes service.removePerson(book, person) is just a
> wrapper for book.remove(person). Do you think OCL could have role here,
> for describing the service logic?
>
I am not sure how OCL would fit here. For sure we can write
implementation code into the model and the generation would create the
EOperations' bodies, but I am not sure what role would OCL play here.
> Concerning databinding: In my mental model, the server/service manages a
> set of connected resources, that provides a context for the messages
> sent to and from the service. When sending e.g. a Person as a parameter,
> you can either model it as a Person's id parameter (a string), and look
> it up manually, or model it as a Person, and actually send the URI
> fragment for the Person in a Resource. The latter is more elegant, but
> requires more of the framework. I think if this is done correctly, EMF
> will handle most if not all of the details. In my understanding, this is
> CDO's approach (?), although it uses its own connection mechanism
> (net4j?) instead of SOAP messaging.
>
> We may need is an Ecore model of (a) SOAP (message), so we can build
> messages as EObjects (structures) and just serialize them, letting EMF's
> XML support handle all the details. In the context of BPMN, it is
> important to know the actual XML (serialization) format used, since a
> BPMN model only support XML as data, which in our approach equals
> serialized EObject structures.
>
I was not clear about what I mean by databinding. In CXF terms, this
means the mechanism used to serialize the parameters and deserialize the
return types to/from the SOAP body. This serialization depends on many
things, as you mentioned, and we need to provide a way for it to work
when we use EObjects as parameters/return types. When we use a simple
String with the id, it is simple, but when we use complex objects we
might need some adjustments to the standard EMF serialization. I was
already able to make it work with simple Document/Literal, but other
options might change the XML and I have to analyze better how it will work.
Bests,
Thiago
> A side note: I've been planning to use Javascript and e4x for a quick
> and dirty solution for both the client and server side, as described in
> http://www.ibm.com/developerworks/webservices/library/ws-aja x1/ and
> .../ws-ajax2/. Since I'm already using Javascript this may provide a
> quick and flexible solution.
>
> Hallvard
|
|
|
| Re: EMF, WSDL and SOAP [message #212477 is a reply to message #212475] |
Fri, 18 April 2008 08:26 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Thiago Tonelli Bartolomei wrote:
>
> nice. I have to take a closer look at Intalio, seems interesting.
Intalio builds integrated tools on top of existing, standards-based open source
tools (and have donated a GMF-based BPMN editor to the Eclipse STP project).
> You can call it "weaving" when I am automatically generating the Ecore
> models from the WSDL. But if I have the models and I want to expose web
> services, I would prefer "decorating the model" instead ;-)
Yes, I guess "decorating" is a better term, now that I (think I) understand the
approach.
> Let me just finish some details of my implementation and I will apply it
> on your example. I noticed that you haven't sent the phonebook.xsd file,
> but I generated that from you Ecore models and I think it will work
> properly.
Yes, it should! phonebook.xsd is generated directly from the ecore file, without
any modifications.
> I was not clear about what I mean by databinding. In CXF terms, this
> means the mechanism used to serialize the parameters and deserialize the
> return types to/from the SOAP body. This serialization depends on many
> things, as you mentioned, and we need to provide a way for it to work
> when we use EObjects as parameters/return types. When we use a simple
> String with the id, it is simple, but when we use complex objects we
> might need some adjustments to the standard EMF serialization. I was
> already able to make it work with simple Document/Literal, but other
> options might change the XML and I have to analyze better how it will work.
I think I understood what you meant by databinding in this context, i.e. how
parameters and return values are related to the actual objects residing on the
server and client. E.g. if a client has a Person (EObject) and needs to send it
to the server, how can we ensure that the service handler on the server operates
on the logically same Person.
In the easiest case we may be able to rely on EMF serialization: The client and
server both serialize and deserialize messages in the context of the same
Resource, to ensure that EMF's id references are properly resolved.
Suppose both client and server has a ResourceSet containing the data in a
Resource (call it UoD for Universe of Discourse). A message to be sent can be
built as a second Resource (call it M) and inserted into the same ResourceSet.
If this second Resource M is saved, all the objects in the message that are
contained in the first Resource (UoD) will be serialized as ids. The receiver
has the same ResourceSet and UoD Resource and loads the the message into a
Resource M. This resource will then contain the message with references to the
logically same objects in UoD.
The only thing missing is an Ecore model of the SOAP envelope, which is the
basis for the M Resource. I.e. the M Resource will contain an EObject structure
representing the SOAP envelope, the body of which will refer to domain objects
in the UoD Resource:
Resource M Resource UoD
- SOAP envelope - ...
-- SOAP header - ...
-- SOAP body - ...
--- reference to Person object --> - Person object
As you say, this may only work for some WSDL and SOAP options. What I'm hoping
is that the variations in the WSDL and SOAP options may be handled by the
details of the SOAP envelope EObject structure in Resource M. It may also
require a special Resource implementation, to control the serialization?
Hallvard
|
|
|
| Re: EMF, WSDL and SOAP [message #212734 is a reply to message #212477] |
Mon, 21 April 2008 22:03 |
| Eclipse User |
|
|
|
Originally posted by: ttonelli.uwaterloo.ca
Hallvard Trætteberg wrote:
> Thiago Tonelli Bartolomei wrote:
>>
>> I was not clear about what I mean by databinding. In CXF terms, this
>> means the mechanism used to serialize the parameters and deserialize the
>> return types to/from the SOAP body. This serialization depends on many
>> things, as you mentioned, and we need to provide a way for it to work
>> when we use EObjects as parameters/return types. When we use a simple
>> String with the id, it is simple, but when we use complex objects we
>> might need some adjustments to the standard EMF serialization. I was
>> already able to make it work with simple Document/Literal, but other
>> options might change the XML and I have to analyze better how it will
>> work.
>
> I think I understood what you meant by databinding in this context, i.e.
> how parameters and return values are related to the actual objects
> residing on the server and client. E.g. if a client has a Person
> (EObject) and needs to send it to the server, how can we ensure that the
> service handler on the server operates on the logically same Person.
>
> In the easiest case we may be able to rely on EMF serialization: The
> client and server both serialize and deserialize messages in the context
> of the same Resource, to ensure that EMF's id references are properly
> resolved.
>
> Suppose both client and server has a ResourceSet containing the data in
> a Resource (call it UoD for Universe of Discourse). A message to be sent
> can be built as a second Resource (call it M) and inserted into the same
> ResourceSet. If this second Resource M is saved, all the objects in the
> message that are contained in the first Resource (UoD) will be
> serialized as ids. The receiver has the same ResourceSet and UoD
> Resource and loads the the message into a Resource M. This resource will
> then contain the message with references to the logically same objects
> in UoD.
>
> The only thing missing is an Ecore model of the SOAP envelope, which is
> the basis for the M Resource. I.e. the M Resource will contain an
> EObject structure representing the SOAP envelope, the body of which will
> refer to domain objects in the UoD Resource:
>
> Resource M Resource UoD
> - SOAP envelope - ...
> -- SOAP header - ...
> -- SOAP body - ...
> --- reference to Person object --> - Person object
>
> As you say, this may only work for some WSDL and SOAP options. What I'm
> hoping is that the variations in the WSDL and SOAP options may be
> handled by the details of the SOAP envelope EObject structure in
> Resource M. It may also require a special Resource implementation, to
> control the serialization?
>
> Hallvard
Hi Hallvard,
if I understand well, you are talking about distributed ResourceSets,
right? You have a single ResourceSet that is valid throughout your
distributed system, an instance (an EObject) is present only in a single
of its Resources (others carry id references to it), and the Resource
implementation would be responsible for the communication between nodes
in the system (sending objects between nodes and dealing with the
references).
Did I understand it correctly?
So, what I meant by databinding is at a lower level than what you're
saying. I just meant constructing an EObject from an incoming XML inside
a SOAP message or creating the XML for an existing EObject that is being
passed as parameter. It's not about making sure that objects in
different nodes are logically treated as the same object.
I think your idea is very similar to CDO, but not quite. I don't know
much about CDO, but if I am not wrong, it contains a single server with
all resources (ie, all EObjects are logically there), and clients have a
partial view of the server (when they change things, the server is
notified; when something changes in the server, they get notified). In
your case, every node is a kind of server and the instances are
distributed, ie, there are no copies, just references. Again, I must ask
if I am making sense here ;-)
In any case, the implementation of such a functionality could be done on
top of Servus. For example, a Resource in your ResourceSet could
represent a node in the system and saving the resource would mean to use
Servus to call some Web Service present in that node, possibly sending
some EObjects as parameters. Also, Servus could maybe be used as a
replacement for Net4j in CDO, but I don't know these things in depth to
say more than that.
However, I am not sure that using Servus for this system you propose
would be the best option. One of the main purposes of Web Services is
platform independence, i.e., I don't care what technology is on the
other side of the communication link, as long as it understands some
standards. This distributed system that you're talking about would need
that all nodes understand what's going on at the application level,
which means that I need some EMF implementation on each node, or
something that mimics the Resource(Set) semantics. For this reason,
maybe the best would be to use Net4j to make the communication, because
you know that the other side will understand it, and would be much more
efficient than going through WSDL parsing, SOAP processing, etc. Unless
you want to use WSDL/SOAP because they provide nice documentation and a
standard protocol for communication, regardless of the loss of
efficiency. What do you think?
Cheers,
Thiago
|
|
|
| Re: EMF, WSDL and SOAP [message #212783 is a reply to message #212734] |
Tue, 22 April 2008 12:15 |
Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Thiago Tonelli Bartolomei wrote:
>
> Hallvard Trætteberg wrote:
>> Thiago Tonelli Bartolomei wrote:
>>> I was not clear about what I mean by databinding. In CXF terms, this
>>> means the mechanism used to serialize the parameters and deserialize the
>>> return types to/from the SOAP body.
You can think of this problem at the lexical, syntactic or semantic level. The
lexical level is already handled, since this is defined by the basic XML
constructs, like tags and attributes, encoding etc. The syntactic level is also
partly defined by XML, since this is essentially what the XML Schema and WSDL
defines. The semantics concerns what the structure of elements and attributes
means. E.g. that this particular XML element (whether a parameter or return
value) actually refers to a Person object that has a common meaning to both
server and client.
The beauty of EMF is that it handles all three levels, the lexical and
syntactic, since EObject structures are serializable as XML, and the semantic
level, since URI's and ids gives objects "global" identity upon which all
references are based.
>> The only thing missing is an Ecore model of the SOAP envelope, which is
>> the basis for the M Resource. I.e. the M Resource will contain an
>> EObject structure representing the SOAP envelope, the body of which will
>> refer to domain objects in the UoD Resource:
>>
>> Resource M Resource UoD
>> - SOAP envelope - ...
>> -- SOAP header - ...
>> -- SOAP body - ...
>> --- reference to Person object --> - Person object
What I tried to describe (snippet above) was how to make EMF serialization take
care of both the SOAP envelope and body, by modeling each of them.
The "beauty" of SOAP, is that it is neutral to what technology you use on the
client and server, since there is XML support for every platform and language
that you can think of. I suggest using EMF on both sides, but since the XML
format of the messages are well defined, you are not required to use EMF.
> if I understand well, you are talking about distributed ResourceSets,
> right?
In some sense, yes, but not taken to the extreme that CDO does, where each node
is synchronized. I only suggested using ResourceSets in a particular way, so
that the serialization would work without having to touch XML.
> So, what I meant by databinding is at a lower level than what you're
> saying. I just meant constructing an EObject from an incoming XML inside
> a SOAP message or creating the XML for an existing EObject that is being
> passed as parameter. It's not about making sure that objects in
> different nodes are logically treated as the same object.
But don't you have to make sure that the Person you pass as a parameter or
return value is both (de)constructured correctly AND given the logically correct
identity? If you want to change the mobile phone number of a Person, you both
need to make sure that the number is correctly (de)encoded and that the correct
Person is identified.
Since this discussion is about the structure of messages and the best way of
managing them, perhaps we could try to detail the messages that correspond to
the operations in the phonebook example?
Hallvard
P.S. about CDO: I'm not thinking of replacing or reimplementing CDO. But I
envision that SOAP can be added to a CDO-based system, as a more neutral way of
accessing data. Giving the best of both worlds.
|
|
|
Goto Forum:
Current Time: Sat Apr 20 04:33:31 GMT 2024
Powered by FUDForum. Page generated in 0.04752 seconds |
] 
Search
Help
Register
Login
Home
