a mashup-based strategy for migration to web 2...a mashup-based strategy for migration to web 2.0 7...

A MashupA Mashup--Based Strategy for Migration to Web 2.0Based Strategy for Migration to Web 2.0 1

A MashupA Mashup--Based StrategyBased Strategyfor Migration to Web 2.0for Migration to Web 2.0

Dr. Semih Çetin


Content

Statement of the problem and motivation

A proposal for Web 2.0 migration strategy

Closing remarks

Existing technologies and approaches


Statement of The ProblemStatement of The Problem


Service-Oriented Computing (SOC) is a fact today

• Service-Oriented Computing is multi-faceted fact with:� Architecture (SOA – Service-Oriented Architecture)� Computing platform (ESB – Enterprise Service Bus)� Business model (BPM – Business Process Management)

• SOC is somehow “The Next Big Thing” (Gartner):� 80% of all software efforts will be based on SOA by 2009.� 60% of the $527 billion IT professional service industry will be

based on exploiting Web Services.� Next generation Web (Web 2.0) will be the global SOA

platform for applications.� Web itself will be the global ESB containing several sub-ESBs.

• Service-Oriented Computing is not “easy to achieve”.


Difficulties of Service-Oriented Computing

• No common understanding� A fundamental architectural style?� A phenomenon to separate building blocks?� A composite scheme for business process management?� A holistic view covering all of the above?

• Narrow drivers, broad ambition� Will it cut off the future costs?� Do we know to define the impact?

• Skepticism – a need for cultural change� The technology doesn’t work all the time.� It is not for us.� What about the millions of $ cost for existing investment?

• Maybe, the most challenging issue is “migration”.


What business wants...

The Business Back Office Systems

WebPortal

OrderEntry

PayBill

SendGoods

SwiftAdapter

OracleAdapter

PeoplesoftAdapter

SAPAdapter


How many adapters do you need? (250+)Adapter Classes� Data Adapters:

Provide a relational view of proprietarydatabases and file systems

� Application Adapters:e.g. SAP, Siebel, PeopleSoft, JDE

� eBusiness Adapters:e.g. EDI, SWIFT, cXML, HIPAA

� Transaction Adapters:e.g. CICS, IMS, Tuxedo

� Emulation Adapters:e.g. 3270, 5250

� Touchpoint Adapters:e.g. Bill of Materials, Chart ofAccounts, Purchase Order, SalesOrder, Work Order & more

� Program Adapters:e.g. 3GL, 4GL, etc.

ADAPTERS

ADAPTERS

Data

Application

Touchpoint

Program

Emulation

eBusiness

Transaction


Barriers: Moving to Service-Oriented Computing

• B2C Integration� Web 2.0� AJAX� Rich Internet Applications (RIA)� Representational State Transfer (REST)?

• B2B Integration� Enterprise Internet Applications (EIA)� Web Services (SOAP) or something else?

• Non-Functional Requirements (NFRs)� Quality of Services (security, performance, robustness, etc.)� Architectural modeling?� Frameworks, Enterprise Service Busses, Infrastructures?

• Service enablement of today’s legacy applications?


Existing TechnologiesExisting Technologiesand Approachesand Approaches


Cybersoft Research on Web 2.0 Migration


Moving to Web 2.0: Critical points for success...• Web 2.0 does not have generic roadmap as a “silver bullet”

� Different legacy assets� Different technologies� Varying requirements (both functional and non-functional)

• Web 2.0 is technology-based� Requires better infrastructures� Necessitates better tools

• Web 2.0 is business-oriented� Needs better models� Requires business people involvement� Should be enriched by “declarative environments”

• Web 2.0 is a strategy� Should have “strategic” and “tactical” plans� Should have a “reuse” strategy even in migration� Return of investment should be “crystal clear”


Migration Approaches to SOC by Early 2007


A Proposal forA Proposal forWeb 2.0 Migration Strategy:Web 2.0 Migration Strategy:

MMigrigrAAtion totion to SServiceervice HHarmonization comparmonization compUUtingting PPlatform (latform (MASHUPMASHUP))


What is MASHUP?• Provides “harmonization” of

� Different legacy service enablement assets� Different software technologies� Varying requirements (both functional and non-functional)

• With� Domain specific wrappers� A common Choreography Engine

• Using� Domain Specific Languages (DSLs)� Domain Specific Engines (DSEs)� Domain Specific Tools (DSTs)

• Based on� Software Factory Automation (SFA)� Service Asset Meta-Modeling (SAMM)� Model-Driven Development (MDD)


MASHUP is based on “Service Mashups”

RelationshipRelationshipManagementManagement

RichRichContentContent CollaborationCollaboration DiscoveryDiscovery

Web 2.0Web 2.0

SOASOA

COMPOSITIONCOMPOSITION

Single User / AppSingle User / App Global User / AppGlobal User / App


Software Factory Automation (SFA) Approach

Industrial Factory

Programmable Logic Controller (PLC)

Development Environment (DE)

Computer Language (CL)

Programmable Processor (PP)

Software Factory

Domain Specific Kit (DSK)Domain Specific Engine (DSE)

Domain Specific Language (DSL)

Domain Specific Toolset (DST)


An Example to DSK (1): RDBMS

• RDBMS is a business domain independentbusiness domain independent technologyto be used without extensive programming efforts.

• SQL is generic enoughgeneric enough to be a DSL.• SQL is abstract enoughabstract enough to be used in wide variety.• SQL is flexible enoughflexible enough for loosely-coupled designs.• RDBMS is versatile enoughversatile enough to take part in choreography

via different protocols: ODBC, JDBC, ADO, DAO, XA, etc.

DSK

DST

DSL

DSE

RDBMS

Interactive SQL &DBA Utilities

Structured QueryLanguage

Query Listener /Executer


An Example to DSK (2): Web Server

• Web Server is a business domain independentbusiness domain independent technology to beused without extensive programming efforts.

• HTML/XML is generic enoughgeneric enough to be a DSL.• HTML/XML is abstract enoughabstract enough to be used in wide variety.• HTML/XML is flexible enoughflexible enough for loosely-coupled designs.• Web Server is versatile enoughversatile enough to take part in choreography via

different protocols: HTTP, Socket, RPC, etc.

DSK

DST

DSL

DSE

Web Server

HTML AuthoringTools

Hyper Text MarkupLanguage & XML

HTTP Listener /Script Executer


Overview of The MASHUP Approach


Software Factory Automation Model for MASHUP

Service Asset Model

Development & AdministrationEnvironment

Service Orientation Reference Architecture

DSK DSK DSK DSK DSK

ProcessAnd

ServiceQualityModel

A Software Factory

ServiceAsset

Repository

Software Factory Automation for Service-Oriented Computing

Reference Architecture Modeling

Service Asset Meta Model Process Model

DSKDST

DSL

DSE

Screen Scrappersfor Mashupsat B2C Level

Legacy Wrappersat B2B Level


MASHUP Methodology (1)• Step 1: MODEL

� Models target business requirements� Business model is expressed using a

semantic notation (e.g. BPMN)

• Step 2: ANALYZE� Analyzes existing legacy systems� Quality of Service (QoS) attributes are

identified� Important data for Domain Specific

Kits (DSKs) and reference architectureare revealed

• Step 3: MAP & IDENTIFY� Maps functional and non-functional

requirements to DSK components andcomposability issues for choreography

� Business Requirements to Services(B2RS) are determined

� Service to Service (S2S) requirementsare determined


MASHUP Methodology (2)• Step 4: DESIGN

� Designs a concrete Mashup Serverwith DSKs

� Proper DSKs should be identified andassociated languages, engines, andtoolsets are developed

� Choreography Language is structuredaccordingly

• Step 5: DEFINE� Defines Service Level Agreements� Service repository is created� QoS associations are described

• Step 6: IMPLEMENT & DEPLOY� Implements and deploys the system� Screen scrappers are implemented for

service mashups and back-endfunctionality is wrapped by DSKs

� Components are deployed ontoChoreography Engine


Closing RemarksClosing Remarks


MASHUP Approach

• enables the context awareness and dynamic compositionof legacy services via domain specific wrappers.

• does not re-engineer the existing source code.• harmonizes the SOAP and REST models by means of a

common Choreography Engine.• improves the competitiveness of enterprises by moving to

SOC fast and in a reusable manner.• allows the dynamic harmonization of modern and legacy

services.• ensures the Quality of Services with an architecture-based

and domain specific approach.• provides declarative environments for business people.


Why MASHUP is different

• Mashes up� B2B Web Services with SOAP� B2C Client Integration with REST (screen scrapping as needed)

• Ensures Quality of Services with� Reference architecture modeling� Domain specific wrappers

• Provides service interoperability through� Service Asset Meta-Modeling (SAMM)� A common Choreography Engine

• Maximizes the service reuse by� Common service asset model� Service asset repository (quick discovery of services)� Migration strategy wrapped by Domain Specific Kits


MASHUP WorkplanMASHUP is 36-months project� Detailed Business Plan is ready� It has 8 Work Packages� It requires collaborative research

and industrial partnership� 10 technical papers have already

been published and presented� A Ph.D. Thesis has been completed

for background research andpreliminary implementations


What we look for...

• Strategic Partner for� Investing in the research and development of MASHUP� Using and marketing MASHUP for real-life cases

• Research Partners for� Stabilizing the solid research background� Exploring the “what-if cases” collaboratively

• Industrial Partners for� Developing Legacy Service Wrappers (DSKs)� Experiencing and improving the concept and tools� Creating business channels for MASHUP

a mashup-based strategy for migration to web 2...a mashup-based strategy for migration to web 2.0 7...

Documents