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
Message vs Service.
Captain Anonymous
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
wojciu
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
e022
Services should hold a meaningful business area , probably covering at least one business entity. I for one would never have an "authentication service" like someone suggested here.
By the way, in the scenario sailu describes I would (probably) partition services a little differently - first checkout is probably not a service . The scenario is more aligned with Client/Server/Service situation where the Server is the web-server. Checkout is then a consumer which will talk with a purchasing service. the steps to verify and validate the customer would probably be in the customer service and the send confirmation would probably occur in the checkout as a result of getting a confirmation message from the purchasing service.
Arnon
kittani
Services should hold a meaningful business area , probably covering at least one business entity. I for one would never have an "authentication service" like someone suggested here.
By the way, in the scenario sailu describes I would (probably) partition services a little differently - first checkout is probably not a service . The scenario is more aligned with Client/Server/Service situation where the Server is the web-server. Checkout is then a consumer which will talk with a purchasing service. the steps to verify and validate the customer would probably be in the customer service and the send confirmation would probably occur in the checkout as a result of getting a confirmation message from the purchasing service.
Arnon
Icesniper789
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 “genericservice” with the one and only method "ProcessRequestMessage".
Clemens
DismasX
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.
RMarceloJR
Sailu,
You have started a nice thread... you must have look at Jimmy Nilsson's Weblog he posts a lot of soa questions like this thread.
Implicit behavior means that is not clear what it does. A service that not clearly describes what it can and accepts everything [weak contract]. Then you as a customer of that service must pray that the right thing comes back or nothing.
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
It's true what you are saying, the message is leading if something changes you must update your services, the ERD from the database applications is the XSD of services. When you must change your ERD in a database application you had to change al the other layers, when the change had to be visible at the front-end. The ERD is leading. That is the same with services when you change the XSD you must change everything. Versioning of services is a hot topic. The patterns and practices group of Microsoft is working on it.. And an xml-any attribute is not the right solution.
It's allways a difficult decision how fine grained you must make you're services. Things you can take in consideration are: what is the impact when a contract needs changes, [what you are saying] clients don’t have to know everything, should I use an aggregation service , what is the re-use of the serve, do I really need it , etc... Somebody more
Clemens
bluntcoder
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
Jkumar
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
the.zypher
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.
Lale Divringi - MSFT
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
matu007
The reason it is not a service (in my opinion) is that it is too fine grained to be one - it isn't a cohesive "chunk" of business functionality aligned to business needs.
At best it is a component, a reusable component- it may use the same communication mechanism used by the service (be that web-services, messaging etc.) but it doesn't
have to be autonomous, it doesn't have to have the overhead of a separate edge.
You can take a look at my presentation on SOA which (I hope) explains what I think constitutes a service.
Arnon
MainSoft
Aaron,
Why 'Authentication Service' is not valid I suggested this as a service but not necessarily exposed to external parties but rather avaiable as a service within the Firewall. This way any new business process can resuse this service without having to go thru. it's own authentication mechanism. This way composite services or process services can be implemented using existing services.
Praveen.P.L
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