The Service Interface

I am very keen on the idea of having one single way to get to the business logic - exactly what the Service Interface does for us. I have to wonder though whether one single interface for everything is really necessary.

Since I have these great things like ProDataSets, Client Principals, etc. that I can use for the OpenEdge clients, I don't want to have to decompose them to meet the lowest common denominator. That said, I still want to use the single point of entry to the business logic.

(Perhaps what I will describe here is somewhat swayed by the OpenEdge Reference Implementation examples I worked with)

Since I want the advanced capabilities for my "smart" (ABL) clients and I want a simple interface for other clients, perhaps we should introduce something that sits between the client and the Services Interface. Clearly we would have to implement this on the server side, but the only real job of this new "thing" would be to convert a web services request to meet the API of my Services Interface and back again for the output parameters. That might include things like restructuring parameters and possibly authentication/authorisation (although this might be better pushed down into the Business Services Layer or up into an ESB if we have one).

Of course, then we get into the question of whether we then need one of these new "things" for our .Net & Java clients, which could also access the business logic through the open client technology. I am going to consider WebSpeed clients in the same category as GUI & character client.

What we would end up with is this. The OpenEdge client would be able to use the Service Interface directly (fastest, least layers, most integrated). We would then have a new "thing" for other clients. In fact, we might end up with one for each of the other open client technologies - a total of four. The idea though is that the extra three all use the same standard Service Interface.

I think that architectural decision is something to be considered separately from the question of one single generic Web Service or many descriptive and purposed Web Service.

I am very keen on the idea of having one single way

to get to the business logic - exactly what the

Service Interface does for us. I have to wonder

though whether one single interface for everything is

really necessary.

== snip==

I think that architectural decision is something to

be considered separately from the question of one

single generic Web Service or many descriptive and

purposed Web Service.

I would like to hear from as many people out in the community as possible on this question.

There is a suggestion that people might be viewing this question in terms of a binary choice between a single entry point for ALL business logic calls OR EVERY business logic call has it's own entry point.

Isn't there a middle road?

Isn't it possible to have a combination of both approaches? That is, a single entry point for some/maybe even most of the business logic calls, and specific entry points for what's left.

And what about the signature patterns of the business logic calls? Isn't possible to construct entry points around repeating signature patterns similar to interface realization? But then how this affect the functional grouping of services?

Let's get some discussion going.

So what do I think about the question of one single generic Web Service or many descriptive and purposed Web Service.

I think it make a big difference who is writting the client that will use these services.

If it is a small development team with good communication and access to the source of both the client and the server, perhaps a generic interface is the way to go. One can just ask the other if the required service is available. Of course, they could read the design specifications and documentation, but particularly with small development groups, those things are rarely kept up to date.

If the development team(s) are bigger, are geographically distributed or the client and server component are developed with different technologies, I would tend towards more descriptive and purposed services.

Perhaps we could even go with a mixture of the two with our own clients using a single standard interface (again fastest, least layers, etc), but the new "thing" that sits between the client request and the Service Interface (see my previous reply) would also do the translation from a many structured, purposed entry point back into the standard Service Interface.

The downside of having more services include: needing to rebuild proxies, needing to deploy them, having far more exposed interfaces that need to be managed.

The upside of have more services include: services being self documenting, less ambiguity in the services provided -> leading to greater ability to break up the client side and server side development group. (outsourcing possibilities, etc)

There's a lot of leg work involved in keeping the documentation up to date if the services aren't self documenting. Perhaps if we were using a MDA approach or some other kind of roundtrip engineering, we would provide the models to the client development teams?? I guess that would still hold true regardless of the design decision of single or multi interfaces.

One thing that I think is very important is standards in the interfaces. Both with one single service that accepts the request details in the form of parameters and the more structured, purpose interface, it's possible to be inconsistent in the naming of the business entities & tasks. If we care about our own sanity ot that of the people who will maintain the application 10 years down the track, we need to define some standards and stick with them.

Comments?

I am very keen on the idea of having one single way

to get to the business logic - exactly what the

Service Interface does for us. I have to wonder

though whether one single interface for everything is

really necessary.

I don;t think it is feasible, possibly or even desirable to have one SI for everything

Since I want the advanced capabilities for my "smart"

(ABL) clients and I want a simple interface for other

clients, perhaps we should introduce something that

sits between the client and the Services Interface.

Clearly we would have to implement this on the

server side, but the only real job of this new

"thing" would be to convert a web services request

to meet the API of my Services Interface and back

again for the output parameters. That might include

things like restructuring parameters and possibly

authentication/authorisation (although this might be

better pushed down into the Business Services Layer

or up into an ESB if we have one).

>

This 'thing' you describe is very much the approach that was taken with the AutoEdge sample (coming soon folks!) with respect to web services. We introduced a layer, that offers fine grained services that we could proxy, that indeed did some data mapping, and then turns round and calls the 'generic' SI.

Of course, then we get into the question of whether

we then need one of these new "things" for our .Net &

Java clients, which could also access the business

logic through the open client technology.

Depends In theory you should be able to pass the ProDataSets as ADO or SDO (depending on the client). I say theory because we hit a current limitation, that meant, just like the web service example above, we had to introduced a layer to convert ProDataSets from static to dynamic.

What we would end up with is this. The OpenEdge

client would be able to use the Service Interface

directly (fastest, least layers, most integrated).

We would then have a new "thing" for other clients.

In fact, we might end up with one for each of the

other open client technologies - a total of four.

The idea though is that the extra three all use the

same standard Service Interface.

Indeed with AutoEdge we ended up with 4 (Generic, Web Services, .NET & HTML)

But that was just our approach So I'm keen to hear what people do in the 'real world'

There is a suggestion that people might be viewing

this question in terms of a binary choice between a

single entry point for ALL business logic calls OR

EVERY business logic call has it's own entry point.

Obviously not the intention, if people are reading it that way. Hence the closing comment about 'doing it differently'

Isn't there a middle road?

===snip========

Let's get some discussion going.

And would/does tools support have an impact on the design/architecture route chosen?

Hi Jamie,

i guess what you mean as 'thing' is a facade. It will hide the real implementation from the clients. Your OE clients can indeed use the producer interface: direct access to a .p on an appserver. Other clients will use the consumer interface: a facade to the bl. The facade will take care of 'restructuring', authentication etc. And it doesn't have to cost any extra coding: because it will always be done in exactly the same way, it's easy to generate.

One of the concepts we're currently designing and documenting is that of a Service Adapter, which would I believe be this 'thing' that you refer to Jamie.

The Service Adapter is a client side (and I use client in the broadest term here) component that is responsible for managing the communication with the server Service Interface. It may have the responsibilities of service discovery, managing protocols, etc in order to make sure the client request is directed to the correct service side routine/producer (whatever term you feel comfortable with) with the correct parameters, data, etc. In the document I'm writing I currently define a Service Adapter thus:

'..a client side component who's responsibility is to manage access to a service provider, whilst isolating the client from the specific terms of the services contract. As a function of this management, it is the role of the Service Adapter to discover the relevant service provider for the service being requested'.

Does this sound like your 'thing'

Mike

Where is the service adapter for a browser client?

This does indeed sound like my 'thing'. The question that follows is: is the Service Adapter just a component that is used to build the Presentation Layer (and probably the Integration Layer) or is it in fact a layer in itself?

If so, that would make the Service Interface a layer as well...

This raised the broader question: where is the 'client' for a browser client?

If we consider a WebSpeed solution, you could very much argue that while the visualisation is done in the browser itself, the actual 'client' is the WebSpeed agent that uses the (ABL) Service Adapter to access the Service Interface and Business Logic in the back end.

I think this all gets much harder if you want to use MVC to design your 'client'. Clearly, you'll be implementing MVC in the ABL running on the WebSpeed agent (it's only being in the browser client), but if you want to get into AJAX, you'll need to split your Presentation Layer design into different parts, running on different machines and even programmed in different languages!

Perhaps we should start a different thread to discuss this further.

This is all true. I think that adding a single point is a great start and it makes it easy for people to get going. However the fine grained approach is also critical. Lets look at an example:

1. I have create 300 services. Generically they are all available or disabled by default

2. I have a customer how buys my product in an ASP model and then has 3 other, of their, customers using it

3. Now I sell my customer certain services for a fee (lets say 1c per access for some) but want to disable others that were built, and paid for, by another customer

4. The first customer wants to on-sell the services to his/her clients and change 2s per access or maybe $500 a month.

So, I need a system when my one set of Progress services an be available in multiple different ways depending on both an individual, a group or a set of groups (where groups can contain groups). I also need to track access, charges etc.

So, not sure if that adds anything but there is my $0.02 (2c) worth.

Muz

PS I'd also want to super Services that are made of other other services which the customer may not have individual access to ...

Murray, have you looked at the AutoEdge application yet? The service interface there is pretty interesting in terms of having a common base, but multiple facades appropriate to the different possible UIs. One of the implications is that all of the core functionality is common, regardless of access path, so one has a central place to put logic on permissions and charges.

Sorry no - what is this "autoEdge" thing???

See this thread http://www.psdn.com/library/thread.jspa?threadID=2459&tstart=0 in this very forum.

Have a look here:

Ahh - thanks guys. I did see the earlier link but it didn't do anything (ie. FireFox just froze up) so I gave up.

Don't give up!