Dear readers,
As normal part my work on integration I am always asking: What is the interface to that system?
You would expect that in this time, I would get a WSDL. Well, no!
I often get a View or Stored Procedure. In the SAP environment there are iDocs (EDI) or RFC.
Sometimes, it can be explained by the age and technology of the systems.
How do I explain the other case? The cases where web services are possible or even available.
Well, I think it is just more comfortable to offer the service that you can support best.
There maybe other considerations like SOAP overhead, better security and layers of technology. Two examples: A binary communication maybe more secured that XML and programming a call to a web service is more effort than calling a stored procedure.
It is just like my answer to SOAP vs REST - The protocol and specific technology is not critical as long as the service is clear, usable and perform well. Anyway, protocols and technologies come and go while the application stays.
So how would service consumers discover the non-SOAP service? There are tools as part of ESB's that enable the discovery.
After all the above, I would like to state my own base rules for SOA:
See you next time,
Noam
As normal part my work on integration I am always asking: What is the interface to that system?
You would expect that in this time, I would get a WSDL. Well, no!
I often get a View or Stored Procedure. In the SAP environment there are iDocs (EDI) or RFC.
Sometimes, it can be explained by the age and technology of the systems.
How do I explain the other case? The cases where web services are possible or even available.
Well, I think it is just more comfortable to offer the service that you can support best.
There maybe other considerations like SOAP overhead, better security and layers of technology. Two examples: A binary communication maybe more secured that XML and programming a call to a web service is more effort than calling a stored procedure.
It is just like my answer to SOAP vs REST - The protocol and specific technology is not critical as long as the service is clear, usable and perform well. Anyway, protocols and technologies come and go while the application stays.
So how would service consumers discover the non-SOAP service? There are tools as part of ESB's that enable the discovery.
After all the above, I would like to state my own base rules for SOA:
- Service repository - expose any service in a unified manner
- Consumable services - services that are available and technically consumable to all systems in the organization
- Technology - any technology that enables inter-system communication. That may include ESB if the environment is too heterogeneous
See you next time,
Noam
> I qualify this question as from a developer who never raised his/her had to look around and ask 'What and why am I doing? Who needs it beside my manager and/or me?'
Discovery of services automatically in UDDI-like structure has proofed inefficiency. The first laud bell was shout by IBM when that created registry and repository for service without UDDI. The entire concept of auto-discovery is not thought through well. This concept cannot answer a very simple question: if auto-discovery is the only one way used by the system to find appropriate service, what the system should do if such service is not found? And the service may be not found automatically due to million technical and spelling reasons (plus, another million of semantic mismatches). Thus, relying on the auto-discovery for serious business solutions is irresponsible if not silly.
This is why people use other means to find needed service in the UDDI, i.e. manual means. SOAP in this procedure has priority #16 (do not ask me why it is not #22). Service Consumers do not care about SOAP or WSDL to discover the service; they care about business functionality and provided service results (Real World Effect), and if these two are suitable for the consumer needs we can start talking about interfaces. People should discover services by the Service Descriptions that include much more different things than WSDL, or Jini Java, or CORBA IDL interfaces.
Great base rules. And also, great site overall. Managing Automation is also consistently analyzing [SOA Software]
Take a look at there recent post.