Enterprise Abstraction

RSS in Plain English

Darren Barefoot posted about this nifty video RSS in Plain English by Common Craft. 

There are two types of Internet users, those that use RSS and those that don't. This video is for the people who could save time using RSS, but don't know where to start.
I love the explanation, as well as the format of the presentation.  Probably not news for most of you, but a useful link when you're trying to explain RSS to people.  The web's not about web pages anymore.

At my organization we'd always talked about producing new technologies at the pace of "web time".  Perhaps we should be striving to get our information out in "blog time" instead?  Visiting web pages one at a time seems so old fashioned and slow these days.  It's amazing how perceptions change.

Rise and fall of Corba

The Rise and Fall of Corba (ACM Queue, Vol 4, No. 5, June 2006) describes the good, the bad and the ugly of Corba, and issues warnings to avoid the same with current initiatives for web services standards.

The short version of the article:  Corba sucked because of complexity and in-fighting and it is the fault of the overly democratic process at OMG.  From the article:

A democratic process such as the OMG's is uniquely ill-suited for creating good software. Despite the known procedural problems, however, the industry prefers to rely on large consortia to produce technology. Web services, the current silver bullet of middleware, uses a process much like the OMG's and, by many accounts, also suffers from infighting, fragmentation, lack of architectural coherence, design by committee, and feature bloat. It seems inevitable that Web services will enact a history quite similar to CORBA's.

Public Review Draft WS-BPEL 2.0

IT Toolbox reports:

Last Thursday, August 24 the OASIS BPEL Technical Committee published the first Public Review Draft of WS-BPEL 2.0. This is a major milestone that many folks have been awaiting for nearly 3.5 years – since the spec was donated to OASIS.

See the Public Review Draft of WS-BPEL 2.0

SOA and libraries

Richard points out a posting by Peter Murray of OhioLink regarding his search for SOA related materials and standards with regard to libraries, an area in which both Richard and I have a keen interest.

At CISTI we've been moving forward in our efforts to define a set of core library services to support the organizations upcoming business needs, and it's quickly becoming apparent to us that these services are prime candidates for reuse well beyond our own walls. 

Of course, we could wait for all the standards groups to work and come to consensus... but past experience shows that to be a failing strategy where most technology is concerned.  I guess we'll just follow the best practice path, and hope that we create services that are malleable enough to conform if need be in future. 

If VHS vs Beta has shown us anything it's that it's not always the BEST standard that wins, it's the one that was made open and available with at least reasonable quality.

Web service standards poster

This poster of web services standards - available in PDF format, is just nifty.  It reminds me of a similar one in the information science community called the metamap - Warning - Adobe plugins and such may be required for viewing.

The MetaMap is a pedagogical graphic which takes the form of a subway map. Its aim is to help the information science community to understand metadata standards, sets, and initiatives of interest in this area.

Service naming standards

I've been doing some hunting to follow up on my previous posting regarding web service naming conventions and standards.  The pickings are slim.  Thomas Erl, a Canadian SOA expert and author, mentions some SOA naming conventions in an article he wrote for Oracle entitled Standardizing Service Endpoints. 

He prescribes a practical approach, naming services based on the utility (verb), entity (noun) or task/function (verb-noun -- do something to something), dependant on the scope and context of the service.  He also warns about ensuring that operations within the service reflect appropriately the scope of the service, and to eliminate redundancy in operation names.

From the article:

• The utility-centric context is found in application services involving operations that encapsulate cross-cutting functions, such as event logging, exception handling, or notification. These reusable services need to be labeled according to a specific processing context, agnostic in terms of any particular solution environment. For example, a utility service might be named Notify.
• An entity-centric context is established in a business service that represents a specific business entity, such as an invoice or a purchase order. The labeling of entity-centric business services is often predetermined by the entity name. For example, a service may simply be named Invoice or Customer.
• Task-centric contexts are required for services modeled to encapsulate process logic. In this case, the thread that ties together the grouped operations is a specific activity being automated by the service logic. Therefore, the use of verbs in service names is common. For example, a task-centric service may be called GetProfile or ProfileRetrieval, if that accurately represents the task's scope.

As with service names, labeling individual service operations is also a process that should be subject to standards and guidelines and for which there are already several best practices.

For example, the naming of the service itself ought to influence how the individual operations are labeled. Because a good service name will already clearly establish a meaning and a context, operation names should be streamlined to avoid the use of redundant wording. Take an operation that retrieves invoice history data for a service named Invoice. This operation does not need to be labeled GetInvoiceHistory, because the invoice context is already established by the service name. GetHistory would be sufficient.

Thomas really helped us move forward with our SOA initiative at CISTI both with a workshop to bootstrap our process, and through his books. 

What's an ESB

ZDNet asks:  What's an ESB?  It seems to me the best definition is that it's a burgeoning new market for a lot of software companies.  That always makes me a bit wary.

Wikipedia defines an ESB as:

an enterprise service bus refers to a software architecture construct, implemented by technologies found in a category of middleware infrastructure products usually based on Web services standards, that provides foundational services for more complex service-oriented architectures via an event-driven and XML-based messaging engine (the bus). An enterprise service bus generally provides an abstraction layer on top of an Enterprise Messaging System which allows integration architects to exploit the value of messaging without writing code. Contrary to the more classical EAI approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary.

perhaps we should all contribute our thoughts in that forum.

Ron Ten-Hove offers the more succinct:  " An Enterprise Service Bus (ESB) is a distributed middleware system for integrating enterprise IT assets using a service-oriented approach."   It may be worth mentioning that Ron and others have been working on the Open ESB project.

Do I need one?  I'm not sure.  I've heard many say that with good planning of services, and a well thought out infrastructure, depending on your needs and circumstances, and ESB is not required, but that it could certainly make life easier.

A strategy I've heard is that it's wise to plan your services as if you don't have one, and are not going to have one... essentially treating the ESB as an addition or an afterthought, thereby encouraging robust and efficient service design.  Sounds like sage advice.  I've also heard that a good governance structure around SOA would be important before implementing an ESB. 

Perhaps then it would be best to wait until things are a bit more mature before diving into the still undefined world of the ESB?  It seems pretty clear that a good strategy would be to concern ourselves with the architecture first, and ESBs second.

Web service naming convention

A developer recently asked me about standards for naming web services.  I have no idea.  Our architecture standard names components as "verb noun" phrases, so I suggested things like:  "AuthenticateClientService" and "FindDocumentService".  Yes, the "Service" portion does seem redundant, but we're thinking that it will help readily identify it when referenced out of context in future.

Is there any sort of convention for naming web services in the enterprise?

Mr. Malik asked the question awhile back, but that's all I've been able to find, and it seems no answer was provided.  The many examples of WSDL's I've seen lack consistency, and seem to rely on the whim of the creator.

Your suggestions and pointers are requested and welcome.

UPDATE:  I discovered some info on good service/web service naming practices.

OASIS SOA reference model accepted

 Duane Nickull has announced the release of an SOA reference model from OASIS.

The OASIS Service Oriented Architecture TC will develop a Reference Model for Service Oriented Architecture. This is primarily to address SOA being used as a term in an increasing number of contexts and specific technology implementations. Sometimes, the term is used with differing - or worse, conflicting - understandings of implicit terminology and components. This Reference Model is being developed to encourage the continued growth of different and specialized SOA implementations whilst preserving a common layer of understanding about what SOA is.

Duane describes it as "the first true public standard to describe SOA".  A problem that's been looking for a solution for some time.  One that I've encountered first hand. 

I can't seem to get access to the newly published SOA Reference Model for Committee Specification (membership required it seems), but a draft is available.

SOA explained and defining architecture terms

By far the best introduction for the layperson I've seen on services and SOA is the article What Is Service Oriented Architecture by Hao He at xml.com.  It's slightly dated and get's mildly technical at the end, but it gets the idea across in a single page.   I particularly like the quote (and indeed personal architecture principle):   "Things should be made as simple as possible, but no simpler", by Albert Einstein.  Another excellent resource is the ABC's of SOA by CIO Magazine which is a bit longer, but broader in scope and more up to date.

I don't believe that everyone needs to know how the architecture process works within an organization.  Indeed, if you're running your architecture as a service, then most don't need to know much at all except what goes in (business desires) and what comes out (wonderful excellent plans and implementations that move the business efficiently forward).

I do believe that the business needs to understand the ideas of architecture, including services and SOA.  One of the most effective ways to do that is to define your terms in the context of your enterprise.  Services, web services, business services, product, offer, even client can cause all kinds of consternation and risk.  Particularly if the groups your communicating with not only don't understand the terms, but where each group and individual applies their own meaning to the terms.  Business terms must be understood uniformly across the business.

My humble advice would be:  as early as possible, take the time to sit down with your architecture business stakeholders and define these terms.  Come to a consensus... even make up common terms if you must, but you must all be on the same page with the same nomenclature in the end.  Then, use the terms, and correct mis-usage.  The few minutes spent in the exercise will be worth a complete library of books and papers explaining these terms and concepts, and will be invaluable when you meet next time to discuss ideas.