Hi,
Today we had a meeting with Sanjiva, Sumedha, Harshana, Manuranga and
myself. The discussion was the new language changes for DSS 4.0, and also
how some of its features to be used as the general mapping format to be
used in other places in the platform as well, e.g. for the DevStudio data
mapping tool.
Basically in the new format, in the data service queries, we are going to
make it's input and output data abstract. That is, it will no longer define
XML elements in the result sections, and it will have a generic object
model for the parameters and for the result section.
So this is basically an intermediate object model populated from the data
received from the data sources, after a specific query is executed, and
this data structure will be serialized into a target wire format, such as
XML, JSON, Thrift and so on, which are defined in the operations and
resource definitions. And also in the same way, the input message will be
converted from the wire format to this intermediate data structure.
With these functionality, data services can support complex data service
scenarios, such as complex input messages, which contains data for many
aggregated queries, and by supporting the new object model, it can map to
many output types using the same data services query, so we can efficiently
support features like content negotiation.
Following contains a sample configuration of the format we decided so far
to represent the object model:-
<struct name="Data">
<list name="Employees">
<struct>
<field name="firstName" type="string" />
<field name="lastName" type="string" />
<field name="dob" type="dateTime" />
<list name="nicknames" type="string" />
</struct>
</list>
</struct>
Notice the inner struct is anonymous, but it is also possible for a named
struct to be defined globally and it to be reference within another type
definition, like "<list name="Employees" type="Employee">", this is in the
same way it works in XML schema. With this, we can re-use same type
definitions in different queries etc..
So basically something similar to above configuration will represent a data
service query parameters section (it doesn't have to be a single parent
item there, it can have multiple root field items), and also, same type of
configuration will be used for the result section as well, and there will
be a separate mapping configuration, which will be used to map the data
results of a query to this object model, that is we have to tell, how the
field "Data.Employees.firstName" will be populated, as in, which record in
the result set will fill that value, this mapping format is still not
decided. I will work on a possible representation on that and update this
thread.
Cheers,
Anjana.
--
*Anjana Fernando*
Technical Lead
WSO2 Inc. | http://wso2.com
lean . enterprise . middleware
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
