Hi Srinath,
On Wed, Jun 5, 2013 at 4:42 AM, Srinath Perera <[email protected]> wrote:
> 1) why we have struct inside the <list> ?
>
That basically says, this is a list of elements of a struct type. In the
same way, for primitive types, we directly mention the type as I've shown
in the "nicknames" list.
> 2) How do we query? Xpaths (from input message)
>
Yeah, the input message is not mentioned here yet, the mapping from input
message to this intermediate model we have to figure out. Yeah, one option
to do is, fill in the field in the intermediate model by using XPath for
XML, and JSONPath for JSON and so on ..
> 3) Are we trying to do one data model that support both JSON and XML? So
> each service will have both. If we are OK for JSON or XML model (not both)
> did we consider the templates oppose to this model? (just thinking aloud.
> Templates are very clean if it can work)
>
Yeah, basically one intermediate data model in the query section for all
wire formats, and in the operations, when defining the actual XML or JSON
formats, we do the mapping from our model from the query to that format,
for XML, JSON and so on, for example, for XML, we can use a templating
mechanism like the following (this would be the ouput section of the
operation)
<operation name="getCustomerAddress" transports="http,https,thrift">
...
<output messageType="application/xml, text/xml">
<message>
<status>
<code>$status.code</code>
<warns>
<entry>$status.warnings</entry>
<warns>
</status>
<customers>
<customer>
<customerNumber>$customers.customer.customerNumber</customerNumber>
<customerLastName>$customers.customer.customerLastName</customerLastName>
<customerFirstName>$customers.customer.customerFirstName</customerFirstName>
</customer>
</customers>
</message>
</output>
...
</operation>
So here, the field such as "$customers.customer.customerNumber" are values
read from the data model in the query. So here, there are some things we
have to figure out, like how the XML model here infers the information as
to how "//customers/customer" element should be a repeating element and
all, even though most of the information for this can be retrieved from the
intermediate data model in the query, but there are some edge cases, which
can be tricky.
Cheers,
Anjana.
>
> --Srinath
>
>
> On Tue, Jun 4, 2013 at 6:25 PM, Anjana Fernando <[email protected]> wrote:
>
>> 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
>>
>
>
>
> --
> ============================
> Srinath Perera, Ph.D.
> http://www.cs.indiana.edu/~hperera/
> http://srinathsview.blogspot.com/
>
--
*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
