Questions on Savara Development Process

[jeffdelong]

The following is from an email exchange:

On Jan 20, 2010, at 5:32 AM, Thorbjørn Blixen-Finecke wrote:

Hi

First of all this site is a great idea. The SOA Platform is very flexible which makes it usable for almost anything, but with the flexibility of course also comes the possibility of solving a problem in many different ways. Having some guidelines on how JBoss thinks the SOA Platform should be used is very useful.

I have some questions regarding the following pages:

Concept: Considerations and Guidance for Creating ESB Services:

This page describes that one service can perform multiple tasks depending on the message it receives. That is there is one ESB archive with one service (AccountService) that can receive four different types of messages (CreateAccount, UpdateAccount, DeleteAccount and GetAccount). An alternative design would be one ESB archive with four services (CreateAccountService, UpdateAccountService, DeleteAccountService and GetAccountInfoService), each taking a specific type of message.

Is there a particular reason for letting one service having multiple purposes, as opposed to one specific purpose? (I suppose the pattern of one service performing multiple operations actually fits in well with the way the SOAPProcessor exposes existing web services).

Jeff replied:

"I think limiting a service to a single task can make the services too fine-grained and perhaps harder to maintain. So with the account entity, if we add a new field to account, it would be added in four services if every task was a different service. SOAPProcessor can expose existing web services with multiple operation, however EBWS will only create a single generic operation, Hence it we use EBWS to define a service that performs multiple tasks, we want it to accept a message where the task to be performed is defined in the message structure."

Task: Define Message Schema:

This description refers to a sample schema (See Message Schema Template), but the schema has not been uploaded yet. It would be very nice to have this sample schema (I suppose it would be a supertype most schema types in the information model would inherit as it could contain elements such as operation and perhaps version?) as it would also clearly demonstrate that the intention is to let one service have multiple capabilities.

Jeff replied:

"I did not realize that these files were not part of the upload (I need to investigate that). Thanks for pointing this out. I have attached the files to this post."

Finally it would be very nice to see on what elements versioning should be handled. Should the services be versioned for instance by adding a version number either to the category or the service name (ie. AccountServiceVer01 or similar), or should the messages be versioned? (I imagine the latter would make integration with jBPM a lot easier, since the processes would not be hard coded to a specific service version).

Jeff replied:

"I think a discussion on versioning is warranted and will try to add that at some point. I think that message versioning should be the first strategy. Part of the rationale for using an extensible message structure is to support change with minimal impact. So if a new field is added to the entity, the message schema can be extended to support it. However existing clients may still be able to use the old message structure (assuming the new field is not mandatory from a business perspective).

Service versioning will be required at some point. The ESB can help here, by providing a facade or proxy for the original service, but mapping it to the new service, with perhaps some data enhancement as part of the ESB service. In this way a jBPM (or BPEL) process, or any other consumer, would not necessarily be impacted by bringing out a new version. Back to the account example, a new field is required, and it can be determined in some other way than the client providing it, so the ESB service adds additional logic to determine the new field's value before invoking the new version of the actual service."