Friday, February 6, 2009

Single Service: Multiple Interfaces – Service Design Pattern

In one of my recent project, I encountered an interesting challenge. There was couple of services. Each of these services needs to serve various consumers which have diverse background. Few of the customers were interested in one type of interface (Web Service) while other set of consumers were demanding SOAP over JMS, CORBA calls and few more. This was interesting situation. My SOA instinct told me to look for solution in ESB. But none of ESB was able to provide such diverse channel transformation. Then I discovered that solution lies some where else.

“A service should have multiple interfaces in terms of technology & business needs if ESB fails to provide.”

I realized from analysis of various other projects that this is a pattern which is quite prevalent but not explained in detail. I call this pattern Single Service: Multiple Interfaces.






Discovery of this pattern also leads to another pattern – Separation of Service Implementation and Service Interfaces. I will discuss this pattern in detail in some future post.
Posted by tjain at 8:34 PM
Labels: , , , , , ,

3 comments:

  1. purushottamanFebruary 13, 2009 at 4:08 AM

    Hi Tushar,

    Nice post.

    I have a question on the implementation of a service transaction control and a BPEL transaction control in the SOA suite. I have done a study based on the OASIS Business Transaction Protocol specification and also the following WS specs based on WS-Transactions, WS-Coordinations, WS-BusinessActivity.Is the WS-Co-ordination framework and WS-AtomicTransaction standards available out of the box from the oracle soa suite. Though I have already worked on the design similar to these standards, any existing example or implementation available out of the SOA suite will be beneficial.

    Thanks,

    Purushottaman

    ReplyDelete
  2. tjainFebruary 20, 2009 at 6:14 PM

    Hi Purushottaman,

    In this blog I prefer to stay focused on SOA, BPM/EPM, EAI and Architecture and platform independent. I will appreciatr if you visit my another blog http://oracle-fusion-middlware.blogspot.com/ where I focus on platforms e.g Oracle Fusion Middleware, TIBCO, web Method, JBoss, etc.

    ReplyDelete
  3. AntonAugust 3, 2012 at 7:14 AM

    Hi Tushar,

    You say that multiple interfaces for a single service are possible in a SOA environment. However your example is only based on a "technology gateway" kind of problem - need to close a gap in the technology stack with multiple types of consumers.

    What do you think about a scenario where multiple interfaces are defined, to be able to collaborate on the same data. That is under the assumption that no two services can share the same database, i.e. data ownership has to be strictly defined for each service.

    There would be cases like:

    1. Customer service with a Customer DB. One interface is CustomerManager and another interface is ItineraryManager, both working on the same DB. A worse option would be having CustomerService and ItineraryService accessing the same Customer DB. Do you agree with that example?

    2. Game Service with a Game DB. Capabilities provided are "game contract store", "game signup", "make game predictions", "game resulting", "game payout", "provide game predictions history". How would you recommend to name the interfaces, one for the game (rules) management, and another for the history (separation choice can be different), without confusing the consumers across the company? Do they need to know that they access the same service, or not, i.e. should interfaces be transparent to them? Options would be to have GameManagement(Service) and GameHistory(Service), or even GameManagementInterface/GameHistoryInterface?!

    Hope you get my question, on how to define interfaces for the public without causing confusion about what are the building blocks of the system.

    Regards,
    Anton

    ReplyDelete

Subscribe to: Post Comments (Atom)