soa总结1.htm

介绍了soa的一些情况

function Constellation(Births,B)
{
	//alert(Births.substring(0,1));
	var s = "<img width=15 height=15 src=" + HU + "images/" + GDI + "cnstl/z";
	switch(Births)
	{
	case 1:
		if(B>=21)
		{s+="11.gif alt=水瓶座";}
		else{s+="10.gif alt=魔羯座";}
		break;
	case 2:
		if(B>=20)
		{s+="12.gif alt=双鱼座";}
		else
		{s+="11.gif alt=水瓶座";}
		break;
	case 3:
		if(B>=21)
		{s+="1.gif alt=白羊座";}
		else
		{s+="12.gif alt=双鱼座";}
		break;
	case 4:
		if(B>=21)
		{s+="2.gif alt=金牛座";}
		else
		{s+="1.gif alt=白羊座";}
		break;
	case 5:
		if(B>=22)
		{s+="3.gif alt=双子座";}
		else
		{s+="2.gif alt=金牛座";}
		break;
	case 6:
		if(B>=22)
		{s+="4.gif alt=巨蟹座";}
		else
		{s+="3.gif alt=双子座";}
		break;
	case 7:
		if(B>=23)
		{s+="5.gif alt=狮子座";}
		else
		{s+="4.gif alt=巨蟹座";}
		break;
	case 8:
		if(B>=24)
		{s+="6.gif alt=处女座";}
		else
		{s+="5.gif alt=狮子座";}
		break;
	case 9:
		if(B>=24)
		{s+="7.gif alt=天秤座";}
		else
		{s+="6.gif alt=处女座";}
		break;
	case 10:
		if(B>=24)
		{s+="8.gif alt=天蝎座";}
		else
		{s+="7.gif alt=天秤座";}
		break;
	case 11:
		if(B>=23)
		{s+="9.gif alt=射手座";}
		else
		{s+="8.gif alt=天蝎座";}
		break;
	case 12:
		if(B>=22)
		{s+="10.gif alt=魔羯座";}
		else
		{s+="9.gif alt=射手座";}
		break;
	default:
		s="";
	}
	if(s!=""){s+=" align=absmiddle>";}
	return(s);
}

function DisplayBirthAnimal(BirthYear)
{
	var temp,t="<img width=15 height=15 src=" + HU + "images/" + GDI + "snxa/sx";
	BirthYear%=12;
	switch(BirthYear)
	{
		case 0: t+="9s.gif alt=申猴";break;
		case 1: t+="10s.gif alt=酉鸡";break;
		case 2: t+="11s.gif alt=戌狗";break;
		case 3: t+="12s.gif alt=亥猪";break;
		case 4: t+="1s.gif alt=子鼠";break;
		case 5: t+="2s.gif alt=丑牛";break;
		case 6: t+="3s.gif alt=寅虎";break;
		case 7: t+="4s.gif alt=卯兔";break;
		case 8: t+="5s.gif alt=辰龙";break;
		case 9: t+="6s.gif alt=巳蛇";break;
		case 10: t+="7s.gif alt=午马";break;
		case 11: t+="8s.gif alt=未羊";break;
		default: t = "";
	}
	if(t!=""){t+=" align=absmiddle>";}
	return(t);
}

function DisplayOfficerString(Officer)
{
	var t,n,f=0;
	var str="";
	t = Officer.split(",");
	for(n=0;n<=t.length;n++)
	{
		if(t[n]>=0 && t[n]<=5)
		{
			if(f == 0)
			{	f = 1;
				str += DEF_UserOfficerString[t[n]];
			}
			else
			{
				str += "," + DEF_UserOfficerString[t[n]];
			}
		}
	}
	var re = /(,)/gi;
	str = str.replace(re,"<br>&nbsp; &nbsp; &nbsp; ");
	return(str);
}

function htmlencode(str)
{
	var re = /(<)/gi;
	var rv = str.replace(re,"&lt;");
	re = /(>)/gi;
	rv = rv.replace(re,"&gt;");
	re = /(\")/gi;
	rv = rv.replace(re,"&quot;");
	return(rv);
}
//-->
</SCRIPT>

<SCRIPT language=javascript>ds(87471,0,0,"20051229152623",457,"光哥",192,"",3,7,"",547,"0",1572954,"","20031020143656","密","20060108201243",481,"../images/upload/face/2004/05/11/4210537500000.gif",65,65,2,"19750106000000",1,"",0,0,0);
</SCRIPT>
<BR><SPAN style="LINE-HEIGHT: 15pt"><B>原创－SOA架构与业务支撑系统规划设计</B><BR><BR>
<TABLE style="LINE-HEIGHT: 15pt" cellSpacing=0 cellPadding=0 width="100%" 
border=0>
  <TBODY>
  <TR>
    <TD><SPAN 
      style="FONT-SIZE: 12px">这些天终于暂时把手头上的事情放下来，看了看网上的帖子，发现有些网友们开始讨论关于SOA架构在新建业务支撑系统中的应用之类的话题，说实话，看完了这些帖子后我忍不住想站出来谈一下自己在这方面的体会，在我参加的项目规划过程当中，我发现在谈这个话题的时候，无论是推SOA的厂家，诸如BEA, 
      IBM等，还是实际做业务支撑系统系统集成商，都有着一些思想的误区，厂家们往往拼命强调SOA架构的好处，但是并没有告诉用户SOA架构的业务支撑系统应该是什么样子，包括哪些技术要素？而集成商往往对业务支撑系统本身非常熟悉，但是谈到SOA往往想到的只是服务组装，而到底怎么进行服务组装，而服务组装是不是又是SOA的全部内涵呢，又是不得而知的答案。所以往往在这个过程当中，我们发现SOA和BOSS本身总是脱离的，很难用BOSS的语言谈SOA，这也是有些运营商听了很多次SOA都记不住的最主要原因。<BR>这里我就不对SOA的概念进行介绍了，权当大家都对SOA有了一般的了解。下面谈一下我在这方面的一些只言片语的理解，希望大家一起讨论。首先我觉得SOA并不是一种现成的技术，而是一种架构和组织IT基础结构及业务功能的方法，是一个能够长期指导业务系统规划开发的方法， 
      SOA并不仅仅是一种开发方法，它还具有管理上的优点。例如，现在管理员可直接管理开发人员所构建的相同服务，这远胜于以往管理单个应用的方式。通过分析服务间的交互，SOA可以帮助运营商了解何时以及为什么业务逻辑被切实执行了，这使管理员或系统分析师能够有针对性的优化现有的业务流程。可以说采用SOA架构的业务支撑系统的最终蓝图将是模块化，流程驱动，多种渠道统一访问，业务过程实时监控，有着统一开发部署技术体系和安全管理的系统。画出来就是一副细化了的包含业务功能模块和管理数据对象的业务支撑系统应用服务图（Telecom 
      Application Map）<BR>通常我们谈SOA，大家印象最深的就是”服务”, 
      正因为很多人认为“服务”的封装，编排就是SOA，所以导致很多运营商和集成商对其没有太多兴趣，也一直认为SOA架构短期内不适合，其实真正SOA的内涵是一套完整全新的IT架构设计思想，如果按照生命周期来划分，SOA应用的生命周期分为开发、集成、编排、访问、分析、实施、管理、安全八大环节，每个环节都有其专门的技术理念，有些环节还有相应推荐的技术标准。而对电信行业的业务支撑系统来说，也应该从这八个环节来考虑系统的各个阶段规划设计，这才是SOA的精髓所在，如果把这八个环节的内容都变成业务支撑的语言，那么SOA才能被广泛采纳。<BR><BR>未完待续<BR><BR><BR>光哥意见，仅供参考！<BR></SPAN></TD></TR></TBODY></TABLE></SPAN><BR><BR>[ 
<FONT class=GrayFont color=#888888>这个贴子最后由光哥在2006-1-6 17:11:31编辑过</FONT> ]&nbsp; 
&nbsp;<BR><IMG height=2 src="SOA总结1.files/blank.gif" width=2> 
</TD></TR></TABLE></TD></TR></TABLE>
<SCRIPT language=javascript>ds(87481,87471,0,"20051229161351",6,"光哥",192,"",3,7,"",547,"0",1572954,"","20031020143656","密","20060108201243",481,"../images/upload/face/2004/05/11/4210537500000.gif",65,65,2,"19750106000000",1,"",0,0,0);
</SCRIPT>
<BR><SPAN style="LINE-HEIGHT: 15pt">
<TABLE style="LINE-HEIGHT: 15pt" cellSpacing=0 cellPadding=0 width="100%" 
border=0>
  <TBODY>
  <TR>
    <TD><SPAN 
      style="FONT-SIZE: 12px">&nbsp;原创－SOA架构与业务支撑系统规划设计之二<BR><BR><BR>通常我们谈SOA，大家印象最深的就是”服务”, 
      正因为很多人认为“服务”的封装，编排就是SOA，所以导致很多运营商和集成商对其没有太多兴趣，也一直认为SOA架构短期内不适合，其实真正SOA的内涵是一套完整全新的IT架构设计思想，如果按照生命周期来划分，SOA应用的生命周期分为开发、集成、编排、访问、分析、实施、管理、安全八大环节，每个环节都有其专门的技术理念，有些环节还有相应推荐的技术标准。而对电信行业的业务支撑系统来说，也应该从这八个环节来考虑系统的各个阶段规划设计，这才是SOA的精髓所在，如果把这八个环节的内容都变成业务支撑的语言，那么SOA才能被广泛采纳。<BR>首先来谈谈SOA架构中大家最关心的“服务”, 
      SOA本身的定义就是面向服务的架构，而什么才是业务支撑系统中的“服务”呢，这个问题如果搞不清楚，SOA就无从谈起了。因为SOA中对服务的封装的意义在于对服务的编排进而行程业务流程，业务支撑系统当中的服务应当确定为业务组件更为贴切。那么举例说明一下，在业务支撑系统当中，存在着很多的流程，有的是面向客户的，有的是面向网元的，有的是纯粹后台的，在寻找定位“业务组件”之前，应该首先定义业务支撑系统当中的功能域，明确定义每个功能域内功能模块的范围，然后进一步细化每个功能域的功能点，按照功能域和业务类型进行流程的分类；按照业务部门提出的业务流程去定位每个业务流程当中调用的具体功能点，对各个业务流程中操作的数据进行归纳汇总； 
      基于流程分析的结果定义可重用的业务组件以及组件的相关属性如返回值、参数和异常。<BR>这里我们将服务改成为业务组件，它是基于商务对象的原子操作。如创建客户资料、改变服务状态、查询服务状态等原子功能可以组装在等多个流程中。所以我们看到业务组件实际上包括两个最重要的含义，一个是“操作”，一个是操作的“数据”，举一个实际的例子，在一个停开机业务当中，有如下的步骤，首先根据号码查询客户的基本资料；检查客户的服务产品关系状态；根据用户所选择的鉴权方式检查用户的密码或者证件号码。如果鉴权通过才允许办理业务；选择停机类型或者开机类型，进行逻辑检查；生成新的订单资料；更新服务产品关系表的状态和停机锁字段；登记工单服务状态变更明细；更新服务产品停机时间表的相应字段。在这个过程中，我们看到每个步骤都是一个功能点，都是一个对某个数据的操作，因此这些就是我们要寻找的原子服务，或者说是业务组件。而每个业务组件也都会出现在其他业务流程当中，也就是可以被重用的组件。<BR><BR>关于业务组件的分类和封装以及分层管理，先不说了，我先去赴一个饭局。<BR>未完待续！<BR><BR>光哥意见，仅供参考！<BR></SPAN></TD></TR></TBODY></TABLE></SPAN><BR><BR>[ 
<FONT class=GrayFont color=#888888>这个贴子最后由光哥在2006-1-6 17:12:31编辑过</FONT> ]&nbsp; 
&nbsp;<BR><IMG height=2 src="SOA总结1.files/blank.gif" width=2> 
</TD></TR></TABLE></TD></TR></TABLE>
<SCRIPT language=javascript>ds(87596,87471,0,"20051230142655",3,"光哥",192,"",3,7,"",547,"0",1572954,"","20031020143656","密","20060108201243",481,"../images/upload/face/2004/05/11/4210537500000.gif",65,65,2,"19750106000000",1,"",0,0,0);
</SCRIPT>
<BR><SPAN style="LINE-HEIGHT: 15pt">
<TABLE style="LINE-HEIGHT: 15pt" cellSpacing=0 cellPadding=0 width="100%" 
border=0>
  <TBODY>
  <TR>
    <TD><SPAN 
      style="FONT-SIZE: 12px">&nbsp;原创－SOA架构与业务支撑系统规划设计之三<BR><BR><BR>上个帖子写了一下对原子服务，或者称之为业务组件进行了描述，那么实际上对于SOA架构下的业务支撑系统来说，就要求开发商把系统的功能原子化，在SOA的原则当中，重点强调的是服务的可重用性。将应用逻辑代码和接口代码分离，便于对任何一个原子服务进行接口封装和调用，只有这样才能做到服务的可重用性。<BR>例如在现有大多数的营销系统中，“客户服务功能修改”功能可以由“客户信息装载”、“服务功能修改”、“工单数据生成”、“相关数据处理”四个“原子服务”完成，通过将这四个“服务”连接，就实现了“客户服务功能修改”的业务功能。也许业务规则会发生变化，比如，要求在“服务功能修改”之前先检查该客户的信用，应用的修改只要在流程中插入“客户信用检查”，形成“客户信息装载”、“客户信用检查”、“服务功能修改”、“工单数据生成”、“相关数据处理”的新流程，就满足业务部门的要求了。另一方面，其他的业务流程也可以调用“客户信息装载”等“原子服务”，组成其他的业务流程。系统的灵活性还表现在“服务”本身的修改上，只要“服务”的接口定义不变，“原子服务”本身的代码修改和功能实现的改变对业务服务流程都可以不产生影响。<BR>在这里之所以将SOA中的服务称之为原子服务，是因为在实际的业务支撑系统当中，一个原子服务是可以被多个流程所调用，例如一个检查客户信息状态的原子服务就会出现在多个业务流程当中。而几个原子服务打包能成为一个“服务”，例如上面所说的由四个原子服务组成的“客户服务功能修改”这个服务，如果对里面的四个子服务不作修改，那么这个服务就可以被其他流程直接调用。<BR>其实如果将NGOSS 
      TNA的思想和SOA结合在一起，我们会发现其实很多地方有着共性，那么我就利用我的理解用对业务支撑系统当中的业务组件管理做一个说明，如果结合二者的话，最理想的情况应该是在业务支撑系统的当中形成一个基础技术平台，这个层面负责业务组件的封装和组合，基础技术平台层内部应该建设一个业务组件的Pool，负责业务组件的分类层级管理，对所有的业务组件行程注册，登记，发布，修改，撤销，集成的功能，将所有的原子服务在一个Pool里面进行管理，而对于电信行业业务支撑系统来说，这种业务组件的管理应该有其行业特点。这里我个人认为应该将功能域的思想继续延伸下去，对业务组件进行分类，可以按照功能域分成客户类组件、帐务类组件、产品类组件、服务类组件以及界面类组件等等，按照业务和功能类型进行业务组件的一套完整生命周期管理。上述的组件都是指的SOA中的服务。这些组件的分类组件位于组件Pool的上层，下一层就是最基础的业务组件，也就是原子服务，即那些最小化不可分割的业务操作，例如查询客户信息，检查客户状态等等原子服务。这些原子服务的业务组件可以打包成为上面的分类业务组件<BR>总结起来，就是通过业务组件管理Pool，对原子服务组件进行分类定义，按照管理对象进行分类，定义原子服务组件之间的关系, 
      定义原子功能的操作权限，定义组成原子服务组件的基础技术组件（与业务无关），提供可视化的管理工具定义原子功能。<BR>那么说了这么多，是不是所有的业务支撑系统的功能点都能打包成为服务或者原子服务呢？我个人认为不是，这也就是为什么说SOA不是万能的原因，那么什么样的原子功能可以被封装，什么不适合，其实是跟实现业务流程的工作流技术分不开的，这也是SOA里面封装服务后要做的下一步重要工作。今天有点累了，先写到这里，我想下篇就这个问题分析一下。再之后开始进入另外一个新的SOA与BOSS结合的一个领域BAM.<BR>由于我写的是帖子，所以是想到哪里就写到哪里，可能大家看起来没什么条理，其实我也是把自己的一些体会在慢慢整理的过程中，希望和大家一起进步！<BR><BR>光哥意见，仅供参考！<BR></SPAN></TD></TR></TBODY></TABLE></SPAN><BR><BR>[ 
<FONT class=GrayFont color=#888888>这个贴子最后由光哥在2006-1-6 17:13:53编辑过</FONT> ]&nbsp; 
&nbsp;<BR><IMG height=2 src="SOA总结1.files/blank.gif" width=2> 
</TD></TR></TABLE></TD></TR></TABLE>
<SCRIPT language=javascript>ds(87795,87471,0,"20051231161007",1,"光哥",192,"",3,7,"",547,"0",1572954,"","20031020143656","密","20060108201243",481,"../images/upload/face/2004/05/11/4210537500000.gif",65,65,2,"19750106000000",1,"",0,0,0);
</SCRIPT>
<BR><SPAN style="LINE-HEIGHT: 15pt">
<TABLE style="LINE-HEIGHT: 15pt" cellSpacing=0 cellPadding=0 width="100%" 
border=0>
  <TBODY>
  <TR>
    <TD><SPAN 
      style="FONT-SIZE: 12px">&nbsp;原创－SOA架构与业务支撑系统规划设计之四<BR><BR><BR>今天是2005年最后一天，现在的公司办公室没什么人，大家基本都回家了，留下无事的我，就续写一下吧。昨天花了一些篇幅把我个人对业务支撑系统中的SOA“服务”的理解说了一下，我这个帖子是把过去的思想心得做了总结，所以我不会象那些专业推广SOA厂家那些有条理的讲SOA的过程和原理，只是把我认为SOA思想当中能跟业务支撑系统有着紧密结合的部分说一下。<BR>从前面我提到过的SOA生命周期当中，开发、集成、编排、访问、分析、实施、管理、安全当中，前面我说到了自己对原子服务封装和服务组装的一些看法。那么下面继续这个话题讨论。<BR>在业务支撑系统的基础技术平台上，可以构建一个业务组件的Pool，或者说是服务和原子服务的管理库，分两个层面对业务流程当中每个不可继续分割的业务操作(有动作，有数据)进行了业务组件的封装，通过统一接口的expose，可以实现服务和原子服务的可重用性。<BR>那么有了基础的业务组件管理库，有了封装和可以组合的服务了，下一步就是编排的工作，在这里不可避免的就会提到一种技术就是工作流技术，工作流技术在这两年也是各个咨询公司和中间件厂家广泛推广的技术。<BR>在业务系统中，通常通过控制后台系统资源满足前端用户的业务需求。通过核心业务逻辑的实现可以完成这些功能。在很多传统的系统中，业务支持的部分与资源控制的部分经常混合在一起，业务流程与业务功能完全淹没在技术实现的细节中，在业务变迁或新业务出现的情况下，实际上要付出相当大的努力，才能提供新的业务功能，很难满足业务部门快速推出新服务。<BR>根据SOA的理念，对核心业务处理逻辑进行分离，因此结合业务组件库的分层管理原则，可以让不同功能去调用不同层次的业务组件，可以分解为两部分，一部分为面向业务，面向用户的层次，主要使用封装的业务组件，提供对最终业务流程，业务功能的支持，一部分为面向系统资源的资源访问层次和基础业务组件（原子服务），主要提供对最终技术实现资源的支持。这两部分逻辑有着不同的特点和业务处理要求。业务流程/功能层的特点是面向业务和用户，功能复杂，变化快，对灵活性的要求很高。而资源访问层相对来说比较稳定，功能较简单。通过进行功能的分离，就可以把变化的部分和不变的部分拆分开来。资源访问层成为基本组件，在业务流程/功能层通过组合和包装的方式构造最终的业务组件。<BR>但是在整个业务支撑系统当中，有一个非常重要的问题，也是我最近一直困惑的一个问题，也就是在原子服务定义封装形成Pool后，是不是用工作流引擎去使用所有的服务实现业务流程呢？答案显然是否，因为如果所有的业务流程都利用工作流引擎来实现，系统效率将非常成问题，而且大规模的改革也会导致管理的混乱。<BR>首先业务支撑系统当中有些功能模块是不适合用工作流技术的，例如计费系统，计费系统的工作流程象是一个流水线，从采集，预处理，查重，分拣，披价。。。到帐务处理，也包含了很多功能模块，但是即使我们细化了原子服务也会发现，这里面的原子服务的重用意义很小，因为计费里面的功能点基本都是给计费系统这个固定流程的系统用的，是一套标准化的直线业务流程。<BR>此外那些还有一些模块也不适合用工作流技术，但是在服务库形成后，如何划分业务支撑系统的工作流应用范围是现在运营商关心的一个问题，我最近参与的一个项目也恰好要考虑这个，不知各位大侠能否给小弟提点建议。<BR>因为我一向本着不讲产品不做广告的原则，所以我在这里就不讲工作流技术了，但是稍微想说的是，在NGOSS 
      TNA里面对电信业务系统的工作流倒是了一些建议，尤其是提出的Contract 
      的概念，跟SOA只对服务封装相比，更强调组件和组件之间交互的过程和标准化管理，对接口的定义管理做了非常细致的工作，也是工作流技术在电信企业应用时候的重要参考。<BR>并且NGOSS里面也推荐了业务支撑系统当中使用工作流技术的四个周期，从业务设计到查询，从流程执行到流程管理的四个标准，BPML, 
      BPQl, 
      BPEL,BPMN，由于这四个标准当中有些特性对于业务支撑系统的业务流程设计执行有着相应的优势。<BR>这里因为篇幅关系，不对这四个标准做介绍了。今天就说到这里吧，祝大家新年快乐！ 
      我会在元旦期间续写。<BR><BR>光哥意见，仅供参考！<BR></SPAN></TD></TR></TBODY></TABLE></SPAN><BR><BR>[ 
<FONT class=GrayFont color=#888888>这个贴子最后由光哥在2006-1-6 17:14:42编辑过</FONT> ]&nbsp; 
&nbsp;<BR><IMG height=2 src="SOA总结1.files/blank.gif" width=2> 
</TD></TR></TABLE></TD></TR></TABLE>
<SCRIPT language=javascript>ds(87849,87471,0,"20051231233841",4,"llandyl",2124,"",3,4,"",22,"0",88982,"","20040814101220","密","20060105173045",81,"",90,90,0,"0",1,"",0,0,1);
</SCRIPT>
<BR><SPAN style="LINE-HEIGHT: 15pt">
<TABLE style="LINE-HEIGHT: 15pt" cellSpacing=0 cellPadding=0 width="100%" 
border=0>
  <TBODY>
  <TR>
    <TD><SPAN style="FONT-SIZE: 12px">欢迎继续SOA生命周期当中 
      开发、集成、编排、访问、分析、实施、管理、安全等内容。</SPAN></TD></TR></TBODY></TABLE></SPAN><BR><IMG 
height=2 src="SOA总结1.files/blank.gif" width=2> 
</TD></TR></TABLE></TD></TR></TABLE>
<SCRIPT language=javascript>ds(87859,87471,0,"20060101080456",5,"John",679,"",87,3,"",63,"0",105775,"","20040324230810","密","20060102070353",62,"",65,65,2,"0",0,"",0,0,0);
</SCRIPT>
<BR><SPAN style="LINE-HEIGHT: 15pt">
<TABLE style="LINE-HEIGHT: 15pt" cellSpacing=0 cellPadding=0 width="100%" 
border=0>
  <TBODY>
  <TR>
    <TD><SPAN 
      style="FONT-SIZE: 12px">光哥对在业务支撑系统中使用SOA的见解很有深度。我认为对SOA的应用的讨论很有必要。SOA是IT架构发展的必然趋势。但错误的、盲目的使用SOA的后果会和错误的、盲目的使用EAI的后果类似：不仅劳民伤财，还会影响运作。<BR><BR>我想从以下几个方面谈一下我的看法。但因为我的中文打字太慢，我把它分成几个帖子，等有时间逐一献丑。但欢迎诸位各抒己见—或许我都不必写我的帖子了。<BR><BR>1． 
      &nbsp; &nbsp; &nbsp;SOA中有哪些优势是被证实的（有哪些是未被证实的）<BR>2． &nbsp; &nbsp;