How to name a service operation?

[Former Member]

Say that I have a business object called Customer that has the following attributes

ID
Name
Address
   Street
   Postal code
   City
   Country
Credit limit

Now suppose that the Query Customer In service interface already has an operation defined called FindCustomerSimpleByID. That operation has an response message containing ID, Name and Address.

Then I want another operation that returns the ID and CreditLimit base on the ID. The name FindCustomerSimpleByID is already taken. I don't want to add the credit limit to the first operation since it is sensitive data that only some processes should have access to.

What does the eSOA naming convention say in this case?

BR

/Alexander

[Former Member · Accepted solution]

Hello Alexander,

It is not at all required to have a new service for this.

You can enhance the existing FindCustomerSimpleByID with CreditLimit.

Regards,

Shankar

[Former Member · Accepted solution]

So I should call it the new service

FindCustomerSimpleByIDWithCreditLimit

and the messages

CustomerSimpleByIDWithCreditLimitQuery

CustomerSimpleByIDWithCreditLimitResponse

or should it be

FindCustomerSimpleWithCreditLimitByID

and the messages

CustomerSimpleWithCreditLimitByIDQuery

CustomerSimpleWithCreditLimitByIDResponse

I just want to make sure that anyone famliar with the eSOA concept understands what the service operation does and how it its related to other service operations in the service interface.

I read the Enterprise Services Enhancement Guide but was unable to find the answer to my question.

Edited by: Alexander Isacson on Mar 20, 2009 9:26 AM

[Former Member · Accepted solution]

Hello Alexander,

The service name will remain FindCustomerSimpleByID.

In the response message of this operation, in addition to ID, Name and Address you can add CreditLimit.

Regards,

Shankar

[Former Member · Accepted solution]

I take it that eSOA model only allows for one set of simple output parameters for a given search criteria, in this case searching by ID.

Of course there is no technical limitation for this and we can define several more services and name them as we please. The main reason for us to separeate the services is from a security perspective, we want different authentication for the service that exposes customers credit limits. Other reasons for separating the services could be performance, one consumer needs the adress, which consists of many long elements, and another one doesn't.

Can anyone confirm that I have not missed the part of eSOA that addresses this before we deviate from standard.

BR

/Alexander