{Enric Jaen Villoldo}

SOA : "so-ah" or "S-O-A" ?

2005-12-19T05:59:00.000-08:00

It is not clear how SOA should be pronounced. Here there is a discussion

WSDL is agreed that pronounces as wiz-dull

Presentation at MWS05

2005-12-16T11:30:00.000-08:00

You can reach here the presentation I gave at Middleware for Web Services about WSODL. In summary, I defend the OO paradigm for modeling web services, rather than the message-oriented. I am not saying that WSDL is not necessary -WSDL is good at machine level- but that shouldn't be way humans model web services. OO is necessary, and the prove of that is that: how many people program using a non OO language?
Please note that the presented WSDOL interface language has evolved since then. A new version wil be presented soon.

discussion about Web services and objects - round 1

2005-08-27T03:54:00.000-07:00

There is here a very interesting discussion. I support Michi's position.

about x/o impedance mismatch

2005-08-26T23:10:00.000-07:00

I will give my opinion about situations which supposedly there is an x/o impedance mismatch but IMO they are not.

I understand by x/o impedance mismatch any mismatch between XML and OO that cannot be solved
by the toolkit.

I have read the article 'Rethinking the Java SOAP stack' and I have to say that I
don't agree with some of the mismatches:

1) XML->clases. (x->o) They give a pattern restriction example.The toolkit can perfectly
support pattern checking for value compliance.

4) unportable types -> (o->x) regarding Hashtable, I agree. Regarding datetime, the
workaround is to put the time in UTC, so where is the problem?

8) mixing of XML and serialized data in JAX-RPC -> I would like to see a real situation
where this can occur.

Regarding C-omega, I read "programming with Rectangles,trianges and Circles, and I didn't
find many issues that cannot be solved by the toolkit:

1) Edge-labelled vs. Node-labelled. -> I don't understand this mismatch. I don't agree
that an xml element is always a type. I would better say that an xml element has
associated a type. For example, in .. x has
associated type int, but x is not a type itself (you can reference Point, but you can't
reference element x from another element). Similarly, in object-oriented languages class
Point {int x, int y} x has associated type int.

2) Attributes versus elements. -> I don't agree. The toolkit can define define classes
with booleans that indicate if the class attributes are xml attributes or not.

3) Elements versus complex and simple types. -> I don't agree. (note that I have named
Point elements) is perfectly mapeable to class Line{ Point p1; Point p2}

4) Multiple occurrences of the same child element. -> I don't agree. A toolkit could
generate a class that manages this situation.

5) Substitution groups vs derivation and the closed world assumption. -> They say "At
first glance simple types seem to correspond to primitive types in Java or C#...
primitive types in most object-oriented languages are sealed (final), and cannot be
further specialized" I don't agree. Why is not possible to define wrapper classes for
primitive types?

6)Namespaces, namespaces as values. -> They say " For instance in C# or Java field names
are never qualified." Why would you need namespaces is fields?

7) Occurence constraints part of container instead of type. -> I don't agree. Why can't a
toolkit generate a class with a counter of array elements and check for the max limit?

8) Mixed content. I don't agree. A toolkit can maintain a list of content.

about RPC-style web services

2005-08-22T23:03:00.000-07:00

I read a discussion about whether RPC-style are useful or not (Stefan Tilkov). From my point of view, there is one major reason why RPC web services are necessary: Microsoft is involved. CORBA is an excellent OO middleware, but without the support of Microft, and the counterpart for DCOM. So the only technology that really interoperates between the Microsoft world and the rest of the world is RPC Web Services.