Prepend
2007-10-26
SOA Registries- What I need
I was cleaning out my briefcase and found some notes I had written down about what characteristics I need in an SOA registry (or repository if you're one of those people).
I've seen almost all of these features spread out across a couple of different products, but I think eventually you will need these in order to have a successful SOA implementation. Each of these items deserves a whole post, so I'll keep it brief in this post.
A last note before I start enumerating is that I think SOA Registries are more useful at the private/internal/enterprise rather than the outdated public UDDI model of 5 years ago. Registries needed to enable an enterprise's modular development, but aren't required for locating public services as it's pretty much impossible to get all the different providers together in one registry.
So that's a couple of useful things that I'd like to see in my service registry. It goes beyond what some of the big vendors are selling by adding in some user centric features. Don't think that this is all based around bottom-up as there is still governance and all the other stuff that goes into the review a service is put through so that it can make it into the registry.
I've seen almost all of these features spread out across a couple of different products, but I think eventually you will need these in order to have a successful SOA implementation. Each of these items deserves a whole post, so I'll keep it brief in this post.
A last note before I start enumerating is that I think SOA Registries are more useful at the private/internal/enterprise rather than the outdated public UDDI model of 5 years ago. Registries needed to enable an enterprise's modular development, but aren't required for locating public services as it's pretty much impossible to get all the different providers together in one registry.
- Service Level Agreements- the SLAs available for the service should be listed out so an architect or program manager can search based on what is compatible with their system needs.
- Security - what kind of authentication is needed for the consumer to implement. Here's where you get all the various metadata that tells potential service consumers the kludgy way that userids. Until an enterprise gets their single sign-on, SAML compliant wonderland authentication framework in place, you can look to the registry to see if a service needs basic auth (and where to get a userid), digital certificates (and where to get a cert), custom headers, etc etc.
- Data classification - what kind of data is passed in the service. I'm currently dealing with this in the public health sector as there are special regulations that kick in when you deal with Personally Identifiable Information (PII).
- Endpoint - of course this is in the WSDL, but for non-WSDL services, you have to have the endpoint.
- Service Interface/Schema - again, another item in WSDL, but this needs to be available for POX, etc.
- Examples & Documentation - essential to have links to example client calls and user documentation on how to use the service. This sounds like a no brainer, but every time I've had a "WSDL only registry" there is always reams of extra work that goes into demonstrating how to call the service. An even better way of documenting the service is to provide test programs/classes that a potential user can download and play around with. Don't assume that all your users have fully licensed SOA tools.
- Approval Level/Rating - this should show what approvals and governance checks the service has gone through. Is this a demo service? Or does it meet all the necessary service characteristics that the service governance center came up with. Think of this as a stamp of approval. You don't have to limit this to just a formal approval, think of a digg/reddit type rating where users in your systems can add their thumbs up to a service. Word is going to get out if developers across your company like the service anyway, make it easier for them.
- Providing organization- who built this service. This is especially important in a federated repository where it is not necessarily clear who is responsible for maintaining a service.
- Version/last updated - not only showing the current version but other related versions.
- Timeliness- how long is this version guaranteed to be supported.
- Keywords/tags - service provisioners should add keywords to allow for easier searching and finding of related services.
- Usage statistics- how many executions per time period, average time of execution. Stuff like this. Implement service performance measurement and publish the results as part of the registry.
- RSS for updates and announcements - allow consumers to subscribe to a service's feed to see when a new version is coming out, known issues, etc etc.
- Cost/chargeback model- if your enterprise charges for services (which has its pluses and minuses as Nick Malik pointed out) then go ahead and show it as part of the registry. Buy 1,000 transactions, get 1 free.
So that's a couple of useful things that I'd like to see in my service registry. It goes beyond what some of the big vendors are selling by adding in some user centric features. Don't think that this is all based around bottom-up as there is still governance and all the other stuff that goes into the review a service is put through so that it can make it into the registry.
Labels: SOA
¶ 3:52 PM 0 comments
2007-09-06
IBM SOA Certification
IBM announced two weeks ago that they would launch a free 12 week SOA mentor program to their IT certification program.
Just email fedsoa@us.ibm.com to register for the program. There's a real world meeting on Sep 12, but everything else is through email and webex.
You still need to pay for the exams, but free classes are cool.
Just email fedsoa@us.ibm.com to register for the program. There's a real world meeting on Sep 12, but everything else is through email and webex.
You still need to pay for the exams, but free classes are cool.
Labels: SOA
¶ 9:13 PM 0 comments
2007-08-31
Anti-Anti-SOA
My google alert picked up Stefan Tilkov's post agreeing with Radovan Janecek's Anti-SOA post. So I will add in my own equally valid opinion to this chain.
To recap, Stefan and Radovan think that commonly accepted infrastructure pieces like ESBs and BPEL are actually detrimental to SOA.
While some of their points are accurate (encouraging P2P service communication rather than funnelling all SOA traffic through gateways or intermediaries), the term Anti-SOA is just provacative.
ESB/WSM/BPEL are all valid components of SOA infrastructure because they all serve valid purposes. Trying to create and maintain a single ESB or a single BPEL engine is fruitless, but so is trying to build a highly available, extreme transaction environment without orchestration, transformation, reliability, security, etc that these tools provide. (sorry about the run on).
My experience is that if you try to deliver on a good SOA without providing the appropriate infrastructure and tools, then you will fail. If you try to create a solid governance policy without delivering the support that you find in ESBs and Registries then it will make your task that much more difficult.
My take on ESBs is that they are a good place to run services and they provide a lot of needed infrastructure (security, transformation, reliability, persistence, orchestration, on and on) that you need to implement somehow. ESBs should not be treated as the end all service environment for an organization and should be designed to work with external and internal partners (especially since that line is getting blurred more and more) services regardless of what kind of implementation provisions and executes the services.
At the end of the day, an organization needs the services provided by an ESB or a BPMS or a Registry/Repository or a Management System. But it is just one piece of the SOA implementation. If a vendor comes by and says ESB = SOA then question loudly and frequently.
To recap, Stefan and Radovan think that commonly accepted infrastructure pieces like ESBs and BPEL are actually detrimental to SOA.
While some of their points are accurate (encouraging P2P service communication rather than funnelling all SOA traffic through gateways or intermediaries), the term Anti-SOA is just provacative.
ESB/WSM/BPEL are all valid components of SOA infrastructure because they all serve valid purposes. Trying to create and maintain a single ESB or a single BPEL engine is fruitless, but so is trying to build a highly available, extreme transaction environment without orchestration, transformation, reliability, security, etc that these tools provide. (sorry about the run on).
My experience is that if you try to deliver on a good SOA without providing the appropriate infrastructure and tools, then you will fail. If you try to create a solid governance policy without delivering the support that you find in ESBs and Registries then it will make your task that much more difficult.
My take on ESBs is that they are a good place to run services and they provide a lot of needed infrastructure (security, transformation, reliability, persistence, orchestration, on and on) that you need to implement somehow. ESBs should not be treated as the end all service environment for an organization and should be designed to work with external and internal partners (especially since that line is getting blurred more and more) services regardless of what kind of implementation provisions and executes the services.
At the end of the day, an organization needs the services provided by an ESB or a BPMS or a Registry/Repository or a Management System. But it is just one piece of the SOA implementation. If a vendor comes by and says ESB = SOA then question loudly and frequently.
Labels: SOA
¶ 9:14 PM 0 comments
