Comments on the Thomas Erl service modeller

[objectiser]

Firstly wanted to say that I thought it was a comprehensive and useful contribution.

However, based on my understanding of what is required (which may be wrong), I don't see this style of modelling meeting the needs of the Overlord project.

1) The principle issue is that I believe the tool is focused on the specification of composite relationships between services. This would be ok for an SCA type modeller, however I think we need something that can describe the dependencies between actions in a pipeline (such as for an ESB), which could not be expressed in this type of tool. It is likely that an SCA style composite/static view of relationships between services would be useful, but not as the main level of detail entered by the user - this would more likely be presented in an outline view.

2) The way the tool is structured, it is necessary to define a service interface with operation definitions, and then link these operations to the definition of the composites. However in an ESB you have greater flexibility to bind untyped endpoints to action pipelines. I think we need the ability to express both types of scenario.

3) The style of the tool does not fit well with Eclipse. I think it is important that the tool is Eclipse plugin based.

4) Further to (3), as the tool is specified as a single standalone application, it manages a repository of all services and maintains information about the links between them - consumers and providers. In an Eclipse based environment, I would envisage each 'service' being represented in a separate model file, therefore information about links between services would need to be managed using either local project paths, cross project dependencies, or links to remote repositories. This area needs careful consideration, to enable simple local use, while enabling the tool to be encorporated into an enterprise development/test/production cycle, and support for advanced change management features, etc.

[marklittle]

"objectiser" wrote:
Firstly wanted to say that I thought it was a comprehensive and useful contribution.

However, based on my understanding of what is required (which may be wrong), I don't see this style of modelling meeting the needs of the Overlord project.

Overlord isn't tied to the ESB, but needs to be able to work with services that are defined in an implementation neutral manner.

1) The principle issue is that I believe the tool is focused on the specification of composite relationships between services. This would be ok for an SCA type modeller, however I think we need something that can describe the dependencies between actions in a pipeline (such as for an ESB), which could not be expressed in this type of tool.

That really depends upon what you think Overlord is about. It's not simply about the ESB, or CDL, or a repository. It's about the providing an overall governance solution in a way that does not necessarily expose the underlying implementation aspects. So things like "action pipelines" are very specific to JBossESB and although at some level of service development the ESB service designer will need to know about them and have suitable tools to allow the construction of services from them, the higher level service composer doesn't care less: "action pipelines" are backend implementation issues for the service.

I think this just shows again that we do need more tools for different roles and actors within the environment. Thomas' contribution is useful at one level (similar to http://jira.jboss.com/jira/browse/JBIDE-2068), but it certainly wasn't designed for specific service development. But likewise, a tool that allowed you to develop your service from actions (like http://jira.jboss.com/jira/browse/JBIDE-2064) wouldn't be right for composing the interactions between those services or for building composite services.

It is likely that an SCA style composite/static view of relationships between services would be useful, but not as the main level of detail entered by the user - this would more likely be presented in an outline view.

2) The way the tool is structured, it is necessary to define a service interface with operation definitions, and then link these operations to the definition of the composites. However in an ESB you have greater flexibility to bind untyped endpoints to action pipelines. I think we need the ability to express both types of scenario.

I think we definitely don't want to overload the use of the tool, i.e., not make one tool try to do more than it really can meaningfully. It's definite that the Service Modeler isn't right for building JBossESB services, but then it wasn't designed for that. But it's different if we're looking at a generic service modeler.

3) The style of the tool does not fit well with Eclipse. I think it is important that the tool is Eclipse plugin based.

I agree that it should be Eclipse based. Also the use of Word isn't necessary either.

4) Further to (3), as the tool is specified as a single standalone application, it manages a repository of all services and maintains information about the links between them - consumers and providers. In an Eclipse based environment, I would envisage each 'service' being represented in a separate model file, therefore information about links between services would need to be managed using either local project paths, cross project dependencies, or links to remote repositories.

The information about the services and the providers should be retained within the repository (e.g., DNA). There are definitely a number of ways in which this data could be represented. But it shouldn't be done in a way that precludes non-Eclipse views on to the repository.

This area needs careful consideration, to enable simple local use, while enabling the tool to be encorporated into an enterprise development/test/production cycle, and support for advanced change management features, etc.

Agreed, but we have to start with an understanding of what we're trying to model. I think we're getting close, but I'm not entirely sure.

[marklittle]

BTW, one other thing to realise: the current ESB action chaining approach will change in the 5.0 architecture and revert to what we had originally intended back in 2005. That means the model will be based on composition of services and linking together of their interactions. Things like actions will be a backend implementation detail (if they exist at all). Most services will be POJOs, with a suitable layer that does not start exposing them directly on to the bus (otherwise we're back to just distributed objects, which is not where we want to be).

There'll probably be things called domains (there are some prototypes of the 5 architecture) where services can be deployed. Domains may span VMs and properties (e.g., security, transactions, etc.) are attached to them, i.e., services inherit those capabilities by virtue of which domain they're deployed within. If you've ever looked at CORBA POA then this should be familiar.

But all of this is a little way off. It'll hit the community a while before it goes into any supported product.

[objectiser]

I think I probably expressed my points badly, grounding them in a concrete example (i.e. ESB). I understand and agree with the technology agnostic aim of the service modeller.

What I meant was that I believe that we need the ability to express behaviour in the service modeller (which I described as action pipelines in point 1) - otherwise not sure how behavioural governance will be achieved.

However on second thoughts the best way to achieve this would be to have the service model referencing a behavioural description (which could be a link to the CDL), rather than encoding it itself.

If this approach is taken, we then need to work out how to incorporate conformance checking into each of the relevant service implementation tools. Taking JBossESB as an example - the http://jira.jboss.com/jira/browse/JBIDE-2064 designer would need to enable an implementation model (describing the action pipelines) to reference the appropriate goverance service model (directly or indirectly), and then use any associated behavioural description (i.e. CDL) to initiate a conformance check against the action pipeline - thus reporting conformance issues against the graphical representation of the behaviour (i.e. the action pipeline).

Is this more along the lines you are think?

[objectiser]

Are there any documents outlining more detail about the version 5 approach?

[objectiser]

My main interest in the way version 5 is configured (at this point) is that it will enable the same type of explicit behavioural description that we are currently looking to provide with the conversation based actions in 4.3?

[marklittle]

"objectiser" wrote:

What I meant was that I believe that we need the ability to express behaviour in the service modeller (which I described as action pipelines in point 1) - otherwise not sure how behavioural governance will be achieved.

Yes, I agree. I think for the avoidance of doubt we should talk about service modelling and the Thomas Erl Service Modeller (TESM) as separate entities for now.

However on second thoughts the best way to achieve this would be to have the service model referencing a behavioural description (which could be a link to the CDL), rather than encoding it itself.

I'm not sure if the behavioural description needs to be associated "by reference" or "by value". I typically prefer by reference for things that may need to be changed independently, so I think I agree.

If this approach is taken, we then need to work out how to incorporate conformance checking into each of the relevant service implementation tools. Taking JBossESB as an example - the http://jira.jboss.com/jira/browse/JBIDE-2064 designer would need to enable an implementation model (describing the action pipelines) to reference the appropriate goverance service model (directly or indirectly), and then use any associated behavioural description (i.e. CDL) to initiate a conformance check against the action pipeline - thus reporting conformance issues against the graphical representation of the behaviour (i.e. the action pipeline).

Is this more along the lines you are think?

Yes.