A Table of Contents for a Detailed Design

While this is not a Standard Template and should not be treated as one, it is the result of my attempt to come up with A Table of Contents for a Detailed Design Specification using WebSphere Process Server.

1: Purpose of the Document
The need for a detailed design document is authored here.
2: Scope of the Document
List out specifically what the document covers and excludes.
3: Solution Overview
This section will give a brief background of the implementation of the solution.

4: SCA Elements
All elements of Business Transactions are referred to as Service Components. Examples of SCA elements are as follows:
Access to Web Services
Enterprise Information System Service Assets
Business Rules
Workflows
Databases
This section should list out the SCA Elements.

5: Business Objects / SDO (Service Data Objects)
Business objects define the data flowing between SCA components. Business objects provide an abstraction for data access and are based on a data access technology called Service Data Objects (SDO). SDOs provide a universal means of describing disparate data. Business objects provide rich features to map, manage, and transform data to underlying IT and are described through a standards-based XML schema
This section should list out the SDO’s in detail.

6: CEI
Common Event Infrastructure and the use of a Common Utility Framework for the purpose of:
Logging
Auditing / Archiving / Re Processing
Error / Exception Handling
Notifications
Security
With the Common Event Infrastructure (CEI), service components can emit events that can be captured by business monitors such as WebSphere Business Monitor for real-time monitoring of business processes.
This section should List the specific Events that will be handled by the CUF/CEI.

7: Supporting Services
Supporting services are components that are needed in any integration solution, including data transformation and synchronization services. This Section will list the details of the Supporting Services.

Mediation Flows
WebSphere Enterprise Service Bus provides the ESB functionality, with mediation flows that can operate on messages to perform
• XML-based data transformation
• protocol transformation between various transports
• custom Java operations
• routing
This section will detail out all the mediation flows

Interface Maps
Using interface maps, you can invoke components by translating calls to them. It is possible for interfaces of existing components to match semantically but not syntactically. This is especially true for components that already exist and services that need to be accessed.
This section will detail out the Interface Maps

Business Object Maps
Business object maps, you can translate one type of business object Into another type of business object. You can use these maps in a variety of ways, for example, in an interface map to convert one type of parameter data into another.
This section will detail out the BO Maps

Relationships
You can use relationships to establish relationship instances between object representations of the same logical entity in disparate back-end systems. For example, the same customer’s address might need to be updated in various back-end systems, such as an enterprise resource planning (ERP) system and a customer relationship management (CRM) system. These relationships can be established and managed automatically using the relationships service component. These relationships are typically accessed from a business object map when translating one business object format into another.
This section will list the relationships to be accessed from a BO.

Selectors (Dynamic Service Selections)
You can use selectors for dynamic selection and invocation of different services, which all share the same interface. WebSphere Process Server offers a Web-based interface to enable dynamic updates to the selection criteria and target services, which means that a module that has been deployed at a later time can still be called by this selector component, enabling dynamic changes to the integration solution
This section lists out the Dynamic Service Selections.

8: SCA Element Implementations:
There are Multiple ways of implementing a SC Element
Business Processes
A business process component implements a Business Process Execution Language (BPEL)-compliant process. You can develop and deploy business processes that support long- and short-running business processes and a compensation model within a scalable infrastructure. You can create BPEL models in WebSphere Integration Developer or import from a business model that you have created in WebSphere Business Modeler or any other modeling tool that supports the BPEL standard.

Human Tasks
Human tasks are stand-alone components that you can use to assign work to employees. Additionally, the human task manager supports the ad hoc creation and tracking of tasks. WebSphere Process Server also supports multi-level escalation for human tasks, including e-mail notification and priority aging.

Business State Machines
Business state machines provide another way of modeling a business process. Some processes are easily described as a sequential flow of activities, and they can be modeled as business processes. However some processes are driven by events rather than a sequence, and in this case, the business state machine is a better fit for modeling the process. One example is an ordering process where you can modify or cancel the order at any time during the order process until the order is fulfilled.

Business Rules
Business rules are a means of implementing and enforcing business policy through externalization of business function. As a result, dynamic changes of a business process are enabled for a more responsive business environment.

9: SCA Elements Interface (How to call this component)
By definition, an interface is the place at which independent and often unrelated systems meet and communicate with each other. An interface can be defined by any programming or interface definition language. WebSphere Process Server currently supports a Java interface definition and an XML definition (Web Services Description Language (WSDL) port type). The arguments described in an XML schema are exposed to programmers as SDOs. The WebSphere Integration Developer tooling primarily generates interfaces using the WSDL representation.

10: SCA Elements Reference (What this component calls)
An SCA reference specifies other SCA services that a component uses. These can be soft links that do not have to specify which specific component will be used.

12: Project Build & Design
Libraries
List of Project Libraries referenced / used.
Modules
How the Business Integration Module is developed and the artifacts (services choreography into Business Processes) that are built. Any Import, Export and Service Components that are used should be listed here.

13: Assembly & Deployment
How the Module is packaged, deployed and tested in the development/testing/staging/ production environments.

14: Conclusion

15: Signoff

To Do - Marked as "Is Done"! :)

So finally! I am Back! and this time feeling a lot lighter! :) with almost all of my tasks marked finished I am all set to let my hair down and have some fun!

Very soon I would be back to my old habit of mass mailing :) Nope I don't spam and neither do I ever forward. Its always to stop by and say a hi and get in touch with people who are special for me.

So have fun till you get my personal note of "hi" and an update about stuff really moving me right now..

luv as always
~sayli :)

Do you carry the ROCKING DJ REMIX Effect ! ;) :)

Instead of starting out afresh on a Monday Morning in school/college/at work you'd rather bunk and go on a long drive away from the noisy city...

If you are human you'd have these feelings atleast once in a bluemoon..and just when you feel this way you have Radio Mirchi playing "Khwaja mere Khawja from Jodha Akbar" so it makes the feeling even worse!

So what do you do.. well.. dig into tht CD Case and hunt for this [otherwise seems wierd to listen] ROCKING DJ REMIX featuring "Pardesia"! :)

and play this on full volume [with the car windows drawn up ofcourse] to accompany your hubby deary in doing the famous step! (you feel like: Yea Boy! We Rock! Totally!!)

It leaves you feeling so much younger at heart and excited about having to start a gr8 work week!! ;) Sometimes, doing weird things lights up your day - Instantly!

B'Bye to the 'Monday Morning Syndrome!' :);)
Keep Rocking!! :)
~ sayli :)

667 - A Failed Attempt

This is for all those who wish to be:
"An IBM Certified SOA Solution Designer"

Well, I appeared for the test only to discover the following:

1: You must attempt a Sample Paper before you take the final exam

2: SW717, SW718, SW719 aren't sufficient to get you to crack it!

3: The "test your knowledge" sections at the end of those modules arent a per cent close to the kind of questions you would be asked in 667

4: 667 is not for people who have their knowledge and experience restricted to Application/Data/Information/Process integration only WITHIN an ENTERPRISE. It is much beyond just B2C integration or plain application integration.

5: It throws scenarios from varied verticals right from banking to manufacturing and healthcare to telecom.

6: If you thought no one uses MainFrames today - you are wrong. There will be hordes of questions on how you would integrate with CICS/VMS/IMS. So an experience with integrating with MainFrames in a B2B as well as B2C scenario is definitely a plus!

7: and like my Brother Anant mentioned in his sms[which truly made me feel nicer abt myself]: "its imp dat u enjoi ur journey in lyf 2 reach ur final destination nd nt get 2 stresd out over d result of 1 damn certification..take it easy nd b chilled..alldmad rush in lyf smetimes makes us forget d achievements we already have made 4ourslvs.."

8: :) smile ! :) therez always a next time :)

Good Luc to all the to be "SOA Solution Designers"!

lots of luc as always
~ sayli :)

21 Days - An Unsuccessful End..! :)

So the maximum number of days I could religously wake up and stick to my routine was just 7 days in a row.

March 8th - International Womens Day - when we celebrate the achievements of women world over, was the Day I made my 1st excuse and broke my regime - what an Achievement! :)

Thanks to DJ Suketu and the rocking Saturday night Vodafone Annual Party @Pancards - Sunday I oversleep! :)

So with a feeling of guilt of not having exercised 2 days in a row I wake up for a Monday morning Jog and follow it up on Tuesday to fall sick and drag myself to office till Friday.

Come Saturday and I decide to focus on preparing for my certification and hence give up my regime altogether!

But this still doesnt stop me from asking Abhi to buy me new fitness gear and get myself enrolled for Power Yoga n Aerobics ;)

I am at it again ! :)

Being a Fitness Freak helps - but only on Alternate Days - or better still - how about 4days a week ?? :)

so long as the weighing scale pointer doesnt tilt rightways & your tape shows the same numbers ;) :)

~ sayli :)

To Succeed as an EAI Architect

As authored by Eric Roch reproduced here with an inclusion (and slight modification) of only the most relevant and notable facts:

The Career Path to being an EAI Architect must include technical and leadership milestones. Often developers overlook the need for strong written and verbal skills needed to produce coherent design documents and communicate the system vision to a team of developers. Once the design deliverables are in place the architect must then act as a technical lead to ensure the design principals are complied with to produce the components that must work together as an integrated system.

For an EAI architect, there is no way around a strong technical knowledge base. You must know the integration tools intimately to define the role the tools will play in a total solution. A solution typically consists of the EAI tools, application servers, web servers and enterprise applications like ERP systems.

The architect must understand where components of the system should be built and how these components interact to create a composite application. The goal of EAI is to integrate disparate system to function as a one. The systems to be integrated, are essentially the components and message flows, broker orchestrations, adapters, etc. are the integration environment that requires design artifacts defining the component relationships.

We effectively treat systems to be integrated as objects with interfaces and message flows into these interfaces. It is therefore critical that the architect has a solid understanding of OOA/OOD and UML.

Another important aspect of creating architecture is the use and creation of design patterns. This is the fundamental means to reuse design artifacts, so a study of design patterns is a requirement for an EAI architect.

Some design patterns categories that apply to EAI follow:

Enterprise Architecture:

SOA, ESB, Hub and Spoke

Reference Architecture: Composite Applications, Portals, Web Servers

Integration: File Transfer, Messaging, Shared Database

Application Architecture:

Application Server Platform: Model View Controller (MVC) e.g. Struts Model View

Integration Broker: Validate, Enrich, Transform, Route, Operate (VETRO)

Messaging: Publish-Subscribe, Request-Reply, Filter, Routing

Services: Canonicals, Security, Common Error Handler

Business Process Management:

Business: Codified Business Rules

Workflow: Control Flow, Branching and Synchronization, State-Based Instance management and task priority

To Sum it Up:

1. First make sure you have a solid development background in the tool set. You cannot make it to the next level without understanding the tools for EAI.

2. Study OOA/OOD and UML and be able to produce design deliverables with UML.

3. Collect a library of design patterns from books and past projects.

4. Develop your written and verbal skills by looking for opportunities to produce design deliverables and present them to the development team.

5. Look for opportunities to act as a technical lead always seeking to lead bigger efforts to the point where you can lead large projects (from a technical perspective). People skills, negotiation and communication are critical in this step.

I am already acquainting myself with design patterns and a business requirements specification deliverable. Exploring further on both these lines is going to be very interesting.

keep you posted
~ sayli :)

The 7 Disciplines - of the IT Architect Profession

This is the information I came across on the IBM site publicly available to everyone.

Again one of those pieces of information that i wished to archive here to enlighten myself and others alike.

The IT Architect Profession can be classified in 7 disciplines:
1: Application Architecture
2: Enterprise Architecture
3: Information Architecture
4: Infrastructure Architecture
5: Integration Architecture
6: Operations Architecture
7: Systems Engineering and Architecture

The role of the IT Architect involves listening to clients, understanding their business requirements and defining the structure of information technology solutions. They assist clients on their hardware and software infrastructure and help clients decide which platform is best for their applications. They may also lead the technical sales team in their proposal activity. There are roles that include Technical Sales Architects (which can be on a sales plan – see sales roles), or Test architects. Some of the more common IT Architect roles are listed below:

Infrastructure Architect:

This role concentrates on the design of infrastructures including servers, storage, workstations, middleware, non-application software, networks, and the physical facilities that support the applications and business processes required by the client. Included in the focus areas is the critical evaluation and selection of the software and hardware components of the infrastructure. Infrastructure Architects are responsible for performance, availability and scalability of the infrastructure.

Integration Architect:

The primary focus of an Integration Architect is to design and develop solutions that fully integrate and collaborate with existing IT systems in order to perform an automated business function. These solutions may use different technologies, vendors, platforms, and styles of computing. The Integration Architect has a holistic view of enterprise solutions, including a sound appreciation of operational costs, security, performance engineering, application development and systems management.

Operations Architect:

These professionals focus on the design of systems to manage the infrastructure and applications used by the client. This role focuses on defining plans, strategies and architectures for the installation, operation, migration and management of complex information systems. An Operations Architect gathers and analyzes client I/T needs, translates these needs into requirements for specific systems management processes, products, and services, and may lead or advise the teams which install, operate and maintain the I/T system.

Systems Engineer:

This role provides creates technical solutions for customers in the delivery of complex projects/programs, including complex system integration projects. Their responsibilities span the end-to-end lifecycle of a complex project, from system requirements through delivery and production/deployment, providing technical, architectural, and project management leadership to insure overall solution integrity.

Hope it helped.

A Quarter of a Year Nears its End..!

6th of March! Time just flew by me! And I almost always feel like that!! :) Before the 1st Quarter of this New Year Ends, I need to re visit my To Do List. This time I have way too many things left undone.

Hopefully noting down all that’s pending is going to help me organize my thoughts and avoid distractions. Before it gets too late and I have too many reminders pouring in from different sources via umpteen channels let me pin this up - the 1st Quarter ending TO DO List !

As a self made promise, I am going to come back and color code the executed items to Green! :)

Personal High Priority:

1: Follow Up on the Passport Name Change Application (cnt believe i waited 2 long yrs to get this done !! )

2: Purchase an External Portable HD

3: Finalize on a configuration for the Laptop and get it shipped

4: Back Up and Consolidate Data spread across 3 machines

5: Update my Address Book and Delete obsolete Mail Id’s

6: Share Seema’s Wedding Snaps with the GANG ! :)

Finance:

1: Deposit money in my PPF Account

2: Submit IT Proofs externally: Medical, LTA Bills & Investment Proofs

3: Validate the amount of Tax Paid this Financial Year and prepare to pay more or ask for returns

4: Review Investments made in Y07 and Plan Investments for Y08

5: Set aside Premium & PPF amounts for next year in a Liquid Scheme

6: Open a Joint Demat and a Savings account (again cnt believe we waited 2 long yrs ....!)

Health:

1: Polish my Teeth

2: Got to get my Eyes Checked

3: Weigh & Measure Up [last noted: Sat March 1st 2008, Wednesday Jan 16th]

4: If required, revisit the current exercise and diet regime

My Wardrobe:

1: Revamp my Wardrobe

2: Donate unused/illfitting clothes/accessories

3: Discard Old Cosmetics

Personal Low Priority:
1: Purchase New Bed/Coushion Covers

2: Retire the Old Curtains

3: Collect the Marriage/Reception Photo CD’s from Abhis Friend (again cnt believe i waited 2 long yrs .... done!) :)

4: Follow up with Abhis Friend for the Wedding/Reception CDs and the 2nd Anniversary PPT!

IBM Related:
1: Enroll and finalize on the Exam Date
2: Appear for the Certification Exam
3: Update my CV in the IBM format

Vodafone Related:
1: Surrender my Vodafone Official Cell Phone Plan and acquire a different Number
2: Back Up Data on My Vodafone Machine

:( thts a long list :( I got to get going ! :)
~ sayli :)

What's on my SOA Time Table...

The IBM SOA FOUNDATION is an integrated, open standards based set of

• Best Practices
• Patterns & SOA Scenarios
• IBM Software for SOA

to provide you with the architecture knowledge to get started with SOA.
The results of SOA Best Practices are:

• The SOA Life Cycle
• The SOA Reference Architecture
• The SOA Programming Model

The different Scenarios are as follows:

1 Service Creation
2 Service Connectivity
3 SOA Design
4 Process Scenario
5 BPM Scenario
6 Information as a Service
7 Interaction & Collaboration
8 SOA Security
9 SOA Governance

The IBM Software for SOA:

IBM SOA Foundation - Model Phase:
WebSphere Business Modeler
Rational Software Architect

IBM SOA Foundation: - Assemble Phase:
WebSphere Integration Developer
Rational Application Developer
Lotus Domino Designer
WebSphere Portlet Factory
Rational Tester for SOA Quality

IBM SOA Foundation - Deploy Phase:
WebSphere DataPower SOA Appliances
WebSphere Process Server
WebSphere ESB
WebSphere Message Broker
WebSphere Adapters
WebSphere Portal
WebSphere Application Server
WebSphere Extended Deployment
IBM Information Server
WebSphere Business Services Fabric
WebSphere MQ
Lotus Expeditor
FileNet P8

IBM SOA Foundation - Manage Phase:
Tivoli Access Manager
Tivoli Composite Application Manager for SOA
Tivoli Federated Identity Manager
Tivoli Provisioning Manager
WebSphere Business Monitor

Governance and Best Practices
WebSphere Service Registry and Repository

IBM SOA Foundation - Governance
WebSphere Service Registry and Repository
Rational Asset Manager
Tivoli Change and Configuration Management Database

I have started to demonstrate abilities to choose the right mix of Best Practises, Software and Scenarios to implement a SOA for any Enterprise. I need to refine my knowledge a lot more and hopefully the above contents will help me stay focussed and progress in the right direction to elevate my implementation skills.

Good Luc to all those whose share the same Vision as I do! :)

~ sayli :)

21 Days!! A Progress Report :):):)

Feb 29th Friday Day 1 : It took me half an hour just to get myself out of bed. But I did, thanks to Abhi :) he reminded me that I had pledged ! :) We joked a hell lot on that note :)

March 1st Saturday Day 2 : I walked a little more than the usual 5 Kms :) I do crazy things when Abhis not around! :) [He got out & returned before I did, since he works on saturday and for me its a holiday! :)]

March 2nd Sunday Day 3: Today I wasn't gonna be allowed to over stretch myself since my Fitness Instructor (read Abhi) accompanied me for good! :) The time spent sitting beside Abhi and watching the Sun come up admist tranquil greenery was a wondeful way to unwind post a long brisk walk and an almost perfect start to the day! I started to wonder why we choose to cuddle up and laze around in bed every Sunday Morning when we could have more fun outdoors! I look forward to many more such Sunday Mornings.

March 3rd Monday Day 4: Okay! So today I took about close to 15 mins to get out of bed ! :) Hopefully tomorrow would be a better story! I must honestly admit that my ankels are in pain and I hope to get a nice massage from Hubby deary only to start out on my "Jog a Lil Walk a Lil day" tomorrow! :) ;)

Drivers for using WebSphere Message Broker as an ESB

Typically, WebSphere Message Broker is used to integrate disparate systems. It is designed to transform any format of data between any type of application using any communications protocol or distribution method. It is used where there is a need for high-performance and complex integration patterns.

Consider the following reasons for using a WebSphere Message Broker as an ESB with WebSphere Process Server:

1: You are currently using WebSphere Message Broker and want to leverage existing skills.

2: You have extensive heterogeneous infrastructures, including both standard and non-standards-based applications, protocols, and data formats. For example, you are using industry formats such as SWIFT, EDI, or HL7.

3: You are implementing a wide range of messaging and integration patterns, for example, complex event processing and correlation, message splitting, and aggregation.

4: You need extensive pre-built mediation support.

5: Reliability and extensive transactional support are key requirements.

6: You want to achieve high-performance with horizontal and vertical scaling.

7: You want integration with other IBM WebSphere and Tivoli® products, as well as third-party JMS providers.

8: You want to natively transform non-XML formats without the use of adapters or user-written data transformations.

9: You want advanced publish and subscribe capabilities, including the use of a wide range of transports; high speed, low-latency messaging; and both topic and content-based routing.

10: You need complex event processing. Complex events are conditions that relate to multiple messages and are defined by applying a combination of logical, arithmetic, and temporal operators to messages or message attributes.

The IntelligentFilter and SituationManager SupportPac™ provides the ability to handle complex events that span multiple messages. Its complex event processing engine enables fast and reliable development of reactive applications, without requiring programming skills.

11: You want to integrate telemetry devices. WebSphere Message Broker can coordinate end-to-end telemetry integration. It can serve as a conduit for passing data from remote telemetry devices into enterprise applications.

Similarly, it can control data flow from command or control applications to remote control devices.

OSS - Operational Support Systems

Operations Support Systems (also called Operational Support Systems or OSS) are computer systems used by telecommunications service providers. The term OSS most frequently describes "network systems" dealing with the telecom network itself, supporting processes such as maintaining network inventory, provisioning services, configuring network components, and managing faults.

Operations Support System (OSS) performs management, inventory, engineering, planning, and repair functions for tele-communications service providers and their networks. For traditional telecom service providers, Operations Support Systems (OSSs) were mainframe-based systems designed to support telephone company staff members to automate their daily jobs such as order processing, line assignment, line testing and billing, etc.

Functions of an OSS solution may include the following components:

1: Order processing, accounting, billing and cost management
2: Network inventory, service provision, design and assign
3: Network discovery and reconciliation, trouble and fault management, capacity management
4: Network elements, asset and equipment management, field service management

A brief History of OSS Architecture:

A lot of the work on OSS has been centred on defining its architecture. Put simply, there are four key elements of OSS:
Processes : the sequence of events
Data : the information that is acted upon
Applications: the components that implement processes to manage data
Technology : how we implement the applications

During the 1990's, a 4-layer model of TMN was applicable within an OSS:

1: Business Management Level (BML)
2: Service Management Level (SML)
3: Network Management Level (NML)
4: Element Management Level (EML)

A fifth level is mentioned at times being the elements themselves, though the standards speak of only four levels.

To conclude, the OSS supports the traditional Resource and Resource Facing Service domains, whereas the BSS supports the more Customer Facing domains.

BSS - Business Support Systems

Business Support Systems (BSS) are the systems that a telephone operator or telco uses to run its business operations. The term BSS is no longer limited to telephone operators offering mobile to fixed and cable services but also can apply to service providers in all sectors such as utility providers.

Typical types of activities that count as part of BSS are taking a customer’s order, managing customer data, billing, rating, and offering B2B and B2C services. In summary, Business Support Systems (BSS) cover 4 main areas:

Product Management: Product management supports the sales and management of products, offers and bundles to businesses and mass-market customers. Product Management regularly includes offering cross-product discounts, appropriate pricing and customer loyalty programs.

Customer Management: Service Providers require a single view of the customer and regularly need to support complex hierarchies across customer-facing applications. Customer Management also covers requirements for partner management and 24x7 Web-based customer self-service.

Revenue Management: Revenue Management is a BSS focus on billing, charging and settlement that can handle any combination of OSS services, products and offers. BSS Revenue Management supports OSS order provisioning and often partner settlement.

Fulfillment Management: Fulfillment Management as part of assurance is normally associated with Operational Support Systems though Business Support Systems are often the business driver for Fulfillment Management and order provisioning.