Message vs service.
Hi
I will appreciate if any of the experts here can take a quick look here and share some input which might be useful. I have made a post here earlier:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=385522&SiteID=1
Any help will be appreciate.
Thanks,
Sailu.
Here is some details of the post:
*************************************************
Message vs Service.
EmailValidation message vs EmailValidation Service.
SOA is mostly about services and messages.
Rather than create a number of services with different names
would it be recomended if we create 1 generic service and
have it request/reply messages.
For ex: EmailValidation service.
Instead of creating a service for email validation, create
a validationService and have it process all the validation messages for the application.
Just wondering how others are approaching this.
Thanks
Sailu
--
Sai
05-03-2006, 6:21 PM UTC
Arnon Rotem Gal Oz
Posts 127 Re: Message vs Service.
Was this post helpful ?
Hi sailu,
I think SOA is more about bringing people, business processes, policies and technology more closely aligned by using loosely coupled software agents and their compositions.
Regarding your question. I don't think anyone can give you off-hand advice on how to partition a business into services. The prime directive though would be business alignment. The services should represent coarse grained chunks of business behavior. One nice analogy I heard is that the boundaries between services would roughly be equivalent to those of departments in the pre-computing era.
It seems to me (judging from the names of the messages/services only -since that is what you supplied) that none of the two options should really be services. they might be components inside a service (which doesn't mean they can't use technologies usually associated with SOA).
Arnon
--
http://www.rgoarchitects.com/blog
Report Abuse
05-03-2006, 7:00 PM UTC
Clemens Reijnen
Posts 20
Re: Message vs Service.
Was this post helpful ?
I agree with Arnon, keep in mind the loosely coupled thing. But...
Do you really need an email validation service or can you better use client side validation with regularexpresions? When validation is that simple you must use client side. But when you must validate a zipcode, you better can use an service, and please don't cal it ValidateService. What will happen when other people need to use that service... and they don't know what it will validate.
Clemens
--
www.ClemensReijnen.nl / IASA Netherlands
Report Abuse
05-03-2006, 8:29 PM UTC
brk
Posts 4 Re: Message vs Service.
Was this post helpful ?
A Service in SOA is actually a business service and meets the core tenets of service such as services are autonomous, boundaries are explicit, share schema not code and governed by policy.
In real world what this means is that a Service should be based on the business requirement or goal. Thinhs such as data validation are not really good candidates for service.
Below are some examples of service:
1.. Authentication service - implementation can be based on AD or custom auth or somehting else.
2. Bank Account Inquiry for personal account
Hope that helps.
- Kumar
--
Architect - http://byaksblog.blogspot.com/
Report Abuse
05-03-2006, 8:52 PM UTC
Sailu
Posts 4
Re: Message vs Service.
Thanks for your valuable input.
Here is what we have.
We have 1 web service which we call as GenericWebService.
It has only 1 method in it.
The method is:
public string ProcessRequestMessage(string xmlString)
{
// Create an xmldocument from xmlString.
// Use dependency injection and get a Interface object.
// then call interface.ProcessRequestMessage(xmlString);
}
All our request messages are in xmlformat.
We just maintain 1 webservice for exposing business logic and data logic.
This will help us in lowering the maintenance of web services.
It keeps the design (if i may) also simple.
So if we were to implement Authentication Service:
We do not create a service.
But we create messages.
1 message class called Authenticate with properties (username and passwd).
Another message class if you want to authenticate against AD called AuthenticateAD (userName,passwd)
and so on...
If in the future if business process changes then the services do not get affected
but the message contracts get changed.
Since they are in xml, modification to contracts become easy.
Just wanted to know if you see any problems with this approach.
Once again, Thanks to everyone for your input.
Sailu.
--
Sai
Report Abuse
Yesterday, 4:28 PM UTC
B. Kumar
Posts 4 Re: Message vs Service.
Was this post helpful ?
Sailu,
The approach you are taking is very similar to Message Driven Bean(MDB) in J2EE. Anyway here are my thoughts:
1. Having a single method on the Service Interface to process all messages is right approach. But this service interface should be restricted to a single business component (not necessarily a sinlge class) which is responsible for providing related set of business functions.
2. A Service interface should be defined for each business component.
3. In SOA the idea of having serive interfaces fronting a business components is that these services can be orchestrated to provide new business capabilities or respond to quick bsuiness needs easily. If all you have is a single service that is abstracting all business functionality, then orchestration is not possible and service reusability is minimal to none as no one knows that service exists.
When you think about services don't limit yourself to just one or two applications but take a holistic view of the entire IT Asstes or applications. Having distinct services each providing self contained business functionality will allow them to be stored in a enterprise service repository where they are easir to discover, version and reuse.
- Kumar
--
Architect - http://byaksblog.blogspot.com/
Report Abuse
Yesterday, 5:26 PM UTC
Sailu
Posts 4
Re: Message vs Service.
Hi Kumar,
Thanks for your input.
You said:
::3. In SOA the idea of having serive interfaces fronting a business components is
::that these ::services can be orchestrated to provide new business capabilities or
::respond to quick bsuiness ::needs easily. If all you have is a single service that is
::abstracting all business functionality, ::then orchestration is not possible and service
::reusability is minimal to none as no one knows that ::service exists.
Let's take an example of orchestration:
I am treating an orchestration as a process.
A Customer adds products to a cart and enters credit card information and clicks on buy.
Assume The process involves the following steps:
Receive the info from the client.
1. Verifying the credit history of the customer.
2. Verifying if the Customer has enough funds available.
3. Applying the purchase.
4. Send confirmation to the customer.
Assume we create a Service called CheckoutService with the following messages in it:
1. ReceiveCustomer(Customer). // Get the customer serialize/deserialize/disassemble the xml/authenticate/log/etc...
2. VerifyCustomerCrditHistory(Customer). // Contacts the crdit beurau and verifies this credit history
3. VerifyBalance(Customer). // Contact the bank and verifies the balance.
4. Purchase(Customer). // Purchases if the blance is available
5. SendConfirmation(Customer). // Sends the confirmation whether the purchase has been successful or if there was any problem.
So, this is what you are suggesting to do is what i see.
What we are thinking is just create one message ProcessCheckout(Customer), in which you call
the above 5 messages.
Should you have a requirements change/modification where you need to have the customer validated against n CreditBureus: there are 2 things you can do:
1. Change your implementation in Step 2. // Create 2 threads and have 1 contact credit bereau1 and in another thread contact credit bereau2.
2. Create a new ProcessNewCheckout(customer) message.
Call the 5 steps above with the changed implementation in step 2.
Like this we do not change the service but the message only gets changed and the new process is
implemented without affecting the existing process. This is a succesful orchestration is my understanding.
Please let me know if you see any problem.
Thanks,
Sailu
--
Sai
Report Abuse
Today, 6:56 AM UTC
Clemens Reijnen
Posts 20 Re: Message vs Service.
Was this post helpful ?
There is a nice article on theserverside.net about soa anti-patterns [not new, on the TechEd Europe 2004 or 2005 he gave a presentation about this topic] and one of them Ron Jacobs mention is 'loosely-goosey':
He said: "One anti-pattern I describe is 'loosely-goosey.' This is the idea that you are going to have an interface that accepts a fixed set of things but which also [allows] an extensible hunk of XML that someone might send. If I do this, the contract is weak."
If you use a pattern like this, you tend to rely on the implicit behavior of the service, he indicated. It works, but can falter when it encounters services outside of its initial experience.
"If architecture] is based on implicit behavior," said Jacobs, "it is very fragile."
I agree with Ron and I think this is what you are doing with the 揼enericservice?with the one and only method "ProcessRequestMessage".
Clemens
--
www.ClemensReijnen.nl / IASA Netherlands
Report Abuse
Today, 2:53 PM UTC
B. Kumar
Posts 4
Re: Message vs Service.
Was this post helpful ?
I'll implement each of the following as distinct or separate services. Each service has it's own contract defined by WSDL - MEP (Message Exchange Patterns) and Schema based message formats:
1. ReceiveCustomer(Customer). // Get the customer serialize/deserialize/disassemble the xml/authenticate/log/etc...
Service name is not intutive. think about changing name to something like AuthenticateCustomer or ValidateCustomer.
2. VerifyCustomerCrditHistory(Customer). // Contacts the crdit beurau and verifies this credit history
This service can be broken into two separate services - one service to get Customer Creidt History and another for Verification. The reason for second service is different process might take apply diff. decision rules based on the credit history.
3. VerifyBalance(Customer). // Contact the bank and verifies the balance.
Change name to VerifyCustomerBankBalance.
4. Purchase(Customer). // Purchases if the blance is available
If this is a service which is responsible for performing total purchase cost, ACH or Credit Card transaction, placing shipping order to the warehouse etc., then think about dividing these into separate services.
5. SendConfirmation(Customer). // Sends the confirmation whether the purchase has been successful or if there was any problem.
change name to SendPurchaseConfirmationToCustomer.
Now coming to your original single service implementation which your are saying is going to perform this orchestration, then I would classify such a service as Process Service. In an ideal scenario I'll use an Orchestration tool to perform this (BizTalk). This process service is more tied to a specific business process or application.
But you still need to publish all the other services that this process service is using, to be available for reuse in multiple business processes. That is true SOA - not hiding everything behind one service and calling different services internally based on diff. messages.
Hope that helps.
--
Architect - http://byaksblog.blogspot.com/
Report Abuse
Today, 3:51 PM UTC
Sailu
Posts 4 Re: Message vs Service.
Hi Clemens/Kumar
Thanks for your input.
Clemens,
You refer to:
"If [architecture] is based on implicit behavior," said Jacobs, "it is very fragile."
What is implicit/explicit behavior of architecture?
Kumar,
You said:
******************
I'll implement each of the following as distinct or separate services. Each service has it's own contract defined by WSDL - MEP (Message Exchange Patterns) and Schema based message formats:
******************
Why? The problem i see with this is, for every service you add we expect the
developers to add a web reference to that service. Just for 1 process/orchestration
you add so many web references... why? And what if things change in the services?
Do we have to keep updating web references or proxy layers we use to access these services?
I just don't see the value in these things?
You also said:
*********************
But you still need to publish all the other services that this process service is using, to be available for reuse in multiple business processes. That is true SOA - not hiding everything behind one service and calling different services internally based on diff. messages.
*********************
Why? My point is why should we expose every service/method/message we use to our clients.
Isn't it better security to let the clients know as little as possible.
If the clients need to access business logic then let them know about the messages that
they could access and that's it.
Please feel free to let me know if you have any suggestions/input.
Thanks,
Sailu
