Paul Gielens:ThoughtsService : Service Orientation (SO/A)

RESTful Data Services

p.gielens — Mon, 30 Apr 2007 20:00:18 GMT

Today at the Mix '07 event in Las Vegas Microsoft's "data programmability" team announced "Astoria": Data Services for the Web. Astoria is an early piece of technology for creating and executing data services. The cool part is that it uses the Entity Data Model to model data in terms of entities. These services and entities are surfaced to the web as a REST-style resource collection that is addressable with URI's and that agents can interact with using HTTP verbs such as GET, POST or DELETE.

Interesting to see that Microsoft is taking the REST route.

For more information visit the Astoria live lab and check out this podcast with Pablo Castro talking about programming data on the web.

Process and Control SOA

p.gielens — Sat, 03 Feb 2007 13:19:00 GMT

I tried to commit to the simple rule “do not post a post on a post”, but now that Gregor has this excellent post on “Validating Dynamic Systems” on his blog. I’m going to say goodbye to the rule for now. Apparently Gregor and Erik created a talk on Software Visualization and already discussed their thoughts during the Crested Butte workshop in 2005. Guys why didn’t you bring up this subject in Arosa?

Anyway, one of my clients is struggling with the idea of “chain logging” systems for a while now. I shared thoughts with Cyrille Visser who made the initial design and we both ended up agreeing that the meta-model is the single most important thing. The meta-model is hard to agree upon in a large organization of organizations. There are multiple information levels for the visualization component to be effective. The visualization component(s) thus has to have multiple abstractions.

Process control systems in the oil and gas, automotive and feed industries have loads of experience in process visualization. It is going to be interesting to see how experiences in other industries are going to help up to bring order into the service oriented chaos.

Web Service Software Factory leaves a sour taste

p.gielens — Sun, 24 Sep 2006 20:37:00 GMT

Why do I spend so much time with the ADO.NET vNext bits? Udi just reminded me why with his post Web Service Software Factory – Data Access CRUD! Web Service Software Factory implements (or at least the generated code base does) the Three-Layered Services Application reference architecture in which data and behavior are scattered throughout the software (see Organizing Domain Logic for an in-depth discussion). I can only hope better tooling produced by the source itself will help .NET developers realize there is an (better) alternative to layer a service-oriented application.

With no adequate tooling in place to support a particular design pattern it wouldn't make sense to promote it.

Mind your Versioning Strategy

p.gielens — Sun, 21 May 2006 10:46:00 GMT

Arjen quoted Haralampos Routis’s reply over at the Spring Web Services Forum stating: The implementation of the interface is important but it can also change in time. The interface on the other hand cannot/should not change. Thus invest on XML Schema and WSDL, because these are the essence of Web services.

To me an interface implies a couple of things, namely, a service contract and data/message contract and their implementation details, with them, not necessarily having the same versioning strategy.

Service contracts, data/message contracts are amended over time, this is the reality. One strategy for a service contract is to add a new contract but continue to support the original contract. Data/message contracts however have a build-in versioning system, assuming you use XML to describe the message body. I think my point is, yes I wholeheartedly agree that you need to invest in the service contract (WSDL) and data/message contract (XML), but I also want to stress the importance of the versioning strategy.

A Remote Interface should look Different from a Local Interface

p.gielens — Sat, 03 Dec 2005 18:29:00 GMT

The product of the discussion between Ralf Westphal and Ingo Rammer is this decision flow chart.

We’ve already had this discussion in our office a couple of times. In this discussion I always ended up on the left side of the decision flow chart where most of my colleagues picked the right side. I’m not saying either one is right or wrong… just different. I can foresee the discussion whether a remote interface should look different from a local interface evolving in the ObjectRelationalMapping vs. Relational debate.

Service Anti-Patterns, Command vs. Document Message

p.gielens — Sat, 27 Aug 2005 12:11:00 GMT

Via Arjen, Service Pattern and Anti-Patterns. While reading this article last night I got sucked into thinking about using a Document Message pattern:

1.)

[WebMethod()]

public FindCustomersByCountryResponse FindCustomersByCountry(FindCustomersByCountryRequest request)

{

}

vs a Comand Message pattern.

2.)

[WebMethod()]

public Customer[] FindCustomersByCountry(string country)

{

}

3.)

[WebMethod()]

public Customer[] FindCustomersByCountry(Country country)

{

}

Although EIP gives very clear guidance on when to use what, my experience is that most services based on Web Services technology use the Command Message pattern where services based upon MQ technology make good use out of both Message pattern styles. Why is that? Given the fact that services are build to last, I think I prefer, in the context of a Web Service, Document Messages and explicitly design a request/reply messages as if it is a Command Message. …and stay away from option 2 altogether.

Any thoughts?