jump to navigation

SDP(Service Delivery Platform) Intro-from SOA perspective September 15, 2009

Posted by Terry.Cho in Architecture, SDP.
Tags: , , , ,
2 comments

Initiative

Common Telecom trend is Service Delivery Platform (SDP).

Telecom system has two challenges. Their business and technical platforms are changing very quickly. During few years they have been have a lot of platforms like Google Android, Microsoft Windows Mobile, Apple IPhone,Black berry,Symbian platforms. And service is extended from simple voice call & SMS to Multimedia service, application, Location based service etc. Following these business change they have to develop new application and integrate with legacy applications. Because telco has a lot of protocols and network layers (SIP,Paray-X,VoIP etc). Integration is getting more harder and complex. So they now need integrated and unified service platform to adopt business change quickly. This is the reason why SDP is required.

SDP is “Telco specific version of SOA”.

Concept of SDP is very simple. It exposes capability of system with unified interface. It reduces integration costs and let telco company to adopt new requirement quickly.

In addition by providing common services like billing,charging,logging, it removes duplication in implementation. This concept is exactly matched with SOA. So we can call SDP to “Telco specific version of SOA”. Only difference of SDP between traditional SOA is SDP requires network abstraction layer. In traditional SOA we had service enablement layer. It changes legacy protocol (SAP,MQ,Sieble) to unified SOA platform(Webservice etc.). It has been implemented with Adapters (JCA) or Other service enablement layers. In same way SDP has same abstraction layer. If traditional SOA communicated with legacy APPLICATION, SDP communicated with legacy NETWORK APPLICATION (SIP application, SMSC application, Paray-X based Application etc.). So in SDP there is network abstraction layer with network adapters.

Another difference between SDP and traditional SOA is SDP is B2C system (Service system). Traditional SOA is commonly designed for internal enterprise. SDP provides service to end user device (Mobile device, IP TV, Voip phone etc). So SDP covers more number of users than enterprise system and requires more faster response time. And message flow is more simpler than enterprise. As a result SDP has to have simple architecture to support fast response time, huge scalability.

Common architecture of SDP

Let’s think about common SDP architecture. SDP has 3 layers in the internal.

sdp

Ÿ   Service enablement layer

Network based application like SMS,VOIP has own protocol. Service enablement layer abstracts this network application and expose the capabilities with unified message protocol. By doing this user easily can use network based application without telco specific technology.

Service enablement layer also covers legacy integration. SDP can be integrated with legacy business system. For example Billing and Charging system in SDP can be integrated with Financial modules in ERP system. So Service enablement layer expose capability of legacy business system.

As a result the service enablement layer abstracts all of technical differences and let user can see the legacy components with same way.

Ÿ   Service component

Service component is software system that provides capabilities. Like SOA services. In SDP we have common services for telco system.

For example Contents Management, Billing, Charging & Rating, User Profile Management, Location Based Management. These components are implemented over specific vendor solution.

Commonly customer already has the service components. In that case abstract legacy service component and delegate the service in this service component layer.

Ÿ   Service exposure

Service components are exposed by this layer. This layer provides infrastructure of service.

For example it orchestrates existing services and make a new function. Mediate existing service. I will not describe this layer detail because this layer is same as traditional SOA concept (Orchestration with BPM, Mediation & single entry point with ESB etc)

Oracle solution mapping

Oracle has products that implements SDP.

SOA suite

For service exposure and service component development SOA suite is right for the requirements.

Oracle Service Bus is positioned for single entry point of SDP. And it enables service mediation. Complex service orchestration and long running process is implemented with Oracle BPEL/PM.

Oracle BPEL/PM also used for legacy system integration with various legacy adapters.

Oracle Coherence is used for storing & caching data. It is useful to manage & caching user profile data.

ODI is used for data provisioning between service components. And also can be used in contents provisioning.

Oracle WebLogic Server is used for component implementation with middleware features. It hosts component.

OCSG

It is used as network adapter in SDP. It supports specific telco protocol and expose the service to SOA platform. It also supports partner management and billing etc. Some capability can be duplicated with SOA platform or legacy business application. In that case based on business scenario, design should be considered.

OAAS

Like OCSG it enables network abstraction. But it just support SIP based application.

Conclusion

Common problem in SDP project is nobody can define SDP. SDP is de-facto standard. There is no standard reference architecture. So definition of SDP is different depends on industry. (Mobile, IPTV, VoIP etc.)

Think about SDP simple. SDP is telco specific SOA. It needs network adapter in addition to traditional SOA. And it is B2C system. It means it requires more concurrent user , faster response time and more simple architecture (message exchange format) than enterprise system. After understanding these characteristics of SDP, SDP is not hard to understand anymore.

ESB Design Pattern – Generic Proxy Pattern August 19, 2009

Posted by Terry.Cho in Architecture.
Tags: , , , , , , ,
3 comments

Generic Proxy Pattern

The Generic proxy pattern is a design pattern for ESB to reduce factory job and provide more flexibility to ESB design. Oracle ESB has 2 service types.

  • Business Service : This service provides a delegate for the real web service. It is used as a interface for real webservice.
  • Proxy Service : This service has mediation pipeline to provide flexibility for business service access. It covers transformation, routing, adding of new functionality and sometimes includes service orchestration.

One issue in OSB design proxy service is that normally we have cross cutting concerns like logging,authentication,authorization etc. Typically in OSB, we have to implement these in each proxy service. This introduces a lot of factory work and reduces system flexibility as changing cross cutting concerns becomes more difficult.

For example, we can implement logging with a Java call out in OSB. We can put the call out  into each proxy service. If we change interface of the java-call out class, we have to change all of proxy service in the system. The Generic proxy pattern helps us to remove this factory job.

Today with introduction of WEB 2.0, there are a lot of defecto standard protocol like XML/HTTP RPC, REST,JSON etc. Sometimes SOA systems have to support these kinds of protocols.  The generic proxy pattern provides a protocol converter.

Generic Proxy Pattern is consists of four layer.

genericproxy

  1. Edge Proxy (Inbound) :  This is entry point of our ESB. It covers protocol conversion to internal SOA protocol. (Web service)
  2. Common Proxy : This is point to handle cross cutting concerns for system – Authorization,Authentication,Logging,Billing etc. And route the service request to appropriate local proxy.
  3. Local Proxy : It is one-to-one mapping to Business service. It can just forward request to business service. OR it contains mediation logics (Intermediary logic – Transformation, Routing, Function adding etc)
  4. Edge Proxy (Outbound/Optional) : This proxy is another edge proxy for outbound protocol conversion. This is optional. In our architecture internal protocols are integrated with webservice. This proxy is used for legacy integration.
  5. Business Service :  There is some design options.

In type of service, we can provide internal service and external service. Internal service is for internal system and it doesn’t need any security checking. The security checking is covered by firewall etc. In that case we can separate Edge proxy&Common proxy to external and internal.

In the edge proxy we can separate internal and external service with URL prefix. Http://myplatform/internal/serviceURI Http://myplatform/external/serviceURI.

And each edge proxy uses internal common proxy and external common proxy. In internal common proxy we remove security related logic & billing related logic.

Logical proxy and business service are reused same way for external and internal exposing.