Monday, October 3, 2011

Canonical Best Practices

Here are some quick notes on best practices for creating a canoncial data model that is easily understandable and useable across an organization.

Define clear schema creation guidelines
  • Versioning, namespaces, and naming
  • Use file comments and xsd:documentation
Centralize "common" types and elements in common schemas
  • Define entities shared across schemas in a common schema
  • Have a simpleType schema and a commonTypes schemas

Beware of enumerations (make sure it can be strictly defined and will not change). There are actually very few things that can be represented by a truely definitive list.  For example, most people think the US states are a good example of an enumeration since there are only 50 of them but what about Guam or the District of Columbia or US Virgin Island.

Protocol-independent
  • Create types in domain schema and create separate message schema that contain messages. The message schemas would leverage the domain schemas.  (i.e. Guest.xsd and GuestMessages.xsd)
There are several XML schema design patterns at http://developers.sun.com/jsenterprise/archive/nb_enterprise_pack/reference/techart/design_patterns.html. Over the years we have found that several tools don't fully support the different patterns so care should be taken to make sure your current and future tools support the pattern that you choose.  We prefer a modified Garden of Eden pattern.  It is modified because we don't recommend exporting everything but think of it as an API and expose only the types that schema users want to reference.

Schema versioning is one of the greatest concerns when working with a canonical data model.  Once developers start using your CDM it becomes harder and harder to make changes without impacting the current services.  Determine a standard on how major and minor version numbers will be used to support backward compatibility.  We use minor version numbers to represent changes that are fully backward compatibility and major version numbers to represent changes that require users to modify their code to utilize the new schema.

Define magical words that are used consistantly across all schemas.
  • If 'Id' is used to identify a single object use it consistantly across all schemas. Don't mix Code and Id (eg. CountryId, CountryCode)
  • Use attributes only for metadata and/or optional data
Stay away from edge XSD elements since tool vendors support them differently
  • xsd:any
  • xsd:substitutionGroup



Executing on SOA strategy

Sitting in a packed house watch Eben Hewitt discuss Executing a SOA Strategy and sharing his experiences with rolling out SOA at Choice Hotels. Good services need to have several attributes:

- Strong interface
- interoperability
- reusable & composable
- standard contract
- independent lifecycle
- discoverable and governable - not necessary from the beginning but needed quickly after first services are rolled out.

Criteria for a pilot project:

- Meaningful business value but don't bet the farm
- non-mission critical
- flexible delivery data
- don't cross organizational boundries
- make sure you have a good executive sponsor

A nice shout out from Eben for the help with the SOA Maturity model.

Don't confuse and merge SOA governance and SOA Compentency Center.  They have different but complementary roles in an organization.

SOA compentancy Center
- Act as a focal point for training and knowledge transfer
- Early adopters of new technology so they can set direction of where and how to use various tool sets
- Act as a deep bench to development teams when additional SOA bandwidth is necessary

Using SOA tools does not mean you are doing SOA. All of your SOA concepts should be tool independent.  Make sure you don't buy tools and then recreate the current state diagram using the new tools.  Look at how the current state diagram can be improved by SOA independent of the tool.


Tuesday, September 13, 2011

Oracle Service Bus (OSB) and JCA Adapters

We were recently working on a project that had the need to create a custom JCA adapter to connect from the OSB to a legacy C application.  We figured this would be something fairly easy to do since the WebLogic Server, BPEL and OSB all support JCA adapter out of the box.  It turns out that the current OSB (11g) doesn't fully support the JCA adapter specification.  It only supports the following JCA compliant adapters provided by Oracle:
  • Oracle Adapter for Oracle Applications
  • Oracle JCA Adapter for AQ
  • Oracle JCA Adapter for Database
  • Oracle JCA Adapter for Files
  • Oracle JCA Adapter for FTP
  • Oracle BAM Adapter
  • PeopleSoft Adapter
  • SAP R/3 Adapter
  • Siebel
  • J.D. Edwards
The OSB already has transports that support File/FTP so these really are not needed.  We actually tried using these on the bus and didn't have much success so quickly reverted back to the built in OSB functionality.

Anyway, we were looking for a way to utilize the custom JCA adapter on the bus and came across the OSB Transport API. It appeared that this would do the trick but seemed extremely complicated so we kept digging. We eventually settled on deploying the JCA adapter to the WebLogic Server and writing a small wrapper class that made it easy to access the adapter with a JNDI lookup. 

We were then able to simply use a Java Callout from the OSB to access the adapter.  This is obviously not the most elegant solution but has proved to work extremely well.  We were a little concerned about performance so we did a little testing.  We were able to push a single WLS managed server to over 3,000 adapter calls/second which is more then sufficient for our application. 

A few details:

  • The JCA wrapper class takes and returns an XML document as a string
  • It then uses JAXB to marshall/unmarshall it and calls the adapter
  • The marshaller has been optimized to not destory itself every time to prevent marshalling bottlenecks
  • The JCA wrapper also caches the JCA connection information

Monday, July 11, 2011

Which SOA Suite tool to use when reading a JMS topic

We have been doing a lot of event driven architecture with our clients lately and one question that comes up a lot is which SOA Suite component to use as the consumer. There are a couple of options available: OSB business service and BPEL using the JMS adapter.

Ideally you would like to use the OSB for its performance, statelessness, and low overhead but there is little gotcha that is pretty important when reading from topics. The current version of the OSB (11.1.1.5) doesn't support setting the JMS consumer name. The OSB auto-generates the JMS consumer name that is pretty unreadable and impossible to determine the client it is associated with. When connecting to a topic this is very important because that is the only way to know which consumers are connected to the topic and which ones are missing.

The JMS JCA adapter used by BPEL allows the developer to set a meaningful name to a durable subscriber. This makes it really easy when looking at the list of durable subscribes on a topic to determine which consumers are connected and listening and which consumers are not there. BPEL has some additional overhead (dehydration) but in most cases this can mitigated making the BPEL with JMS JCA adapter the better choice.

Wednesday, June 1, 2011

Service Based Chaos

A lot of companies that I come across become a victim of their own SOA success. They successfully complete their first project and the word gets out about the potential of SOA. This leads to many groups wanting to take advantage of the benefits of SOA. This is a good thing right???? The problem is processes, governance, and standards are normally an after thought when trying to get the first project out the door.

It is not a big problem during the first project because the team is normally small and the scope is controlled. Once the gates start to open up and new developers outside of the initial project are added with different skill levels chaos normally ensues. This is because there is little to no time to focus on best practices, standards and processes to share knowledge and put controls in place on the new projects. This leads to service based chaos.

Here is a link to a podcast that I did with Oracle that covers this topic and how we help a client avoid issues.

http://streaming.oracle.com/ebn/podcasts/media/10048058_Choice_Hotels.mp3